Responsible Scaling Policy (RSP): What It Is and How the Major Labs Compare

A Responsible Scaling Policy (RSP) is a frontier AI developer’s own published commitment to test its models against defined dangerous-capability thresholds, and to apply stronger safeguards before releasing or continuing to train a model that crosses one. The term originates with Anthropic, which published the first RSP in September 2023 and has since revised it several times — the current version, RSP v3.4, took effect July 8, 2026. In practice, “RSP” is now used loosely across the field to describe an entire category of frontier-safety commitment: OpenAI’s Preparedness Framework and Google DeepMind’s Frontier Safety Framework are built on the same underlying logic, even though neither lab calls its own document an RSP.

All three documents are voluntary, self-published policies, not regulation. They are commitments a lab makes to itself and to the public about how it will behave, and their credibility rests on whether the lab actually follows them — which is precisely the gap NIKOLAI, CASRAI’s frontier-AI-safety dictionary, exists to make checkable: NIKOLAI crosswalks the vocabulary these frameworks use (capability threshold, safety case, evaluation run, elicitation method) against what labs actually publish, element by element.

How a Responsible Scaling Policy works

The mechanism is the same across all three frameworks, even where the vocabulary differs:

1. The lab defines a small number of catastrophic-risk domains it is worried about — typically chemical, biological, radiological and nuclear (CBRN) weapons uplift, cyberattack automation, and AI systems that can accelerate their own further development.
2. For each domain, the lab defines a capability threshold: a specific, described level of model capability at which the risk becomes serious enough to require new safeguards.
3. The lab commits to testing its models against these thresholds before and during deployment, using defined evaluation methods.
4. If a model crosses a threshold, the lab commits to applying a pre-defined, stronger tier of safeguards — covering security, deployment restrictions, or both — before continuing.

Anthropic’s RSP names its safeguard tiers AI Safety Levels (ASL), modeled loosely on biosafety-level conventions. Crossing a capability threshold — for example, the AI R&D automation or CBRN uplift thresholds in RSP v3.4 — requires the corresponding tier’s capability threshold commitments, such as the ASL-3 Security Standard and ASL-3 Deployment Standard, to already be in place.

Capability threshold vs. Critical Capability Level (CCL)

The three frameworks use different names for the same basic object, and the differences are worth being precise about because they are not identical in scope:

• Anthropic (RSP v3.4) calls it a capability threshold, tied to an AI Safety Level. Thresholds in the current RSP cover areas including CBRN weapons development, cyberattack capability, and AI R&D automation (with a distinct, more stringent threshold, AI R&D-4, for models capable enough to trigger misalignment-focused commitments).
• OpenAI (Preparedness Framework v2) defines two threshold levels per category — High and Critical — across three Tracked Categories: Biological and Chemical, Cybersecurity, and AI Self-improvement. A separate set of Research Categories (Long-range Autonomy, Sandbagging, Autonomous Replication and Adaptation, Undermining Safeguards, and Nuclear and Radiological) is tracked without yet having defined thresholds, reflecting earlier-stage understanding of those risks.
• Google DeepMind (Frontier Safety Framework v3.1) uses Critical Capability Level (CCL): a capability level at which a model “may pose heightened risk of severe harm” without mitigation, across domains including CBRN, cybersecurity, ML R&D acceleration, harmful manipulation, and misalignment (a model’s capacity to undermine human control or oversight). FSF v3.1 added a second, earlier tier, Tracked Capability Levels (TCLs), which trigger a lighter proportionate-assessment process before a model reaches full CCL severity — there is no equivalent earlier-warning tier in the current RSP or Preparedness Framework.

The practical difference: DeepMind’s two-tier CCL/TCL structure is explicitly built to catch risk earlier in a model’s development, while Anthropic’s and OpenAI’s frameworks concentrate mitigation obligations at a single named threshold per capability area. A full side-by-side of trigger conditions and safeguard obligations across all three frameworks is a longer comparison in its own right — see RSP vs. Preparedness Framework vs. Frontier Safety Framework for the detailed table.

Safety case / affirmative safety case

A safety case (Anthropic’s RSP uses the term affirmative case in the misalignment context; DeepMind’s FSF uses safety case review) is a lab’s written, evidence-backed argument for why a specific model is safe enough to deploy or to continue training, rather than a bare assertion that it is. Under RSP v3.4, once a model crosses the AI R&D-4 capability threshold, Anthropic commits to developing “an affirmative case identifying the most immediate and relevant misalignment risks from models pursuing misaligned goals and explaining how we have mitigated them” before proceeding. DeepMind’s FSF similarly commits to a safety case review before external launches where a relevant CCL has been triggered. NIKOLAI tracks this as a distinct dictionary element — see Safety Case (Assurance Argument) — precisely because “we did a safety case” and “we published a safety case that independent reviewers could evaluate” are very different claims, and the frameworks themselves are not always explicit about which one a given disclosure represents.

Capability elicitation

Capability elicitation is the practice of testing a model at its actual best capability, rather than its capability under casual or default prompting — because a model that fails an evaluation under weak elicitation can still possess the dangerous capability, undetected. Anthropic’s own account of RSP evaluation practice acknowledges that some earlier evaluations “lacked some basic elicitation techniques such as best-of-N or chain-of-thought prompting,” and RSP v3.0 extended evaluation intervals to roughly six months specifically to allow time for higher-quality, better-elicited evaluations rather than rushed ones. NIKOLAI’s elicitation method element exists for the same reason this matters for verification: a disclosure that a model “passed” an evaluation is close to meaningless without knowing what elicitation effort was applied to try to make it fail.

Dangerous capability evaluations: what they actually test for

Dangerous capability evaluations are the concrete tests run against a model to determine whether it has crossed a capability threshold or CCL. They are domain-specific and typically combine automated benchmarks with structured human-uplift studies. Examples grounded in the frameworks above:

