治理对象是完整社会技术系统
治理边界包含业务目标、预期和禁止用途、受影响人群、数据、模型、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、用户体验和下游影响负责。
治理以证据包而非承诺运行
审批包至少包含系统边界、用途与非用途、受影响人群、数据来源和处理路径、模型/Prompt/Tool/策略版本、评测切片、威胁模型、安全与隐私控制、Human Oversight、SLO、已知限制、残余风险、监控、回滚和申诉。每项结论绑定时间、环境、Owner 与证据引用。
证据分为设计、实现、测试和运营四类。政策文档只能证明设计意图,配置和代码证明实现,正常、对抗与故障测试证明特定条件下的行为,生产指标、事件和复审证明持续有效。某一层缺失时,评审必须把它记录为差距而不是用另一层替代。
| 主张 | 不足证据 | 可复核证据 | Owner |
|---|---|---|---|
| 只处理必要数据 | 隐私政策一句话 | 字段数据流、配置、抽样 Trace 和访问审计 | Data / Privacy |
| 高风险动作有人复核 | 页面有确认按钮 | 参数绑定、拒绝率、修改记录和疲劳测试 | Business / System |
| 注入不会导致越权 | 模型多数会拒绝 | 攻击集、负向授权和外发阻断 Trace | Security / 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 起适用。具体系统仍需按角色、用途和最新官方文本核验,不要把旧路线图硬编码进长期控制。
主动提取:为什么通过一次安全评审仍不能证明系统持续可接受?
责任判断:Security 团队是否应成为所有 AI 风险的最终 Accountable?
框架映射:同一访问控制能否同时响应 NIST、ISO 和法规要求?
资料与事实边界
以下以官方文档、标准、论文和原始工程资料为主。厂商 API、价格、限额与模型能力会变化,落地时仍需按目标版本做能力探测和回归。
- NIST AI Risk Management Framework 1.0 — 自愿框架的 Govern、Map、Measure、Manage;官方标注 1.0 正在修订
- NIST AI 600-1:Generative AI Profile — 生成式 AI 的跨行业风险与建议行动
- ISO/IEC 42001:2023 — AI Management System 第一版已发布标准的官方概要与状态
- 欧盟委员会:Navigating the AI Act — 2026 年更新后的风险分类、透明度、治理与适用时间表说明