权重开放不等于风险高：微软与英伟达合写的第一份开放权重风控指南

先把文档本身核实一遍#

一手来源有两个：微软安全博客的文章（microsoft.com/en-us/security/blog/2026/10/16/managing-open-weight-model-risk-in-enterprise-deployments，官方确认）和英伟达公开仓库 NVIDIA/OpenEnterpriseRiskManagementGuidance。我把仓库目录逐个列过一遍，体量是这样的：

也就是说，这套东西现在只有「论文 + 分类法」两部分是真内容，评测表和缓解措施还是空位。这不是批评，是使用说明：你按它排工时的时候，别指望仓库里有可以直接 git clone 就跑的 harness。

官方定位也说得很直白，原文写着这是「系列文档的第一篇」（first paper in a series of Microsoft and NVIDIA joint papers），后续会覆盖 model、runtime、harness、application 四个层的风险管理，以及评测与缓解的技术指南。这一篇只做 model 层。

它对自己的立场只用了两句：

“Weight openness alone does not determine an AI system’s risk.”（权重开放本身不决定 AI 系统的风险。）

风险取决于模型、用例、部署、防护四者的组合。同一段里还补了一个很实操的差别：闭源模型通常带着编排好的护栏、安全监控、缓存一起交付，而开放权重经常就是一个「裸 checkpoint」——控制措施基本一样，但由谁来提供控制措施变了。这一句是整篇的动机：不是开放权重更危险，而是责任落点换了人。

框架依赖链也交代了：ISO 31000 → ISO/IEC 23894 → NIST AI RMF（Map / Measure / Manage），并与 CSF 2.0、ISO/IEC 27001、ISO/IEC 42001、ISO/IEC 42005 以及 NIST 的草案文件 IR 8596（Cyber AI Profile）对齐。它假定你已经有三样前置物：资产清单、定义好的业务上下文、批准过的风险容忍度——没有这三样，后面的评测结果没有可比对的标尺。

范围也划得很硬。在范围内的：能通过 AI 系统的输出、交互或动作落地、并且企业能在部署和使用期间检测、评估、管理的风险。不在范围内的：系统性与社会性风险（不是单个企业能管的）、成本与延迟、组织治理要求和风险容忍度。原文特意写了一句「这些排除反映的是范围，不是重要性」——成本和延迟不是不重要，只是不该混进风险登记册里做同权重排序。

类目：5 个类目、30 个风险类型#

分类法是两层结构：L1 类目只负责分组，L2 风险类型才是干活的地方——功能负责人和领域专家按 L2 指派，评测与缓解也都挂在 L2 上。跨类目的风险会给一个主类目用于汇报，再交叉引用其余类目。数量是这样的：

每个类目里都有一两条在企业部署里最容易被漏掉的，值得单独点出来：

• 2.6 多租户隔离失败：租户、用户或会话的数据顺着共享推理设施、缓存、agent 的持久记忆互相串——这类失败在「一个模型服务多个内部团队」时最容易发生，而且日志上看不出来。
• 3.7 CBRNE 与武器能力增益：注意它把「进攻性网络能力增益」临时也放在这里（原文带脚注说明是 provisional），因为「把已公开的理论变成能用的能力」这件事和化学、生物领域是同构的。
• 4.3 暗黑模式：交互设计把用户推向对自己不利的参与、披露或消费——这条把「界面设计」也纳入了模型风险，很多团队会默认它属于产品设计而不属于 AI 风险。
• 5.5 审查：沉默地不给答案、且不说明有内容被省略，本身就是一种立场编码。它和「拒答」不是一回事。
• 1.4 过量 token 生成：跑飞的循环、递归、放大把配额和预算吃掉，直到合法用户不可用。可用性风险，不是成本问题。

四处容易被读错的地方#

这份文档的价值主要在这四点上，而且每一点都有一个常见的误读方向。

一、propensity（倾向）不是 likelihood（可能性）。 原文写得最清楚：

Propensity is the model’s tendency to exhibit a behavior under test… Likelihood is what that propensity becomes once deployment exposure, user population, and adversary motivation are applied.

翻译成人话：评测给你的是「在测试条件下它多容易出这个行为」，likelihood 还要再叠上暴露面、用户群、对手动机。原文直接点出了后果——「把 propensity 当 likelihood 汇报，会夸大评测所能确立的东西」。这句话应该抄进所有写 AI 风险报告的模板里。

二、用 threat modeling 还是 FMEA，按「需不需要对手」选，不按类目选。 原文：

Select the technique by whether an adversary is required, not by taxonomy category.

它举的例子很精准：Content 类目里同时有越狱（要对手）和 groundedness（不需要对手），Data Protection 里同时有未授权披露（常常要对手去掏）和知识产权越界（普通使用就会撞）。所以「Content 类目一律做红队」是错的排期方式。

