Preparedness Framework
Published Version 2. Last updated: 15th April, 2025 · Printed on the cover page as "Version 2. Last updated: 15th April, 2025"; the openai.com announcement "Our updated Preparedness Framework" carries the same date, April 15, 2025. The PDF's internal build date is 28 April 2025, which reflects a regeneration of the file rather than a new version; Appendix A's change log describes only the v1-to-v2 changes. The first version ("beta") dates from December 2023.
Not law. This is a company's own public position on AI regulation. It is not law, and it carries no legal force.
What it argues for
This is the internal safety regime OpenAI applies to its own frontier models: "OpenAI’s approach to tracking and preparing for frontier capabilities that create new risks of severe harm." It sets a deliberately high severity bar, defining "severe harm" as "the death or grave injury of thousands of people or hundreds of billions of dollars of economic damage", and admits only capabilities that are plausible, measurable, severe, net new and "instantaneous or irremediable". Three Tracked Categories result: Biological and Chemical, Cybersecurity, and AI Self-improvement. Five Research Categories (Long-range Autonomy, Sandbagging, Autonomous Replication and Adaptation, Undermining Safeguards, Nuclear and Radiological) sit below them, and persuasion is removed from the framework altogether. Each Tracked Category has two thresholds. At High, the commitment is "We won’t deploy these very capable models until we’ve built safeguards to sufficiently minimize the associated risks of severe harm". At Critical, the risk table says "Until we have specified safeguards and security controls that would meet a Critical standard, halt further development". Evidence flows through two documents: a Capabilities Report built from automated "Scalable Evaluations" and a Safeguards Report assessing residual risk. An internal Safety Advisory Group reviews both and recommends to OpenAI Leadership, which decides and can act without the SAG, which "does not have the ability to “filibuster”"; the board's Safety and Security Committee can reverse decisions. The framework also carries a conditional escape valve: if a competitor ships a High or Critical system without comparable safeguards, OpenAI "could adjust accordingly the level of safeguards that we require", provided it says so publicly and keeps its safeguards "at a level more protective than the other AI developer". External involvement is largely discretionary. Third-party evaluation happens "when available and feasible", and public disclosure of results "may be redacted or summarized where necessary".
Stated positions (13)
- Severity bar: "By “severe harm” in this document, we mean the death or grave injury of thousands of people or hundreds of billions of dollars of economic damage." Harms below that level are left to OpenAI's wider safety stack.
- A capability becomes a Tracked Category only if its risk is plausible, measurable, severe, net new and "Instantaneous or irremediable". Version 2 tracks Biological and Chemical, Cybersecurity, and AI Self-improvement, and moves Nuclear and Radiological into Research Categories.
- Persuasion is dropped: "Persuasion category risks do not fit the criteria for inclusion", and are instead handled through the Model Spec, usage prohibitions and influence-operation investigations.
- Deployment gate at High: "We do not deploy models that reach a High capability threshold until the associated risks that they pose are sufficiently minimized."
- Development gate at Critical: for all three Tracked Categories the risk table prescribes "halt further development" until safeguards and security controls meeting a Critical standard have been specified. OpenAI adds: "We do not currently possess any models that have Critical levels of capability, and we expect to further update this Preparedness Framework before reaching such a level with any model."
- Evaluation is designed to approximate a motivated adversary, using a variant with "a negligible rate of safety-based refusals" and "the best presently-available scaffolds". Any one-time elicitation is treated "as a lower bound, rather than a ceiling".
- Scope covers "every frontier model (e.g., OpenAI o1 or OpenAI o3) that we plan to deploy externally", significant internal agentic systems, and significant changes to deployment conditions such as "releasing weights". The SAG decides ambiguous cases.
- Governance is internal and ends with the CEO. The SAG recommends and OpenAI Leadership makes "all final decisions, including accepting any residual risks and making deployment go/no-go decisions". The SAG "does not have the ability to “filibuster”", and the board's Safety and Security Committee "may reverse a decision and/or mandate a revised course of action."
- Marginal-risk clause: if another developer releases a High or Critical system without comparable safeguards, OpenAI may lower its own requirements. It would do so only if the overall risk does not meaningfully rise, it acknowledges the change publicly, and "in order to avoid a race to the bottom on safety, we keep our safeguards at a level more protective than the other AI developer".
- External checks are discretionary. OpenAI will work with third parties to evaluate models "when available and feasible", may seek third-party stress testing of safeguards "in particular for models that are over a High capability threshold", and the SAG "may opt to get independent expert opinion".
- Public disclosure is committed but bounded. Published results "will include the scope of testing performed, capability evaluations for each Tracked Category, our reasoning for the deployment decision", with safeguards information added above High, but they "may be redacted or summarized where necessary".
- Security controls for High-capability models are aligned with "ISO 27001, SOC2, NIST SP 800-53, and FedRAMP". They include least privilege, zero-trust principles, multi-person approval for changes to critical infrastructure, and "Independent Security Audits" by third-party auditors.
- Update discipline: "We will review and potentially update the Preparedness Framework for continued sufficiency at least once a year." Version 2 also chose to "Deprioritize safety drills" in favour of continuous red-teaming.
About this document
A 22-page typeset PDF (LaTeX) of roughly 10,000 words, issued in OpenAI's corporate name with no named author. It has a cover page with the title and version line, a one-page overview, a contents page, five numbered sections and three appendices. The sections are: Introduction, including "Why we’re updating the Preparedness Framework"; Deciding where to focus, covering the five tracking criteria and Table 1 (Tracked Categories, with High and Critical thresholds, associated risks and safeguard guidelines) and Table 2 (Research Categories); Measuring capabilities, covering Scalable Evaluations, Deep Dives, testing scope and Capabilities Reports; Safeguarding against severe harm, covering safeguard selection, Safeguards Reports, the marginal-risk clause and Critical-level development safeguards; and Building trust, covering internal governance, public disclosure and third-party testing. Appendix A is a twelve-point change log from version 1. Appendix B sets decision-making roles for the Safety Advisory Group, OpenAI Leadership and the board's Safety and Security Committee. Appendix C gives illustrative safeguards and efficacy assessments against malicious users and misaligned models, and the security controls required for High-capability models. The document is self-directed throughout: it binds OpenAI's own process and makes no asks of governments beyond commitments to "Contribute towards improved public policy and pandemic preparedness" and to cyberdefence policy. It footnotes its borrowings from Anthropic's Responsible Scaling Policy and Meta's Frontier AI Framework.
How this sits against AI law
Each stance compared with what EU and US instruments actually require. Where no instrument addresses a theme, that gap is shown rather than hidden.
A published frontier safety framework with capability thresholds
OpenAI publishes a framework naming its Tracked Categories, setting High and Critical capability thresholds for each, mapping thresholds to required safeguards and security controls, and committing to review the framework at least once a year.
Article 55 requires systemic-risk providers to evaluate models and assess and mitigate systemic risks, but the Act itself does not oblige a provider to publish a risk framework or define capability tiers. Writing a Safety and Security Framework is a commitment under the voluntary GPAI Code of Practice.
SB 53 requires a large frontier developer to write, implement and publish a frontier AI framework describing how it defines and assesses catastrophic-risk thresholds, applies mitigations, uses third-party assessment, secures unreleased weights and governs the process, and to review it at least annually. OpenAI's SB 53 compliance document is its separate Frontier Governance Framework.
Deployment and development gates at High and Critical capability
Models reaching a High threshold are not deployed until safeguards sufficiently minimise the associated risk of severe harm. For Critical capability the framework prescribes halting further development until safeguards and security controls meeting a Critical standard have been specified.
Article 55(1)(b) requires systemic risks to be assessed and mitigated but sets no capability tier at which a model may not be placed on the market or development must stop. Under Article 93 the Commission can require mitigation or restrict, withdraw or recall a model after it reaches the market.
SB 53 is a transparency statute: it requires the framework and a pre-deployment transparency report to be published, and penalises false statements about them, but it conditions neither deployment nor continued development on any safeguard threshold.
How severe a harm must be before the framework applies
The framework covers only risks of "severe harm", defined as the death or grave injury of thousands of people or hundreds of billions of dollars of economic damage. Persuasion risks are excluded because they do not meet the tracking criteria.
Article 3(65) defines systemic risk to include actual or reasonably foreseeable negative effects on public health, safety, public security, fundamental rights or "the society as a whole" that can be propagated at scale, which is a much wider net than a mass-casualty or catastrophic-economic-loss bar.
SB 53's catastrophic risk starts at the death of or serious injury to more than 50 people, or more than $1 billion in damage from a single incident. That is orders of magnitude below OpenAI's threshold of thousands of deaths or hundreds of billions of dollars.
Third-party evaluation and independent review
OpenAI will work with third parties to evaluate models when it deems deeper testing warranted and such testing is available and feasible. It may seek third-party stress testing of safeguards, particularly above High, and the Safety Advisory Group may obtain independent expert opinion.
Article 55(1)(a) requires model evaluation including adversarial testing but leaves the choice between internal and independent external testing to the provider, the same discretion the framework reserves.
SB 53 requires the framework and transparency reports to describe any use of third-party evaluators, not to use them. EO 14409's pre-release access for covered frontier models is likewise voluntary.
Security controls for High-capability models
High-capability models require security threat modelling, defence in depth and zero-trust architecture, least-privilege access with multi-factor authentication, secure development and supply-chain controls, round-the-clock monitoring, red-teaming and independent security audits, aligned with ISO 27001, SOC 2, NIST SP 800-53 and FedRAMP.
Article 55(1)(d) requires only "an adequate level of cybersecurity protection" for systemic-risk models and their physical infrastructure, naming no specific controls, standards or audit requirement.
SB 53 requires a large frontier developer's framework to describe the cybersecurity practices it uses to secure unreleased model weights against unauthorised modification or transfer, which is the disclosure the framework's security appendix supplies.
Public disclosure of evaluation results and deployment reasoning
For major deployments OpenAI will publish the scope of testing, capability evaluations for each Tracked Category and its reasoning for the deployment decision, plus safeguards information for models beyond High. These disclosures may be redacted or summarised to protect intellectual property or safety.
Articles 53 and 55 require documentation for the AI Office and downstream providers and one public artefact, a summary of training content. Nothing in the Act obliges a provider to publish evaluation results or its deployment rationale.
SB 53 requires a transparency report published before or concurrently with deploying a new frontier model, which for large frontier developers must summarise catastrophic-risk assessments and their results and the role of third-party evaluators, with redactions allowed for trade secrets and security.
Reporting serious incidents to authorities
The framework sets up internal reporting only. Employees can raise concerns about noncompliance through a Raising Concerns Policy, and OpenAI will investigate and take corrective action. It makes no commitment to report safety incidents to any government authority.
Article 55(1)(c) requires systemic-risk providers to track, document and report serious incidents and possible corrective measures to the AI Office, and as appropriate national authorities, without undue delay.
SB 53 requires frontier developers to report critical safety incidents to California's Office of Emergency Services within 15 days, or 24 hours where there is imminent risk of death or serious physical injury. It also protects whistleblowers who report catastrophic-risk concerns to authorities, beyond an internal channel.
The Preparedness Framework is stricter than current law on process and looser on scope. It has hard gates the law does not: no deployment at High without sufficient safeguards, and a halt to development at Critical. It also names security controls in detail. Neither the EU AI Act, whose Article 55 duties are stated as outcomes, nor California SB 53, which requires a published framework but conditions nothing on its content, has either gate. On the other side, its definition of severe harm (thousands of deaths or hundreds of billions of dollars) sits far above SB 53's catastrophic-risk line of more than 50 deaths or $1 billion, and far narrower than the AI Act's systemic-risk concept, which reaches fundamental rights and "society as a whole". It also removes persuasion entirely. The biggest gap with both regimes is incident reporting. The framework never commits OpenAI to tell any authority about a serious incident, although the AI Act and SB 53 now require exactly that. OpenAI covers those duties in a separate compliance document, its May 2026 Frontier Governance Framework, rather than in this one.
Source
https://cdn.openai.com/pdf/18a02b5d-6b67-4cec-ab64-68cdfbddebcd/preparedness-framework-v2.pdf- Date on the page:
- Version 2. Last updated: 15th April, 2025
- Source checked:
- opened and confirmed on 2026-09-29