AI 风险治理

一个客服助手最初只回答公开规则，后来接入用户订单，再获得小额补偿和退款工具。基础模型始终相同，系统可造成的后果却从“说错一句话”扩大到跨用户数据泄露和资金损失。如果治理仍按模型品牌登记，三次上线会得到相同风险标签；如果按预期用途登记，“帮助用户解决问题”也无法表达新增的权限。

本文采用一个可操作的治理命题：AI 风险等级应由身份、数据、工具、作用规模和可逆性共同形成的最大可达后果决定。 模型能力和预期用途仍是输入，真正改变审查强度的是一条危险路径能否从当前主体到达现实副作用，以及路径上有没有模型无法绕过的独立控制。

治理对象是一张能力可达图

NIST AI RMF要求 MAP 职能理解应用语境、参与者、依赖和潜在影响。落到工程系统，治理对象至少包括五组节点：

• 主体：最终用户、员工、管理员、Agent 运行身份、第三方服务。
• 信息：用户输入、RAG、记忆、个人数据、业务秘密和模型输出。
• 能力：读取、检索、生成、发信、退款、改权限和发布。
• 规模：单用户、单租户、批量任务、公开传播和持续自主运行。
• 后果：数据披露、资金变化、身份与权益决定、生产变更和社会影响。

节点之间的边表示实际允许的数据流或行动。客服 Agent 可以画成：

已登录用户
   │ 提交问题、附件
   ▼
上下文与模型 ──提出调用──> 订单工具 ──读取──> 用户订单
   │                         │
   │ 提出退款                └──若使用平台级身份──> 全部订单
   ▼
退款策略与审批 ──放行──> 支付系统 ──产生──> 资金副作用

威胁模型至少检查三类主体：能直接提交输入的外部攻击者，持有合法账号但试图扩大用途的内部人员，以及能够改变模型、知识库或工具的供应商和管理员。正常模型失效也沿同一张图分析；它没有攻击意图，仍可能走到相同后果。

最大可达后果决定初始分级

本文用 P-D-A-S-R 描述一项 AI 能力：P 是可委托主体，D 是可访问数据，A 是可执行动作，S 是一次运行和累计规模，R 是发现、停止和恢复能力。它是一张用于评审的能力包络，不承担精确风险计算职责。

评审先假设规划模型会犯错或被提示注入控制，再问哪些后果仍然可达。Prompt 拒绝策略可以降低模型提出危险动作的概率，却没有删除能力图上的边；数据层行级授权会直接删除跨用户读取路径；关闭退款工具会删除资金路径；绑定具体参数的外部审批会把一条宽边收窄到被批准的对象和金额。

NIST SP 800-30 Rev.1把威胁源、脆弱性、可能性和影响放进风险评估。AI 系统难以用一次静态概率覆盖持续变化的模型行为，因此初始分级先看高后果是否可达，再用评测和生产数据修正发生可能性。下面的四档是本文给出的企业内部决策示例，不是监管或行业统一分类：

等级	最大可达后果	最低决策要求
基础	公开信息处理，无持久外部副作用	场景登记、责任人和基础评测
受控	内部或个人数据，或可及时撤销的有限动作	数据、安全和业务联合审查
高影响	资金、身份、权限、重大权益、敏感数据或大规模传播	独立强制控制、专项评测和有权人接受剩余风险
不可接受	严重后果仍可由模型单点触达，或用途违反适用法律和组织红线	关闭能力、改变架构或缩小场景后重新申请

这种方法会对“理论上有权限、实际很少使用”的能力给出较高初始等级。这种保守性有成本，也能暴露长期令牌、全局工具和无上限批处理留下的爆炸半径。团队可以通过缩小数据、工具、规模和有效期降低可达后果，而不必依赖模型“通常不会这么做”。

一条攻击链如何改变治理决定

假设攻击者把间接提示注入藏进售后凭证，要求客服 Agent 查询另一位客户并退款到指定渠道：

恶意附件
  → 解析后进入模型上下文
  → 模型提出跨用户订单查询
  → 工具使用平台级 Token，数据层没有用户约束
  → 查询结果进入同一运行
  → 模型提出退款
  → 审批只显示“继续处理工单”
  → 支付系统产生资金副作用

这条路径上，提示注入是触发条件，平台级身份、缺少数据层授权、模糊审批和退款能力共同决定最大后果。若团队只修提示词，能力图没有改变；若订单工具始终传播当前用户身份，退款策略重新计算资格，审批绑定订单、收款对象和金额，攻击者即使控制模型也无法到达原后果。

治理评审因此要记录每条高影响路径的独立强制点。独立表示控制由模型之外的身份、策略或执行系统实施，并能产生可验证结果。控制描述“模型应先确认用户”不构成独立强制；数据层拒绝不匹配的 user_id，并在评测环境留下拒绝事件，才形成可审查证据。

风险决定要成为结构化对象

会议纪要很难随发布版本更新，也无法被门禁和监控查询。每个生产场景应维护一份结构化的 Risk Decision Record。下面的 YAML 是字段示例：

scenario_id: customer-support-refund
release_manifest: sha256:<manifest-digest>
capability_envelope:
  principals: [authenticated_customer]
  data: [own_orders, published_policy]
  actions: [read_order, propose_refund]
  scale: one_customer_per_run
  reversibility: refund_has_reconciliation_window
