Contents
  1. 一、总体判断
  2. 二、RSP v3.4 的核心治理结构
  3. 三、四类能力阈值
  4. 四、ASL-4 应如何理解
  5. 五、从控制清单转向 Safety Case 的深层影响
  6. 六、Frontier Safety Roadmap 的价值与边界
  7. 七、Risk Report 是整个框架的核心控制载体
  8. 八、最具争议的机制:Marginal Risk Analysis
  9. 九、外部审查机制:方向正确,但仍不是真正的前置 assurance
  10. 十、内部治理结构的主要优点和不足
  11. 十一、v3.4 相对上一版本的实际变化
  12. 十二、与 MAS / MindForge 银行框架的根本区别
  13. 十三、对银行 Agentic AI 风险治理最有价值的六项借鉴
  14. 十四、最终评价
  15. 参考资料

Anthropic Responsible Scaling Policy v3.4 解读:从控制清单到 Safety Case

对 Anthropic RSP v3.4 的治理结构拆解:四类能力阈值、Risk Report 的控制载体作用、Marginal Risk Analysis 的争议,以及这套前沿实验室自治框架对银行 Agentic AI 风险治理的六项可借鉴之处与三项不可照搬之处。

分析对象:Anthropic,Responsible Scaling Policy v3.4

分析基准日:2026 年 7 月 25 日(新加坡时间)

阅读说明:本文是基于 RSP v3.4 正文与附录的解读笔记,评价部分为独立判断,不代表 Anthropic 立场。文中与 MAS / MindForge 的对照依据公开监管文件,见末节“参考资料”。与本站既有分析(Claude Opus 5 系统卡解读Claude Fable 5 / Mythos 5 系统卡解读)互补:本文拆解的是治理方法本身,两篇系统卡解读则是该方法在具体模型上的实际应用与其证据边界。

一、总体判断

Anthropic《Responsible Scaling Policy v3.4》不是一套完整的企业 AI 风险管理框架,也不是传统意义上的模型风险管理政策。它更准确地说是一套面向 Frontier AI 开发商的:

能力阈值触发机制 + 灾难性风险 Safety Case + 开发/部署决策治理 + 对外问责机制。

其最重要的制度变化,是从早期较为规则化、控制清单化的 AI Safety Level(ASL),转向以“开发商能否提出充分、可信的安全论证”为核心的 argument-based / safety-case-based governance

这种转变提高了框架对技术快速变化的适应能力,但同时降低了控制要求的确定性、可审计性和强制停止能力。RSP v3.4 因此是一份较成熟的“前沿模型安全治理宪章”,但仍然不是严格意义上的独立风险治理或监管级 assurance framework。

二、RSP v3.4 的核心治理结构

RSP v3.4 可以拆解为五个相互连接的层次:

层次 主要机制 实质功能
1. Capability Thresholds 定义四类灾难性能力或使用阈值 决定何时需要升级风险控制和论证标准
2. Frontier Safety Roadmap Security、Alignment、Safeguards、Policy 路线图 将长期安全目标转化为公开计划
3. Risk Reports 每 3–6 个月形成综合风险报告 形成开发和部署决策的 Safety Case
4. Governance CEO、RSO、Board、LTBT、内部举报等 决定谁审查、批准和监督风险
5. Competitor-contingent commitments 根据竞争者能力和安全措施调整承诺 处理 Frontier AI 的集体行动问题

关键逻辑是:

能力增强 → 威胁路径变得可信 → 风险控制升级 → 形成安全论证 → 决定是否继续开发或部署。

这比单纯基于模型规模、参数数量或算力设置门槛更加合理,因为真正的风险来自模型在特定环境中的能力、访问权限、可利用性和行为倾向,而不是模型大小本身。

三、四类能力阈值

RSP v3.4 没有简单采用一个线性的 ASL-1 至 ASL-4 分级,而是分别定义四类重大威胁路径。

1. 非新型化学或生物武器能力

阈值是模型能够显著帮助具备普通技术背景的个人或小团队制造或使用具有灾难性后果的化学、生物武器。

Anthropic 当前计划维持或增强 ASL-3 级保护,例如:

  • Constitutional Classifiers;
  • trusted-user access control;
  • jailbreak red teaming;
  • bug bounty;
  • threat intelligence;
  • 模型权重和基础设施安全控制。

行业标准则要求开发商证明,普通用户或小团队不会因为模型而显著提高造成灾难性伤害的可能性。

2. 新型化学或生物武器能力

