AI Governance Engineer
GitHub

How the frontier labs govern themselves, mapped to NIST AI RMF and ISO/IEC 42001

Three frontier labs publish the policy that decides when a model is too capable to train or ship as is. This page lays them side by side, dimension by dimension, and shows where the same question sits in the NIST AI RMF and ISO/IEC 42001.

The versions mapped

As of 30 Sep 2026. Each policy is versioned by its lab; a new version can move, rename or drop a section, so every cell below names the version it was read in.

How to read this

These are voluntary policies that each lab writes, applies and revises for itself. None of them is a law, a standard or a certification scheme. Two of the labs also publish a separate compliance document for California's frontier AI law; those are noted beside their policy above, not mapped as columns.

A cell is coverage, not compliance. It says that a section of the document deals with the dimension in that row. It does not say that the lab meets its own policy, that the policy meets the NIST AI RMF or ISO/IEC 42001, or that two cells in a row ask for the same thing. A solid chip marks a section that is mainly about the row; a dashed chip marks one that touches it. Where a document has nothing on a row, the row says so rather than stretching a section to fill the cell.

NIST AI RMF and ISO/IEC 42001 are generic: they govern any AI system, not frontier models. Their cells show where an organisation that runs either would file the same question, with NIST's subcategories as NIST prints them and ISO clauses by number and title only.

Coverage at a glance

How deeply each document deals with each dimension. The number counts the sections mainly about the row; more sections is not better coverage, and a filled cell says nothing about whether anyone meets it. Select a cell to read the sections.

  • Sections mainly about the dimension
  • Only sections that touch it
  • Documented gap
  • Documents with a section mainly about it (“Main in”)
  1. Risk domains covered
  2. Capability thresholds
  3. Evaluation triggers and cadence
  4. Evaluation method and validity
  5. Deployment safeguards
  6. Security of model weights
  7. Deploy, pause or stop decision
  8. Roles and accountability
  9. Public reporting
  10. External review
  11. Internal reporting and non-compliance
  12. Policy versioning and updates
  13. Link to regulation
Dimensions covered

Dimension × framework

13 dimensions · 5 columns · 143 references (63 with a verbatim quote). Select a row or a cell to read the sections in full.

Download CSV Download JSON

Crosswalk One governance dimension per row; three lab policies, then NIST AI RMF and ISO/IEC 42001. Select a dimension or a cell to read the mapped sections.
  • Solid: maps to
  • Dashed: related
  • “?”: not yet verified

Scroll the grid sideways, or read each topic below.

Anthropic RSP framework OpenAI Preparedness framework Google DeepMind FSF framework NIST AI RMF framework ISO/IEC 42001 standard
Risk domains covered §1 p. 6 §1 p. 8 Intro p. 3 §2.2 §2.3 §2.3 (box) §1.2 §1.3.1 §2.2.3 MAP 5.1 MEASURE 3.1 6.1.2 6.1.4
Capability thresholds §1 p. 4 §1 p. 9 App. B p. 17 §2.2 §2.2 Table 1 §1.2 §2.2 §3.2 MAP 1.5 GOVERN 1.3 6.1.2 6.1.3
Evaluation triggers and cadence §3.1 p. 11 §3.1 off-cycle §3.2 §3.3 §1.3.2 §1.3 §3.2.1 MEASURE 2.6 MEASURE 3.1 8.2 8.4
Evaluation method and validity §1 p. 4 §3.3 p. 12 §1 p. 8 §3.1 §2.3 Table 2 §1.3.2 §1.3.2 note MEASURE 2.5 MAP 2.3 MEASURE 2.13 9.1 A.6
Deployment safeguards §1 p. 6 §3.3 p. 12 §4.2 §4.1 App. C.1, C.2 §2.1.2 §3.1.2 §1.3.3 MANAGE 1.3 MANAGE 4.1 8.3 6.1.3 A.6
Security of model weights §1 p. 7 §1 p. 9 App. C.3 §4.4 §2.1.1 §3.1.1 §2.2 MEASURE 2.7
Deploy, pause or stop decision §3.4 p. 13 §3.4 item 5 App. A p. 17 §4.2 §2.2 Table 1 §1 §1.3.5 §2.1.2 MANAGE 1.1 MANAGE 2.4 GOVERN 2.3 6.1.3 A.6
Roles and accountability §4 item 1 §4 items 2, 8 §3.4 item 4 App. B §5.1 §4.1 §5.1 GOVERN 2.1 GOVERN 2.3 5.3 5.1 A.3
Public reporting §3.5 p. 14 §2 p. 11 §4 item 3 §5.2 §4.3 §5.2 GOVERN 4.2 MEASURE 2.8 A.8
External review §3.6 p. 14 §3.6.1 to 3.6.3 p. 15 §4 item 7 §5.2 §3.1 App. C.3 Overview §1.3.2 MEASURE 1.3 GOVERN 5.1
Internal reporting and non-compliance §4 item 4 §4 item 5 §3.3 p. 13 §5.1 App. C.3 App. B §4.1 §1.3.2 GOVERN 4.3 MANAGE 4.3 GOVERN 2.1 10.2 A.3
Policy versioning and updates §4 item 8 Changelog Intro p. 3 App. B App. A §4.4 §5.1 §5.3 GOVERN 1.5 MANAGE 4.2 7.5 5.2
Link to regulation Intro p. 4 Intro fn. 1 §1 p. 5 §5.2 GOVERN 1.1

By dimension

Each dimension: the question it answers, a short neutral reading, then every mapped section.

Risk domains covered

Which catastrophic-risk domains does the policy track, and which are research categories only?

