OpenAI quietly published a document on May 28, 2026 that reads less like a research paper and more like a legal filing — and that distinction is the whole point.
What the FGF Is and Is Not
The Frontier Governance Framework (FGF) is a compliance-translation document, not a new safety methodology. Published by OpenAI on May 28, 2026 , it maps parts of the company's existing internal Preparedness Framework (PF) onto two statutory regimes: California's Transparency in Frontier Artificial Intelligence Act (TFAIA / SB 53) and the EU AI Act's General-Purpose AI (GPAI) Code of Practice . It is not a model release, not the "Frontier" enterprise agent product, and not a change in how OpenAI evaluates risk.
Quick Answer: OpenAI's Frontier Governance Framework, published May 28, 2026, is a regulatory-translation layer — not a new safety method. It documents how the internal Preparedness Framework maps onto California's TFAIA (SB 53) and the EU AI Act GPAI Code, covering models that could cause 50+ fatalities or $1B+ in damage.
The framing matters for anyone tracking how labs operationalize compliance. OpenAI states the PF remains the foundation for its frontier-risk program — including internal practices that can and do exceed current legal requirements — while the FGF is a narrower layer documenting legally-oriented processes for covered frontier models and EU "general-purpose AI models with systemic risk" . The FGF does not describe that broader internal program; it describes the slice that statutes can audit.
The clearest signal of this split is the threshold gap. The FGF anchors "covered risk" to legal definitions: foreseeable, material risks where a model materially contributes to more than 50 fatalities or more than $1 billion in property damage from a single incident . That bar is deliberately lower than the PF's separate "severe harm" framing — death or grave injury to thousands of people, or hundreds of billions of dollars in economic damage . Two thresholds, two purposes: one tracks statute, the other tracks OpenAI's own risk appetite.
"The Preparedness Framework remains the foundation for our frontier-risk program, while the Frontier Governance Framework documents the compliance-oriented processes for covered models," per OpenAI's published framework (source: OpenAI, 2026-05).
This is a compliance bridge built ahead of enforcement — the EU regime becomes fully enforceable on August 2, 2026 , and TFAIA's obligations are arriving alongside it.
The Compute Thresholds That Define Coverage
Coverage under the FGF is binary and compute-gated: a model is either above a statutory training-compute line — and therefore in scope — or it is not. California's TFAIA (SB 53) defines a "frontier model" as a foundation model trained with more than 10^26 integer or floating-point operations — counting subsequent fine-tuning, reinforcement learning, or other material modifications — and treats you as a "large frontier developer" once affiliated annual gross revenue exceeds $500 million. The EU sets its line one order of magnitude lower.
The EU AI Act presumes a general-purpose AI model has high-impact, systemic-risk capability when training compute exceeds 10^25 FLOP — ten times more sensitive than TFAIA's bar. Compute is not the only trigger: under Article 51, the European Commission can designate a model as systemic-risk regardless of its training compute, which means a sub-threshold model can still be pulled into scope by regulatory decision rather than by raw FLOP count.
| Dimension | California TFAIA (SB 53) | EU AI Act / GPAI Code |
|---|---|---|
| Compute trigger | >10^26 ops (incl. fine-tuning, RL, modifications) | >10^25 FLOP presumed systemic-risk |
| Discretionary trigger | Revenue-gated developer status | Commission designation (Article 51) |
| Developer threshold | >$500M affiliated annual gross revenue | Provider of a systemic-risk GPAI model |
| Catastrophic-risk bar | 50+ fatalities or $1B+ property damage from a single incident | |
The harm definitions are deliberately aligned across both regimes. Each anchors coverage to foreseeable, material contribution to more than 50 fatalities or more than $1 billion in property damage from a single incident, via CBRN assistance, autonomous cyber or criminal conduct without meaningful human oversight, or evasion of developer and user control (source: TechTimes, 2026-05). That bar is intentionally lower than the Preparedness Framework's internal "severe harm" framing — death or grave injury to thousands of people, or hundreds of billions in economic damage — because the two documents serve different purposes (source: KeepingUpWith.ai, 2026-05).
The practical consequence for developers tracking this: statutory coverage is a switch, not a slope. Models below the compute lines are not covered by the FGF's reporting machinery at all. They still fall under OpenAI's internal Preparedness Framework, which applies regardless of threshold — so a model can be exempt from the legal-compliance layer while remaining subject to the same internal risk categories that gate deployment.
Four Capability Domains the Framework Addresses
The FGF organizes its frontier-risk work around four domains: cyber offense, CBRN, harmful manipulation, and loss of control . Each domain is meant to be scoped against a capability scale that pre-deployment assessments use to decide whether a covered model may have reached a new risk tier. But the four are not equally built out — two have concrete tiered scales, and two are explicitly less settled, which tells you where OpenAI thinks the measurable risk currently lives.
Cyber offense and CBRN carry the most developed three-tier scales . Within CBRN, OpenAI says it principally builds safeguards around biological and chemical threats and prioritizes biological evaluations because of their higher potential severity, benchmarking novice uplift against a 2021 baseline of available tools . Nuclear and radiological risk is the acknowledged gap: working nuclear-weapon development cannot be fully studied outside classified contexts, so OpenAI commits only to continued threat-model research and engagement with national-security stakeholders rather than a published tier scale .
Harmful manipulation is flagged as exploratory. Instead of committing to a pre-deployment evaluation methodology, the framework suggests influence-operation risks may be better addressed through system-level mitigations — particularly post-deployment monitoring — than through evals run before launch . For developers reading this as a compliance signal, it is an honest admission: OpenAI does not yet claim a reliable way to measure manipulation capability at the model level, so it shifts the control point downstream to deployment.
Loss of control is defined as losing the ability to reliably direct, modify, or shut down a model . Its capability points focus on autonomy, deception, monitoring evasion, the limits of chain-of-thought monitoring, and unauthorized action. The inclusion of chain-of-thought-monitoring limits is the technically interesting line here — it concedes that interpretability of a model's reasoning trace is itself a safeguard that can degrade as models grow more capable, rather than a fixed guarantee.
Read together, the four domains map cleanly onto the EU AI Act's Article 55 obligation to evaluate and adversarially test systemic-risk models . The uneven maturity across them — hard scales for cyber and bio, research promises for nuclear, monitoring for manipulation — is the framework telling you which threats it can currently quantify and which it can only watch.
Cyber Offense and CBRN Capability Scales
The cyber offense and CBRN domains are the two places where the Frontier Governance Framework commits to explicit three-tier capability scales, because they are the threats OpenAI believes it can currently measure. Each scale describes escalating levels of model capability that pre-deployment assessments must rule out before a covered model ships . Tiers are scoping tools — they define what a given evaluation needs to disprove — not binary kill switches that automatically block a release.
For cyber offense, Tier 1 is assistance roughly comparable to publicly available resources. Tier 2 is substantial uplift to small organizations through end-to-end automation or vulnerability discovery and exploitation. Tier 3 is the most severe: a tool-augmented model that autonomously identifies and develops functional zero-day exploits across many hardened, real-world critical systems, or that devises and executes novel attack strategies from a high-level goal .
For CBRN, OpenAI principally builds safeguards around biological and chemical threats and prioritizes biological evaluations because of their higher potential severity. Tier 2 covers meaningful counterfactual assistance to novice actors relative to a 2021 baseline of available tools . Tier 3 covers expert enablement of a highly dangerous novel threat vector, or a fully automated design-acquisition-production-deployment pipeline.
| Tier | Cyber offense | CBRN (bio/chem priority) |
|---|---|---|
| Tier 1 | Assistance comparable to public resources | Below meaningful counterfactual uplift |
| Tier 2 | Substantial uplift to small orgs via end-to-end automation or vuln discovery/exploitation | Meaningful counterfactual uplift to novice actors beyond a 2021 baseline |
| Tier 3 | Autonomous zero-day discovery/exploitation across many hardened critical systems, or novel attack strategy from a high-level goal | Expert enablement of a novel highly dangerous threat vector, or a fully automated design-to-deployment pipeline |
Nuclear and radiological risks sit deliberately outside this clean tier structure. OpenAI acknowledges that working nuclear-weapon development cannot be fully studied outside classified contexts, so it cannot offer a comparable assessment methodology here . Instead of a scale, the framework commits to continued threat-model research and ongoing engagement with national-security stakeholders — a stated process, not a resolved evaluation.
For developers reading this as a compliance map, the practical takeaway is what each scale obligates. A covered model's pre-deployment evaluations have to produce evidence that the model has not reached Tier 2 or Tier 3 in cyber or CBRN before it ships; passing those tests helps rule a threshold out rather than proving capability is absent . The tiers tell you exactly which uplift scenarios OpenAI considers material — and, in the nuclear case, where it is honest that it has no number to give.
Clearing the Bar: How OpenAI Decides What Ships
OpenAI's deployment decision rests on two conservative rules that bias the process toward caution: a single passing evaluation can never clear a model on its own, and uncertainty is resolved against deployment. Before any covered model ships, in-scope evaluations must indicate it has not reached a new risk tier — but the framework treats those results as a floor, not a verdict . That distinction is what makes the decision process worth reading line by line.
The first rule: one-time elicitation results are treated as a lower bound on real-world capability, never a ceiling . In practice this means a model that fails to produce a dangerous capability under one round of prompting is not assumed safe — better elicitation, fine-tuning, or tool augmentation later could surface what the first attempt missed. A clean eval rules a threshold out; it does not prove the capability is absent.
The second rule is more aggressive. When OpenAI cannot rule out that a capability point has been crossed, it treats the model as having crossed it — even without direct evidence . Absence of proof is read as presence of risk, which inverts the usual burden and forces mitigations on by default in ambiguous cases.
"When OpenAI cannot rule out that a model has reached a new threshold, it treats the model as having crossed it — even without direct evidence." — OpenAI Frontier Governance Framework (source: AI News, 2026-05)
Scalable automated evaluations do the first-pass detection — they are designed to flag whether a model may have reached a new tier rather than to confirm it has . Because that signal is deliberately incomplete, OpenAI supplements it with three more expensive checks before deployment:
- Human expert red-teaming — adversarial probing by specialists who try to elicit the capability the automated suite could miss .
- Expert consultations — domain input on whether observed behavior maps to a material threat in cyber, CBRN, manipulation, or loss of control .
- Resource-intensive third-party assessments — independent evaluations that add an external check on the lab's own conclusions .
The outcome gates shipping directly. If residual risk exceeds an acceptable level, the model is not deployed until additional mitigations bring it back down . When residual risk is judged acceptable, OpenAI documents the justification alongside the explicit conditions under which that judgment could fail . For developers, that written record of failure conditions is the most useful artifact here — it states, in advance, what would force a re-evaluation rather than leaving the call to post-hoc interpretation.
Reporting Obligations Under TFAIA and EU GPAI
Once a model ships, the FGF binds OpenAI to two distinct reporting clocks — one set by California's TFAIA, one by the EU GPAI Code of Practice — and they do not run on the same schedule. Under TFAIA, OpenAI must publish a transparency report before or concurrent with each covered deployment, file quarterly catastrophic-risk summaries to the California Office of Emergency Services (Cal OES) or another agreed schedule, and report critical safety incidents within 15 days . That window compresses to 24 hours when an incident carries imminent risk of death or serious physical injury . For developers tracking how fast a known issue becomes public record, those are the deadlines that matter.
The EU side is event-triggered rather than calendar-driven. OpenAI commits to update a Model Report whenever it reasonably believes the basis for accepting a model's systemic risk has been materially undermined — by post-training changes, riskier integrations, or serious incidents . For its most capable frontier models, it will additionally decide whether to update the report at least every six months, subject to stated exceptions . Note the wording: the obligation is to evaluate whether an update is needed every six months, not to issue one — a distinction worth watching as the EU regime becomes fully enforceable on August 2, 2026 .
Above the per-model cadence sits a slower governance loop. OpenAI commits to a formal Framework Assessment at least every 12 months, counted from the effective dates of both TFAIA and the EU Code . Material changes to the FGF itself are documented in a changelog published within 30 days of the change and escalated to two bodies: the OpenAI Foundation board's Safety and Security Committee and the board of OpenAI Ireland Limited .
The practical takeaway for anyone building on these models: the changelog is the document to bookmark. A revised threshold or a downgraded mitigation will surface there within 30 days, which gives integrators a concrete signal — independent of marketing copy — that the conditions under which a model was cleared have shifted.
Corporate Accountability by Jurisdiction
The FGF assigns legal responsibility to two named entities, split by regulatory regime. OpenAI OpCo LLC is the designated responsible party for TFAIA compliance covering U.S. frontier models, while OpenAI Ireland Limited is the provider of record for EU general-purpose AI models with systemic risk and exercises EU oversight . That second designation is not cosmetic: the EU AI Act requires an in-region responsible party, and naming the Irish entity is how OpenAI satisfies it. For an integrator, this clarifies who is actually on the hook when an incident report or a Model Report update is due — the answer depends on which jurisdiction's model you are building against.
OpenAI is listed by the European Commission as a signatory to the EU's General-Purpose AI Code of Practice, published July 10, 2025, whose Safety and Security chapter applies to the small set of providers of the most advanced systemic-risk models . Signing the Code is the voluntary route to demonstrating compliance ahead of the AI Act's full enforcement, rather than a separate obligation.
On the security side, the framework points to OpenAI's Information Security and Privacy Program, which it states is aligned with ISO 27001, 27017, 27018, and 27701 and supported by SOC 2 Type II evaluations . The documented controls are the kind a developer can map against their own threat model:
- Encryption at rest and in transit, multi-factor authentication, and multi-party approval for sensitive operations
- Sandboxed execution with restricted network egress by default — relevant if you reason about model-tool boundaries
- Detailed logging, rate limits, and continuous monitoring
- Red teaming, penetration testing, vulnerability scanning, and a vulnerability disclosure program
None of this is novel for a cloud vendor at OpenAI's scale, but listing it inside a governance document tied to statutory thresholds is the point: the controls become part of the evidence base regulators can audit, not just internal hygiene.
Acknowledged Limits and Open Questions
The FGF is most useful where it admits what it cannot yet do. Two of the four risk domains lack a settled pre-deployment methodology, the framework is explicitly a versioned snapshot rather than a stable specification, and the Preparedness Framework's most severe tier sits entirely outside this document. Reading the gaps is as instructive as reading the commitments.
Nuclear and radiological risk has no resolved assessment methodology, and OpenAI names the reason directly: a working nuclear-weapon development pathway cannot be fully studied outside classified contexts . Its stated response is procedural rather than technical — continued threat-model research and engagement with national-security stakeholders. For CBRN, the company prioritizes biological and chemical evaluations because of their higher tractable severity, leaving the nuclear branch as a research commitment, not an operating scale.
Harmful manipulation is the weakest-defined of the four. The FGF does not commit to a pre-deployment evaluation framework here; instead it positions system-level mitigations — especially post-deployment monitoring of influence operations — as the primary lever . That is a defensible engineering choice for diffuse, post-launch harms, but it means a covered model can ship before its manipulation profile is characterized.
The document is also a moving target by design. OpenAI commits to a formal Framework Assessment at least every 12 months from the effective dates of TFAIA and the EU Code , with the EU regime becoming fully enforceable on August 2, 2026 . Early TFAIA caselaw or fresh European Commission guidance could force substantive revisions before the next cycle, so the FGF you read in mid-2026 may not be the one regulators audit in 2027.
Finally, note what is absent. The Preparedness Framework's separate "severe harm" program — thousands of deaths or hundreds of billions of dollars in economic damage — operates above and independently of the FGF and is not disclosed here . The takeaway for developers tracking this space: treat the FGF as a compliance map to statutory thresholds, not a complete account of how OpenAI governs its frontier models — the higher-stakes machinery lives elsewhere, undisclosed.
Frequently asked questions
What is the OpenAI Frontier Governance Framework?
The Frontier Governance Framework (FGF) is a compliance-translation document OpenAI published on May 28, 2026 . It maps parts of OpenAI's internal Preparedness Framework onto two statutory regimes: California's Transparency in Frontier Artificial Intelligence Act (TFAIA / SB 53) and the EU AI Act's General-Purpose AI Code of Practice . It is not a new model, not a new product, and not a new internal safety methodology — it documents legal-compliance processes for covered frontier models.
How does California TFAIA define a 'frontier model'?
Under TFAIA, a "frontier model" is a foundation model trained with more than 10^26 integer or floating-point operations, including subsequent fine-tuning, reinforcement learning, or other material modifications . The law's obligations attach to a "large frontier developer" — one whose affiliated annual gross revenue exceeds $500 million . A model below the compute bar, or a developer below the revenue threshold, falls outside the statute.
Does the FGF replace the Preparedness Framework?
No. OpenAI states the Preparedness Framework (PF) remains the internal foundation of its frontier-risk program and can exceed current legal requirements . The FGF is the narrower, compliance-scoped layer: it documents processes only for statutory-covered models and EU GPAI models with systemic risk . The PF tracks broader internal categories — Biological and Chemical, Cybersecurity, AI Self-improvement, plus research categories — that the FGF does not fully expose.
What happens when OpenAI cannot rule out a capability threshold has been crossed?
OpenAI treats the model as having crossed that threshold, even without direct evidence . The framework is conservative by explicit design: one-time elicitation results are treated as a lower bound on real-world capability, not a ceiling, and passing a pre-deployment test can help rule a threshold out but never proves one has not been reached . If residual risk stays above acceptable levels, the model is not deployed without sufficient additional mitigations.
What is the difference between TFAIA and EU GPAI compute thresholds?
TFAIA sets coverage at more than 10^26 FLOP, while the EU AI Act presumes systemic-risk capability at more than 10^25 FLOP — ten times lower . The European Commission can also designate a model as systemic-risk regardless of its training compute under Article 51 . Both regimes share the same catastrophic-risk damage threshold: more than 50 fatalities or more than $1 billion in property damage from a single incident .