• CBRN / bio-chem uplift: whether a model can provide “meaningful counterfactual assistance” — assistance beyond what a person could already get from tools and information publicly available as a baseline — to a novice actor attempting to create a biological or chemical weapon. This is the operative test in OpenAI’s Preparedness Framework v2 Bio/Chem High threshold, and a close analogue drives Anthropic’s and DeepMind’s CBRN thresholds.
• Cyber-offense capability: whether a model can automate end-to-end cyberattacks against a reasonably hardened target, or automate discovery and exploitation of real vulnerabilities, without substantial human operator input.
• AI R&D / ML R&D acceleration: whether a model’s assistance to a research team is equivalent to adding a skilled research engineer to every researcher’s workflow (OpenAI’s framing), or whether it can significantly accelerate the pace of frontier AI development itself (DeepMind’s framing) — both aimed at the same underlying worry, that AI-accelerated AI development could outpace the safeguards meant to govern it.
• Misalignment / control-undermining behavior: whether a model shows the capacity or propensity to resist correction, shutdown, or oversight by its operator — evaluated separately from the more concrete uplift-style tests above because it concerns the model’s own behavior rather than what it enables a third party to do.

NIKOLAI records individual evaluation runs against these categories as part of its own element set, distinct from the elicitation method applied and from any evaluation-validity threats (systematic reasons a given evaluation result might not reflect true model capability, such as insufficient elicitation, contamination, or scoring artifacts) that could undermine the result.

Model weight security

Model weight security refers to the technical and procedural controls a lab places around access to a frontier model’s trained weights, on the premise that if usable weights leak or are stolen, every downstream safeguard built into the deployed product can be bypassed by simply running the model without them. RSP v3.4’s ASL-3 Security Standard requires measures including multi-party authorization and mandatory code review on production code that could grant persistent, high-privilege access to model weights; temporary access limited to the smallest necessary set of permissions; and hardware-authentication-device prompts with logged justification and employee approval before access is granted. OpenAI’s and DeepMind’s frameworks impose comparable security-mitigation requirements once a model crosses a CBRN- or cyber-relevant threshold, though the specific control catalogs differ by lab.

Pre-deployment testing requirements

All three frameworks require capability evaluation before a new model is deployed, not only afterward. Under RSP v3.4, Anthropic commits to running its defined evaluation suite at regular intervals during training and before external release, escalating to more frequent or more targeted testing as a model’s capability approaches a known threshold. DeepMind’s FSF commits to a safety case review before external launches whenever a relevant CCL has been triggered by internal testing. OpenAI’s Preparedness Framework v2 similarly gates deployment on the tracked-category thresholds described above, with required safeguards specified for each threshold a model is found to have crossed. The common structural claim across all three: a model is not supposed to ship past a threshold with the corresponding safeguards not yet in place.

Tiered / internal deployment

Not every use of a frontier model is “deployment” in the external, public-product sense, and the frameworks distinguish general external release from narrower, higher-trust access. Anthropic’s RSP describes a tiered access system: general access through consumer and API products uses standard safeguards, while specialized use cases can receive enhanced access after due diligence into the requester’s trustworthiness and the beneficial nature of the use case. DeepMind’s FSF separately commits to expanded governance specifically for large-scale internal deployments of advanced ML-research models — recognizing that a model used only inside the lab to accelerate its own AI R&D can pose the risks the framework is meant to catch even if it is never released publicly. NIKOLAI tracks this distinction as internal deployment and internal-use risk, since a framework that only gates public releases can still miss a model whose most consequential use never leaves the lab that built it.

How the three frameworks compare, at a glance

All three commit a lab to: naming specific dangerous-capability domains in advance, defining a threshold within each domain, testing against those thresholds before and during deployment, and pre-committing to specific safeguards once a threshold is crossed. Where they diverge is in threshold granularity (DeepMind’s two-tier CCL/TCL structure vs. single-threshold designs elsewhere), how explicit the required safeguards are once a threshold is crossed, and how much of the underlying evaluation evidence is published rather than only referenced. None of the three frameworks is externally audited by a government body as a condition of operating — all three are unilateral commitments, which is exactly why independently checking what a lab has actually published, against what its own framework calls for, is a distinct and necessary exercise. See RSP vs. Preparedness Framework vs. Frontier Safety Framework for the full comparison.

Frequently asked questions

Is a Responsible Scaling Policy a law or regulation?

No. An RSP is a voluntary policy a company publishes about its own conduct. It creates a public, checkable commitment, but no external regulator currently requires a specific frontier lab to have one or enforces its contents as law.

Do OpenAI and Google DeepMind have their own RSP?

Not under that name. OpenAI’s equivalent document is its Preparedness Framework (currently v2); Google DeepMind’s is the Frontier Safety Framework (currently v3.1). Both serve the same core function as Anthropic’s RSP — defined capability thresholds tied to defined safeguards — with differences in terminology and structure described above.

What actually happens when a lab says a model crossed a threshold?

The specific consequence depends on the framework and the threshold, but it generally means the lab has committed to applying a named, stronger tier of safeguards — tighter security controls around the model’s weights, deployment restrictions, or both — before continuing to train or release that model, and in some cases (such as Anthropic’s AI R&D-4 threshold) to publishing a safety case explaining why it is proceeding anyway.

How current is this page?

This page reflects Anthropic’s RSP v3.4 (effective July 8, 2026), OpenAI’s Preparedness Framework v2 (published April 15, 2025), and Google DeepMind’s Frontier Safety Framework v3.1 (updated April 17, 2026). All three frameworks are revised periodically; check each lab’s own published policy for the current version before relying on a specific threshold or safeguard commitment.