The Voluntary 30-Day AI Review Is a Procurement Signal, Not a Compliance Checkbox

On June 2, 2026, President Trump signed an executive order titled "Promoting Advanced Artificial Intelligence Innovation and Security," asking AI companies to voluntarily hand their most powerful models to the government for testing up to 30 days before public release (NPR). An earlier draft gave reviewers 90 days. Lobbying cut it to 30. Within a week, a predictable wrong question lands on procurement desks: are our AI vendors compliant with the new review?

There is no "compliant" to be. The order explicitly bars any mandatory licensing, preclearance, or permitting for the development, release, or distribution of new AI models (OPB). The review is voluntary by design, which reframes the entire thing for anyone buying frontier models. You cannot audit a vendor against it. What you can do is read a vendor's participation as a procurement-risk signal, then close the gap it leaves with contract language. That single distinction is the spine of everything below.

What the order actually does, and what it does not guarantee

Read literally, the order creates a channel, not a control. It gives the government access to designated models for "up to 30 days" before the developer shares them with trusted partners, down from the 90-day window in an earlier proposal (A&O Shearman). Agencies have 60 days to design the voluntary framework and the classified benchmarking criteria, with the Treasury Department forming an "AI cybersecurity clearinghouse" alongside NSA, CISA, and NIST (Federal News Network).

For a buyer, the operative limits matter more than the headline. The framework applies only to models representing "a meaningful step-change in cyber capabilities," not incremental version updates (Federal News Network). The models are tested in classified environments (Nextgov). So the review is short, optional, government-facing, scoped to a narrow class of releases, and conducted where you will never see a result.

Each of those limits maps onto a different control in your program. A 30-day ceiling makes the evaluation a snapshot rather than continuous monitoring, so its assurance expires the moment the model is patched. Because the scope is confined to step-changes, the everyday production model you license usually sits out of frame entirely. And testing inside a classified setting leaves no report to attach to a vendor file, no findings to reconcile against a SOC 2 exception register, and nothing your auditor can sample. Without an artifact, the control fails sampling and gets written up as an exception.

The review window covers a step-change frontier release. The model you actually deploy is almost always an incremental successor or a fine-tuned enterprise variant that never entered the 30-day channel at all. "The vendor participates" is not the same fact as "this model was reviewed."

How to weigh participation in diligence

When there is no regulatory floor, the voluntary designation becomes the floor. Buchanan Ingersoll's analysis of the order is blunt about where that leads.

The frontier-model designation, though voluntary, "may become a de facto benchmark influencing procurement decisions, insurance underwriting and litigation standards" (Buchanan Ingersoll).

That is the mechanism pulling this out of the compliance bucket and into vendor risk. The signal is real but narrow. Participation tells you a vendor is willing to be looked at by a national-security testing body, that it has the legal and engineering maturity to operate inside a classified evaluation, and that it accepted the disclosure posture. It does not tell you the model passed, what was found, or whether the version in your contract was the version examined. You would read it the way you read a SOC 2 Type II report from a subprocessor that refuses to hand over the report: a statement of intent and capability, after which you go looking for the actual control elsewhere.

The people closest to the science want that limit understood. AI safety researchers Geoffrey Hinton and Yoshua Bengio argue that safety cannot rest solely on corporate self-regulation, because commercial pressure prioritizes development speed over risk mitigation, and the order lacks mandatory safety measures (The Conversation). For a buyer, that is not a political observation. It is a statement that the upstream control you are leaning on is structurally optional, which means your downstream contract has to assume it can disappear.

Who participates, and how the products map

The participating set is now concrete. OpenAI and Anthropic signed the original memoranda of understanding with the U.S. AI Safety Institute, inside NIST and Commerce, back in 2024, allowing government access to major new models before and after public release (Axios).

On May 5, 2026, the Commerce Department's Center for AI Standards and Innovation (CAISI) announced renegotiated pre-deployment evaluation agreements adding Google DeepMind, Microsoft, and xAI (Nextgov). That brings the count to five frontier labs in CAISI pre-deployment review, with more than 40 model evaluations completed to date (TechJack Solutions).

The buyer-facing products map onto that set. You contract with Anthropic Claude API and OpenAI API from the two original 2024 participants. Azure OpenAI Service is Microsoft's enterprise channel, joining the review in May 2026. Gemini is Google DeepMind's product, and Grok by xAI is the most recent entrant. The participation question belongs on a vendor questionnaire, but its answer is one input, not a verdict.

Neither end of the spectrum decides the matter on its own. A non-participating vendor is not automatically disqualified; a small open-weights provider may never enter the channel yet hand you full training-data provenance and an output indemnity. A participating vendor is not automatically safe either, and a named one may still decline to share any evaluation detail. Rank vendors by the signal, then bind them with the contract.

Questions to put on the vendor questionnaire

Because the evaluation happens in a classified environment and is never buyer-facing, your due-diligence process has to extract the equivalent assurances directly. Put these in writing and require written answers, not a sales call.

• Scope match. Was the specific model version in our proposed contract submitted for pre-deployment review, or only a predecessor frontier release? Incremental successors are out of scope by the order's own terms.
• Disclosure posture. What evaluation results, summary findings, or attestations can you share under NDA? "None, it's classified" is an answer you record and weigh, not a wall you stop at.
• Channel commitment. Do you commit to submitting future step-change releases, and will you notify us when a model we use is or is not covered?
• Capability disclosure. What is your internal process for disclosing dangerous cyber-capability findings, independent of the government channel, and on what timeline does the buyer hear about them?
• Subprocessor reach. Which subprocessors touch our prompts, outputs, or logs, and are any of them outside the participating-lab perimeter?