Anthropic's threshold table has four rows: two for chemical and biological weapons, one for misaligned AI in high-stakes settings and one for automated R&D 1. OpenAI tracks biological and chemical, cybersecurity and AI self-improvement, and keeps other areas, nuclear and radiological among them, as research categories 2. Google DeepMind sets levels for CBRN, cyber, harmful manipulation (labelled exploratory), machine learning R&D and misalignment 3. NIST and ISO ask an organisation to identify its risks without naming a domain 45.

  • §1 p. 6 Anthropic RSP 1. Our Recommendations for Industry-Wide Safety The threshold table has four rows: non-novel chemical/biological weapons production, novel chemical/biological weapons production, misaligned AI systems in high-stakes settings, and automated R&D in key domains; cyber and persuasion have no row. Source ↗
  • §1 p. 8 Anthropic RSP 1. Our Recommendations for Industry-Wide Safety For now, our evaluations will focus specifically on AI R&D, as this domain likely plays to AI systems' current strengths The automated R&D row names energy, robotics, weapons development and AI itself as domains, and states that evaluations currently focus on AI R&D. Source ↗
  • Intro p. 3 Anthropic RSP Introduction although this policy focuses on catastrophic risks, they are not the only risks we consider important The policy is limited to catastrophic risks; other risks are handled through the Usage Policy and societal impacts research. Source ↗
  • §2.2 OpenAI PF Tracked Categories Defines three Tracked Categories (Biological and Chemical, Cybersecurity, AI Self-improvement), each with a threat model approved by the SAG. Source ↗
  • §2.3 OpenAI PF Research Categories Lists Research Categories that do not yet meet the tracking criteria: Long-range Autonomy, Sandbagging, Autonomous Replication and Adaptation, Undermining Safeguards, Nuclear and Radiological. Source ↗
  • §2.3 (box) OpenAI PF Changes to Tracked Categories in version 2 Persuasion category risks do not fit the criteria for inclusion. Explains the split of former Model Autonomy, the move of Nuclear and Radiological to a Research Category, and that Persuasion is handled outside the Framework (text continues on PDF page 9). Source ↗
  • §1.2 DeepMind FSF 1.2 Critical Capability Levels and Tracked Capability Levels For misuse risk, we define CCLs in the following risk domains where the misuse of model capabilities Defines CCLs for misuse risk in three domains (CBRN, cyber, harmful manipulation) and for machine learning R&D and misalignment risk. Source ↗
  • §1.3.1 DeepMind FSF 1.3.1 Risk Identification CBRN, cyber, harmful manipulation, as well as machine learning R&D and misalignment. Names the four identified risk domains and states that other domains continue to be assessed and the approach will be updated as appropriate. Source ↗
  • §2.2.3 DeepMind FSF 2.2.3 Harmful Manipulation The CCL and our assessment of the risk in this domain is exploratory and subject to further research Labels the harmful manipulation CCL and its risk assessment as exploratory and subject to further research. Source ↗
  • MAP 5.1 NIST AI RMF MAP 5.1: Likelihood and magnitude of each identified impact (both potentially beneficial and harmful) based on expected use, past uses of AI systems in similar contexts, public incident reports, feedback from those external to the team that developed or deployed the AI system, or other data are identified and documented. Asks for the likelihood and magnitude of each identified impact to be documented, the generic counterpart of naming the risk domains a policy tracks. Source ↗
  • MEASURE 3.1 NIST AI RMF MEASURE 3.1: Approaches, personnel, and documentation are in place to regularly identify and track existing, unanticipated, and emergent AI risks based on factors such as intended and actual performance in deployed contexts. Covers identifying and tracking existing, unanticipated and emergent risks, which touches how new risk domains enter scope. Source ↗
  • 6.1.2 ISO 42001 AI risk assessment The AI risk assessment clause is where an organization identifies the AI risks it tracks; it names no catastrophic-risk categories. Source ↗
  • 6.1.4 ISO 42001 AI system impact assessment Covers assessing potential consequences of AI systems for individuals, groups and societies, which touches which harm domains are considered. Source ↗

Capability thresholds

How does the policy define the capability levels that change what the lab must do?

Anthropic sets thresholds in a table of capabilities, planned mitigations and industry-wide recommendations, and keeps AI Safety Levels only to describe present mitigations 1. OpenAI defines High and Critical thresholds for each tracked category 2. Google DeepMind defines Critical Capability Levels and, in version 3.1, lower Tracked Capability Levels 3. NIST's risk tolerance subcategory and ISO's risk assessment and treatment clauses are the closest generic counterparts; neither defines capability levels 45.

  • §1 p. 4 Anthropic RSP 1. Our Recommendations for Industry-Wide Safety The left column identifies capability thresholds that would call for heightened mitigations. Thresholds are set out in a three-column table: capability thresholds, the company's planned mitigations, and industry-wide recommendations. Source ↗
  • §1 p. 9 Anthropic RSP 1. Our Recommendations for Industry-Wide Safety our models would be able to fully substitute for our entire set of Research Scientists and Research Engineers, at competitive costs The automated R&D threshold is operationalized as full substitution for research staff at competitive cost or a defined dramatic acceleration of AI progress. Source ↗
  • App. B p. 17 Anthropic RSP Appendix B: Notes on ASLs Earlier editions of our RSP defined "AI Safety Levels" with specific lists of required controls. AI Safety Levels are retained only to describe present levels of mitigation, not to define required controls for future capability levels. Source ↗
  • §2.2 OpenAI PF Tracked Categories High capability thresholds mean capabilities that significantly increase existing risk vectors for severe harm. Defines High and Critical capability thresholds and what each requires (safeguards before deployment; safeguards during development for Critical). Source ↗
  • §2.2 Table 1 OpenAI PF Table 1: Tracked Categories Gives the High and Critical threshold text, associated risk and risk-specific safeguard guidelines for each Tracked Category (table spans PDF pages 6 to 7). Source ↗
  • §1.2 DeepMind FSF 1.2 Critical Capability Levels and Tracked Capability Levels TCLs are meant to capture significant risks that may manifest at a lower capability threshold than our CCLs Defines Critical Capability Levels (severe harm) and introduces Tracked Capability Levels for significant risks at a lower capability threshold. Source ↗
  • §2.2 DeepMind FSF 2.2 Misuse Capability Levels Sets out the CBRN, cyber and harmful manipulation CCLs and the CBRN TCL, each CCL with a recommended security level (Tables 2.2.1.a to 2.2.3.a, pp. 11 to 12). Source ↗
  • §3.2 DeepMind FSF 3.2 ML R&D and Misalignment Capability Levels Sets a Stealth and Situational Awareness TCL and ML R&D acceleration and automation CCLs (Table 3.2.2.a, p. 15). Source ↗
  • MAP 1.5 NIST AI RMF MAP 1.5: Organizational risk tolerances are determined and documented. Requires organizational risk tolerances to be determined and documented, the generic analogue of a capability threshold. Source ↗
  • GOVERN 1.3 NIST AI RMF GOVERN 1.3: Processes, procedures, and practices are in place to determine the needed level of risk management activities based on the organization’s risk tolerance. Ties the level of risk management activity to the risk tolerance of the organization, as tiered safeguard levels do. Source ↗
  • 6.1.2 ISO 42001 AI risk assessment Covers analysing AI risks and evaluating them against risk criteria, the generic analogue of a threshold; it defines no capability levels. Source ↗
  • 6.1.3 ISO 42001 AI risk treatment Covers selecting treatment options and controls for assessed risks, which touches tying safeguards to a risk level. Source ↗

Evaluation triggers and cadence

When must a model be evaluated: before deployment, on a schedule, or when its capability changes?

