第 5 章 风险评估与问责

学习目标

• 将AI风险写成包含受影响者、发生条件与损害的损害场景。
• 说明NIST AI RMF的四项功能、七项可信性特征及生成式AI配置文件的风险类别。
• 区分四类风险应对与剩余风险，配置与风险等级成比例的管控。
• 设计法律要求的记录及组织解释判断所需记录。
• 说明管理体系认证、前沿安全框架的目的与局限。

引言

设想某公司将二十项AI使用场景全部归为“高风险”，每一项都附加事先审议、双重审查和每月报告。三个月后，委员会被文件淹没，反而没有精力深入审查真正影响客户的两项。相反，若把全部场景都定为“低风险”，又将无人关注。风险评估并不是把风险消除，而是确定将有限的注意力和资源投入何处。试图以同样方式守住所有地方，结果可能任何地方都没有守好。

而且，这些判断必须能够在日后得到解释。无论是监管机构、客户，还是下一年的负责人来询问，都应有记录回答“为何选择这些管控措施，又接受了哪些风险”。这种能够解释决策的记录，才是问责的实质。

本章介绍的框架是整理判断的工具，并非法令，因此尤其应留意它们如何与第2、3章的法定义务相互衔接。本章从如何写明风险开始，梳理NIST AI RMF的结构、可信性特征和生成式AI风险类别，接着介绍应对选项与各等级管控映射、法定要求与自主措施的区别、记录与审计、运营中的监测。最后审视ISO/IEC 42001及前沿安全框架能够说明什么，以及不能说明什么。

核心概念

将风险写成损害场景

“偏见风险”“幻觉风险”等标签无法直接评估。风险须写明谁、在什么条件下、受到什么损害，才能测量并管控。

不良示例：偏见风险
良好示例：意图分类模型将带方言的语音咨询误判为“非投诉”，
          导致老年客户的解约请求处理慢于平均水平。（受影响者：老年客户，
          条件：非标准表达，损害：处理延迟与额外费用，恢复：退费可部分弥补）

对于每个损害场景，分别评估影响（损害程度、对权利的影响、恢复可能性、受影响人数）与可能性（发生频率、相关条件有多常见）。风险等级应围绕对人和权利的影响确定，而非按照成本。仓库与学校建筑的安全检查周期不同，原因在于建筑内的人，而不是建筑的价格。

NIST AI RMF的结构与起步流程

NIST人工智能风险管理框架（AI RMF 1.0，2023年1月26日发布）分四项功能。

NIST说明，在Govern建立之后，多数情况下从Map开始，接着进入Measure或Manage，并按需要在各功能之间来回推进、反复实施。这不是按顺序做完一次就结束的流程，而是持续运转的循环。

可信AI的七项特征

AI RMF提出，值得信赖的AI应具备七项特征，分别是：有效且可靠（valid and reliable）、安全（safe）、具备信息安全保障与韧性（secure and resilient）、具有责任性与透明性（accountable and transparent）、具有可解释性与可诠释性（explainable and interpretable）、增强隐私保护（privacy-enhanced），以及在管理有害偏见的同时实现公平（fair with harmful bias managed）。

NIST将“有效且可靠”解释为可信性的必要条件，并将“负责且透明”视为与其他所有特征都相关。各项特征之间可能发生冲突，因此需要根据具体情境取得平衡。例如，说明越详尽，越可能与隐私或安全要求发生冲突。

三个看似相近的特征，其实回答不同问题。透明性回答系统中“发生了什么”；可解释性回答决定“如何”作出；可诠释性回答决定“为何”如此，以及对用户意味着什么。能用日志还原输入和模型版本，属于透明性；让客户理解本人结果的原因，则是可诠释性的问题。

生成式AI配置文件的十二类风险

NIST AI 600-1（生成式AI配置文件，2024年7月）归纳生成式AI特有或放大的十二类风险。

这张表适合用作防止遗漏损害场景的检查表。对于每项使用案例，都浏览全部十二个类别，选出与该案例相关的类别，再为每个被选中的类别写出具体损害场景。

四类风险应对与剩余风险

AI RMF要求依影响、可能性、资源对已记录风险处理排序（MANAGE 1.2），应对选项为缓解（mitigating）、转移（transferring）、规避（avoiding）、接受（accepting）（MANAGE 1.3）。

在所有管控措施都实施之后，仍然留下的风险称为剩余风险。AI RMF要求将对下游采购方和最终用户不利的剩余风险形成文件记录（MANAGE 1.4）。剩余风险不应隐瞒，而应明确写出，由有权接受者签字，必要时告知接收系统的一方。转移也不会使风险消失：即使合同能够分担成本，受影响者遭受的损害仍然存在。因此，对人影响较大的风险，不能仅靠转移来应对。

按风险等级映射管控

本章技能目标是“按风险等级映射管控”。预设各等级管控组合，可加速并统一判断。

