Who actually writes AI policy when a phone call outweighs an executive order

There is a version of AI policy that lives in official documents. Executive orders, regulatory frameworks, ministerial white papers. It has the right tone. It cites research. It gets announced at summits.

Then there is the version that actually happens.

Earlier this year, a US executive order on AI safety was pulled at the last minute. Not through a formal legislative process. Not because new evidence changed the calculus. Reports pointed to direct calls from a small number of influential tech figures to the White House. The order did not survive the weekend.

I am not writing this to relitigate that specific decision. I am writing it because of what it reveals about the structure underneath. When a handful of founders can override a sitting government's policy position with a phone call, the formal governance layer stops being the actual governance layer. It becomes the visible layer. The real decisions are happening somewhere else.

This is not new. But AI makes it sharper.

Industry has always lobbied government. That is not a scandal; it is how representative systems work in practice. What is different with AI is the concentration and the speed.

A handful of companies control the frontier model infrastructure that governments, militaries, hospitals, and financial systems are now building on top of. Those companies are run by a small number of people who have, in several cases, direct personal relationships with heads of state. The lag between a technology entering critical infrastructure and a government understanding it well enough to regulate it has never been wider.

So you get a structural imbalance. The people who know the technology best are the people who profit from it most. The people who write the regulations often do not use the products day to day. Consultations happen, but the information asymmetry does not close.

This is not unique to the US. The EU's AI Act took four years to pass. In that window, foundation models went from a research curiosity to the backbone of commercial software at scale. By the time the ink was dry, the landscape the Act was written for had already changed.

What agencies and product teams actually feel

I want to bring this closer to ground level, because this is not just a story about Washington or Brussels.

Every agency and product team building on AI right now is operating in a policy environment that can shift without notice. Safety guidelines that existed last quarter may not exist this quarter. Deployment requirements that seemed fixed are being renegotiated in real time by people whose names do not appear in the official consultation documents.

That has a practical effect on how you build.

We have had clients pause projects because a regulatory requirement they had planned around was suddenly uncertain. We have had others accelerate because a restriction they expected to face was quietly dropped. Neither outcome was the result of their own planning. Both were the result of decisions made above the waterline of public policy, by people they will never meet.

The honest response to that is not panic. It is to build in a way that does not depend on any single regulatory interpretation being stable. That means keeping your architecture modular enough to swap providers. It means not hard-coding compliance assumptions into your product logic. And it means treating governance documentation as a live artifact, not a project deliverable you finish and forget.

The optimistic reading, and why I am only half convinced by it

There is a case to be made that informal power channeled through people who understand the technology is better than formal regulation written by people who do not. That a founder calling the White House to flag a technically illiterate policy provision is a feature, not a bug.

I understand the argument. Some AI safety proposals have been written with so little technical grounding that compliance would have been performative at best and actively counterproductive at worst. If a phone call prevents a bad rule from becoming law, maybe the outcome is fine even if the process is not.

But the process matters independently of any single outcome. A governance system that works because the right person happened to make the right call this time is not a system. It is luck. And it scales in exactly the wrong direction. As AI capability increases and the stakes of each decision rise, you want more structural accountability, not less. What we have now is the opposite trajectory.

The other problem is selectivity. Informal power does not advocate for all stakeholders equally. It advocates for the people who have the access. A small startup without a direct line to a head of state is subject to whatever policy survives those calls. A hospital system deploying AI diagnostics has no seat at that table. A city government trying to procure AI tools for public services is reading the same press release the rest of us are, after the decision is made.

What this means for how we work

At Studio Hyra we work with founders and product teams who are building things that matter on top of AI infrastructure they do not fully control, inside a regulatory environment they cannot fully predict. That is just the condition. The question is how to work well inside it.

A few things we have found useful.

Separate your risk layers. Regulatory risk and model risk are not the same thing. A policy change that affects your deployment approach is a different problem from a model update that changes your output behavior. Treat them separately in your architecture and in your planning.

Do not optimize for the current policy state. Build for the principle behind the policy, not the specific provision. If the underlying concern is user privacy, design for privacy in a way that survives whatever the regulation ends up saying. Rules change. The concern that generated them usually does not.

Pay attention to the informal layer. This is slightly uncomfortable advice, but it is honest. Read what the major lab founders are saying in interviews and on social platforms. Not because they are always right, but because their stated positions tend to predict where policy will land before the formal documents catch up. It is an imperfect signal. It is still a signal.

Build relationships with your own policy environment. If you are deploying AI in a regulated sector, your legal and policy context is as much a part of your product environment as your API stack. The teams that treat it that way are less likely to be caught flat-footed when something shifts.

None of this is a solution to the structural problem. The structural problem is real and I do not think any agency or product team fixes it from the inside. But you can build in a way that does not pretend the structure is more stable than it is.

The question worth sitting with

We are at a point where AI policy is being written by a combination of formal process and informal pressure, in proportions that are not publicly legible. That is uncomfortable. It is also, for now, the actual situation.

The more useful question is not who should have power over AI governance in an ideal world. It is what posture makes sense for builders, product leaders, and agencies operating in the world as it is. My answer is: stay technically literate, stay structurally flexible, and do not confuse the published policy with the whole story.

The phone calls were always happening. We are just paying closer attention now.