Anthropic ties evaluation to Risk Reports on a fixed cadence, with an off-cycle analysis when a model is significantly more capable than those already analysed 1. OpenAI evaluates every covered model before deployment and lists what counts as a covered deployment 2. Google DeepMind requires an assessment before first external deployment and checks later checkpoints for material capability change against alert thresholds 3. Neither Anthropic's nor OpenAI's current text sets a compute-based trigger. NIST and ISO place evaluation inside the ongoing risk process 45.

  • §3.1 p. 11 Anthropic RSP 3.1. Scope and Timing We will publish a Risk Report every 3-6 months. Risk Reports are published on a fixed cadence and cover publicly deployed models plus internally deployed models that exceed prior risk levels for misalignment or automated R&D. Source ↗
  • §3.1 off-cycle Anthropic RSP 3.1. Scope and Timing An off-cycle risk analysis is required when a publicly deployed model is significantly more capable than previously analyzed models, and within 30 days for such an internally deployed model. Source ↗
  • §3.2 OpenAI PF Testing scope Lists covered deployments (frontier models to be deployed externally, significant internal agents, changed deployment conditions, unexpectedly capable updates) and allows a development checkpoint to be covered; no compute-based trigger or fixed calendar cadence is stated. Source ↗
  • §3.3 OpenAI PF Capability threshold determinations Prior to deployment, every covered model undergoes the suite of Scalable Evaluations. Every covered model undergoes the Scalable Evaluations prior to deployment and the results go to the SAG in a Capabilities Report. Source ↗
  • §1.3.2 DeepMind FSF 1.3.2 Inherent Risk Assessment We conduct a critical capability assessment prior to the first external deployment Requires a critical capability assessment before first external deployment, uses material capability change assessments on post-training checkpoints to decide whether later versions need one, and sets alert thresholds to flag a CCL before the next assessment. Source ↗
  • §1.3 DeepMind FSF 1.3 Risk Management Process throughout the model development process, on various checkpoints or versions of a model, both before and after deployment. States that the risk management process runs throughout model development, on checkpoints or versions, before and after deployment. Source ↗
  • §3.2.1 DeepMind FSF 3.2.1 Stealth and Situational Awareness Tracked Capability Level When a model has reached this TCL, we will carry out periodic residual risk assessments of the misalignment risk posed. Once this TCL is reached, periodic residual risk assessments of misalignment risk are carried out, including for high-risk internal deployments. Source ↗
  • MEASURE 2.6 NIST AI RMF MEASURE 2.6: The AI system is evaluated regularly for safety risks – as identified in the MAP function. The AI system to be deployed is demonstrated to be safe, its residual negative risk does not exceed the risk tolerance, and it can fail safely, particularly if made to operate beyond its knowledge limits. Safety metrics reflect system reliability and robustness, real-time monitoring, and response times for AI system failures. Requires the AI system to be evaluated regularly for safety risks and shown to be within risk tolerance before deployment. Source ↗
  • MEASURE 3.1 NIST AI RMF MEASURE 3.1: Approaches, personnel, and documentation are in place to regularly identify and track existing, unanticipated, and emergent AI risks based on factors such as intended and actual performance in deployed contexts. Asks for approaches to regularly identify and track emergent risks, touching evaluation cadence. Source ↗
  • 8.2 ISO 42001 AI risk assessment (operation) The operational clause on performing AI risk assessments at planned intervals and on significant change is the closest match to evaluation triggers. Source ↗
  • 8.4 ISO 42001 AI system impact assessment (operation) The operational clause on performing AI system impact assessments at planned intervals touches assessment cadence. Source ↗

Evaluation method and validity

How are capabilities elicited, and how is the result's validity argued?

Anthropic does not prespecify evaluations; it asks for analysis and arguments that make a strong case for safety, and notes that models may detect testing 1. OpenAI aims elicitation at the high end of what threat actors could achieve and treats sandbagging as a research category 2. Google DeepMind describes early-warning evaluations with scaffolding and extra inference compute, and a safety buffer below each level 3. NIST's MEASURE function is the generic counterpart; ISO's monitoring and measurement clause touches it 45.

  • §1 p. 4 Anthropic RSP 1. Our Recommendations for Industry-Wide Safety we cannot presently give highly specific advance detail on what evaluations will determine whether risk thresholds have been passed The policy states that it does not prespecify evaluations and instead requires analysis and arguments making a strong case for safety. Source ↗
  • §3.3 p. 12 Anthropic RSP 3.3. Contents capability and alignment evaluations (conducted internally and by external parties as appropriate), their results Each Risk Report must document capability and alignment evaluations for in-scope models, including evaluations by external parties where appropriate, and their results. Source ↗
  • §1 p. 8 Anthropic RSP 1. Our Recommendations for Industry-Wide Safety an evolving technology that may increasingly have the ability to detect and manipulate testing. The misalignment row notes that models may increasingly be able to detect and manipulate testing, which limits the guarantees the company gives. Source ↗
  • §3.1 OpenAI PF Evaluation approach we regard any one-time capability elicitation in a frontier model as a lower bound, rather than a ceiling, on capabilities Describes elicitation aimed at the high end of expected threat-actor elicitation, Scalable Evaluations with indicative thresholds, and Deep Dives that validate them. Source ↗
  • §2.3 Table 2 OpenAI PF Table 2: Research Categories Adopt elicitation approach that overcomes sandbagging, or use a conservative upper bound of the model's non-sandbagged evaluation results The Sandbagging row sets the response when evaluation behaviour may diverge from performance under real conditions. Source ↗
  • §1.3.2 DeepMind FSF 1.3.2 Inherent Risk Assessment we seek to apply appropriate scaffolding, inference compute, and other augmentations Describes early warning evaluations and applying scaffolding, inference compute and other augmentations; continues on p. 6 with more frequent evaluation or adjusted alert thresholds if the safety buffer is no longer adequate. Source ↗
  • §1.3.2 note DeepMind FSF Note on Machine Learning R&D CCLs other actors may put significantly more effort into eliciting capabilities than we put into assessing risk, thus requiring conservatism Notes that other actors may put more effort into elicitation than the assessment does, requiring conservatism, and allows internal ML R&D progress data to inform the ML R&D CCL assessment. Source ↗
  • MEASURE 2.5 NIST AI RMF MEASURE 2.5: The AI system to be deployed is demonstrated to be valid and reliable. Limitations of the generalizability beyond the conditions under which the technology was developed are documented. Requires the system to be demonstrated valid and reliable and the limits of generalizability to be documented. Source ↗
  • MAP 2.3 NIST AI RMF MAP 2.3: Scientific integrity and TEVV considerations are identified and documented, including those related to experimental design, data collection and selection (e.g., availability, representativeness, suitability), system trustworthiness, and construct validation. Covers scientific integrity and TEVV considerations, including experimental design and construct validation. Source ↗
  • MEASURE 2.13 NIST AI RMF MEASURE 2.13: Effectiveness of the employed TEVV metrics and processes in the MEASURE function are evaluated and documented. Asks for the effectiveness of the TEVV metrics and processes themselves to be evaluated. Source ↗
  • 9.1 ISO 42001 Monitoring, measurement, analysis and evaluation Covers determining methods for monitoring, measurement, analysis and evaluation so results are valid; it is not specific to capability elicitation. Source ↗
  • A.6 ISO 42001 AI system life cycle The life cycle control objective includes verification and validation of AI systems. Source ↗

