Responsible Scaling Policy

A tiered framework defining minimum security and deployment controls required at each level of model capability. Each ASL mandates specific interventions:

• ASL-1: No meaningful risk; standard security practices apply
• ASL-2: Early signs of dangerous capabilities; requires trusted computing and insider threat programs
• ASL-3: Model can meaningfully increase risk of catastrophic misuse; requires air-gapped environments and hardware security modules
• ASL-4+: Model poses existential risk; deployment is prohibited until safety cases are validated

Predefined, measurable benchmarks that trigger a mandatory pause and safety review before scaling continues. These thresholds are defined by dangerous capability evaluations:

• CBRN proficiency: Ability to assist in designing chemical, biological, radiological, or nuclear weapons
• Autonomous replication: Capacity to self-exfiltrate, acquire compute, and operate independently
• Persuasion and manipulation: Surpassing human baselines in political or social influence tasks
• Cyber-offense: Ability to discover and exploit zero-day vulnerabilities at scale

Each threshold is linked to a specific evaluation suite with pass/fail criteria.

A structured argument that a system is sufficiently safe to operate in its intended environment. Unlike a simple checklist, a safety case must provide:

• Claims: Explicit assertions about system safety properties
• Evidence: Empirical results from evaluations, red-teaming, and formal verification
• Argumentation: Logical reasoning connecting evidence to claims
• Uncertainty quantification: Explicit acknowledgment of confidence levels and remaining risks

Safety cases are living documents reviewed by internal safety teams and external auditors before each capability threshold is crossed.

Legally and operationally binding commitments that halt scaling unless specific conditions are met. These commitments are designed to be verifiable by external parties:

• Compute caps: Hard limits on training FLOP until safety conditions are satisfied
• Staged rollout: Gradual deployment to restricted user bases with continuous monitoring
• Kill switch mechanisms: Pre-deployed shutdown protocols triggered by anomaly detection
• Third-party audit requirements: Mandatory external validation before crossing ASL boundaries

These commitments transform safety from an aspiration into an enforceable operational constraint.

The organizational architecture that owns and enforces the RSP. Effective governance separates safety authority from product velocity:

• Safety team independence: Direct reporting line to the board, not the CTO
• Veto power: Authority to halt training runs or block deployments without executive override
• Whistleblower protections: Guaranteed anonymity and legal protection for internal reporters
• Board-level risk committee: Dedicated oversight body with technical AI safety expertise

This structure prevents safety-washing by ensuring the RSP is not merely advisory.

Mechanisms for independent verification that RSP commitments are being honored. Transparency requirements escalate with capability:

• ASL-2: Annual third-party audits with summary reports published
• ASL-3: Continuous monitoring by an external auditor with real-time access to training logs
• ASL-4: Regulatory body oversight with mandatory pre-deployment notification

Audits verify compute usage, evaluation results, and safety case validity. Findings are published to prevent regulatory arbitrage and build public trust.

A predefined performance boundary that a model must meet on safety benchmarks before it is approved for deployment. In an RSP context, this threshold acts as a gating criterion; if a model fails to meet the minimum score on dangerous capability benchmarks, the scaling protocol prevents its release. These thresholds are often defined using Reinforcement Learning from Human Feedback (RLHF) evaluations and are continuously re-assessed during post-market surveillance.

A test designed to measure an AI model's proficiency in domains that could cause catastrophic harm, such as bioweapons design or autonomous replication. RSPs mandate that developers run these benchmarks at specific compute thresholds. If a model demonstrates a dangerous capability spike, it triggers an automatic pause on scaling until the risk is mitigated. These evaluations are a critical component of the System Card documentation.

A regulatory mandate requiring developers to report to authorities when training runs exceed a specified computational power limit. Under a Responsible Scaling Policy, internal governance often mirrors this external mandate. Crossing a predefined FLOP/s boundary automatically triggers a mandatory internal review, a new round of Adversarial Robustness Benchmark testing, and a potential halt to further investment until the safety case is validated.

A transparency artifact that documents the safety evaluation and operational context of an entire AI system, not just the model. While a Model Card describes the weights, a System Card is the primary output of an RSP review. It details the specific guardrail configurations, the results of red-teaming exercises, and the residual risk scoring that justified the decision to scale or pause deployment.

A document detailing the findings from an adversarial simulation designed to uncover safety and security flaws in an AI system. RSPs rely heavily on structured red-teaming at every scaling stage. The report must demonstrate that the model resists jailbreak susceptibility and prompt injection vulnerabilities before the policy allows the system to move from a sandboxed environment to a production API with higher user privileges.

A hard-coded, immediate shutdown protocol to halt an AI system's operation during a critical failure or containment breach. This is the ultimate safety backstop in a Responsible Scaling Policy. If the system exhibits specification gaming or alignment faking that bypasses automated guardrails, the kill switch allows the human-on-the-loop overseer to instantly decommission the instance without requiring complex software negotiation or model consent.