开放权重 AI 的风险管理框架：六个阶段、四个风险维度（安远AI&智谱）

9 月 29 日，Anthropic 发布的一项最新研究指出，以 GLM-5.3 为代表的新一代开放权重模型，其网络攻击能力正在跨过一个重要阈值。过去更多出现在受控前沿模型中的高级能力，正在逐渐进入任何人都可以下载、修改和部署的开放权重模型。

这使开放权重模型的风险管理变得更加现实。对于 API 模型，开发者仍然可以通过身份认证、调用限制、输入输出检测、日志监控甚至关闭服务等方式持续控制风险；但模型权重一旦公开，原有控制条件就会明显削弱。权重难以召回，安全机制可能被重新微调，下游部署也可能完全脱离原开发者的监控。

针对这一问题，Concordia AI 与 Z.AI 发布了《Frontier Open-Weight AI Risk Management Framework》。

论文原文（PDF）

这套框架延续此前前沿 AI 风险管理框架的基本结构，同时针对开放权重模型不可逆、可修改、难监控等特点进行了调整，形成了两条主线：一条是覆盖模型风险管理全过程的六阶段流程，另一条是用于具体分析风险来源的 E-T-C-R 四维模型。

框架总览

六阶段流程依次包括：

风险识别
↓
风险阈值
↓
风险分析
↓
风险评价
↓
风险缓解
↓
风险治理。

它解决的是“风险应该按照什么流程管理”的问题。

E-T-C-R 则解决“具体应该从哪些角度判断风险”的问题。其中，E 代表 Deployment Environment，即部署环境；T 代表 Threat Source，即威胁源；C 代表 Enabling Capability，即使能能力；R 代表 Societal Resilience，即社会韧性。

前三个维度延续自此前的风险管理框架，而社会韧性是开放权重版本中最值得关注的新增内容。换句话说，这套框架已经不再把模型能力本身视为风险判断的唯一核心，而是进一步考虑模型会在哪里运行、由谁使用，以及现实世界有没有足够的能力承受相应影响。

▎第一阶段：风险识别

风险管理首先需要明确模型可能带来哪些严重风险，但对于开放权重模型，仅仅判断“模型是否具备某种危险能力”还不够。更关键的问题是：公开权重以后，相比现有技术生态，现实风险到底增加了多少。

这对应框架中的 Marginal Risk，即边际风险。如果某项能力已经可以通过其他开放模型、公开工具或者商业 API 轻易获得，那么一个新模型即使拥有类似能力，其额外风险未必很高。反过来，如果一个模型第一次把原本只有专业团队才能完成的任务降低到普通用户也可以操作，那么它造成的风险增量就可能非常明显。

因此，这一阶段的重点不是单独给模型能力打分，而是分析模型能力、现有替代工具以及权重开放后可获得性的变化。最终需要形成一份风险清单，明确哪些能力和使用场景值得进入后续评估。

▎第二阶段：风险阈值

识别风险之后，下一步是确定什么程度的风险可以接受。否则即使模型测试得再充分，也难以回答一个最基本的问题：结果达到什么水平以后需要采取限制措施。

风险阈值相当于为后续评估建立一把统一的尺子。框架需要提前划定不同风险区间，例如哪些情况可以正常进入后续流程，哪些情况需要加强控制，哪些情况已经超出可接受范围。这样做的意义在于避免“先看到结果，再重新定义安全标准”。

这一阶段本身并不负责判断某个具体模型是否可以发布，而是提前建立判断依据。后续风险分析得到具体结果后，再与这些阈值进行比较，最终进入发布决策。

▎第三阶段：风险分析

第三阶段是整套框架的核心。传统模型安全评估往往非常关注模型能力本身，而开放权重框架认为，模型能力只有放入真实环境中才有实际意义，因此风险需要从 E、T、C、R 四个维度综合分析。

E：Deployment Environment，部署环境。 同样一个模型，运行在隔离实验室、普通企业系统或者关键基础设施中，所产生的现实风险完全不同。这里需要分析模型能够接触哪些系统、是否可以访问互联网、是否具备工具调用能力，以及是否能够影响真实环境。

T：Threat Source，威胁源。 模型由谁使用同样会改变风险。普通用户、专业研究人员和组织化程度较高的恶意主体，在资源、专业能力和行为动机上存在很大差异。开放权重模型尤其需要关注这一点，因为模型发布后，开发者很难继续通过账号审核和调用限制控制使用者范围。

C：Enabling Capability，使能能力。 这一维度关注模型能够为用户增加多少实际能力。关键不是 Benchmark 分数本身，而是模型是否显著降低了某些高风险任务的技术门槛，或者把过去难以完成的事情变得更加容易。