Deployment safeguards

What must be in place before a model that reaches a threshold is deployed?

Anthropic plans to keep ASL-3 protections for its chemical and biological thresholds and describes implemented mitigations in each Risk Report 1. OpenAI requires a Safeguards Report and safeguards that sufficiently minimise the risk before a model at High capability is deployed 2. Google DeepMind sets a develop, review and update process, with a safety case at a Critical Capability Level 3. NIST's MANAGE function and ISO's risk treatment clauses hold the same decision in generic form 45.

  • §1 p. 6 Anthropic RSP 1. Our Recommendations for Industry-Wide Safety classifier guards at least as robust as our initial Constitutional Classifiers; access controls for trusted users with exemptions to classifier guards For chemical/biological thresholds the company plans to maintain ASL-3 protections, extended to more use cases for the novel weapons threshold. Source ↗
  • §3.3 p. 12 Anthropic RSP 3.3. Contents Risk Reports must describe implemented mitigations across security, deployment safeguards and alignment, with discussion of their effectiveness. Source ↗
  • §4.2 OpenAI PF Safeguard sufficiency Covered systems that reach High capability must have safeguards that sufficiently minimize the associated risk of severe harm before they are deployed. Defines the Safeguards Report (risk pathways mapped to safeguards, efficacy, residual risk, limitations) and requires safeguards that sufficiently minimize risk before deploying High capability systems (PDF pages 11 to 12). Source ↗
  • §4.1 OpenAI PF Safeguard selection Sets the selection process per threshold and separates safeguards against malicious users from safeguards against a misaligned model (Table 3). Source ↗
  • App. C.1, C.2 OpenAI PF C Illustrative safeguards, controls, and efficacy assessments Gives illustrative, non-exhaustive safeguards and efficacy assessments against malicious users (C.1) and a misaligned model (C.2, from PDF page 19). Source ↗
  • §2.1.2 DeepMind FSF 2.1.2 Deployment Mitigations Where the model has reached a CCL, the residual risk assessment will be supplemented with a safety case. Sets a three-step process for external deployments of models at a misuse T/CCL: develop and assess safeguards (with a safety case at a CCL), pre-deployment review, post-deployment updates. Source ↗
  • §3.1.2 DeepMind FSF 3.1.2 Deployment Mitigations limiting affordances, monitoring and escalation, auditing, and alignment training Applies the same process to ML R&D and misalignment T/CCLs, adding high-risk internal deployments and measures such as limiting affordances, monitoring and escalation, auditing and alignment training. Source ↗
  • §1.3.3 DeepMind FSF 1.3.3 Risk Mitigation Distinguishes security mitigations from deployment mitigations and states that specific mitigations may be determined when a T/CCL is reached. Source ↗
  • MANAGE 1.3 NIST AI RMF MANAGE 1.3: Responses to the AI risks deemed high priority, as identified by the MAP function, are developed, planned, and documented. Risk response options can include mitigating, transferring, avoiding, or accepting. Requires responses to high priority AI risks, including mitigation, to be developed, planned and documented. Source ↗
  • MANAGE 4.1 NIST AI RMF MANAGE 4.1: Post-deployment AI system monitoring plans are implemented, including mechanisms for capturing and evaluating input from users and other relevant AI actors, appeal and override, decommissioning, incident response, recovery, and change management. Covers post-deployment monitoring plans, incident response and override mechanisms. Source ↗
  • 8.3 ISO 42001 AI risk treatment (operation) The operational clause on implementing the AI risk treatment plan is the closest match to applying required safeguards. Source ↗
  • 6.1.3 ISO 42001 AI risk treatment Covers choosing risk treatment options and the controls needed to implement them. Source ↗
  • A.6 ISO 42001 AI system life cycle The life cycle control objective includes deployment, operation and monitoring of AI systems. Source ↗

Security of model weights

What protection of model weights and infrastructure does the policy require or recommend?

Anthropic recommends, as an industry-wide measure, weight protection likely in line with RAND SL4 at the novel chemical and biological threshold, and protection against state actors and insiders for automated R&D 1. OpenAI lists the security practices required for High capability models 2. Google DeepMind aligns its recommended security levels with the RAND framework for model weight security 3. NIST covers security and resilience in MEASURE 2.7; the ISO/IEC 42001 clauses in this crosswalk do not address it 45.

  • §1 p. 7 Anthropic RSP 1. Our Recommendations for Industry-Wide Safety This would likely mean security roughly in line with RAND SL4 The industry-wide recommendation for this threshold includes protection against theft or modification of model weights, likely at a level in line with RAND SL4. Source ↗
  • §1 p. 9 Anthropic RSP 1. Our Recommendations for Industry-Wide Safety Even malicious employees and other insiders with maximal levels of access will not be significantly enabled to cause catastrophic harm. The automated R&D recommendation extends security to top-tier state actors and to insiders, including the CEO and privileged technical staff. Source ↗
  • App. C.3 OpenAI PF C.3 Security controls We will require the following practices for High capability models: Lists security practices required for High capability models: threat modeling, defense in depth, least privilege, secure development and supply chain, operational security, independent audits. Source ↗
  • §4.4 OpenAI PF Increasing safeguards before internal use and further development Critical capability models require safety and security controls during development, robust to internal and external malicious actors and to misalignment. Source ↗
  • §2.1.1 DeepMind FSF 2.1.1 Security Mitigations We also define and recommend "Security Level 2+," which uses RAND Security Level 2 (SL2) as a baseline Aligns security levels with the RAND model weight security framework and defines Security Level 2+ with added measures against insider threats and well-resourced non-state actors. Source ↗
  • §3.1.1 DeepMind FSF 3.1.1 Security Mitigations Security mitigations also protect against the risk of the model exfiltrating itself. Covers exfiltration and unauthorized modification for ML R&D CCLs, including the model exfiltrating itself; Table 3.2.2.a (p. 15) recommends Security level 3 and 4. Source ↗
  • §2.2 DeepMind FSF 2.2 Misuse Capability Levels we believe these recommendations will only be effective if the entire frontier AI field applies them Presents recommended security levels as the minimum the frontier AI field should apply and states they are effective only if the whole field applies them. Source ↗
  • MEASURE 2.7 NIST AI RMF MEASURE 2.7: AI system security and resilience – as identified in the MAP function – are evaluated and documented. Requires AI system security and resilience to be evaluated and documented; it does not name model weights specifically. Source ↗
  • ISO 42001 No section maps. No ISO/IEC 42001 clause present in the crosswalk data addresses security of model weights or infrastructure.

