版本与法律边界截至 2026-08-16,NIST 官方标注 AI RMF 1.0 正在修订;ISO/IEC 42001:2023 仍是已发布第一版;EU AI Act 的适用时间表已在 2026 年更新。本文只说明治理映射方法,不判断具体义务或认证符合性。
责任不变量参与者可以很多,但每个风险接受、发布、暂停和退役决定只能有可识别的最终责任人;框架名称不能替代 Owner 与证据。

治理对象是完整社会技术系统

治理边界包含业务目标、预期和禁止用途、受影响人群、数据、模型、Prompt、Tool、Runtime、人工流程、供应商和运营环境,并贯穿设计、采购、开发、发布、运行、重大变更与停用。只审模型卡会漏掉资源授权、人工误批、流程绕过和供应商切换。

风险也不限于网络安全。错误决策、公平差异、隐私、透明度、操纵、可访问性、可靠性、成本失控和责任争议可能由同一链路共同产生。系统卡应说明影响对象如何获得披露、纠正、申诉或人工渠道,不能把 Human-in-the-Loop 仅定义为内部按钮。

按影响和自治程度分级用例

分级先看意图用途是否影响权利、机会、资金、健康、安全或关键服务,再看数据敏感度、覆盖人群、规模、Agent 自治、动作可逆性和人类复核有效性。模型相同不代表风险相同:摘要内部会议与自动拒绝贷款需要完全不同的证据和决策权。

“有人审核”只有在审核者获得独立证据、具备权限与时间、能修改或拒绝、不会因批量请求疲劳且有申诉渠道时才真正降低风险。高等级用例需要更强的评测、红队、数据审查、审批、监控、回滚和高层风险接受;禁止用途应在 Capability、策略与采购层阻断。

用例分级变量与门禁强度示例
变量较低风险较高风险治理响应
影响可编辑草稿权利、资金、健康或安全提升独立验证与决策层级
自治只读建议直接执行或多步委派缩小 Capability、增加审批和 Kill Switch
可逆性低成本撤销不可逆或外部承诺前置预览、双人控制和补偿计划
人群与规模小范围内部专家大众或弱势群体、大规模批处理影响评估、申诉和分群监控

责任必须落到组织角色

Business Owner 对用途正当性、受影响人群、业务结果和残余风险接受负责;System/Model Owner 对架构、版本、评测、控制实现和运行证据负责;Data Owner 决定来源、用途、质量、访问与保留;Security、Privacy、Legal 依据专业领域提供挑战和门禁;Operator 与 Approver 对具体操作、培训和升级路径负责。

RACI 不能让所有人都成为 Accountable。发布批准、重大例外、事故分级、暂停和退役分别指定一名最终责任角色,并保留 Consulted 与 Informed。供应商负责其合同范围内的模型和服务,企业仍要对自己的用途、数据、Tool、用户体验和下游影响负责。

治理决策链:专业门禁提供证据,业务责任人作出有边界的风险决定
业务提案用途、非用途、影响人群和价值 Owner。
专业挑战Data、Security、Privacy、Legal 与 Quality。
风险决定放行、限域、补偿控制、拒绝或有期例外。
持续监督指标、事件、申诉、变更与退役触发。

治理以证据包而非承诺运行

审批包至少包含系统边界、用途与非用途、受影响人群、数据来源和处理路径、模型/Prompt/Tool/策略版本、评测切片、威胁模型、安全与隐私控制、Human Oversight、SLO、已知限制、残余风险、监控、回滚和申诉。每项结论绑定时间、环境、Owner 与证据引用。

证据分为设计、实现、测试和运营四类。政策文档只能证明设计意图,配置和代码证明实现,正常、对抗与故障测试证明特定条件下的行为,生产指标、事件和复审证明持续有效。某一层缺失时,评审必须把它记录为差距而不是用另一层替代。