R：Societal Resilience，社会韧性。 这是开放权重版本中新增加的一维。它关注的不是模型本身，而是现实世界能否抵抗、吸收、恢复和适应模型可能带来的风险。如果关键基础设施安全水平较低、漏洞长期得不到修复、事件响应能力不足，那么同样的模型能力会产生更高风险；反之，如果外部防御体系已经比较成熟，现实影响就可能有所下降。

因此，开放权重模型的风险不能简单理解为“模型越强越危险”，更准确的判断应该是：模型能力在特定部署环境中，被特定主体使用时，会产生什么影响，而现实社会又具备多强的应对能力。

▎第四阶段：风险评价

完成风险分析之后，框架才进入正式的风险评价阶段。这里需要把 E-T-C-R 分析结果与此前设定的风险阈值进行比较，从而判断当前风险是否处于可接受范围。

开放权重框架并没有把最终决策简化为 Open 或 Closed。相比“发”与“不发”的二元选择，它更强调 Staged Release，也就是阶段性发布。模型可以从内部测试开始，逐步扩大到可信研究者、受控访问、有限开放、阶段性开放，最终再进入完整权重开放。

因此，这一阶段真正需要决定的是“当前适合开放到什么程度”。如果风险较低，可以扩大开放范围；如果风险接近警戒线，则可以限制对象和使用条件；如果风险明显超过阈值，则应推迟甚至暂停完整权重发布。

这种机制也意味着发布决策不是永久不变的。部署环境、威胁水平和社会韧性都会变化，因此今天不适合完整开放的模型，未来可能在条件成熟后重新进入评估。框架所强调的不是一次性的发布审批，而是持续评估和动态调整。

▎第五阶段：风险缓解

对于 API 模型，很多风险缓解措施都可以部署在服务层，例如身份认证、调用限流、输入输出检测和日志审计。但开放权重模型一旦进入下游生态，原开发者无法保证这些措施始终存在，因此风险控制必须更加前移。

这意味着需要更多关注训练数据治理、安全预训练、后训练、能力评估以及发布前限制。开放权重场景下尤其需要区分 Behavioral Safety 和 Capability Safety，也就是行为层安全与能力层安全。

模型经过安全对齐以后可能会拒绝某些请求，但如果底层能力仍然存在，下游用户仍可能通过再次微调改变模型行为。相比“模型会拒绝做”，开放权重环境更关心“模型到底会不会做”。

当然，这并不意味着所有潜在风险能力都可以直接删除。代码、生物、推理等能力往往同时具有正常用途和双重用途，因此风险缓解的目标不是追求绝对消除能力，而是根据前面的风险等级，配置与之相匹配的训练、评估和发布措施。

▎第六阶段：风险治理

开放权重模型还改变了风险责任的分布方式。传统 API 服务的责任链相对集中，模型开发者通常能够控制服务和用户访问；开放权重之后，模型可能依次经过基础模型开发者、模型平台、微调者、量化或衍生版本制作者、应用开发者、部署基础设施，最终到达用户。

这意味着任何一个环节都可能改变模型的行为或实际风险。例如微调者可以调整模型能力，应用开发者可以为模型接入工具和业务系统，部署者则决定模型最终运行在什么环境中。此时，再要求最初的基础模型开发者承担全部安全责任并不现实。

开放权重版本带来的四个变化

如果把整套框架进一步压缩，可以看到四个比较明显的变化。

其中最重要的变化，是社会韧性被正式纳入风险分析。这意味着开放权重 AI 的治理视角已经不再局限于“如何约束模型行为”，而开始进一步考虑现实社会是否具备足够的防御和恢复能力。

从“是否开放”，转向“如何管理开放”

Anthropic 昨天的研究讨论的是一个现实变化：高级网络能力正在进入开放权重模型。而 Concordia AI 与 Z.AI 的这套框架，则试图回答能力扩散之后应该如何治理。

它给出的并不是一个简单的“开放”或“封闭”答案，而是一条更完整的风险管理链：先识别风险和确定阈值，再通过 E-T-C-R 分析现实风险，随后决定发布方式，并配置相应的缓解措施和治理责任。

开放权重因此不再只是一个模型授权方式的问题，而逐渐成为一个贯穿训练、评估、发布和下游使用全过程的风险管理问题。

随着开放权重模型能力继续提升，这套框架真正需要解决的核心问题也会越来越明确：

当强大的模型越来越难以长期保持在封闭环境中，我们应该如何让它的开放过程变得可评估、可控制，也更可承受。