Deploy, pause or stop decision

Who decides whether to deploy, restrict, pause or stop, and by which rule?

Anthropic's CEO and Responsible Scaling Officer approve each Risk Report and decide on deployment and development plans; its commitments to delay depend on what competitors do 1. OpenAI's Safety Advisory Group recommends and OpenAI Leadership decides; for Critical thresholds the guideline is to halt further development until safeguards are specified 2. Google DeepMind proceeds only when the appropriate governance function finds the residual risk acceptable 3. NIST asks whether development or deployment should proceed (MANAGE 1.1) 45.

  • §3.4 p. 13 Anthropic RSP 3.4. Procedures The CEO and RSO will make the ultimate determination regarding the adequacy of the risk assessment and any downstream deployment or development plans. The CEO and the RSO approve each Risk Report and decide on downstream deployment or development plans, then notify the Board and LTBT. Source ↗
  • §3.4 item 5 Anthropic RSP 3.4. Procedures When marginal risk analysis plays a major role in a decision to move forward, the Board and LTBT must explicitly approve the Risk Report. Source ↗
  • App. A p. 17 Anthropic RSP Appendix A: Commitments Related to Competitors we would strongly consider pausing development and/or deployment to improve the safety profiles of our models even in cases not covered below. Delay commitments are contingent on competitor scenarios, and the appendix states that pausing may be considered in other cases. Source ↗
  • §4.2 OpenAI PF Safeguard sufficiency Sets the SAG decision points (recommend deployment, request further evaluation, or recommend alternative conditions or additional safeguards), with recommendations going to OpenAI Leadership. Source ↗
  • §2.2 Table 1 OpenAI PF Table 1: Tracked Categories Until we have specified safeguards and security controls that would meet a Critical standard, halt further development For each Critical threshold the safeguard guideline is to halt further development until Critical-standard safeguards and security controls are specified (quote from the Biological and Chemical row; the Cybersecurity row reads "security controls standards"). Source ↗
  • §1 OpenAI PF Introduction We do not deploy models that reach a High capability threshold until the associated risks that they pose are sufficiently minimized. States the deployment rule for High thresholds and the development requirement for Critical thresholds. Source ↗
  • §1.3.5 DeepMind FSF 1.3.5 Risk Acceptance Determination Sets the conditions under which a model at a misuse T/CCL, an ML R&D CCL or the ML R&D and misalignment TCL is deemed acceptable for further development or deployment (continues on p. 8). Source ↗
  • §2.1.2 DeepMind FSF 2.1.2 Deployment Mitigations external deployments of a model take place only after the appropriate governance function determines the residual risk to be acceptable External deployment proceeds only after the appropriate governance function determines residual risk acceptable; §3.1.2 (p. 14) extends this to high-risk internal deployments. Source ↗
  • MANAGE 1.1 NIST AI RMF MANAGE 1.1: A determination is made as to whether the AI system achieves its intended purposes and stated objectives and whether its development or deployment should proceed. Requires a determination of whether development or deployment of the AI system should proceed. Source ↗
  • MANAGE 2.4 NIST AI RMF MANAGE 2.4: Mechanisms are in place and applied, and responsibilities are assigned and understood, to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use. Covers mechanisms and assigned responsibilities to supersede, disengage or deactivate AI systems. Source ↗
  • GOVERN 2.3 NIST AI RMF GOVERN 2.3: Executive leadership of the organization takes responsibility for decisions about risks associated with AI system development and deployment. Places responsibility for decisions about AI development and deployment risks with executive leadership. Source ↗
  • 6.1.3 ISO 42001 AI risk treatment Risk treatment option selection touches the decision to proceed, restrict or avoid; it sets no pause or stop rule. Source ↗
  • A.6 ISO 42001 AI system life cycle The life cycle control objective covers the deployment stage at which a deploy decision is taken. Source ↗

Roles and accountability

Which roles or bodies own the policy and approve decisions under it?

Anthropic names a Responsible Scaling Officer and gives its Board, with the Long-Term Benefit Trust, a role in decisions and policy changes 1. OpenAI sets out the Safety Advisory Group, Leadership as final decision maker and oversight by a committee of its Board 2. Google DeepMind allocates responsibilities across legal, compliance and safety reviews without naming a body 3. NIST GOVERN 2 and ISO clause 5 cover roles and leadership in any organisation 45.

  • §4 item 1 Anthropic RSP 4. Governance a designated member of staff who is responsible for the implementation of this policy The Responsible Scaling Officer is responsible for implementing the policy, with six listed duties including approving development or deployment decisions. Source ↗
  • §4 items 2, 8 Anthropic RSP 4. Governance The LTBT is regularly briefed on Risk Report matters, and the Board approves policy changes in consultation with the LTBT. Source ↗
  • §3.4 item 4 Anthropic RSP 3.4. Procedures After approval, the CEO and RSO share decisions, the Risk Report and internal feedback with the Board and LTBT. Source ↗
  • App. B OpenAI PF B Decision-making practices Making all final decisions, including accepting any residual risks and making deployment go/no-go decisions, informed by SAG's recommendations. Sets SAG responsibilities and membership, OpenAI Leadership (CEO or designee) as final decision maker, and oversight by the Board's Safety and Security Committee, with the Board able to reverse a decision. Source ↗
  • §5.1 OpenAI PF Internal governance Refers to the decision-making practices in Appendix B and commits to documenting reports to the SAG and its decisions and reasoning. Source ↗
  • §4.1 DeepMind FSF 4.1 Governance structure This includes legal, compliance, and safety reviews with escalation procedures to ensure appropriate oversight. States that responsibilities are allocated across the organization with legal, compliance and safety reviews and escalation procedures; it names no specific body or role. Source ↗
  • §5.1 DeepMind FSF 5.1 Updates The updated version and framework assessment will be reviewed by the appropriate corporate governance bodies. States that the updated Framework and the framework assessment are reviewed by the appropriate corporate governance bodies. Source ↗
  • GOVERN 2.1 NIST AI RMF GOVERN 2.1: Roles and responsibilities and lines of communication related to mapping, measuring, and managing AI risks are documented and are clear to individuals and teams throughout the organization. Requires roles, responsibilities and lines of communication for AI risk management to be documented and clear. Source ↗
  • GOVERN 2.3 NIST AI RMF GOVERN 2.3: Executive leadership of the organization takes responsibility for decisions about risks associated with AI system development and deployment. Assigns executive leadership responsibility for decisions about AI risks in development and deployment. Source ↗
  • 5.3 ISO 42001 Roles, responsibilities and authorities Requires top management to assign and communicate responsibilities and authorities for relevant roles. Source ↗
  • 5.1 ISO 42001 Leadership and commitment Covers top management leadership and commitment to the AI management system. Source ↗
  • A.3 ISO 42001 Internal organization The internal organization control objective covers AI roles and responsibilities within the organization. Source ↗