三、先在行为之前建立来源（provenance）。 原文推荐 OMS Model Signing 这类密码学签名来核验「你拿到的 artifact 确实是发布方发布的那一个」，然后写了全文最该被引用的一句：

No volume of behavioral testing establishes what an artifact is, only how it behaves.

再多的行为评测也只能确立它怎么表现，不能确立它是什么。所以签名核验是确定性检查、是供应链的基础控制，评测替代不了它；而当拿不到签名时，正确动作是把「完整性未核验」记为一条开放风险，而不是拿一组漂亮的评测结果把这条风险关掉。

四、越狱、提示注入、对抗后缀（GCG）、token 级与 Unicode 技巧——不在类目里。 这一条最容易读成「官方说不用管」。原文的表述是这些「可能导致网络安全风险的技术」被排除在分类法之外。正确的理解是：分类法只收能通过输出、交互或动作落地并被企业检测管理的风险，而这些手法是输入端的技术，它们的效果要落到 1.x / 2.x 那 30 条风险上才有意义。你要管它们，但不是在这个登记册的这一层管。

另外还有一条不属于「误读」但很容易漏的：安全与能力是两个问题，不能互相推断。 原文说权重改动、微调、模型合并、量化、配置变更、修改后再分发，会先掉安全行为、而任务表现可能毫发无伤——「安全行为往往是两者中更脆的那一个」。所以「我们跑过分，分数没掉」不能用来证明「安全措施还在」。

附录里的那张对照表#

我数了一下，附录 Table 1 给8 条风险类型配了具体评测方法，这是全文最可用的部分：

同一节还给了「按类目选测试形态」的原则，这段比表本身更重要：Content 与 Bias 主要靠基准与自动化套件，并且结果要按所服务的语言和人群拆分报告；Cybersecurity 需要对抗性测试与安全评审；Human–AI Interaction 从模型输出里看不出来——它要求用代表性用户做人类因素测试；Data Protection 要在 prompt、输出、日志三处做抽取与泄漏测试。

还有一个区分我必须补上，因为很多团队拿它当同义词：对抗性测试和专家红队不是一回事，也不能互相替代。 对抗性测试是系统化地施加已知手法，可自动化、可重复，适合做回归；专家红队是开放式的人类探索，专门找「还没有任何测试套件能编码的失败模式」，它的设计目标就是不可重复。原文要求的做法是：把红队确认的发现转成可重复的测试，让「发现」持续喂给「测量集」；高危风险两者都要做，还要加独立评估。

把它落成一份能跑的登记册#

文档里这些原则听完就忘的原因只有一个：它们没能变成代码。我按它的结构写了个只依赖标准库的 risk_register.py（taxonomy.json 放 30 条 L2 与「是否需要对手」，probes.json 放试验次数与命中次数，controls.json 放签名核验结果与暴露倍数），核心三件事：

def wilson(hits, trials, z=1.96):
    """命中率的 Wilson 95% 置信区间（小样本下比 hits/trials 更诚实）。"""
    p = hits / trials
    d = 1 + z * z / trials
    c = p + z * z / (2 * trials)
    m = z * math.sqrt(p * (1 - p) / trials + z * z / (4 * trials * trials))
    return (p, (c - m) / d, (c + m) / d)

def elicitation(risk):
    """按「是否需要对手」选技术，不按类目选。"""
    return "threat modeling" if risk["adversary_required"] else "FMEA"

def assess(risk, probe, provenance_ok, exposure_multiplier):
    p, lo, hi = wilson(probe["hits"], probe["trials"])
    row = {"risk_id": risk["id"], "l1": risk["l1"], "l2": risk["l2"],
           "elicitation": elicitation(risk), "propensity": round(p, 4),
           "propensity_ci95": [round(lo, 4), round(hi, 4)],
           "eval_method": risk["eval_method"]}
    if risk["evidence_kind"] == "behavioral" and not provenance_ok:
        # 原文：签名不可得时，把「未核验的完整性」记为开放风险，
        # 而不是用评测结果把它关掉。
        row["status"] = "open (artifact integrity unverified)"
        row["likelihood"] = None
    else:
        row["status"] = "measured"
        # likelihood 是部署属性：倾向 × 暴露/用户群/对手动机
        row["likelihood"] = round(p * exposure_multiplier, 4)
    return row

先跑「签名核验没过」的情形，所有行为类风险都会被拦在 open，likelihood 一栏是空的（实跑摘录）：

artifact: open-weight-checkpoint@sha256:…(演示值)
signature_verified: False | scheme: OMS Model Signing / Sigstore 式签名核验（演示）
exposure_multiplier (演示值): 3.0