这是更高的能力阈值:模型能够替代目前极为稀缺的世界级专家,使资源充足的团队完成端到端的新型生物或化学武器开发。

这不仅要求防止普通用户滥用,还要防御:

  • 有组织的高能力威胁行为者;
  • 模型权重盗窃;
  • 模型修改;
  • 高水平 jailbreak;
  • 内部人员协助。

RSP 认为,这一层级的安全措施可能需要接近 RAND Security Level 4(RAND SL4)。这里的 RAND SL4 是网络和模型权重安全等级,不是 Anthropic 的“ASL-4”。

3. 高风险环境中的失配或恶意 AI

阈值针对具备以下组合特征的系统:

  • 被高度依赖;
  • 能访问敏感资产;
  • 具有一定自主规划能力;
  • 能够欺骗、隐藏行为或规避检测;
  • 有机会实施不可逆的破坏。

RSP 特别关注 AI 被用于 AI 实验室内部研发的情形,因为模型可能:

  • 修改后续模型的训练过程;
  • 污染训练数据;
  • 操纵安全评估;
  • 隐藏自身能力;
  • 影响人类研究人员的判断。

建议控制包括内部隔离、代码审查、行为监控、能力测试以及对欺骗、操纵和 sabotage propensity 的评估。

4. 关键领域的自动化研发能力

这是 RSP v3.4 中最重要、也是“highly capable model”的实质阈值。

Anthropic 将阈值视为达到以下任一条件:

  1. 模型能够以具有竞争力的成本——成本不超过人类团队约五倍——替代整个 Research Scientist 和 Research Engineer 团队;或
  2. AI 研发自动化导致 AI 总体能力进步速度出现“dramatic acceleration”。

“dramatic acceleration”不是简单的研究人员生产率翻倍,而是 AI 能力进步速度相对于无显著 AI 研发贡献的基线翻倍,并且这种加速具有持续、自我强化的可能。RSP 还要求与至少三代模型的历史趋势进行比较。

该阈值的核心不是“模型会不会自己做任务”,而是:

模型是否已能显著加速产生更强模型的过程,从而压缩社会识别、评估和控制新风险的时间。

四、ASL-4 应如何理解

基于 v3.4,把“ASL-4”简单解释为“自主性安全”并不准确。

RSP v3.4 的实际立场是:

  • ASL 仍可用于描述当前已有的一组安全措施,例如 ASL-3 protections;
  • 但对于未来更高级能力,Anthropic 不再倾向于事先规定固定的 ASL-4 控制清单;
  • 原因是控制清单可能迅速过时,也可能无法覆盖新的攻击和失配路径;
  • 因此,未来更强调开发商针对具体威胁行为者和威胁模型提出一套完整安全论证。

附录 B 明确说明,固定控制清单对于未来能力层级“过于僵化”,因此转向论证系统风险是否被有效控制。

所以更准确的区分是:

概念 含义
ASL-3 Anthropic 当前一组较明确的部署与安全保护措施
ASL-4 在旧版本语境下可能表示更高级保障层级,但 v3.4 不再把它作为固定控制标准
RAND SL4 针对高能力国家级或高资源攻击者的安全防护成熟度
Highly capable model 在 v3.4 中主要由自动化 AI R&D 阈值定义
Safety Case 证明特定模型在特定威胁模型下的风险已被充分控制

五、从控制清单转向 Safety Case 的深层影响

这是 RSP v3.4 最值得关注的制度变化。

Safety Case 的优点

第一,避免控制形式主义。即使开发商完成了所有预设控制,也不代表实际风险已被控制。Safety Case 强迫开发商解释:

  • 威胁行为者是谁;
  • 如何造成伤害;
  • 模型具备哪些必要能力;
  • 控制如何中断攻击链;
  • 控制有效性的证据是什么;
  • 剩余风险是否可接受。

第二,可以适应未知风险。固定清单通常建立在已知攻击路径上,而前沿模型能力和攻击方法变化过快。

第三,把“是否安全”从单项测试转化为综合判断,覆盖:

  • capability;
  • propensity;
  • exposure;
  • threat actor;
  • safeguards;
  • security;
  • residual risk。

Safety Case 的问题

