President Trump has delayed signing an executive order aimed at tightening AI security, choosing not to move forward with a draft that would have required pre-release government security reviews of AI models. The decision, according to comments associated with the delay, was driven less by opposition to the general idea of oversight and more by dissatisfaction with the language in the order—an explanation that, while seemingly narrow, points to a much bigger issue in AI governance: how policy is written can determine whether it becomes enforceable, workable, and effective—or whether it stalls in legal and bureaucratic limbo.
The draft order’s core concept was straightforward enough on paper. Before certain AI models could be released, the government would conduct security reviews designed to identify risks—particularly those tied to misuse, vulnerabilities, or capabilities that could be leveraged for harmful purposes. In practice, however, “pre-release review” is not a single policy lever. It is a whole system: definitions of what counts as a model subject to review, thresholds for triggering oversight, timelines for evaluation, standards for risk assessment, and the question of who gets to decide what “safe enough” means. When any of those pieces are unclear or contested, the order can become difficult to implement quickly, and difficult to defend legally.
Trump’s stated concern about the wording suggests that the administration may have concluded that the draft’s phrasing could create unintended obligations or operational bottlenecks. That matters because AI development moves fast. If a review process is too slow, too broad, or too ambiguous, it can effectively function as a de facto moratorium—whether or not that was the intent. On the other hand, if the language is too vague, it can fail to produce consistent outcomes, leaving companies uncertain about compliance and regulators without clear authority.
In other words, the delay is not just about one document. It’s about the architecture of oversight itself.
A policy fight over definitions, not goals
AI security oversight often sounds like a technical problem—how do you evaluate models for risk?—but it is frequently a legal and administrative problem first. The phrase “pre-release government security reviews” raises immediate questions that lawmakers and agencies must answer in plain terms:
What qualifies as an “AI model” for the purpose of review?
Does it include open-source weights, fine-tuned derivatives, or only frontier systems?
Are reviews triggered by capability level, intended use, training data characteristics, or something else entirely?
Who determines the threshold—an agency, a panel, or a delegated office?
What is the scope of the review: cybersecurity risks, dual-use concerns, privacy issues, or broader safety hazards?
What happens if a model fails review—can it be blocked, delayed, or required to undergo changes?
Even if the administration agrees with the general objective—reducing the chance that dangerous systems reach the public unchecked—the draft language may have been insufficiently precise. Or it may have been precise in ways that the administration found unacceptable. For example, some versions of AI oversight proposals have been criticized for being overly expansive, capturing too many systems and creating a compliance burden that smaller developers cannot meet. Others have been criticized for being too narrow, leaving gaps where the most consequential models slip through.
Trump’s comment that he didn’t want to “get in the way” of the work going on in this area reads like a signal that the administration wants to avoid disrupting ongoing efforts—whether those are internal government initiatives, interagency coordination, or private-sector security practices. But the same statement also implies that the draft order, as written, risked interfering with the pace or direction of that work. That is a subtle but important distinction. It suggests the administration is not rejecting oversight; it is rejecting the mechanism as currently drafted.
Why “language” can be the whole ballgame
When presidents delay executive orders over “language,” it can sound like political theater. Yet in governance, wording is often destiny. Executive orders are not statutes, but they still carry legal weight. They direct agencies to act, allocate responsibilities, and establish processes that can later be challenged in court or used as a basis for enforcement.
If the draft order used ambiguous terms—such as undefined categories of models, unclear standards for “security,” or vague timelines—agencies might struggle to implement it consistently. Companies, meanwhile, would have trouble predicting whether they are subject to review, what documentation they must provide, and how long the process will take. That uncertainty can lead to two outcomes that policymakers generally want to avoid: either companies delay releases to hedge against regulatory risk, or they release anyway and hope enforcement never comes.
There is also the question of how the order interacts with existing authorities. The U.S. already has a patchwork of frameworks touching cybersecurity, export controls, procurement rules, and sector-specific regulations. A new executive order that overlaps awkwardly with existing regimes can create confusion. If the draft language didn’t align cleanly with current legal authorities, the administration may have decided it was safer to pause than to sign something that would trigger months of implementation disputes.
Another possibility is that the draft language could have created an expectation of pre-release review that agencies cannot realistically deliver at scale. Government security reviews require expertise, time, and access to model details. If the order implied a level of review capacity that the government does not have, the result could be delays that harm both safety and innovation. In that scenario, the administration might prefer to revise the language to better match operational reality—perhaps by narrowing scope, adjusting thresholds, or clarifying that reviews would focus on specific risk categories rather than attempting to evaluate every aspect of a model.
The tension between speed and scrutiny
AI security oversight is often framed as a tradeoff between safety and innovation. But the real tension is between speed and scrutiny—and the difference is crucial. Innovation doesn’t necessarily require releasing everything immediately. Many responsible development pipelines already include internal red-teaming, vulnerability testing, and risk assessments. What governments add is external validation and accountability, especially when models could be used for harmful purposes.
Pre-release review, however, introduces a new variable: time. If the review timeline is too long, it can discourage developers from engaging with the process. If it is too short, it can become superficial. If it is unclear, it becomes unpredictable.
That unpredictability is exactly what companies hate. It makes planning impossible and can push developers toward either over-compliance (submitting far more than necessary) or under-compliance (submitting too late or not at all). Either approach undermines the goal of targeted, effective oversight.
By delaying the order, the administration appears to be buying time to refine the mechanism so it can be implemented without turning into a bottleneck. The emphasis on language suggests that the draft may have failed to strike the right balance between clarity and flexibility—between what must be done and what can be adapted case by case.
What “pre-release review” could look like in a revised form
While the full details of the draft order are not provided here, the logic of the delay points toward likely revisions. If the administration wants to keep the concept but fix the problems, the next draft could include changes such as:
Clearer triggers for review
Instead of reviewing broadly, the order could define specific categories of models based on capability thresholds, intended deployment contexts, or risk profiles. This would reduce the number of systems subject to review and make the process more manageable.
Defined timelines and escalation paths
Agencies might be directed to complete reviews within set time windows, with explicit procedures for extensions, appeals, or conditional approvals. Without this, pre-release review can become an open-ended waiting game.
More precise standards for what constitutes “security”
Security reviews could be limited to particular risk dimensions—such as cyber vulnerabilities, model behavior that enables wrongdoing, or susceptibility to exploitation—rather than a catch-all evaluation that no agency can fully perform.
A clearer division of responsibilities
If multiple agencies are involved, the order could specify who leads, who supports, and how decisions are coordinated. Interagency ambiguity is a common reason policies stall.
Better alignment with existing authorities
The revised language could ensure the order complements current frameworks instead of duplicating or conflicting with them.
A more realistic compliance pathway
The order might include guidance on what information companies must provide, how confidentiality is handled, and how results are communicated. Without these details, companies may resist participation or flood agencies with inconsistent submissions.
These are not minor edits. They are structural changes. And they are exactly the kind of changes that can require time—especially if the administration wants to avoid signing something that will be criticized as unworkable or legally vulnerable.
The unique challenge of AI security reviews
Security reviews for AI are not like security reviews for traditional software. Models are not static binaries. They can be updated, fine-tuned, and deployed in countless configurations. Even if a government review evaluates a model at one point in time, the model’s behavior can shift after release due to additional training, prompt engineering, or integration into different systems.
That creates a governance dilemma: pre-release review can reduce risk, but it cannot guarantee safety across all future uses. So the policy must decide what it is trying to accomplish. Is it meant to prevent the most dangerous models from reaching the public? Is it meant to require mitigation steps before release? Is it meant to create a baseline of accountability and transparency?
If the draft order’s language implied a stronger guarantee than the government could realistically provide, that could be another reason for delay. Policymakers often underestimate how hard it is to translate “review” into measurable outcomes. The revised language may need to set expectations appropriately—focusing on risk reduction and mitigation requirements rather than promising absolute safety.
Meanwhile, the private sector is not standing still. Many companies already run internal evaluations and publish safety commitments. Some have adopted red-teaming practices, model cards, and usage policies. But voluntary measures vary widely. Government oversight is attractive precisely because it can standardize expectations and create consequences for noncompliance. The challenge is designing oversight that is rigorous without being so heavy-handed that it becomes impractical.
Why the delay may still be a signal of seriousness
It would be easy to interpret