进行映射时，应避免两种想法。第一种是认为等级相同，管控也应完全相同。若造成损害的原因不同，管控措施也必须随之变化：原因是个人信息暴露时，核心是输入最小化；原因是错误回答时，核心则是核查依据和人工审查。第二种是认为风险分数低，便可免除法定义务。下一节将专门讨论这个问题。

区分法定要求与自主管控

登记册管控混合了两种性质：法令要求的，以及组织按风险比例自主选择的。

在登记册设“依据”列，注明法令、合同、内部判断，便可适度降低自主措施，同时不漏法定要求。

记录与审计

问责取决于“事后能否解释”。下列记录或由法律要求，或为实务必需。

这里的关键是版本管理。如果每次更换模型都覆盖原风险管理文件，就无法解释过去某个时点作出的决定。因此，每一版均应注明日期并另行留存。同时，记录本身也是个人信息处理。若把提示词原文完整写进审计日志，该日志便成为新的风险来源。应只记录必要项目，限制访问权限，并确定保留期限。其他法令要求保留的记录，应依《个人信息保护法》第21条第3款，与其他个人信息分开保管。

审计应分别查看两个方面。设计适当性是指管控是否设计得当，能够应对相关风险；运行有效性是指该管控是否实际发挥作用。即使规范写有人工审查，抽取样本后也可能发现完全没有审查痕迹。

运营监测与事故应对

AI部署后仍会改变：输入分布变化、供应商更新模型、用户采用预期之外用法。AI RMF要求执行部署后监测（MANAGE 4.1），向含受影响社区的相关方告知事故错误（MANAGE 4.3），建立最终用户、受影响者报告问题与申诉程序（MEASURE 3.3）。

监测计划应写明三方面。第一，观察什么，例如错误率、各群体性能差距、投诉、人工审查后的修改比例。第二，什么时候采取行动，即指标不可超过的阈值。第三，由谁做什么，例如停用、重新评估、通知。计划也应衔接法定通知程序：获悉对话日志泄露等，或确认存在非法访问但难以确定涉及哪些主体，符合施行令规定的泄露可能性条件时，应启动第3章的72小时通知程序。

ISO/IEC 42001：管理体系认证

ISO/IEC 42001（2023）规定开发、提供、使用AI的组织建立、实施、维持并持续改进AI管理体系的国际标准要求。认证由独立认证机构审核颁发，非ISO直接进行。

认证能说明的是：“该组织具有管理AI的体系，并且通过了审核。”它不保证某项AI产品准确或公平，也不能替代法律合规。营销材料使用认证时，必须准确说明认证范围，包括哪个组织、哪些营业场所、哪些活动。在采购审核中引用供应商认证时，也必须另外评估本组织使用场景的风险。

前沿安全框架

部分AI开发商公开应对尖端模型严重风险的自主框架。

这些框架的目的是在模型开发、部署阶段管理可能导致大规模损害的极端能力风险。在采购审核中，它们可以用作反映供应商安全管理水平的资料。但它们不是数据处理合同，不保证单项输出的准确性或公平性，也不转移引入企业对自身用途进行风险评估、履行法定责任的义务。《人工智能基本法》第32条安全保障义务同样针对运算量极大的尖端系统，因此关注的问题相近；然而，法定义务与自主框架的依据和效力仍然不同。

深入阅读

分数的陷阱

“影响5分×可能性5分”这样的评分表存在三个陷阱。将性质不同的损害合并成一个数字，会使真正需要防范的事项变得模糊；发生概率低但无法恢复的风险，可能被埋在低分之下；依据不足的估计，一旦转化为数字，就容易看起来像已经证实的事实。

解决方法是在分数旁同时记录两项内容。一项是不确定性：评估依据什么，是否有尚未测量的群体或条件。另一项是不受分数影响、必须处理的条件：如法定义务、不可恢复的损害、对儿童或弱势群体的影响。尚未测量的部分应标为“未测量”，而不是“低风险”，并告知接收系统的一方。若生命、安全或权利相关的核心指标尚未测量，必须由风险接受者明确决定是否暂缓部署。

非确定性输出与可复现性

生成式AI按照概率选择下一个词来构造回答，因此即使输入相同，也可能给出不同的答案。这使得我们很难完整复现“当时为什么会产生那种回答”。但这并不意味着可以放弃解释。无法复现时，应保留情境证据：请求时刻、模型及版本、系统提示词版本、通过检索获得的文档标识符、主要设置、输出内容，以及人工审查结果。具备这组记录，即使不能再次生成完全相同的回答，也可以解释当时的回答是在什么条件下产生的。

工作场景

常丰食品：建立首份风险登记册

食品制造商“常丰食品”拟首次登记九项AI用途，包括需求预测、生产线异物图像检测、营销文案、客户聊天机器人、合作方文件摘要。行政团队最初建议“与食品安全有关，全部高风险”。

