AI 风险评估清单：治理职责与完整检查问题

这份清单怎样使用

本文为《可信 AI 伦理指南》2019 年版第三章中文译文，对应印刷页 24至31。它保留原版试用清单的全部问题，供结合具体情境阅读，不把它呈现成现行法律检查表或认证结果。上一部分七项要求与实现方法解释了每组问题的理由。

第二章的核心指导是：整个生命周期满足七项要求，结合技术与非技术方法；推动评估与实现要求的研究、创新、公众传播及伦理人才培养；清楚说明能力、局限与实施方式，让人知道自己正与 AI 交互；促进可追溯、可审计；让各方参与并得到培训；持续识别、评估、记录和沟通原则与要求间的权衡。

第三章据此提供一份非穷尽的试用版清单，主要面向开发者和部署者，适用于自行开发或从第三方取得的系统，尤其是直接与使用者交互的系统。清单不处理可信 AI 的合法性部分，满足清单不证明已经合规，也不提供法律合规指导；使用时须按用途和运行环境调整。

原版设想通过公私部门合作试用清单及治理结构。试用分两路：定性方面，选择具有代表性、来自不同领域和不同规模的少量组织实践并提供深入反馈；定量方面，让所有感兴趣者参与公开咨询。原文计划将反馈整合到 2020 年初的修订版，先形成跨领域基础，再进一步发展行业或应用框架。这是原版历史安排。

把评估纳入治理

组织可以把评估纳入既有治理机制，也可新增流程，选择取决于结构、规模及资源。原文援引的组织变革研究强调，高层关注对于改变十分关键，而广泛参与有助于提高新流程的接受程度及相关性。因此，应同时覆盖日常执行与最高管理层。

使用时，不仅关注已经发现的问题，也要关注无法或难以回答的问题。一个原因可能是开发、测试团队的技能和能力缺少多样性，因此需要请组织内外其他人参与。

应同时用技术语言和管理语言记录全部结果，使各层级都能理解问题解决过程。评估深度应与用途和风险相称。清单不给每个问题预设答案，而是鼓励思考如何落实可信 AI、下一步应做什么。

现有法律可能已经要求某些流程或禁止某些结果，与清单重叠。例如数据保护法律规定个人数据收集处理的义务，而促进合规的内部政策也可能支持伦理处理。但满足清单仍不等于满足法律。组织已有非法律标准评估或软件开发流程时，也无需另起一套孤立工作，可将清单融入其中。

一、人的能动性与监督

基本权利

• 系统可能损害基本权利时，是否开展了影响评估？是否识别并记录不同原则与权利之间的潜在权衡？
• 系统是否与人的决策相互作用，例如推荐行动或决定、呈现选项？它是否会以非预期方式干预最终使用者的决策，影响自主性？
• 是否考虑应告知使用者：某项决定、内容、建议或结果来自算法决策？
• 若是聊天机器人或其他对话系统，使用者是否知道正在与非人类代理互动？

人的能动性

• 系统是否进入工作或劳动流程？若是，是否考虑人与 AI 的任务分配，以确保有意义的互动及适当人工监督、控制？
• 它是否增强或扩展人的能力？是否采取措施，防止人在工作中过度信任、过度依赖系统？

人的监督

• 是否为具体系统和用途考虑了适当的人工控制程度？能否描述人的控制或参与水平？
• “掌握控制的人”是谁？在哪些时点、通过哪些工具能够介入？是否有机制和措施确保人的控制或监督？
• 是否采取措施使自主性治理可被审计，并能纠正有关问题？
• 若系统具有自学习或自主能力，是否设置了更具体的控制与监督机制？建立了哪些检测、响应机制，判断是否可能出错？
• 是否设有在必要时安全中止操作的停止按钮或程序？该程序会完全终止、部分终止，还是将控制交给人？

二、技术稳健性与安全

抵御攻击与安全防护

• 是否评估系统可能受到哪些攻击？是否考虑数据污染、物理基础设施、网络攻击等不同性质的漏洞？
• 是否有措施或系统，保护完整性并抵御潜在攻击？
• 是否验证在意外情境与环境中的行为？
• 是否考虑系统可能具有多大程度的双重用途？若有，是否采取预防措施，包括在适当情况下不发布研究或不部署系统？

后备方案与一般安全

• 遭遇对抗攻击或其他意外时，是否有足够的后备方案，例如切换技术程序，或继续前先请求人工操作？
• 是否考虑具体用途下的风险水平？是否有测量与评估风险、安全的流程？危及身体完整时，是否提供必要信息？是否考虑保险来应对潜在损害？
• 是否识别可预见的其他用途中的安全风险，包括意外或恶意滥用？是否有缓解或管理计划？
• 是否评估系统对使用者或第三方造成伤害的可能性、潜在损害、受影响人群和严重程度？是否考虑责任及消费者保护规则？
• 是否考虑对环境、动物的潜在影响及安全风险？风险分析是否包括网络安全等安全防护问题，可能经由非预期行为转化为人身安全风险或损害？
• 是否估计错误结果、系统不可用、或社会无法接受的结果（例如歧视）会带来什么失败后果？
• 是否定义阈值及治理程序，触发替代或后备计划？后备方案是否已明确并经过测试？

