6 min read
By

OpenAI publishes the Frontier Governance Framework — the EU AI Act track gets concrete

30 May 2026. OpenAI yesterday published the Frontier Governance Framework (FGF) — a public governance document that runs alongside the internal Preparedness Framework and aligns with the EU AI Act Code of Practice for GPAI-SR models and California's SB 53 (TFAIA). Four risk categories with tier thresholds, a Safety and Security Model Report on a six-month cadence and an AI Safety Incident Response Plan (AIRP) are now available in a form that procurement and DPIA can dock onto directly.

3/4-Ansicht Walnussdesk am Moselraum: schmales cremefarbenes Dossier mit zwei Reiterregistern, einziger oxblutroter Wachstropfen auf der Titelseite, walnussgriffiges Messing-Petschaft diagonal; links unten messingbeschlagenes Hauptbuch mit Vier-Zeilen-Tier-Tabelle in Bleistift, Espresso im Lampenpool; rechts oben messingfarbene Lupe; rechter Bildrand goldener Mosel-Terrassen-Bokeh.
AI-generated · gpt-image 2.0

What happened

OpenAI published the Frontier Governance Framework (FGF) as a PDF on 29 May 2026. The document is, in OpenAI's own framing, the public summary of its “Safety & Security Framework” for the EU and at the same time its “Frontier AI Framework” under California's Transparency in Frontier Artificial Intelligence Act (SB 53, signed on 29 September 2025, large-developer obligations from 10²⁶ FLOP cumulative). EU scope: “general-purpose models with systemic risk” (GPAI-SR) under Regulation (EU) 2024/1689 and the General-Purpose AI Code of Practice. The FGF runs in parallel to the internal Preparedness Framework, not as a replacement — the PF remains the internally facing track, not bound to FLOP thresholds. EU-side responsibility: OpenAI Ireland Limited; TFAIA: OpenAI OpCo LLC. Updates run through a Framework Assessment at least every 12 months; for the most capable models, a check is performed at least every six months on whether the Safety and Security Model Report needs to be carried forward.

Reading the move

The categorisation is the methodologically interesting move. Four risk domains — Cyber Offense, CBRN, Harmful Manipulation, Loss of Control — are staged with concretely described capability tiers. Tier 3 Cyber Offense is “a tool-augmented model can identify and develop functional zero-day exploits of all severity levels in many hardened real-world critical systems without human intervention”; Tier 2 Loss of Control is the demonstrated capability to evade Chain-of-Thought monitoring and comparable evaluation methods. “Systemic risk” is quantified (over 50 fatalities or one billion USD in property damages from a single incident). Harmful Manipulation remains explicitly “exploratory” and is to be addressed primarily through system-level mitigations (post-deployment monitoring) rather than pre-deployment evaluations. This is more than a marketing grid: the thresholds become the lingua franca with which external evaluators, regulators and procurement can talk about the same capabilities — and they follow the Frontier Model Forum Risk Taxonomy from April 2025 rather than inventing a new proprietary standard.

What it means for the mid-market

For DACH mid-market companies, the FGF is not an announcement text but a procurement document. The EU AI Act builds the obligations for GPAI-SR models as a shared responsibility: the model provider — here OpenAI Ireland — supplies technical documentation and instructions for downstream providers; the mid-market company that integrates the layer into its own system remains responsible for use-case risk, data quality and oversight. The FGF thus becomes a mandatory annex in the supplier file. Anyone deploying an OpenAI or Azure OpenAI layer in a product or administrative system should not file the document as PR material but as evidence that can be checked against their own risk decision.

The data protection reflex sits in the two-entity model. EU oversight and the Schrems II path run through OpenAI Ireland; the US parent remains obligated under TFAIA, which does not resolve third-country transfers but clarifies the addressees. If you process personal data via OpenAI APIs, including the FGF in the processing register and coordinating with your data protection officer belongs on next quarter's agenda; for regulated industries, the MaRisk/DORA track is added once the Safety and Security Model Report serves as third-party supplier evidence.

What it means for technical practice

Architecturally, the tier taxonomy is the actual movement. OpenAI implements the Frontier Model Forum Risk Taxonomy from April 2025 as a practical build instruction and explicitly references METR's proposed Responsible Scaling Policy line — the same pattern Anthropic and Google DeepMind run. On the standards level, the FGF names two layers: ISO 42001 and the NIST AI Risk Management Framework for the AI risk management layer, ISO 27001/17/18/701 plus SOC 2 Type II for information security. This couples the auditability of AI suppliers to established norms rather than to AI-specific in-house creations — for DACH customers with ISO 42001 certification ambitions, this becomes the direct connection point. Model weights are held encrypted at rest and in transit; the execution context runs in a sandbox with restrictive egress default.

The inclusion of Chain-of-Thought monitoring as a control layer (Tier 2 Loss of Control explicitly describes the capability to undermine this very track) is the open acknowledgement that interpretable intermediate states are not just research toys but an operational control point — with all the implications for in-house agent stacks in the mid-market. The AIRP workflow (detection via automated monitoring, employee escalation or end-user feedback; triage; root cause; external reporting) is directly transferable as a mini blueprint for your own AI incident track.

Concrete recommendation

In this order. First, add the FGF PDF to the supplier file for all OpenAI and Azure OpenAI stacks, and at the six-month re-read pull in the Safety and Security Model Report. Second, extend the AI procurement checklist by four fields: tier reached per risk domain, external evaluators used, AIRP reporting channel, update cadence. Third, extend the Data Protection Impact Assessment with a connecting paragraph on the two-entity model (OpenAI Ireland / OpCo) and on the tier evaluation, and have it countersigned by your data protection officer. Fourth, examine your own agent pipeline for whether Chain-of-Thought monitoring is logged as a control layer — if not, it belongs in the next architecture sprint, before the first productive multi-agent run rolls over it.

This article reflects our technical and strategic assessment. It does not replace legal advice or a Data Protection Impact Assessment.

Sources

About the author

KH

Kim Hartwig

CEO · Moselwal Digitalagentur

Kim is responsible for day-to-day operations and provides strategic support to our clients on a daily basis. Her expertise in computational linguistics combines an understanding of communication with technical know-how.