Safety Case 同样存在明显风险:

  1. 论证具有高度主观性 不同开发商可能对“strong argument”采用完全不同的证据标准。

  2. 容易产生 narrative risk 开发商可能通过复杂论述把证据不足包装成合理不确定性。

  3. 缺乏统一风险容忍度 RSP 没有给出明确的灾难概率上限或 residual risk threshold。

  4. 验证成本极高 审查者必须同时理解能力评估、网络安全、对齐、CBRN、威胁情报和组织治理。

  5. 对独立性要求更高 如果安全论证主要由模型开发团队编制,再由公司管理层批准,容易形成确认偏差。

因此,Safety Case 不能替代控制标准。更稳健的模式应当是:

最低强制控制基线 + 风险专属 Safety Case + 独立挑战 + 持续验证。

六、Frontier Safety Roadmap 的价值与边界

Frontier Safety Roadmap 是公开的中长期改进计划,覆盖 Security、Alignment、Safeguards 和 Policy。它的作用是形成一种“forcing function”:让通常会因商业优先级而被延迟的安全工作获得明确资源和管理层关注。Roadmap 会向员工、Board 和 Long-Term Benefit Trust 披露,并公开经删减版本。

其价值在于:

  • 将抽象安全原则转化为明确目标;
  • 可以跟踪未完成事项;
  • 让公众观察安全能力是否跟上模型能力;
  • 防止安全工作仅在模型发布前临时进行。

但 Roadmap 中的目标并非硬性承诺。Anthropic 明确表示目标是“ambitious but achievable”,可以修改,并只是承诺尽量避免因为无法完成而下调目标。

因此,它更接近:

  • management action plan;
  • public safety strategy;
  • capability uplift plan;

而不是:

  • mandatory control standard;
  • regulatory commitment;
  • deployment precondition。

七、Risk Report 是整个框架的核心控制载体

RSP v3.4 中,Risk Report 实际承担了类似银行中以下文件组合的功能:

  • Model Development Report;
  • Independent Validation Report;
  • Risk Acceptance Paper;
  • Residual Risk Assessment;
  • Deployment Approval Paper;
  • Board Risk Paper。

Risk Report 每 3 至 6 个月发布一次,覆盖:

  • 所有公开部署模型;
  • 部分内部部署但显著提高 misalignment 或 automated R&D 风险的模型;
  • 至少包括用于大规模、完全自主研究的内部模型。

当公开部署的模型显著强于此前已公开分析的模型,或者内部模型产生显著新增风险时,还需要进行非周期性更新。报告的 coverage date 可以早于发布日期最多 30 天。

Risk Report 的结构较完整,包括:

  1. 威胁模型识别标准;
  2. 具体威胁模型;
  3. 模型能力和行为倾向;
  4. Security、Safeguards、Alignment 控制及其有效性;
  5. 其他重大风险因素;
  6. 各威胁路径的剩余绝对风险;
  7. 整体风险判断;
  8. 风险—收益论证;
  9. 后续监控和缓释计划;
  10. 过去控制偏离或变更;
  11. 中间部署决策的回顾;
  12. Safety Roadmap 未完成事项。

这比传统 system card 更强,因为 system card 通常说明“模型能做什么”和“测试结果如何”,而 Risk Report 进一步回答:

基于这些能力、威胁和控制,为什么继续开发或部署仍然是合理的。

八、最具争议的机制:Marginal Risk Analysis

RSP 明确承认一种情形:

  • AI 行业总体绝对风险已经很高;
  • 但 Anthropic 认为,即使自己停止,其他开发商仍会继续;
  • 因此,Anthropic 的“边际风险贡献”可能相对有限;
  • 继续开发可能有助于保留安全研究、政策影响和竞争能力。

如果这种 marginal risk analysis 成为继续推进的重要理由,Risk Report 必须增加:

  • 竞争格局分析;
  • 竞争者能力和控制比较;
  • 该比较如何影响风险判断;
  • 继续推进的社会利益;
  • 对监管和行业安全的倡议工作。

并且需要 Board 和 LTBT 明确批准,而不是仅由 CEO 和 RSO 批准。

这一机制具有现实性,但风险也很明显:

“其他人也会做”可能逐渐成为接受高绝对风险的正当化工具。

从独立风险治理角度,边际风险只能作为补充分析,不能取代以下判断:

  • 自身行为是否超出风险承受能力;
  • 自身控制是否足够;
  • 是否存在不可逆风险;
  • 是否违反社会、法律或受托责任。

银行不应采用“市场其他银行也在使用,所以本行部署的边际风险有限”作为风险接受依据。

九、外部审查机制:方向正确,但仍不是真正的前置 assurance