风险负责人先为每项案例写出损害场景。异物检测AI漏检可能使消费者受伤，而且损害难以恢复，因此列为高风险；但系统设计为在既有金属探测器和人工抽样之外增加检查，而不取代它们。营销文案生成存在虚假、夸大标示风险，列中风险，发布前须由负责人审查。合作方文件摘要仅为内部草稿，列低风险。

客户咨询聊天机器人引起了不同意见，因为如果向询问过敏成分的客户提供错误答复，可能损害健康。负责人选择规避这部分风险：聊天机器人不回答过敏或成分问题，而是引导客户查看官方成分表并联系人工客服，无需将整个机器人全部提升为高风险。其余配送与订单咨询仍归中风险。因为它是生成式AI服务，第31条的告知和标识应另外标为不受风险等级影响的法定要求。

登记册记下风险接受者、重评日期，以及“异物检测夜间照明表现尚未测量”的不确定性。

邻里聊：自动处罚误判后的审计

地区社区应用“邻里聊”以AI审核帖子，自动隐藏辱骂或疑似诈骗内容，反复出现时暂时停用账户。上个月供应商将模型更新至新版后，用户投诉增多：混有地方方言和老年人分词习惯的帖子，越来越常被当作诈骗而隐藏。

审计负责人首先查找记录，确认究竟发生了什么变更。幸好公司为每次判定保留了模型版本、分类标准版次和判定分数。对比更换版本前后的情况，发现新版对某些表达的误判比例上升。同时也发现，原先评估只采用以标准语为主的测试数据，没有测量这些群体之间的差异。

负责人提出三项建议。第一，将账户停用改为运营人员确认后执行，不再自动作出。他也参考了个人信息保护委员会告示附表：自动检测后暂时阻拦，收到请求后由人最终决定的运营方式，被列为自动化决策的例外。第二，向帖子被隐藏的用户告知理由及申诉方式，由人在7天内审查申诉。第三，将模型替换纳入变更管理，新版须先用地区、年龄群体的样本验证，再正式采用。开发团队解释供应商公布的性能分数提高了，但这没有改变判断，因为那些分数不是针对公司自身用户群测得的结果。

审计报告分别列出了两类问题：设计层面的问题，是评估数据的代表性；运营层面的问题，是遗漏了变更管理。报告还附上了恢复被错误封禁账号的处理结果，以及向相关用户逐一告知的结果，作为相应证据。

易错点

1. “所有场景最高管控就安全。” 资源分散会守不住真正高风险处。
2. “供应商有认证，自身可免评估。” 使用背景风险由引入组织评估。
3. “有前沿框架就管住偏见错误。” 框架针对极端能力风险。
4. “RMF按序做一次即可。” 功能反复循环，Govern贯穿全过程。
5. “合同转移后风险消失。” 成本可分担，人的损害仍在。
6. “低分可减少法定义务。” 法定要求不受分数影响。
7. “日志能复现就是说明。” 复现属透明性，当事人理解理由属可诠释性。
8. “换模型覆盖文件为最新版即可。” 解释过去决定须保留各版记录。

要点速览

查阅官方文档

• NIST — AI Risk Management Framework：AI RMF 1.0、修订公告、Playbook、生成式AI配置文件。
• NIST AIRC — AI RMF Core：四功能和子类别（MANAGE 1.2~1.4、4.1、4.3，MEASURE 3.3）。
• NIST AIRC — Trustworthy AI characteristics：七特征，透明性、可解释性、可诠释性区分。
• NIST AI 600-1 — Generative AI Profile：十二类风险定义。
• ISO — ISO/IEC 42001 explained：AI管理体系与认证。
• Anthropic — Responsible Scaling Policy：现行版与修订历史。
• Google DeepMind — Frontier Safety：目的与版本历史。
• OpenAI — Preparedness Framework (v2)：跟踪类别与能力标准。

自测

5-1. 将“幻觉风险”这一标签，改写为一句具体的损害场景，使读者能够看出受影响者、发生条件、所受损害以及恢复可能性。

5-2. 写出NIST提出的可信AI七项特征，并从中选出被解释为可信性必要条件的特征，以及与其他所有特征均相关的特征。

5-3. 从NIST AI 600-1整理的十二类风险中写出五类，再用一句话说明如何利用这份名单编制风险登记册。

5-4. 写出风险应对的四种选择，并说明对人影响较大的风险，为何不能仅依靠合同上的风险转移处理。

5-5. 结合本章讨论的《人工智能基本法》与《个人信息保护法》所涉及的记录，列举两种已经规定保存期限的记录，并分别写出它们各自需要保存多长时间。

5-6. 将AI管理体系标准认证所能证明的范围与不能证明的范围对照列出，每方面各写两项。

5-7. （设计）设想四项AI使用案例，制作风险登记册。在每行写明损害场景、影响、可能性、等级、管控措施、依据（法令、合同、内部判断）、有权接受风险者以及不确定性。

实操练习