On May 28, 2026, OpenAI published its Frontier Governance Framework (FGF) — a 20-page document that translates the company's internal safety operations into a public regulatory artifact. It is one of the cleanest examples to date of a frontier AI developer documenting how its risk-management posture maps to specific named statutes.
For frontier developers, this is a serious piece of compliance infrastructure. For the enterprises that deploy OpenAI models — every F5000 compliance team running ChatGPT Enterprise alongside Microsoft Copilot, Claude, and Gemini — the FGF answers a question your auditor isn't actually asking. The layer your auditor is asking about sits on your side of the API boundary, not OpenAI's.
What the Frontier Governance Framework Actually Does
The FGF is explicit about its audience. From its introduction: "Under California's Transparency in Frontier AI Act (TFAIA), this FGF is our Frontier AI Framework, documenting OpenAI's technical and organizational protocols to manage, assess, and mitigate catastrophic risks, as defined under the TFAIA. Under the European Union's General-Purpose AI Code of Practice (the EU CoP), this FGF serves as our publicly available summary of OpenAI's Safety & Security Framework, describing how we assess and mitigate systemic risks and ensure adequate cybersecurity protection for models covered under Regulation (EU) 2024/1689 (the EU AI Act)."
The four risk categories the FGF covers are all frontier-developer concerns: cyber offense, CBRN (chemical, biological, radiological, and nuclear), harmful manipulation, and loss of control. The systemic-risk threshold OpenAI commits to is precise: "foreseeable and material risks of severe harm … including risks that a model will materially contribute to greater than 50 fatalities or $1 billion of property damages or losses arising from a single incident."
On the process side, the FGF documents OpenAI's Safety Advisory Group, its AI Safety Incident Response Plan (AIRP), a 6-month Model Report update cadence for frontier models, a 12-month framework-assessment cadence, and an Information Security and Privacy Program "aligned with ISO 27001, 27017, 27018, and 27701, and supported by SOC 2 Type II evaluations." It also references ISO 42001, the NIST AI Risk Management Framework, and the Responsible Scaling Policies first proposed by METR as inputs to its approach.
That is a substantive regulatory artifact. It is also, by design, exclusively about what happens at OpenAI before a model reaches your tenant.
The Layer the FGF Doesn't Cover
The FGF governs OpenAI's obligations as a frontier model provider. It does not govern your obligations as a deployer of an AI system that touches your employees, your customers, and your regulated data.
Those deployer obligations exist in the same regulatory frameworks the FGF references — and they sit on a different page of the rulebook:
- EU AI Act Articles 26 and 27 place explicit duties on the deployer of a high-risk AI system, separate from the GPAI obligations on OpenAI. Article 26 assigns operational duties — using the system per instructions, ensuring human oversight, retaining logs. Article 27 requires deployers in scope to complete a fundamental rights impact assessment before putting the system into use. Annex III sweeps in credit scoring, AML risk profiling, employment-decision tooling, and other categories where an enterprise deploys generative AI on top of regulated workflows. Those obligations apply to your firm whether the model came from OpenAI, Anthropic, or anyone else.
- California's TFAIA governs frontier developers. California's existing consumer-privacy and sectoral statutes (the CCPA/CPRA, state insurance and banking rules) continue to govern what happens to consumer data after it leaves your employees' browser tabs.
- HIPAA, GLBA, GDPR Article 32 (security of processing), SOC 2 CC6.6 / CC6.7, and ISO 27001 Annex A.5.34 / A.8.12 all require the data-handling controls to exist on the deployer side. A vendor's Frontier Governance Framework documents the vendor's posture; it does not satisfy any of these for your enterprise.
The FGF makes a subtle but important boundary clear in its own text: the systemic risk assessments and mitigations "apply to covered models that OpenAI has deployed externally, and in some cases internally with respect to risks resulting from circumventing oversight mechanisms." That scope is the model. It is not — and is not claimed to be — the seventy thousand employees in your enterprise who type into your tenant of ChatGPT Enterprise every week.
What Deployer-Side Governance Actually Requires
For an enterprise running ChatGPT (and Claude, and Copilot, and Gemini) inside a regulated environment, the controls auditors look for sit at a different point in the pipeline than the FGF describes:
- Pre-submission policy enforcement. Whether a customer dossier, a patient identifier, or controlled unclassified information ever reaches OpenAI's API is the deployer's call to make. The FGF specifies how OpenAI handles data once it arrives; it offers no help with whether the data should have left your environment in the first place.
- User-attributable audit trail across every AI surface. OpenAI's Safety and Security Model Report covers OpenAI's models. The internal audit trail your examiner asks for — who submitted what, when, into which AI tool, against which organizational policy — is yours to produce, and it has to span every sanctioned and unsanctioned AI tool your workforce actually uses.
- Shadow AI visibility outside the vendor's scope. A clinical analyst at a HIPAA-covered entity with sanctioned ChatGPT Enterprise access will still paste a discharge summary into a personal ChatGPT tab, or into Gemini if Google Workspace is the tab they were already on. The FGF cannot, by design, see that traffic — it doesn't exist on OpenAI's compliance plane.
- Pre-deployment policy authorship in deployer language. OpenAI's risk tiers are graded in terms relevant to a frontier developer (Tier 2 cyber-offense uplift, Tier 3 CBRN novel-threat-vector capability). Your security policy needs to be graded in terms relevant to your regulator: PII classes blocked, MNPI classes blocked, CUI classes blocked, retention periods specified per data class.
None of these are gaps in the Frontier Governance Framework — they're outside its declared scope. The FGF is a vendor-side compliance document. The deployer-side equivalent is whatever you have running in front of your employees' browsers when they open an AI tab.
Two Layers, Two Owners, Two Failure Modes
The healthy way to read the FGF is as exactly half of a two-part compliance architecture. OpenAI takes responsibility for: catastrophic-capability risk under TFAIA, systemic-risk reporting under the EU GPAI Code of Practice, model-level red-teaming, incident response on the model side. The enterprise deploying that model takes responsibility for: which employees and use cases are permitted, what data is allowed to leave the browser, what audit evidence is retained, and how shadow-AI tools outside the sanctioned vendor get caught before they become a breach.
Neither layer substitutes for the other. The vendor-side framework, when done well — and the FGF is done well — closes one set of failure modes. The other set is still yours.
Containment.AI enforces AI governance policies at the browser layer across every major AI surface — ChatGPT, Claude, Copilot, Gemini, Grok, and Perplexity — with per-user policy controls, immutable audit trails, and pre-submission blocking that operates regardless of which vendor's model is on the other end. Start a free trial.
Source: OpenAI's Frontier Governance Framework, May 28, 2026 (PDF). Announcement: OpenAI's Frontier Governance Framework, May 28, 2026.