Responsible Scaling Policy Explained

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:

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.
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.
The lab commits to testing its models against these thresholds before and during deployment, using defined evaluation methods.
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.

Did OpenAI test whether an open-weight model like gpt-oss could be misused after its release on Hugging Face?

Yes. Before releasing gpt-oss-120b and gpt-oss-20b as open-weight models (Apache 2.0, published on Hugging Face on August 5, 2025), OpenAI ran a dedicated Preparedness Framework evaluation built specifically for the open-weight case: because published weights cannot be recalled once released, the lab adversarially fine-tuned copies of the models to simulate a well-resourced attacker trying to strip out safety training, combining helpful-only reinforcement learning with domain-specific capability maximization (added web browsing and expert biorisk data for the biological category; capture-the-flag cyber ranges for cybersecurity). Per OpenAI’s own gpt-oss model card, its Safety Advisory Group concluded that even the adversarially fine-tuned models did not reach the “High” capability threshold in either Biological and Chemical Risk or Cybersecurity, and noted that other already-available open-weight models matched or exceeded that performance — the basis on which OpenAI judged the release an acceptable incremental risk. It is the clearest public example of a lab applying this page’s dangerous-capability-evaluation logic specifically to the open-weight release scenario, where a threshold crossing can’t be walked back with a later patch.

Has any AI model actually triggered an RSP-style safeguard tier, or is this always theoretical?

It has happened once, precautionarily, not as a confirmed threshold crossing. Anthropic activated ASL-3 protections — at the time its highest deployed safeguard tier — for Claude Opus 4 on May 22, 2025, alongside the model’s launch. Anthropic’s own announcement was explicit that this was a precaution rather than a determination: “we have not yet determined whether Claude Opus 4 has definitively passed the Capabilities Threshold that requires ASL-3 protections,” but improved CBRN-related capabilities meant the lab could not confidently rule it out, and the RSP directs Anthropic to apply the stronger tier whenever it cannot make that determination with confidence rather than wait for certainty. It remains the only public instance, across the three frameworks on this page, of a lab actually applying a threshold-triggered safeguard tier to a shipped model rather than only describing the mechanism in the abstract.

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.

Why This Matters for Research Administration

University research-computing and IT-procurement offices selecting an enterprise AI vendor for use in funded research have a genuine, if narrow, use for this page: when comparing options like enterprise Claude, ChatGPT Enterprise, or Gemini, an institution can treat a vendor’s published RSP, Preparedness Framework, or Frontier Safety Framework the way it already treats a SOC 2 report — a public document stating what testing the vendor claims to run, which the office can cite back to the vendor contractually.

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