Public reporting

What does the policy commit the lab to publish?

Anthropic publishes a public version of each Risk Report and lists its grounds for redaction 1. OpenAI commits to publishing Preparedness results for major deployments, possibly redacted or summarised 2. Google DeepMind's framework aims to share information with government authorities in defined cases; its per-model reports are separate documents, not a commitment in the framework text 3. NIST and ISO touch transparency as information for users and interested parties 45.

  • §3.5 p. 14 Anthropic RSP 3.5. Publication and Redactions We will publish a public version of our Risk Report. A public version of each Risk Report is published, with listed grounds for redaction and disclosure of the existence of each redaction. Source ↗
  • §2 p. 11 Anthropic RSP 2. Frontier Safety Roadmap The Frontier Safety Roadmap is published in redacted form with updates on whether its goals are achieved. Source ↗
  • §4 item 3 Anthropic RSP 4. Governance Unredacted Risk Reports go to at least 200 employees and minimally redacted versions to all regular-clearance staff. Source ↗
  • §5.2 OpenAI PF Transparency and external participation This published information will include the scope of testing performed, capability evaluations for each Tracked Category, our reasoning for the deployment decision Commits to public disclosure of Preparedness results for major deployments, including safeguards information above a High threshold, possibly redacted or summarized. Source ↗
  • §4.3 OpenAI PF Marginal risk Any reduction of safeguards in response to another developer's release requires public acknowledgment of the adjustment. Source ↗
  • §5.2 DeepMind FSF 5.2 Disclosures we aim to share relevant information with appropriate government authorities where it will facilitate safety of frontier AI. Describes aiming to share model information, evaluation results and mitigation plans with government authorities when a CCL poses unmitigated material risk to public safety; it does not commit to public reports. Source ↗
  • GOVERN 4.2 NIST AI RMF GOVERN 4.2: Organizational teams document the risks and potential impacts of the AI technology they design, develop, deploy, evaluate, and use, and they communicate about the impacts more broadly. Asks teams to document AI risks and impacts and communicate about the impacts more broadly; it does not prescribe public reports. Source ↗
  • MEASURE 2.8 NIST AI RMF MEASURE 2.8: Risks associated with transparency and accountability – as identified in the MAP function – are examined and documented. Covers examining and documenting risks associated with transparency and accountability. Source ↗
  • A.8 ISO 42001 Information for interested parties The control objective on information for interested parties is the closest match to reporting; it does not prescribe public capability or risk reports. Source ↗

External review

What external or third-party review of the models or of the policy does the lab seek?

Anthropic specifies external review of Risk Reports and a yearly third-party review of procedural compliance 1. OpenAI covers third-party evaluations, stress tests of safeguards and independent security audits 2. Google DeepMind lists involving external parties where appropriate among its aims 3. NIST asks for independent assessors; the ISO/IEC 42001 clauses in this crosswalk do not cover external review 45.

  • §3.6 p. 14 Anthropic RSP 3.6. External Review We will work toward a practice of seeking comprehensive, public external review on our Risk Reports. External review of Risk Reports by third parties is described as a practice being worked toward, with a mandatory minimum for significantly redacted reports on highly capable models and on LTBT request. Source ↗
  • §3.6.1 to 3.6.3 p. 15 Anthropic RSP 3.6.1. Selecting external reviewers Reviewer selection criteria, conflict-of-interest limits, LTBT approval, timing, access and the contents of the public review report are specified. Source ↗
  • §4 item 7 Anthropic RSP 4. Governance On approximately an annual basis, we will commission a third-party review that assesses whether we adhered to this policy's main procedural commitments. A third-party procedural compliance review is commissioned about once a year, limited to procedure rather than substantive outcomes. Source ↗
  • §5.2 OpenAI PF Transparency and external participation when available and feasible, OpenAI will work with third-parties to independently evaluate models. Covers third-party evaluation of tracked capabilities, third-party stress testing of safeguards, and independent expert opinions on evidence produced to the SAG. Source ↗
  • §3.1 OpenAI PF Evaluation approach Deep Dives may include resource-intensive third party evaluations and assessments by independent third party evaluators. Source ↗
  • App. C.3 OpenAI PF C.3 Security controls Independent Security Audits: security controls validated regularly by third-party auditors. Source ↗
  • Overview DeepMind FSF Overview Where required or appropriate, involve external parties to help inform and guide the approach. Lists involving external parties, where required or appropriate, as one of the Framework's aims. Source ↗
  • §1.3.2 DeepMind FSF 1.3.2 Inherent Risk Assessment Where appropriate, we may engage relevant external actors, including governments, to inform our responsible development and deployment practices. Refers to reviewing external evaluations and engaging external actors, including governments, where appropriate; §1.3.3 (p. 6) involves internal and external experts when an alert threshold is reached. Source ↗
  • MEASURE 1.3 NIST AI RMF MEASURE 1.3: Internal experts who did not serve as front-line developers for the system and/or independent assessors are involved in regular assessments and updates. Domain experts, users, AI actors external to the team that developed or deployed the AI system, and affected communities are consulted in support of assessments as necessary per organizational risk tolerance. Calls for independent assessors and AI actors external to the development team to be involved in assessments. Source ↗
  • GOVERN 5.1 NIST AI RMF GOVERN 5.1: Organizational policies and practices are in place to collect, consider, prioritize, and integrate feedback from those external to the team that developed or deployed the AI system regarding the potential individual and societal impacts related to AI risks. Covers collecting and integrating feedback from those external to the team that developed or deployed the system. Source ↗
  • ISO 42001 No section maps. No ISO/IEC 42001 clause present in the crosswalk data covers external or third-party review of models or of the policy; A.10 is about supplier and customer relationships and 9.2 is internal audit.

Internal reporting and non-compliance

How are non-compliance, concerns and incidents reported inside the lab?

