
Voluntary AI frameworks are regulatory signals
OpenAI's Frontier Governance Framework is a well-built compliance document nine weeks before EU enforcement bites. Read it for what it concedes, not what it promises — and ask your vendor for the judgment record instead.
The most useful sentence in OpenAI's new Frontier Governance Framework is not a commitment. It's an admission: on harmful manipulation — one of the four risk categories the document itself names — they are "still in the early stages of developing an approach for assessing" it, and handle it with post-deployment monitoring rather than pre-deployment evaluation.
That sentence is worth more to a buyer than the other nineteen pages, and almost nobody will quote it.
What was published, and what it is for
On May 28, 2026, OpenAI published the Frontier Governance Framework — a document that does double duty by design. Under California's Transparency in Frontier AI Act it is their Frontier AI Framework; under the EU's General-Purpose AI Code of Practice it is the public summary of their Safety & Security Framework for models covered by Regulation (EU) 2024/1689. One artifact, two regimes.
The content is more specific than most governance prose. Four systemic risk categories: cyber offense, CBRN, harmful manipulation, loss of control. A definition of systemic risk with actual numbers in it — foreseeable and material risks of severe harm, including a model materially contributing to more than 50 fatalities or a billion dollars of damage from a single incident. Alignment claimed to ISO 42001, the NIST AI Risk Management Framework, and METR's Responsible Scaling Policy proposal.
The timing is not subtle, and doesn't need to be. GPAI obligations under the EU AI Act have applied since August 2, 2025, but the first year was a good-faith period — the AI Office working alongside signatories to the Code of Practice rather than penalising them. From August 2, 2026, the Commission enforces full compliance, fines included. That is nine weeks from today. Models already on the market before August 2025 get until August 2027.
The obvious read is "OpenAI complied because the deadline is coming". Fine, and true. It also doesn't tell a working engineer anything actionable.
What a framework can and cannot carry
Here's the distinction that matters if you have to sign off on a vendor. A framework describes gates. Evidence proves gates bind. Publishing the first has now become a legal requirement in two jurisdictions; publishing the second has not.
Read the document closely and it says so itself, honestly. Threshold determinations are "informed by" evaluation results and also "reflect a holistic judgment based on the totality of available evidence". One-time capability elicitations are treated as a lower bound, not a ceiling. Out of caution they have counted a threshold as crossed even without direct evidence that it was. Every one of those sentences describes a judgment call by a named group of people, made repeatedly, under commercial pressure, and never published.
That is not a criticism of the document. It's the nature of the artifact. No public framework can carry the thing a risk review actually needs, which is the record of the specific calls: who decided, on what evidence, and which releases went ahead anyway.
The bet
So here's my claim, and I'll take the other side of the consensus on it. Frameworks are about to become worthless as a differentiator, precisely because they're becoming mandatory.
By the time enforcement starts in August, every large frontier developer will have published one of these. They are all mapping to the same two regimes and citing the same three standards — ISO 42001, NIST AI RMF, RSP-style scaling commitments. Converged inputs produce converged outputs. Within a year these documents will be structurally interchangeable, and a procurement team scoring vendors on framework quality will be scoring on prose style.
My bet: the vendors who actually differentiate themselves will be the ones willing to show a customer the judgment record — the threshold calls and the exceptions — under NDA, in a room, with a named owner present. Not published. Shown. And the first serious enterprise deal won or lost on that basis happens well before the August 2027 deadline for legacy models.

What I do in a model risk review now
At Trigent I sit in vendor reviews where a client needs a model decision defended to their own risk committee. The pattern is consistent: the vendor sends the framework, the certifications, and a security questionnaire, and everyone treats the package as the answer. It isn't the answer. It's the cover sheet.
The three questions I ask instead, in this order:
- Who owns the release gate by name, and what happens to them if they're wrong? A framework with no named owner is a description of a process, not a control.
- Show me one evidence artifact from the most recent release — an eval report, a red-team summary, a sign-off record. Not the policy that says such artifacts exist.
- Has a release ever proceeded over an unresolved objection, and what was the disposition? The answer "never" is not reassuring; it usually means nobody is tracking it.
I've had vendors answer all three well and I've had that conversation end the evaluation. Both outcomes were worth far more than the framework PDF, and neither could have been reached by reading it.
There's a corollary I've had to accept about my own work: if I'm asking vendors for evidence artifacts and named owners, my team has to be able to produce ours on the same day's notice. We couldn't, the first time someone asked. That was a fair hit, and fixing it took longer than writing any policy did.
Read it for the concessions
So read these documents — genuinely, read them — but invert how you read them. Skip the commitments; they are written to be unfalsifiable. Go hunting for the sentences where the vendor admits a gap, because those are the only lines that carry information their competitors' documents won't also contain by year end. The harmful-manipulation admission is the tell in this one. It's specific, it's unflattering, and it tells you exactly which risk category to interrogate in the room.
A published framework tells you what a vendor intends; only the exception record tells you what they enforce — ask for the second one before August.


