Anthropic's Responsible Scaling Policy (RSP) is one of the two public scaling policies practitioners point at when designing internal AI governance. As of October 2026 the current text is version 3.4, effective July 8, 2026. Version 3.0, published February 24, 2026, was a full rewrite, and four revisions followed in five months 1 2. Any RSP summary written before 2026 describes a structure the policy has since replaced. The document is worth reading once end to end if you have any role in AI governance; this page is the operating summary plus the parts an enterprise team can reasonably copy.
The core structure
Versions 1 and 2 were built around AI Safety Levels (ASLs). Capability evaluations decided whether a model had crossed the next threshold, crossing one made the matching safeguards a precondition for training or deployment, and Anthropic committed not to train or deploy until those safeguards were in place. Version 3 keeps capability thresholds and keeps the ASL-3 protections Anthropic activated in May 2025, but changes three things 1 2.
First, it separates Anthropic's own plan from an industry-wide recommendation. Each capability threshold now carries two sets of mitigations: what Anthropic commits to as a company, and the more demanding set it says every frontier developer should adopt. The policy states that it cannot commit to the second set unilaterally.
Second, the pause is competitor-contingent. Appendix A commits Anthropic to delay development and deployment as needed in two scenarios: when it has clear evidence it is in the lead, and when every competitor with a comparably capable model can make a strong case that catastrophic risk is contained (in that case, only until Anthropic matches their overall risk-reduction posture). Outside those scenarios it may still pause (v3.1 added language saying so), but it no longer promises to. The stated reason is a collective action problem: one developer pausing while others ship without strong mitigations could leave the world less safe, with the least careful developer setting the pace.
Third, it adds two recurring public artifacts. Risk Reports, due every three to six months, assess risk across all of Anthropic's publicly deployed models, plus any internal model that could pose markedly higher misalignment or automated R&D risk, instead of one release at a time, and go to external reviewers in certain circumstances. A Frontier Safety Roadmap lists dated goals for security, alignment, safeguards, and policy; the policy calls them public goals it will grade itself against, not hard commitments.
What did not change: the trigger is capability, not size or compute. A small efficient model that crossed a chemical or biological weapons threshold would trigger the same mitigations as a frontier model crossing it. That is still the right shape for a risk-based regime, because size proxies poorly for capability.
Figure: The if-then deployment gate as versions 1 and 2 of Anthropic's Responsible Scaling Policy wrote it: capability evaluations decide whether a model has crossed a capability threshold, and crossing one makes the matching safeguards a precondition for deployment. If the safeguards cannot be in place in time, the pause-or-restrict clause holds the release. Version 3 keeps the thresholds but makes the hold depend on what competitors are doing; for an internal release policy, the v2 shape is still the one to copy.
What the thresholds cover
Version 3.4 names four capability thresholds. Paraphrased, with Anthropic's own planned mitigations 1:
| Threshold | What crosses it | Anthropic's plan as a company |
|---|
| Non-novel chemical/biological weapons production | Significant help to people with basic technical backgrounds (for example, undergraduate STEM degrees) in making and deploying chemical or biological weapons with catastrophic potential | Maintain or improve ASL-3 protections: classifier guards, access controls for vetted users exempted from those guards, red-teaming and bug bounties, security controls |
| Novel chemical/biological weapons production | A well-resourced team could use the model, end to end, in place of recruiting one of a small number of world-leading specialists | ASL-3-strength protections across a wider set of use cases; threat-pathway analysis shared with policymakers |
| Misaligned AI in high-stakes settings | Heavily relied-on systems with access to sensitive assets and enough autonomy and subterfuge to plausibly sabotage in ways that raise the odds of a later catastrophe | Report capabilities, propensities, monitoring, and overall risk in Risk Reports |
| Automated R&D in key domains | Models could fully substitute for Anthropic's research scientists and engineers at competitive cost (within a factor of 5), or AI progress runs at roughly double its expected rate for reasons that likely trace to automated AI R&D | Security "moonshot" projects, comprehensive logging of internal AI development, systematic alignment assessments, externally reviewed Risk Reports |
ASLs survive as labels for the mitigations in force today (ASL-2, ASL-3), not as a ladder of future levels. Appendix B says a fixed list of controls for future capability levels proved overly rigid, so for those the policy specifies the argument a developer must make instead. The ASL-1 to ASL-4 ladder in older summaries is the v1 and v2 structure.
Where Anthropic says it stands: the August 2026 Risk Report, with a coverage date of July 15, 2026, says Anthropic acts as though its current models meet the non-novel chemical/biological threshold, judges that they do not yet meet the novel one or either automated R&D criterion, and rates all four risks Low. Two of those ratings went up from the February report: misalignment from very low to low, and non-novel chemical/biological after an access-control gap Anthropic found and closed 3. The thresholds themselves were revised three times in 2026 (automated R&D in v3.1 and v3.4, novel chemical/biological in v3.3), so treat the policy, not this table, as authoritative.
What an internal team can lift
Most companies do not need an RSP at this scale. Most companies do need a smaller version of the structure: a written commitment that specific capabilities, once your model or product reaches them, trigger specific additional safeguards.
The lift list:
The if-then structure. Write commitments as "if our model passes the following eval, then we will have implemented the following safeguards before deployment." The form forces the safeguards to be specific and the triggers to be testable.
The capability evaluation discipline. The Policy is anchored in evaluations. Yours should be too. The eval is the trigger; the eval is what an external auditor will look at. Anthropic's "Challenges in Evaluating AI Systems" piece is honest about how hard the eval work is to do right, which is itself a useful reference for setting expectations internally 4.
The pause-or-restrict commitment, in its v2 form. Versions 1 and 2 said the company would not train or deploy if safeguards could not be in place; that is the part customers and regulators want to see in writing. Copy that version, not the v3 one. Anthropic's case for a competitor-contingent pause is about a race between frontier labs, and your release gate has no such race: nobody else ships your product if you hold it. The internal version is a release-gate policy that lists the conditions under which a release is held back, and who has the authority to make that call.
A risk report on a fixed cadence. v3's Risk Reports cover every publicly deployed model, plus internal deployments that could carry higher risk, every three to six months, separately from per-release documentation. The internal equivalent is a quarterly assessment across every AI system in production, which is also the input to the board readout.
The public document and its changelog. Publishing the Policy commits the organization to it, and Anthropic records every revision in a public changelog: nine versions since September 2023. Most internal teams will not publish their own version, but a version that engineering and product leadership have signed, with a changelog that says what changed and why, is the operational equivalent.
The differences from a risk register
A risk register (see Building an AI risk register) is a list of risks with current mitigations and residual risk. The RSP is a forward-looking commitment about what will happen as capabilities increase. The two complement each other: the register documents current state; the Policy documents future thresholds. A working governance program has both.
Mapping to RMF, the EU AI Act, and SB 53
The RSP-style structure maps to the RMF Govern function. The capability evaluations are Measure activities; the safeguards are Manage activities 5.
For a general-purpose AI (GPAI) model with systemic risk under the EU AI Act, the GPAI Code of Practice turns the RSP shape into a commitment for signatories: Commitment 1 asks for a Safety and Security Framework with systemic risk tiers and the mitigations each tier calls for, and Commitment 7 asks for a Model Report before the model is placed on the market 6. California's SB 53, chaptered September 29, 2025, does the same for large frontier developers (over $500 million in annual revenue, models trained with more than 10^26 operations): publish a frontier AI framework, review it at least once a year, and publish a transparency report when deploying a new frontier model 7. RSP v3 keeps statutory duties like these out of the RSP and handles them in separate compliance documents 1. That split is worth copying: a voluntary policy the team can tighten without a legal review, and a compliance document whose wording counsel owns.
What to do this quarter
- Read the current RSP (v3.4) end to end, then read its changelog. The changelog shows thresholds being reworded each time Anthropic tried to operationalize them, which is the step most internal policies skip.
- Identify the two or three capabilities of your product that would, if substantially increased, change your safeguard requirements. Write an if-then for each.
- Decide who has the authority to invoke the pause or restrict clause. Get that authority in writing.
The point is not to build a scaling policy at the frontier-model scale. The point is to internalize the structure: capability triggers, written commitments, deployment gates. The structure works at smaller scales too, and most enterprise teams need a version of it before any external audit conversation will be useful.
The next chapter, OpenAI Preparedness, covers the parallel public document from the other major frontier lab and where it differs from the Anthropic Policy.