Anthropic and OpenAI both describe a route for staff to report potential noncompliance, which is investigated; Anthropic adds anti-retaliation protection 12. Google DeepMind mentions escalation procedures and incident reporting in post-market monitoring, without a channel for staff 3. NIST's incident communication subcategory and ISO's nonconformity and corrective action clause are the generic counterparts 45.

  • §4 item 4 Anthropic RSP 4. Governance We will maintain a process for Anthropic staff to submit anonymous or identified reports regarding potential noncompliance with this policy. Staff can report potential noncompliance to more than one recipient; substantiated reports involving material safety risk go to the Board, with anti-retaliation protection. Source ↗
  • §4 item 5 Anthropic RSP 4. Governance Non-disparagement agreements may not impede employees from publicly raising safety concerns. Source ↗
  • §3.3 p. 13 Anthropic RSP 3.3. Contents Risk Reports must address deviations from previously described mitigation practices and missed Roadmap goals. Source ↗
  • §5.1 OpenAI PF Internal governance Any employee can raise concerns about potential violations of this policy, or about its implementation, via our Raising Concerns Policy. Noncompliance: employees can raise concerns via the Raising Concerns Policy; potential noncompliance is tracked, investigated and, if substantiated, corrected. Source ↗
  • App. C.3 OpenAI PF C.3 Security controls Operational Security includes continuous log monitoring and incident response by 24x7 on-call staff. Source ↗
  • App. B OpenAI PF B Decision-making practices Fast-track: a rapidly developing risk of severe harm can be sent to the SAG for urgent processing, coordinated with OpenAI Leadership. Source ↗
  • §4.1 DeepMind FSF 4.1 Governance structure escalation procedures Mentions escalation procedures within legal, compliance and safety reviews, without describing a channel for staff to report noncompliance. Source ↗
  • §1.3.2 DeepMind FSF 1.3.2 Inherent Risk Assessment reporting of incidents relating to our frontier safety risk domains Refers to post-market monitoring, including detection, response and reporting of incidents in the frontier safety risk domains; §2.1.2 and §3.1.2 route material safety case updates to the governance function. Source ↗
  • GOVERN 4.3 NIST AI RMF GOVERN 4.3: Organizational practices are in place to enable AI testing, identification of incidents, and information sharing. Requires organizational practices that enable identification of incidents and information sharing. Source ↗
  • MANAGE 4.3 NIST AI RMF MANAGE 4.3: Incidents and errors are communicated to relevant AI actors, including affected communities. Processes for tracking, responding to, and recovering from incidents and errors are followed and documented. Requires incidents and errors to be communicated and processes for tracking and responding to them to be followed. Source ↗
  • GOVERN 2.1 NIST AI RMF GOVERN 2.1: Roles and responsibilities and lines of communication related to mapping, measuring, and managing AI risks are documented and are clear to individuals and teams throughout the organization. Covers documented lines of communication for AI risk management across the organization. Source ↗
  • 10.2 ISO 42001 Nonconformity and corrective action Covers reacting to nonconformities and taking corrective action. Source ↗
  • A.3 ISO 42001 Internal organization The internal organization control objective includes a process for reporting concerns about the role of the organization with respect to AI systems. Source ↗

Policy versioning and updates

How is the policy itself reviewed, changed and versioned?

All three are versioned documents with a change log. Anthropic's Board approves changes in consultation with the Long-Term Benefit Trust 1; OpenAI reviews its framework at least once a year through its decision process 2; Google DeepMind reviews its framework at least once a year 3. NIST and ISO ask for periodic review of policies and control of documented information 45.

  • §4 item 8 Anthropic RSP 4. Governance Changes to the RSP will be proposed by the CEO and RSO, and approved by the Board in consultation with the LTBT. Changes are proposed by the CEO and RSO, approved by the Board in consultation with the LTBT, published by the effective date and recorded in the Change Log. Source ↗
  • Changelog Anthropic RSP Changelog The Changelog records each version from v1.0 (2023-09-19) to v3.4 (2026-07-08) with a summary of changes. Source ↗
  • Intro p. 3 Anthropic RSP Introduction We have always intended for our RSP to be a living document. The policy describes itself as a living document to be updated as understanding improves. Source ↗
  • App. B OpenAI PF B Decision-making practices We will review and potentially update the Preparedness Framework for continued sufficiency at least once a year. Updates to the Preparedness Framework: the SAG reviews proposed changes and recommends through the standard decision process; review at least annually. Source ↗
  • App. A OpenAI PF A Change log Lists the twelve key changes introduced in version 2. Source ↗
  • §4.4 OpenAI PF Increasing safeguards before internal use and further development we expect to further update this Preparedness Framework before reaching such a level with any model. States an expectation to update the Framework before any model reaches Critical capability. Source ↗
  • §5.1 DeepMind FSF 5.1 Updates an assessment of our adherence to the Framework. Requires review at least once a year (more often if adequacy or adherence is materially undermined), covering appropriateness and adherence, with possible updates to risk domains, T/CCLs and methods. Source ↗
  • §5.3 DeepMind FSF 5.3 Past Updates and Changes Version 3.1 (April 17, 2026) Lists versions 1.0 (2024-05-17), 2.0 (2025-02-04), 3.0 (2025-09-22) and 3.1 (2026-04-17) with the 3.1 changes. Source ↗
  • GOVERN 1.5 NIST AI RMF GOVERN 1.5: Ongoing monitoring and periodic review of the risk management process and its outcomes are planned and organizational roles and responsibilities clearly defined, including determining the frequency of periodic review. Requires periodic review of the risk management process, with defined roles and review frequency. Source ↗
  • MANAGE 4.2 NIST AI RMF MANAGE 4.2: Measurable activities for continual improvements are integrated into AI system updates and include regular engagement with interested parties, including relevant AI actors. Covers integrating continual improvement activities into AI system updates; it addresses systems rather than the policy itself. Source ↗
  • 7.5 ISO 42001 Documented information Covers creating, updating and controlling documented information, including version control. Source ↗
  • 5.2 ISO 42001 AI policy Covers the AI policy that top management establishes, which the frontier policies are the counterpart of. Source ↗

Link to regulation

How does the policy relate to law, such as California SB 53 or the EU GPAI Code of Practice?