RSP 为外部评审者规定了较好的独立性要求,包括:

  • 具备危险能力和行为评估经验;
  • 理解 alignment faking 等评估失真问题;
  • 有足够声誉激励提出批评;
  • 收入和业务不能完全依赖 Anthropic;
  • 机构、评审人员及其汇报链不能持有 Anthropic 财务利益;
  • 不得与 Anthropic 人员存在密切私人关系。

评审范围覆盖:

  • 信息是否充分;
  • 分析是否严谨;
  • 主要分歧;
  • 进一步风险缓释建议;
  • 删减是否合理;
  • 删减是否影响外界判断风险。

外部评审者还应公开书面意见。

但它仍有三个关键限制:

1. 不是普遍强制

完整外部评审的最低强制触发条件是:

  • 报告涉及“highly capable model”;且
  • 公共版本被“significantly redacted”。

因此,高风险但未被公司认定为 highly capable,或者删减不被内部认定为 significant 的报告,不一定强制接受完整外部评审。

2. 当前并非严格前置审查

外部报告可以在 Risk Report 提交 Board 和 LTBT 后一周内才提供给评审者,评审者有 30 天发表意见。政策只是表示未来希望实现外部评审先于 Board/LTBT 审查。

这意味着当前机制更接近并行或事后 challenge,而不是部署决策的硬性前置条件。

3. 评审者由 Anthropic 选择

虽然需咨询 Board 并获得 LTBT 批准,但评审者仍由被评审机构选择和付费,独立性风险不能完全消除。

十、内部治理结构的主要优点和不足

内部治理的优点

  • 设立专门 Responsible Scaling Officer;
  • RSO 负责政策执行、资源分配、合同审查和非合规事项;
  • 建立匿名举报渠道;
  • 重大安全违规向 Board 报告;
  • 保护员工公开提出安全问题;
  • 每年进行第三方程序合规审查;
  • RSP 变更需 CEO 和 RSO 提出,并由 Board 在咨询 LTBT 后批准;
  • 至少 200 名员工可以查看完整未删减 Risk Report,普通权限员工可查看最低限度删减版本。

内部治理的不足

  1. CEO 和 RSO 通常仍拥有最终实质决策权 Board 和 LTBT 多数情况下只是收到决定和相关材料。

  2. 缺乏正式的第二道防线结构 没有明确要求风险评估必须由独立于开发、部署和商业团队的职能完成。

  3. 年度第三方审查仅关注程序合规 明确不审查风险结论是否正确或控制是否真正有效。

  4. RSO 仍属于管理层体系 没有明确的任期保护、直接向 Board Risk Committee 汇报权或独立预算。

  5. 没有明确 remediation SLA 对发现的问题没有统一整改期限、风险接受期限和逾期升级机制。

从银行 Line 2 视角,这一结构的独立性弱于典型三道防线安排。MindForge 明确提出,AI-specific review 最有效的方式是由未参与开发、部署或运营的人员实施独立挑战;银行框架还要求 Board、Senior Management、Line 1、Line 2 和 Internal Audit 各自承担明确职责。

十一、v3.4 相对上一版本的实际变化

v3.4 的主要修改并不是扩大风险范围,而是提高流程的可操作性:

  1. 修改自动化 R&D 阈值 如果 AI 虽然贡献巨大,但整体进步速度保持不变或正在减速,则不自动视为达到 dramatic acceleration。阈值旨在捕捉递归式能力加速,而不是一般研发生产率提升。

  2. 缩小完整内部披露范围 完整未删减报告改为至少向 200 名员工提供,而不是所有普通权限员工。其他员工获得最低限度删减版本。

  3. 允许 Risk Report coverage date 早于发布时间最多 30 天 有助于提高报告完整性,但增加信息滞后风险。

  4. 公开说明删减的存在及高层原因 提高 redaction accountability。

  5. 允许不同外部专家分别审查报告不同部分 只要所有未删减部分至少被一名评审者覆盖。

整体判断是:

v3.4 提升了证据治理、保密分层和评审可实施性,但没有实质加强停止开发或部署的硬性约束。

它甚至在内部透明度方面做了有限收缩。

十二、与 MAS / MindForge 银行框架的根本区别

