13.1 AI 风险治理与影响评估：先决定该不该部署
AI 风险不是模型属性的单项分数。它来自用途、数据、模型、人机分工、组织激励和受影响者之间的关系。同一个文本分类器用来整理个人笔记和筛选求职者，风险完全不同。
本课目标
- 以决策和伤害路径为起点定义 AI system boundary；
- 建立角色、用途、数据与第三方依赖清单；
- 用 Govern–Map–Measure–Manage 组织持续风险管理；
- 区分 model capability、system impact 与 legal classification；
- 为 go/no-go、变更和停用保留审计证据。
1. 先画系统，不要只登记模型
一项 AI 服务至少包含：
数据来源 → 清洗/标注 → 训练或外部模型 API
↓
用户/环境 → Prompt/RAG/工具 → 模型输出 → 人或自动流程 → 现实后果
↑ ↓
日志、反馈、监控 ← 申诉、纠错、事件System inventory 记录：
- owner、provider、deployer、operator 和受影响者；
- intended use、禁止用途和部署地区；
- 输入、输出、数据主体、敏感数据和保留；
- model/checkpoint/API、prompt、retriever、index 和 tools；
- 第三方条款、subprocessors、服务地区和退出方案；
- 自动化程度、人工复核、申诉和紧急停止；
- 关键指标、已知限制和最后评审日期。
模型换版本、用途变化、接入新工具或用户群扩大，都可能改变风险等级，不能沿用旧批准。
2. 从决策和伤害路径开始
先把用途写成一句可验证的话：
谁在什么条件下，依据什么输入，使用输出做什么决定，影响谁。以一个假设的服务资源分配系统为例，展开伤害路径：
某服务团队的旧设备漏报任务
→ 训练数据把“未记录”当成“未完成”
→ 系统预测该团队绩效较低
→ 审核员把分数当作统一事实
→ 资源进一步减少
→ 漏报与低绩效形成反馈回路每条路径标注影响对象、严重性、发生条件、可逆性、持续时间、发现难度和现有控制。风险矩阵可以排序，不能把权利、尊严或群体伤害压成一个看似客观的总分。
同时比较“不部署”的后果和非 AI 方案。若规则、人工抽样或改进数据采集已经足够，复杂模型未必带来净收益。
3. NIST AI RMF 是组织框架，不是合规证书
NIST AI RMF 1.0 用四个函数组织风险管理：
- Govern：建立政策、责任、风险容忍度和组织能力；
- Map：理解用途、环境、参与者和影响；
- Measure：选择测试、指标和不确定性分析；
- Manage：排序、缓解、接受、转移或避免风险，并持续监控。
Govern 贯穿生命周期，Map–Measure–Manage 会随系统变化循环。它是自愿、非行业特定的框架，不是一次填写完的 checklist，也不能证明符合某地法律。生成式 AI 还可参考 NIST AI 600-1 中关于 confabulation、data privacy、information integrity、information security 等风险的补充。
4. 风险分级必须绑定场景
可以建立内部 tier，例如：
以下是内部评审分级，不是法律分类，也不替代 AI Act 的定义。
| 等级 | 场景 | 默认要求 |
|---|---|---|
| 低 | 无外部后果的个人辅助 | 基础安全、隐私与质量测试 |
| 中 | 影响业务流程但有人复核 | 影响评估、监控、override、变更门禁 |
| 高 | 就业、教育、医疗、信贷、公共服务等高影响决策 | 独立审查、严格验证、记录、申诉、停用方案 |
| 禁止 | 组织认定不可接受或法律禁止的用途 | 不开发、不采购、不绕道部署 |
“有人工在环”不会自动降级。审核员可能过度依赖推荐、没有时间核验，或只能在系统预设选项中操作。必须测量 override rate、复核质量、处理时间和人工是否掌握必要信息。
例如在复核演练中放入已知的记录缺失错误，观察审核员是否在时限内发现并改正，不能只统计是否点过“确认”。低 override rate 既可能来自准确建议，也可能来自无效复核，需要已知答案来区分。
5. 法律分类要按角色、地区和日期核验
欧盟 AI Act 展示了一种基于用途和角色的监管结构：它区分禁止实践、特定高风险系统、透明度义务和通用目的 AI 模型等要求。适用义务还取决于 provider、deployer、importer 等角色，以及系统输出是否在欧盟使用。
截至 2026 年 9 月 5 日核验，一般适用日期仍为 2026 年 8 月 2 日，但 Regulation (EU) 2026/1744 已修改高风险时间表：Chapter III 第 1 至 3 节（Article 6(5) 除外）对 Article 6(2)/Annex III 系统从 2027 年 12 月 2 日适用，对 Article 6(1)/Annex I 系统从 2028 年 8 月 2 日适用。其他条款和过渡安排另有规定。项目要记录适用条文、角色、系统类别与核验日期；欧委会概览 用于定位规则，具体义务仍以适用法律文本为准。
合规清单也不是完整伦理评估。法律可能只规定最低要求，而用途漂移、权力不对称或难以补救的伤害仍可能构成 no-go 理由。
6. 把控制落到负责人和证据
每项高优先级风险需要：
risk owner
preventive control
detection / metric
threshold and alert
response playbook
residual risk and approver
evidence location
review date例如“旧设备造成群体漏报”不能只写“提升公平性”。控制可能包括修复采集、展示数据完整度、禁止自动扣减资源、分组监控、人工复核和申诉。每个控制都要有测试结果和 owner。
Model card 可以描述模型训练和已知限制；system card/impact assessment 还要覆盖具体工作流、工具、用户和后果。两者不能相互替代。
7. Go / No-Go 不是会议口号
上线证据包至少回答：
- 目标用途是否必要、比例适当且有可比较基线；
- 受影响者和领域专家是否参与，分歧如何记录；
- 关键数据与第三方来源是否有 provenance、许可和删除路径；
- 性能、公平、安全、隐私和鲁棒性是否按关键 slice 验证；
- 人工复核、通知、解释、纠正和申诉是否真实可用；
- 高严重性失败是否有阻断、回滚和事故流程；
- residual risk 由谁接受，依据是什么；
- 无法监控的重大风险是否导致缩小范围或取消部署。
批准必须绑定版本和期限。过期评审、未审用途扩展或关键依赖变化应触发重新评估。
8. 部署后风险会反向改变数据
系统输出会影响未来标签：预测“高风险”的人受到更多检查，因而产生更多违规记录；被低估的区域得到更少资源，随后表现真的下降。这类 feedback loop 使离线历史数据不再代表部署后的环境。
监控除模型质量外，还包括使用率、override、申诉、资源分配、受影响群体结果、数据漂移、异常行为和第三方变更。出现严重伤害时，停用或回退到非模型流程应当可执行，而不是只存在于文档。
常见误区
- 模型风险等于模型准确率：用途和决策后果决定风险。
- 开源模型无需治理：部署者仍负责自己的数据、工具和结果使用。
- 人类最终点击就有人类监督：还要验证能力、时间、权限和抗自动化偏见。
- 通过某个框架就代表合规：框架、标准、法律和内部伦理审查职责不同。
- 上线审批一次有效：用途、模型和环境变化都会使旧证据失效。
练习
- 为服务团队资源分配建议画完整系统边界并列出角色。
- 写三条含反馈回路的伤害路径。
- 用 Govern–Map–Measure–Manage 整理同一项目的控制。
- 设计一项能检验人工复核是否有效的指标。
- 为模型版本、用途和工具变化定义重新审批触发器。
小结
AI 治理的起点不是给模型贴“可信”标签，而是把用途、角色、决策和后果展开。组织先确定风险容忍度，再映射伤害、测量控制并管理 residual risk；法律义务、技术框架和伦理判断各有边界。
下一课沿用漏报例子计算群体指标，再检查这些指标无法决定什么。
参考资料
- NIST, AI Risk Management Framework 1.0
- NIST, Generative AI Profile, NIST AI 600-1
- European Union, Regulation (EU) 2024/1689
- European Commission, AI Act implementation overview