Anthropic says the RSP is not designed to meet every regulatory requirement and handles statutory definitions, such as those of California SB 53, in separate compliance frameworks 16. OpenAI's Preparedness Framework does not refer to a law; its Frontier Governance Framework serves as its SB 53 framework and EU GPAI Code summary 27. Google DeepMind's framework aims to share information with governments but names no law 3. NIST GOVERN 1.1 asks that legal requirements be understood; the ISO/IEC 42001 clauses here do not address them 45.

  • Intro p. 4 Anthropic RSP Introduction Where regulatory requirements exceed or differ from what the RSP covers, we will address them through separate documents. The RSP may serve some regulatory requirements but is not designed to be comprehensive; other obligations are handled in separate documents. Source ↗
  • Intro fn. 1 Anthropic RSP Introduction Where laws such as California SB 53 define this or similar terms with specific thresholds, we address those requirements in separate compliance frameworks. Statutory definitions of catastrophic risk, such as those in California SB 53, are addressed in separate compliance frameworks (footnote 1 to the Introduction, printed at the foot of p. 4). Source ↗
  • §1 p. 5 Anthropic RSP 1. Our Recommendations for Industry-Wide Safety The policy recommends third-party governance of frontier developers and harmonized national regulation, including standards of evidence. Source ↗
  • §5.2 DeepMind FSF 5.2 Disclosures If we assess that a model has reached a CCL that poses an unmitigated and material risk to overall public safety Apart from engaging governments where appropriate (§1.3.2), the link to public authorities is the aim to share information with government authorities when a CCL poses unmitigated material risk; the text names no law, and SB 53 appears only in footnote 1, as the address of Anthropic's compliance framework among other examples of frontier safety frameworks. Source ↗
  • GOVERN 1.1 NIST AI RMF GOVERN 1.1: Legal and regulatory requirements involving AI are understood, managed, and documented. Requires legal and regulatory requirements involving AI to be understood, managed and documented. Source ↗
  • OpenAI PF No section maps. The Preparedness Framework does not map itself to SB 53, the EU GPAI Code of Practice or government notification; §2.1 only lists legal and policy mandates as an input to risk assessment, and the regulatory mapping is in the separate Frontier Governance Framework (companion).
  • ISO 42001 No section maps. No ISO/IEC 42001 clause present in the crosswalk data addresses legal or regulatory requirements, and the standard is not tied to SB 53 or the GPAI Code.

Three readings

For policy teams

Read a row across to see how three labs answer the same governance question, then check the version strip: each policy changes on its own schedule 123. Where binding law meets these policies, start from the regulatory row and the companion compliance documents 67.

The topic crosswalk of laws and standards · Frontier-developer laws in chapter 08

For engineers

The thresholds, triggers and methods rows describe the evaluation work these policies assume: repeatable capability evaluations, elicitation that is argued rather than assumed, and records a reviewer can check 123. The site turns that work into controls you can run.

Frontier AI evaluation assurance · The open controls and their profiles

For auditors

An organisation that runs an ISO/IEC 42001 management system can use the ISO column to see where a policy of this kind would sit in it, and the documented gaps in that column to see what a frontier policy adds on top 5. NIST subcategories give the same view for an AI RMF profile 4.

The obligation register · The Framework Crosswalk pattern

Limits and method

  • Only the three policies are mapped. System cards, per-model reports, safety cases and research papers are left out, although the policies refer to them 123.
  • Policy text can lag practice. OpenAI's Version 2 still says no model has reached Critical capability, while OpenAI said on 1 Sep 2026 that a model meets the Critical cybersecurity threshold under that framework 28. This page maps the text as published.
  • Anthropic's companion compliance framework was read through its announcement only; its own version and date were not checked 6.
  • Page numbers are PDF pages, the ones the #page= links open. In OpenAI's PDF they run one ahead of the printed numbers.
  • The page is updated when any of the three labs publishes a new version: the as-of date, the version strip and every cell change together.
  • Every reference was read in the version named above.

Sources

  1. [1] Responsible Scaling Policy, Version 3.4 (effective 2026-07-08; threshold table, Risk Reports, governance, external review, change log). Anthropic. 2026-07-08. https://www-cdn.anthropic.com/files/4zrzovbb/website/0bacdc8440ea96e62a8766d99ebe1d4eea6d5f3a.pdf (verified: primary)
  2. [2] Preparedness Framework, Version 2 (last updated 2025-04-15; Tracked and Research Categories, High and Critical thresholds, Safeguards Reports, Safety Advisory Group). OpenAI. 2025-04-15. https://cdn.openai.com/pdf/18a02b5d-6b67-4cec-ab64-68cdfbddebcd/preparedness-framework-v2.pdf (verified: primary)
  3. [3] Frontier Safety Framework, Version 3.1 (Critical and Tracked Capability Levels, security and deployment mitigations, governance, updates). Google DeepMind. 2026-04-17. https://storage.googleapis.com/deepmind-media/DeepMind.com/Blog/strengthening-our-frontier-safety-framework/frontier-safety-framework_3-1.pdf (verified: primary)
  4. [4] Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1 (subcategory statements as printed in Tables 1 to 4). NIST. 2023-01. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf (verified: primary)
  5. [5] ISO/IEC 42001:2023 Information technology, Artificial intelligence, Management system (catalogue page; clause numbers and titles as in the site's topic crosswalk, text not quoted). ISO/IEC. 2023-12. https://www.iso.org/standard/42001 (verified: primary)
  6. [6] Anthropic's Frontier Compliance Framework (announcement) (the framework Anthropic publishes under California SB 53). Anthropic. 2025-12-19. https://www.anthropic.com/news/compliance-framework-SB53 (verified: primary)
  7. [7] OpenAI Frontier Governance Framework (OpenAI's framework under California SB 53 and public summary under the EU GPAI Code of Practice). OpenAI. 2026-05-28. https://openai.com/index/openai-frontier-governance-framework/ (verified: primary)
  8. [8] Path to Astra: critical capabilities and frontier safeguards (says a model meets the Critical cybersecurity threshold under the Preparedness Framework). OpenAI. 2026-09-01. https://openai.com/index/path-to-astra/ (verified: primary)

Download and cite

The dataset is JSON and CSV, schema version 1, with a notice inside each file that it is a coverage mapping and not a claim of conformity. It is part of the archived Body of Knowledge, not a separate deposit: cite the concept DOI 10.5281/zenodo.22857084, this page and the date you fetched it. Attribution under CC BY 4.0: Jorge García Aibar.

Related: the topic crosswalk of laws and standards · frontier AI evaluation assurance · the open controls · the reading list.

Cite this dataset

García Aibar, J. (2026). Frontier safety crosswalk [Data set]. In AI Governance Engineering: The Thesis & Body of Knowledge (v0.5.0). https://doi.org/10.5281/zenodo.22956197. https://aigovernanceengineer.com/resources/frontier-safety-crosswalk. CC BY 4.0

BibTeX

@misc{aige2026dataset,
  author       = {Jorge García Aibar},
  title        = {{Frontier safety crosswalk}},
  howpublished = {In AI Governance Engineering: The Thesis \& Body of Knowledge},
  year         = {2026},
  version      = {0.5.0},
  doi          = {10.5281/zenodo.22956197},
  url          = {https://aigovernanceengineer.com/resources/frontier-safety-crosswalk},
  note         = {Version 0.5.0}
}