AI 基础
什么是负责任的人工智能？原则、风险与治理
将 Unite.AI 添加到您在 Google 上的首选来源
负责任的人工智能是对 AI 进行治理的实践，确保其设计、开发、部署和使用始终符合人权、安全、法律、组织价值观以及受影响者的需求。它将宽泛的原则转化为整个生命周期内可追溯的决策和证据。
并不存在唯一的通用检查清单。招聘模型、医疗设备、创意助理和工厂传感器都需要不同的控制措施。一个可信的项目始于对情境和影响的评估，然后进行映射、测量、管理和监控风险。
关键要点
- 在构建之前指定负责的所有者，并明确何时 AI 的使用是不恰当的。
- 在具体情境中评估有效性、可靠性、安全性、保障性、隐私、透明度以及有害偏见。
- 记录数据、模型、决策、局限性、人为监督以及变更历史。
- 向受影响者提供有意义的通知、纠正或申诉渠道，并在发生伤害时提供补救措施。
原则需要可操作的定义
公平可以指相等的错误率、平等机会、个人一致性或实质性的利益分配。透明度可能需要向用户发出通知、提供技术文档、开放审计访问或解释决策。这些目标之间可能会产生冲突。
将每一项原则转化为具体的要求、度量、负责人、阈值和响应。可解释人工智能支持部分透明度目标，但不能取代数据治理，也不能证明系统公平。
治理完整的生命周期
在开发之前，记录目的、受影响群体、可替代方案、预期收益、可能的危害以及法律约束。开发期间，追踪数据权利与质量、模型选择、测试、安全性以及人为因素。上线前，需要提供符合明确门槛的证据。
上线后，监控性能、投诉、漂移、滥用以及意外使用。版本控制和事件响应将负责任的 AI 与AIOps以及常规组织风险管理相连接。
人为监督必须真实有效
如果人员缺乏时间、专业知识、权限、情境或替代方案，就无法提供有意义的监督。需明确哪些决策是自动化的，哪些需要批准，以及系统何时必须回避或升级。
衡量自动化偏差、逆转率、工作负荷，以及受影响者是否能够挑战结果。名义上的“人在回路”可能为决策提供合法性，却未必提升实际效果。
标准、法律与持续改进
如 NIST AI RMF 与 OECD AI Principles 等框架用于组织实践，而法律则在特定司法管辖区内设定约束性义务。合规是底线，而非系统在所有情境下都能产生可接受结果的证明。
独立审查、红队测试、影响评估、审计和公开报告在匹配风险时可以增强证据。将项目链接至网络安全、隐私、可访问性、安全、采购和领域专长，而不是单独设立 AI 委员会。
组织角色与决策权
治理机构设定风险偏好和禁止使用场景。业务负责人对结果负责；产品和工程团队负责落实控制措施；数据管理员负责权利和质量管理；安全、隐私、法律、可访问性、安全和领域专家提供独立质疑。采购部门必须评估供应商证据和合同条款。
明确谁可以批准开发、试点、生产、范围扩展以及退役。高风险决策不应仅由负责上线的团队批准。必须设立升级渠道，以记录理由的方式解决收入、进度、安全和权利之间的冲突。
系统登记册记录所有者、目的、模型、数据、供应商、受影响群体、部署情况、影响层级、评估、事件和审查日期。影子 AI 无法被治理，因此应提供经批准的工具和轻量化入口，以支持低风险实验，而不是仅靠禁止手段。
风险评估与保证
影响评估绘制利益相关者、收益、危害、严重性、可能性、暴露度、可逆性以及现有控制措施。它应审查因决策而受影响的非用户以及系统间的累计效应。可选方案包括非 AI 方法、更窄的功能或不部署。
保证证据可以包括数据审计、模型验证、安全测试、红队演练、人因研究、可访问性审查、子群体分析、文档以及外部审计。证据必须对应声明: 准确性基准无法证明隐私，公平性指标也无法证明合法性。
使用接受阈值和残余风险签署。将已知的局限性和使用条件记录在用户和操作员文档中。当证据不足时，应限制人口、地域、自治程度或用途，并通过受控试点收集数据，而非大规模上线。
监控、事件与补救
监控输入分布、输出质量、校准、覆盖、投诉、子群体结果、安全信号以及下游决策。模型可能在统计上保持稳定，但组织使用方式会漂移——例如，建议分数被硬性排除。运营审计必须同时审查实践和遥测数据。
AI 事件处理流程应接受来自员工、用户、受影响者、研究者和供应商的上报。对直接伤害进行分流，保存版本和证据，遏制系统，通知责任方，尽可能纠正决策，并从激励、数据、设计和运营等维度调查根本原因。
补救措施可包括解释、纠正、人为复审、恢复访问或资金、删除、赔偿以及政策变更。经验教训应更新登记册、测试集、控制措施、采购、培训和风险标准。负责任的项目应展示其在失败后如何进行调整。
在整个生命周期中实现负责任的 AI
将宽泛的原则转化为具体用例的需求。记录目的、使用者、受影响者、数据、模型、决策、收益、潜在危害、法律背景和可替代方案。在采购或开发前对风险进行分类，使高影响系统获得更强的证据、审查、透明度、人为授权和监控。通用的伦理声明不能替代负责的所有者和接受标准。
开发阶段，建立来源和权限，测试数据质量和代表性，对比基线，并评估有效性、鲁棒性、隐私、安全、可访问性和子群体行为。记录模型和系统的局限性，而非仅仅是基准分数。独立审阅者应能够复现关键主张，并检查人为判断在标签、阈值、例外和升级中的介入点。
部署后，监控输入和结果漂移、投诉、覆盖、事件以及现实世界的危害。供应商、模型、数据、政策、用户或运行条件变化时重新评估。对影响人的决策提供申诉和纠正，保持与风险相称的可追溯性，并明确退役和数据删除流程。负责任的 AI 是一个持续的管理系统，将治理与工程证据及运营决策相连接，而非上线前的一次性检查清单。
采购需要与内部开发同等严谨。要求供应商披露预期用途、训练和评估证据、数据处理、安全、更新实践、分包商、事件通知和退出选项。合同语言不能替代买方环境中的测试。维护已部署和实验系统的清单、所有者、依赖关系和审查日期，以防影子 AI 和悄然更换的托管模型绕过治理流程。
向领导层和受影响的利益相关者报告治理结果: 未解决的高风险、事件、逾期审查、重复投诉以及停止部署的情况，比完成的检查清单数量更具意义。保护审阅者免受批准压力，并赋予其要求证据、限制范围或在控制失效时停止使用的权力。
实用实施检查清单
将概念转化为有界、可测试的工作流: 治理 → 映射 → 测量 → 管理 → 监控 → 补救。指定负责的所有者，记录数据和依赖关系，建立简易基线，设定接受和停止标准，测试具代表性的故障，并在扩展范围前定义监控、回滚和审查。记录版本和假设，以便其他团队复现结果并了解变更内容。
上线前，进行有文件记录的就绪审查，参与人员包括构建、运营、保障以及受系统影响的人员。测试常规情形、边界条件、依赖失效和误用；保存证据和未解决的风险。明确谁可以批准发布、修改阈值、覆盖输出或停止运行。实际数据到来后重新评估决定，因为技术上成功的试点并不保证在更大规模上的可靠表现。
- CONTEXT: 目的、人员和可能的影响。
- EVIDENCE: 测试、文档和审查。
- ACCOUNTABILITY: 所有者、监督、申诉和补救。
常见问题
谁对 AI 系统负责？
责任在领导者、产品负责人、数据与模型团队、供应商、运营者、审阅者和部署者之间分配。治理应明确具体的决策权，而不是说所有人都负责。
模型卡足够吗？
不够。文档是有价值的证据，但负责任的部署还需要风险决策、测试、控制、监控、用户流程和补救措施。
主要参考文献