None of these can be answered by checking whether the vendor's logo appears in a CAISI announcement. They are the buyer-side reconstruction of assurances the voluntary review keeps inside the government.

Five contract clauses that carry the real control

This is where the buyer's actual control lives. The review tells you a vendor is willing to be looked at; the clauses below hold the line when it is not, when the model changes, or when the political wind shifts. Five families carry the load.

Training carve-out

Require that the vendor will not use Customer Data, prompts, inputs, outputs, logs, or telemetry to train or improve models without explicit written consent, with opt-out as the default state (Huwyler, AI Procurement Controls). The same model bought through different channels can carry different defaults, which is the central reason this lives in the contract. Anthropic Bedrock and a direct API agreement for the same Claude model are separate paper with separate data-handling terms.

Output indemnification

The supplier should bear liability for non-compliant, infringing, unsafe, or defective outputs and indemnify the buyer (Huwyler). A classified safety evaluation you never see provides no recourse if a model produces an infringing or harmful output in production. An indemnity does.

Change-of-law

Embed a change-of-law clause obligating the vendor to maintain its compliance posture as regulation evolves, at the vendor's cost (Atonement Licensing). The June 2026 order is voluntary today and could be tightened, replaced, or rescinded. A change-of-law clause makes the regulatory trajectory the vendor's problem to track and fund, not yours.

Subprocessor disclosure and exit terms

Require an up-to-date subprocessor list with advance notice of changes and explicit data-residency support (Atonement Licensing). The participating-lab perimeter is not the whole supply chain. Hosting, inference, and tooling subprocessors sit outside any CAISI evaluation, and they are where data-residency and access risk concentrate. A vendor can be a named review participant while routing your prompts through a subprocessor that never entered any government channel, so the subprocessor map is the part of diligence the review demonstrably does not cover.

Pair the subprocessor clause with exit and portability terms: data return and deletion on termination, format guarantees, and a defined transition window. If a vendor declines future review participation, or a finding leaks, or your own risk appetite shifts, exit terms let you act on the signal instead of being locked into it. Portability is also the quiet enforcement mechanism behind every other clause, because a vendor that knows you can leave cleanly has more reason to honor the carve-out and the indemnity than one that holds your data hostage.

Mapping clauses to the controls auditors expect

Vendor-risk teams already operate inside SOC 2 Type II, ISO 27001, and GDPR programs. The clauses above are not a parallel AI regime; they extend obligations you already enforce. The table below maps each control to the framework expectation it satisfies, so the AI clauses ride inside existing third-party-risk and audit-trail processes rather than as an orphaned addendum.

Control	Contract mechanism	Framework it supports
Data not used for training	Training carve-out, opt-out default	GDPR purpose limitation, SOC 2 confidentiality
Liability for harmful output	Output indemnification	SOC 2 processing integrity
Posture maintained as law evolves	Change-of-law clause	ISO 27001 compliance management
Visibility into the supply chain	Subprocessor list, advance notice, residency	SOC 2 vendor management, GDPR Art. 28
Data return and clean exit	Exit and portability terms	ISO 27001 supplier offboarding

Residual risks the contract still leaves open

Even a well-drafted agreement does not close everything, and a vendor-risk owner should name the gaps rather than assume the clauses are airtight.

• Verification gap. A training carve-out is a promise. You generally cannot independently verify a vendor did not train on your data without audit rights and logging you must also negotiate.
• Indemnity ceiling. Output indemnities frequently carry liability caps that fall well below the cost of a serious incident. Read the cap, not just the clause.
• Subprocessor opacity. Advance notice of subprocessor changes is useless unless the contract also grants a real right to object and exit.
• Scope drift. The model you contracted for is patched, fine-tuned, and re-versioned continuously, and none of those changes re-enter the 30-day channel. Your evaluation has to be continuous too.
• Signal decay. Participation status is a point-in-time fact. A vendor that submitted a release in 2024 or May 2026 has made no binding commitment to submit the next one, and the order creates no obligation to keep doing so. A questionnaire answer captured a year ago may describe a posture the vendor has since quietly dropped.

Naming these gaps is not an argument against the clauses. It is the difference between a vendor-risk owner who can defend the residual risk to an auditor and one who presents a signed contract as if it closed the exposure. The order's voluntary structure guarantees that some assurance will always sit outside both the review and the paper. The honest move is to log that residual and price it, not to pretend it is zero.

Implementation guidance for the vendor-risk owner

Translate this into procedure before the next renewal cycle. First, add a single field to your AI vendor questionnaire that records review participation as a fact, not a gate, and capture the scope-match answer next to it. Second, make the five clause families non-negotiable defaults in your AI procurement template, with the training carve-out set to opt-out and an indemnity cap your legal team has sized against a realistic incident. Third, route the subprocessor list into the same continuous-monitoring process you already run for SOC 2 subservice organizations, so AI subprocessors are not a separate spreadsheet that goes stale.

Then attach one standing trigger to the vendor file: re-run the scope-match question every time the vendor ships a point release, because a point release is exactly when participation status silently lapses and the version under your contract drifts away from anything anyone reviewed. The signal degrades on the vendor's release cadence, not your audit cadence. A control that only refreshes at renewal will already be a year stale the first time it matters.