准确性

• 是否在具体系统与用途下，确定准确性的定义和所需水平？是否评估怎样测量、保证准确性？
• 是否确保数据足够全面、及时更新？是否有措施判断是否需要额外数据，例如为改善准确性或消除偏差？
• 是否验证不准确预测会造成何种伤害？
• 是否有办法测量错误预测是否已经多到不可接受？
• 是否建立逐步提高准确性的措施？

可靠性与可复现性

• 是否有策略监测和测试系统是否满足目标、目的及预定用途？
• 是否测试为了复现，需要考虑哪些特定情境或条件？
• 是否建立验证方法，测量和确保可靠性与可复现性的不同方面？
• 是否有流程描述系统在哪类条件下失败？是否清楚记录这些流程，并将其用于可靠性测试和验证？
• 是否有沟通机制，使最终使用者了解系统可靠性的保障？

三、隐私与数据治理

尊重隐私与数据保护

• 是否按用途建立机制，让他人能指出训练、运行数据收集及处理过程中的隐私或数据保护问题？
• 是否评估数据集的数据类型与范围，例如是否包含个人数据？
• 是否考虑不使用、或尽量少使用敏感和个人数据来开发系统或训练模型？
• 是否按用途设置个人数据告知与控制机制，例如在适用时取得有效同意，并允许撤回？
• 是否通过加密、匿名化、聚合等措施加强隐私？
• 设有数据保护官时，是否在早期就让其参与？

数据质量与完整性

• 日常数据管理与治理是否符合相关标准，例如 ISO、IEEE，或广泛采用的协议？
• 是否建立数据收集、存储、处理、使用的监督机制？
• 是否评估对外部数据源质量有多大控制能力？
• 是否有保证质量和完整性的流程？是否考虑过其他流程？如何验证数据没有遭到篡改或攻击？

数据访问

• 采用了哪些协议、流程、程序来管理并确保适当的数据治理？
• 是否评估谁能在什么情况下访问使用者数据？
• 是否确保访问者具有资格、确有需要，并具备理解数据保护政策细节的能力？
• 是否有监督日志，记录谁在何时、何地、以何种方式、为何目的访问数据？

四、透明度

可追溯性

• 是否建立可追溯措施，记录算法系统的设计与开发方法？对于规则系统，记录编程或建模方法；对于学习系统，记录训练方法，以及收集、选择了哪些输入数据、如何完成。
• 是否记录测试与验证方法？对于规则系统，记录采用的情境和案例；对于学习模型，记录用于测试、验证的数据。
• 是否记录算法的结果与决定，也考虑不同情形下的其他可能决定，例如面对不同使用者子群时会产生什么结果？

可解释性

• 是否评估 AI 的决定与结果能够被理解到什么程度？
• 是否评估系统决定在多大程度上影响组织决策？为什么在这一领域部署这个特定系统？它的商业模式是什么，例如怎样为组织创造价值？
• 对于系统为何作出某种选择、导致某种结果，是否提供所有使用者都能理解的解释？
• 是否从设计之初考虑可解释性？是否研究并尝试采用适合该用途、尽可能简单且可解释的模型？
• 是否能分析训练和测试数据，并随时间改变、更新它们？
• 是否能在训练开发后检查可解释性，或访问模型内部工作流程？

沟通

• 是否通过说明或其他方式，告知最终使用者正在与 AI 而非人互动？系统是否清楚标为 AI？
• 是否有机制说明结果背后的理由与判断标准？说明是否清楚易懂，适合目标读者？
• 是否有流程接收反馈，并用反馈调整系统？是否沟通了潜在或被感知到的风险，例如偏差？是否按用途考虑向其他受众、第三方或公众说明？
• 是否澄清系统目的，谁或什么会从产品服务中受益？是否明确使用场景，并清楚沟通，使预期受众能够理解且认为适当？
• 是否按用途考虑人的心理与局限，例如困惑、确认偏误、认知疲劳？
• 是否清楚传达系统特征、局限及潜在缺陷？开发者是否向将它部署进产品服务的人说明，部署者是否向最终使用者或消费者说明？

五、多样性、不歧视与公平

避免不公平偏差