治理主张与可复核证据
主张不足证据可复核证据Owner
只处理必要数据隐私政策一句话字段数据流、配置、抽样 Trace 和访问审计Data / Privacy
高风险动作有人复核页面有确认按钮参数绑定、拒绝率、修改记录和疲劳测试Business / System
注入不会导致越权模型多数会拒绝攻击集、负向授权和外发阻断 TraceSecurity / System
失败可恢复文档写有回滚故障演练、恢复时间和业务对账Operations

重大变更触发重新评估

模型、数据、Prompt、Tool、权限、自治等级、用户群、地域、供应商和人类流程变化都可能改变风险。变更记录比较系统卡、数据流、评测、控制和残余风险,按影响决定局部回归或重新审批;事故、漂移和法规政策更新也能触发评估。

实验环境与正式能力使用不同准入,但“实验”不是绕过底线的标签。它仍需隔离真实用户与敏感数据、限制 Capability、设置时间和规模、指定 Owner 与停止条件。例外记录包含范围、理由、风险、补偿控制、指标、到期、续期权限和回归标准,到期默认关闭而非自动续期。

上线后持续监督

看板按任务、人群、版本、风险和自治切片观察业务正确性、公平差异、安全拒绝、隐私事件、SLO、人工修改/拒绝、申诉、成本和未知终态。供应商通知、用户反馈和近失事件进入统一风险登记,避免只有严重事故才触发治理。

每个指标设置 Owner、阈值、观察窗口和动作。轻度退化可以降低模型或 Tool 范围,中度风险转为强制人工复核,高影响或无法判断时暂停新 Run、撤销能力并保全证据。季度评审重看风险等级、控制有效性、例外和用途漂移;退役还要撤销凭据、关闭入口、处理数据和保留必要审计。

把外部框架映射到内部控制库

NIST AI RMF 1.0以 Govern、Map、Measure、Manage 组织自愿风险管理结果,官方目前标注正在修订;ISO/IEC 42001:2023规定建立、实施、维护和持续改进 AI Management System 的要求;地区法律和行业监管则决定额外义务。三者作用不同,不能互相声称替代。

企业建立一个内部控制库,每项控制记录目标、Owner、适用用例、执行点、版本、测试和运营证据,再维护到各框架条款的多对多映射。框架更新时只做差距分析,不为每个框架复制一套审批、风险登记和证据。认证或遵循自愿框架也不自动等于法律合规。

欧盟委员会 AI Act FAQ截至 2026-08-07 说明:禁止行为、定义和 AI literacy 相关规定自 2025-02-02 起适用;治理和 GPAI 义务自 2025-08-02 起适用;高风险 AI 系统规则从 2027-12-02 起适用,嵌入受监管产品的规则从 2028-08-02 起适用。具体系统仍需按角色、用途和最新官方文本核验,不要把旧路线图硬编码进长期控制。

主动提取:为什么通过一次安全评审仍不能证明系统持续可接受?
模型、数据、Tool、用户与威胁会变化,控制也可能漂移。需要版本绑定的证据、变更触发、生产指标、事件、申诉、例外到期与定期复审。
责任判断:Security 团队是否应成为所有 AI 风险的最终 Accountable?
不应。Security 对安全专业门禁和证据负责,业务 Owner 必须对用途、业务影响和残余业务风险负责;数据、隐私、法律、质量与运营保留各自责任。
框架映射:同一访问控制能否同时响应 NIST、ISO 和法规要求?
可以映射到多个外部要求,但必须分别确认适用范围和证据充分性。内部控制只建一次,不代表满足任一具体法律或认证结论。

资料与事实边界

以下以官方文档、标准、论文和原始工程资料为主。厂商 API、价格、限额与模型能力会变化,落地时仍需按目标版本做能力探测和回归。

  1. NIST AI Risk Management Framework 1.0 — 自愿框架的 Govern、Map、Measure、Manage;官方标注 1.0 正在修订
  2. NIST AI 600-1:Generative AI Profile — 生成式 AI 的跨行业风险与建议行动
  3. ISO/IEC 42001:2023 — AI Management System 第一版已发布标准的官方概要与状态
  4. 欧盟委员会:Navigating the AI Act — 2026 年更新后的风险分类、透明度、治理与适用时间表说明