Anthropic publishes Responsible Scaling Policy version 3

Background

A responsible scaling policy is a public document in which an AI developer sets out in advance what it will do as its models become more capable. Rather than promising one fixed set of safeguards forever, such a policy ties specific measures to measured capability thresholds, so that the decision to add a safeguard is made before a model exists rather than under time pressure. The document is meant to be checkable: people outside the company can compare what was promised with what was done.

What version 3.0 changed

On 24 February 2026 Anthropic published version 3.0 of its Responsible Scaling Policy, a comprehensive rewrite of the document ^[1][2]. The clearest structural change was to split the content in two. One part sets out what Anthropic says it will do on its own; the other is described as an industry-wide "capabilities-to-mitigations map" ^[1]. Anthropic called the revised unilateral commitments more realistic, in the sense of being difficult but achievable ^[1].

A capabilities-to-mitigations map is a way of writing down, for a class of model capability, the kinds of safeguards that would be expected to accompany it. Kept at the level of an industry, it is not something a single developer can settle alone; that is why it sits apart from the commitments the company makes for itself.

Two new public documents

The rewrite added two reporting obligations, each tied to a named document.

The first is a Frontier Safety Roadmap. Anthropic committed to publish a roadmap covering security, alignment, safeguards and policy, and to grade its own progress against that roadmap publicly ^[1]. Writing the areas down in advance and then grading progress in public means the assessment of how far the work has gone is visible outside the company rather than kept internal.

The second is a series of Risk Reports, covering capabilities, threat models and mitigations, to be published every 3 to 6 months ^[1]. In certain circumstances those reports are to be given external expert review ^[1]. Together with the roadmap, the reports put the policy on a calendar: a plan with grades attached, and a recurring account of what the models can do and how it is being handled.

Revisions through 2026

Version 3.0 was not the end of the process. Versions 3.1 to 3.4 followed between April and July 2026 ^[2]. Among the changes in that sequence was a role for the Long-Term Benefit Trust in reviewing Risk Reports ^[2]. The policy was therefore revised several times in the months after the rewrite, with the trust that oversees the company drawn into the review of the reports.

Why the structure matters

Two features of the version 3.0 design are worth separating out.

The first is the boundary drawn between unilateral and collective commitments. A single developer can decide what it will do itself; it cannot by itself set the mitigations an entire industry adopts. Putting the two into one document makes visible which promises lie within the company's own control and which depend on others acting as well.

The second is cadence. A roadmap published once and graded publicly, together with risk reports on a 3 to 6 month cycle, turns the policy into a recurring obligation with dates attached rather than a statement issued once and left standing. The versions that followed between April and July 2026 show the text being revised on that kind of schedule ^[2].

Whether commitments of this sort are actually met is a separate question from how they are written. The purpose of publishing a roadmap, a public grade and dated reports is that the question can at least be asked with reference to specific documents rather than to general statements of intent.