维度 Anthropic RSP v3.4 MAS / MindForge
主要对象 Frontier model developer 金融机构的所有 AI 使用
主要风险 灾难性、全球性、CBRN、失配、自动化 R&D 客户、金融、运营、合规、数据、模型、第三方、声誉等
分析单位 模型及开发商活动 Use case、system、model、enterprise
触发逻辑 能力和威胁阈值 Impact、complexity、reliance、risk materiality
主要证据 Risk Report / Safety Case Inventory、risk assessment、testing、validation、monitoring
治理模式 CEO、RSO、Board、LTBT Board、Senior Management、3LOD、治理论坛
生命周期覆盖 重点关注训练、部署和前沿能力 从立项、数据、开发、测试到上线后监控
风险范围 明确非全面 适用于银行所有重大 AI 风险

MAS 提出,金融机构需要覆盖 AI identification、inventory、risk materiality assessment,以及数据、fairness、transparency、human oversight、third-party risk、testing、cybersecurity、auditability、monitoring 和 change management 等全生命周期控制。

因此,银行不能直接采用 RSP 替代 MindForge 或 MAS AIRG。正确方式是:

以 MAS / MindForge 为基础治理框架,把 RSP 的 capability threshold、Safety Case、Risk Report 和外部挑战机制作为高自主性 Agentic AI 的增强层。

十三、对银行 Agentic AI 风险治理最有价值的六项借鉴

1. 引入能力和使用阈值,而不只依赖 use-case materiality

除 impact、complexity 和 reliance 外,可增加:

  • 工具访问能力;
  • 可执行交易或支付;
  • 可修改数据或代码;
  • 可调用其他 Agent;
  • 可持续自主运行;
  • 是否能隐藏行动;
  • 行为是否可逆;
  • 可影响的客户或资产规模。

2. 为高自主性系统建立 AI Safety Case

要求业务和技术团队证明:

  • 系统边界明确;
  • 威胁模型完整;
  • 攻击路径已识别;
  • 控制可中断关键攻击链;
  • 测试覆盖现实攻击者;
  • 剩余风险在风险偏好内。

3. 将高风险 AI Review 从 checklist 升级为 structured argument review

Line 2 不只检查“是否有 HITL”,还应挑战:

  • HITL 在什么节点发生;
  • 人是否拥有足够信息;
  • 是否可能 automation bias;
  • 高风险动作是否真正需要人批准;
  • 人是否能及时中断 Agent。

4. 建立重大 AI Risk Report

对于高影响或高自主性系统,定期形成:

  • capability changes;
  • incidents;
  • control failures;
  • guardrail bypass rate;
  • residual risk;
  • change history; -未完成 remediation;
  • 下一阶段能力增长风险。

5. 建立公开或监管删减登记

第三方模型供应商以知识产权为由拒绝披露时,应记录:

  • 被删减内容类别;
  • 不披露理由;
  • 是否影响 Line 2 判断;
  • 替代证据;
  • compensating testing;
  • residual uncertainty。

6. 禁止以竞争压力作为单独风险接受理由

“竞争者已经部署”“市场上已有同类产品”“其他银行也在使用”最多只能作为外部环境分析,不能证明本行风险可接受。

十四、最终评价

按治理成熟度评估:

方面 评价
威胁模型思维
能力阈值设计 较强,但仍难以客观测量
Safety Case 方法 先进,但证据标准尚未统一
风险报告与追溯
外部透明度 中等偏强
外部审查独立性 中等
决策权独立性 偏弱
硬性停止机制 偏弱
非灾难性风险覆盖 明显不足
对银行直接适用性 低,适合作为增强模块

最核心的结论是:

RSP v3.4 的价值不在于定义了一个新的 ASL-4,而在于把 Frontier AI 风险管理从“满足哪些控制”升级为“能否用充分证据证明风险已被控制”。

但从 Line 2 风险治理角度,仍必须补上三个关键条件:

  1. 独立于开发和商业决策的风险挑战;
  2. 明确且不可随意解释的风险容忍度和停止条件;
  3. 对控制实际有效性的持续测试与独立 assurance。

参考资料

  1. Anthropic, Responsible Scaling Policy(v3.4 正文与附录,本文主要分析对象)
  2. Anthropic, Announcing Anthropic's Responsible Scaling Policy(框架设计意图的背景说明)
  3. GovAI, Anthropic's RSP v3.0: How it Works, What's Changed, and Some Reflections(上一版本的独立评述,用于对照 v3.4 的变化)

本地参考文件

  • MAS, Consultation Paper on Guidelines on Artificial Intelligence Risk Management
  • MindForge AI Risk Management Executive Handbook
  • MindForge AI Risk Management Operationalisation Handbook
  • ABS Handbook on Generative AI Guardrails in Banking
↑ Back to top