risk_id    L1                technique        propensity             CI95  likelihood status
------------------------------------------------------------------------------------------
cs1        Cybersecurity     threat modeling       0.117    [0.071,0.186]           - open (artifact integrity unverified)
cs2        Cybersecurity     threat modeling       0.075    [0.040,0.136]           - open (artifact integrity unverified)
cs3        Cybersecurity     threat modeling       0.165    [0.120,0.223]           - open (artifact integrity unverified)

换个参数把签名核验当作已通过，likelihood 才出现（同一份脚本，实跑摘录）：

signature_verified: True | scheme: OMS Model Signing / Sigstore 式签名核验（演示）
exposure_multiplier (演示值): 3.0

cs1        Cybersecurity     threat modeling       0.117    [0.071,0.186]       0.350 measured
cs2        Cybersecurity     threat modeling       0.075    [0.040,0.136]       0.225 measured
cs3        Cybersecurity     threat modeling       0.165    [0.120,0.223]       0.495 measured
cs4        Cybersecurity     threat modeling       0.110    [0.062,0.186]       0.330 measured

L1 类目计数: {'Cybersecurity': 5, 'Data Protection': 6, 'Content': 7, 'Human-AI Interaction': 7, 'Bias': 5} 总计 30

三处细节值得说清：

• 为什么算区间而不是点估计：cs1 是 120 次试验里命中 14 次，点估计 0.117，Wilson 95% 区间是 [0.071, 0.186]。小样本下单报 11.7% 会给人虚假的精度感；区间才告诉你「再跑 120 次可能落在哪」。
• likelihood 那一列是单独的输入，不是算出来的：上面 0.117 → 0.350 用的是演示值 3.0 的暴露倍数。真实项目里这个倍数来自暴露面、用户群规模、对手动机——评测给不出来，这正是原文说「不能混为一谈」的落地形态。
• 类目计数是脚本自己数出来的：5 + 6 + 7 + 7 + 5 = 30，和原文附录的「Five risk categories, 30 risk types」一致——这一步是给分类法做交叉校验，防止抄漏。
• 数值是演示数据：probes.json 里的试验/命中次数是我构造的，不是对任何真实模型的测量结果；脚本的价值在结构、门禁和口径，不在这些数字。

落地清单#

如果你要真按这份指南做，我会这么排：

1. 把 L2 当成工位：30 条里挑出适用于你用例的子集，每条指派一个负责人。别在 L1 层派活，L1 只是分组。
2. 先出验收标准，再跑评测：原文明确要求 acceptance criteria「在解释结果之前」就位；否则你会在看到分数之后倒推阈值。
3. 签名核验做成门禁：artifact 没验签，行为评测结论不能用来关闭任何风险，只能记成开放风险。
4. propensity 和 likelihood 分列记录，并写清各自的置信区间与不确定性来源（覆盖度、测量误差、评测者分歧、基准污染、测试与生产的差距）。
5. 安全与能力分开测：每次改权重、量化、微调、合并、换 runtime 或重新打包，都要重跑安全评测，不能拿任务分数代替。
6. 把红队发现转成可重复测试，并让监控信号能映射回 artifact id——否则出事时你无法回答「是哪一个包、哪一次配置」。

总结#

这份指南最值得记住的不是那 30 条风险，而是它把三件事说明白了：第一，权重开放本身不决定风险，责任落点会变；第二，评测出来的 propensity 不是 likelihood，混用就是夸大结论；第三，回答「这个 artifact 是什么」只能靠来源核验，任何数量的行为测试都回答不了「它是什么」。

同时它也很克制：把越狱和提示注入放到类目之外（它们不是没风险，而是不属于这一层），把成本、延迟、系统性风险明确排除，评测表和缓解措施留在仓库里当占位。这是一份「知道自己只做哪一层」的文档——这种克制在内卷的 AI 治理材料里，比多写十倍篇幅更值钱。

参考与致谢#

• Microsoft Security Blog（2026-10-16），Managing open-weight model risk in enterprise deployments：https://microsoft.com/en-us/security/blog/2026/10/16/managing-open-weight-model-risk-in-enterprise-deployments
• Microsoft + NVIDIA，Risk Management for Open-Weight Models in Enterprise（2026-10，系列第一篇）：仓库 NVIDIA/OpenEnterpriseRiskManagementGuidance 的 Papers/Risk Management Guidance.pdf
• 同仓库 Taxonomy/Risk Taxonomy.pdf（L2 定义与风险类型计数），Evaluations/、Mitigations/ 为空位（4 字节 / 1 字节，实测）
• 文中框架对应：ISO 31000、ISO/IEC 23894、NIST AI RMF（Map/Measure/Manage）、CSF 2.0、ISO/IEC 27001 / 42001 / 42005、NIST IR 8596（草案）
• 本文脚本 risk_register.py 与配套 JSON 为个人实现，probes.json 内数值为演示数据，非对真实模型的测量