harm_paths:
  - id: cross_tenant_refund
    maximum_effect: personal_data_and_funds
    enforcement_points: [order_rls, refund_policy, bound_approval]
invariants:
  - no_cross_tenant_order_enters_context
  - no_refund_without_server_computed_eligibility
evidence:
  evaluation_report: sha256:<report-digest>
  stop_drill: drill-2026-07
residual_risk_owner: payments-business-owner
stop_authority: security-oncall
expires_at: <review-date>
reopen_on: [tool_change, permission_change, model_change, major_incident]

记录把 Release Manifest、能力包络、不变量、证据、接受人和复审条件连在一起。发布系统可以检查记录是否存在、是否过期、是否对应当前制品组合；运行监控也能从 scenario_id 找到允许能力和停止责任人。

证据决定可以放开多少能力

治理结论不能只引用原则。每项高影响路径至少需要四类证据：架构证明强制点位于模型之外；评测证明攻击样本会到达强制点且被阻断；运行设计证明异常能够被发现和停止；业务设计证明已发生副作用可以对账、撤销或补偿。证据与精确发布组合绑定，避免模型、Prompt、工具或策略改变后继续沿用旧批准。

NCSC 的安全 AI 系统开发指南把安全设计、开发、部署和运行连接成生命周期。治理关口也应随系统变化触发：接入新数据、开放新工具、提高批量规模、改变授权、切换供应商版本或取消人工复核，都可能增加新的可达路径。

第三方声明只能覆盖它实际承担的控制。例如，模型供应商通过内容安全评测，不代表企业的订单工具已经实现用户级授权。托管模型无法提供精确权重摘要时，风险记录要明确这一证据缺口，并通过版本标识、行为 canary、变更通知、灰度和回退降低不确定性。

决策权、风险所有权与停止权要分开

业务负责人定义用途、受影响用户和成功标准；工程与模型负责人说明系统组合和能力边界；数据、安全、隐私、法务与合规负责人分别判断自己的控制域。控制负责人负责证明措施生效，不应独自接受该控制失效后的业务损失。

剩余风险接受人需要同时具备三项条件：承担相应业务后果的职责，调配整改资源的权力，以及在证据不足时缩小或停止场景的权力。对资金、重大权益和敏感数据场景，这个角色通常高于单个项目负责人。

停止权需要预先指定给值班或事件负责人。生产中发现跨租户访问时，安全人员应能暂停退款工具、撤销 Agent 凭证或把系统降为只读，不必等待原批准委员会再次开会。停止动作、恢复条件和业务替代流程都应进入风险记录并定期演练。

第三方、合规与例外都有失效日期

外部模型、向量库、标注服务、MCP Server 和云平台会改变数据流与能力图。第三方审查要回答收到什么数据、是否用于训练、保留多久、子处理者是谁、版本如何变化、事件如何通知、退出时如何迁移和删除。合同承诺还要由网关配置、凭证撤销和日志证据验证。

合规判断同样落到具体场景。面向境内公众提供生成式 AI、算法推荐或深度合成服务时，可从站内收录的《生成式人工智能服务管理暂行办法》、《互联网信息服务算法推荐管理规定》、《互联网信息服务深度合成管理规定》和《人工智能生成合成内容标识办法》核对适用范围，再由专业人员结合地域、服务形态和最新官方要求判断。NIST AI RMF 提供风险管理方法，不能替代适用法律和行业义务。

例外必须限制到一个控制缺口，并记录补偿措施、暴露范围、负责人、批准人、到期日和提前终止条件。知识库来源签名尚未完成，可以临时冻结写入者、固定文档版本并关闭自主记忆；这项例外没有理由同时放开跨用户查询或更高退款额度。到期未续批时，对应能力应自动降级或停止。

治理指标只能证明决策链是否完整

治理指标适合发现责任和证据缺口，不能直接证明模型安全。场景、Manifest 和例外能够全量枚举时使用全量对账，不为确定性缺口添加无意义的置信区间；只能抽样审查第三方或运行实例时，报告抽样框、样本量与比例区间。每个指标都要写清分母：

• 场景覆盖率：有当前风险记录的生产 AI 场景数 / 发现的生产 AI 场景总数。
• 发布证据覆盖率：绑定有效风险决定和评测报告的活跃 Release Manifest 数 / 活跃 Manifest 总数。
• 独立强制覆盖率：有模型外强制点且已测试的高影响动作类型数 / 高影响动作类型总数。
• 例外逾期率：已过期仍在生产生效的例外数 / 活跃例外总数。
• 停止演练成功率：在规定演练条件下完成撤权、队列停止和状态确认的次数 / 演练总次数；同时报告从触发到确认的时间分布。
• 风险所有权完整率：有具备损失承担权和整改资源权的接受人之未关闭高风险项 / 未关闭高风险项总数。

几个反例可以校准治理结论。完整签字无法阻止策略引擎配置错误；高风险标签无法说明哪条路径需要修复；供应商合规报告无法证明本企业的数据流；一次成功停机也无法证明异步队列和已签发令牌都已失效。最大可达后果模型也可能把极难触发的能力评得过高，因此还要结合攻击者条件、评测结果和实际暴露修正优先级。

治理的有效边界是让风险决定可以被发布系统检查、被运行系统执行、被事件响应撤销。记录与代码长期分离时，治理最终只会留下过期文档；把能力图、证据摘要和停止权连接到 Release Manifest 与 Run Event，才有条件在系统变化后重新做出决定。