• 是否针对输入数据和算法设计，建立避免产生或强化不公平偏差的策略或程序？
• 是否评估并承认数据集组成的局限？是否考虑数据中使用者的多样性与代表性，并测试特定人群或容易出问题的用途？
• 是否研究和使用可用技术工具，改善对数据、模型和表现的理解？
• 是否在开发、部署、使用阶段设置测试和监测潜在偏差的流程？
• 是否按用途设置机制，让他人能提出偏差、歧视或表现不佳的问题？是否清楚说明向谁、怎样提出？除最终使用者外，是否考虑间接受影响者？
• 是否评估相同条件下决定仍可能变化？若会变化，可能原因是什么？是否有机制测量或评估这种变化对基本权利的潜在影响？
• 是否为设计采用适当、可操作的“公平”定义？该定义是否常用，选择前是否考虑其他定义？
• 是否用定量分析或指标，测量并测试采用的公平定义？是否有保障公平的机制，也考虑过其他可能机制？

可访问性与通用设计

• 系统是否适应广泛的个人偏好与能力？
• 是否评估有特殊需要、残障或被排斥风险的人能否使用？这些考虑怎样进入设计，又怎样验证？
• 系统信息是否也能被辅助技术使用者获取？开发时是否邀请这些群体参与或咨询？
• 是否考虑对潜在受众的影响？开发团队是否代表目标使用者，也代表更广泛人群及可能间接受影响的其他群体？
• 是否评估某些人或群体会否不成比例地承受负面影响？是否从其他背景、经验的团队或群体获取反馈？

利益相关者参与

• 是否有机制，让不同利益相关者参与系统开发和使用？
• 在组织引入 AI 前，是否提前告知并让受影响劳动者及其代表参与，为引入做好准备？

六、社会与环境福祉

可持续与环境友好

• 是否有机制测量开发、部署和使用的环境影响，例如数据中心使用什么能源？
• 是否采取措施减少整个生命周期的环境影响？

社会影响

• 系统直接与人互动时，是否评估它会否鼓励人对系统产生依恋与共情？
• 是否清楚表明社交互动是一种模拟，系统不具有人类意义上的“理解”与“感受”能力？译注：这里保留 2019 年原文的判断与措辞，不将流畅对话本身作为心智或感受的证据。
• 是否充分理解社会影响，例如失业或劳动者技能退化的风险？采取了哪些应对步骤？

社会与民主

• 是否评估超出个别最终使用者的更广泛社会影响，包括可能间接受影响的利益相关者？

七、问责

可审计性

• 是否建立有利于审计的机制，例如确保流程与结果可追溯、留有日志？
• 涉及基本权利，包括安全关键应用时，是否确保系统可以被独立审计？

减少并报告负面影响

• 是否开展风险或影响评估，考虑直接与间接受影响的不同利益相关者？
• 是否提供支持问责实践的培训和教育？涉及哪些劳动者或团队职能，是否超出开发阶段？是否讲解潜在适用法律框架？
• 是否考虑设立伦理 AI 审查委员会或类似机制，讨论整体问责、伦理实践及不明确的灰色地带？
• 除内部措施外，是否安排外部指导或审计，监督伦理与问责？
• 是否有流程让供应商、消费者、分销商、销售商等第三方及劳动者报告潜在漏洞、风险或偏差？

记录权衡

• 是否有机制识别系统涉及的利益、价值及潜在权衡？
• 怎样决定这些权衡？是否确保决定被记录？

获得救济的能力

• 出现伤害或不利影响时，是否有足够的救济机制？
• 是否通过机制向最终使用者和第三方说明可以怎样获得救济？

原版结语：清单应怎样继续改进

原文邀请所有利益相关者在实践中试用，并反馈清单是否可实施、完整、适合具体应用或领域，以及它与既有合规、评估流程有何重叠或互补。原文计划依据反馈在 2020 年初向委员会提出修订版。

本章的关键指导是：开发、部署和使用 AI 时，采用并按具体用途调整清单；始终记住清单不会穷尽所有问题。可信 AI 不是打勾，而是在整个生命周期中持续识别要求、评估解决方案、改善结果，并让各方参与。

继续阅读应用机会、关键关切与术语。若要联系业务流程，可以回到可信 AI 与伦理框架，对照原来的反思问题。

参考与延伸阅读

原文：Ethics Guidelines for Trustworthy AI，2019 年 4 月 8 日，European Union，印刷页 24至31。欧盟数字战略原文入口。本页是非官方中文翻译，保留试用版问题及历史计划，调整分篇、分组、术语和版式；问题不是现行认证要求。

依据欧盟再利用说明，原资料采用 CC BY 4.0，本页译文按相同许可提供，不表示原机构认可。

编辑补充：GDPR 官方原文用于独立查询数据保护要求；NIST AI 风险管理框架是另一套公开框架，可比较其治理、情境识别、测量与管理方法，不能据此把两套清单视为等价。