AI 风险管理

它是什么

AI 风险管理是在整个系统生命周期中，持续治理责任、界定使用情境、识别和测量影响，并按优先级处置、监控与沟通风险的组织过程。NIST AI RMF 用 Govern、Map、Measure、Manage 四个相互关联的功能组织这些活动；它们不是必须一次顺序完成的清单，而要随系统和情境变化反复执行。[S1][S2]

为什么需要它

模型质量只是产品风险的一部分。数据来源、用户依赖、自动化权限、第三方服务、申诉渠道和事故响应都会改变影响。没有统一风险过程，各团队可能各自优化指标，却没人决定残余风险是否可接受、谁能停止系统、事故如何通知受影响者。风险管理把技术证据连接到业务选择和明确责任。

它如何工作

Govern 建立政策、角色、风险容忍度和审查节奏；Map 记录用途、相关方、系统组件、预期收益及可能影响；Measure 选择定量与定性方法，测试性能、安全、公平和控制有效性；Manage 根据影响、可能性和资源确定优先级，决定是否继续，并安排缓解、限制、停用、事件响应、恢复和持续改进。每项重要风险都应有所有者、证据、控制、残余风险和复核时间。[S1][S2]

必须澄清的误会

风险管理 ≠ 治理。 风险管理处理的是风险这一条线：识别、评估、处置、监控。治理还要回答谁有权决定、出了事谁负责、对外如何说明。一个团队可以有一份像样的风险清单，却依然没有治理结构——那时风险会被记录，但不会被处理。

风险管理 ≠ 安全技术。 护栏、过滤器、权限控制都是具体手段；风险管理决定这些手段该用在哪、用多严、由谁复核。手段先上、判断后补，通常表现为「拦了很多正常请求，真正危险的场景仍然没覆盖」。

它不追求把风险清零。 风险管理的产出是一个可以被讨论、被复核的处置方案，不是一个「已消除」的结论。把「我们做了风险管理」当成免责声明，是这个流程最容易被用坏的方式。

真实例子

医院计划用 AI 汇总出院记录。团队先限定系统只生成草稿，列出遗漏用药、泄露隐私和自动化依赖等风险；临床、安全与隐私负责人分别确定评测和容忍度。上线前运行离线测试和模拟事故，初期只向少量受训人员开放，所有摘要必须人工签署。若关键用药遗漏率超过阈值，负责人立即停用生成并恢复人工流程，同时通知受影响部门和更新评测集。

什么时候适合与不适合

所有进入真实流程的 AI 系统都需要与影响相称的风险管理，高风险、不可逆或影响大规模人群的用途需要更独立和持续的审查。低风险原型不必复制大型机构流程，但仍应明确用途、数据、负责人和停止条件。框架本身不证明合规或安全，照抄控制清单也可能忽略具体受影响者；资源有限时仍必须解释哪些风险未测量以及为何接受。[S1][S2]

亲自试一下

为一个 AI 功能写一条完整风险记录：使用情境、受影响者、潜在伤害、发生信号、影响与可能性、现有控制、控制所有者、残余风险、停止阈值和下次复核日期。再让非开发成员挑战你的假设。若没人有权执行停止动作，或没有证据判断控制是否有效，这条记录还不能进入发布决策。

接下来学什么

先从AI 安全理解总体目标，再用人工监督明确干预权，以可审计性保留决策证据，并通过在线评估和可观测性持续测量部署后的实际影响。

来源与修订

四项核心功能、全生命周期、角色责任、情境映射、测量和处置结果参考 NIST AI RMF Core [S1]；可按组织场景选择的实施建议和非清单边界参考 NIST AI RMF Playbook [S2]。本文基于 AI RMF 1.0；NIST 已声明该框架和 Playbook 正在修订，因此实施时还需核对当前版本，并按行业、地区与时间复核具体法律义务、风险容忍度、控制措施和责任分工。