Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 26135:2023 人工智能 — 风险管理框架深度解析
ISO/IEC 26135:2023
ISO/IEC 26135:2023 提供了一个专门为人工智能系统定制的全面风险管理框架。虽然 ISO 31000 等通用风险管理标准提供了总体原则，但 AI 系统引入了独特的风险特征——包括算法偏差、不透明性（黑箱问题）、数据依赖性、涌现行为和自主决策——这些都需要专门处理。该标准通过定义结构化的 AI 风险识别、分析、评估和处理过程来应对这些独特挑战，同时考虑 AI 部署的更广泛社会和伦理影响。
AI风险格局与传统IT风险有根本不同。模型漂移、数据投毒、对抗性样本和反馈循环效应是传统风险框架无法充分解决的AI特有风险。ISO/IEC 26135填补了这一空白。
在风险评估开始之前，应建立AI系统的风险承受阈值。该标准强调可接受的风险水平取决于应用领域——医疗诊断AI与内容推荐系统相比具有截然不同的风险承受能力。
不要将AI风险管理视为一次性活动。该标准倡导在整个AI生命周期中进行持续风险监控，特别关注模型更新、数据分布变化和部署环境变更期间。
让来自法律、合规、工程、运营和领域专业知识的利益相关者参与风险评估过程。AI风险是多维度的，需要多样化的视角进行全面的识别。
1. AI风险识别与分类
该标准建立了一个 AI 风险分类体系，分为几个类别：技术风险（例如模型失败、数据质量问题、对抗性漏洞）、运营风险（例如集成失败、可扩展性限制、维护挑战）、伦理风险（例如偏差、歧视、隐私侵犯、缺乏透明度）、监管和法律风险（例如不符合 AI 法规、责任分配）以及社会风险（例如就业替代、环境影响、社会信任侵蚀）。对于每个风险类别，该标准提供了识别技术的指导，包括结构化头脑风暴、情景分析、基于检查表的审查和历史事件分析。
对抗性样本是一种独特的AI特有风险。图像分类器可能被不可察觉的像素修改所欺骗。该标准建议将对抗鲁棒性测试作为任何具有安全影响的AI系统风险评估的一部分。
数据质量风险值得特别关注——垃圾进垃圾出原则在AI中具有放大的后果。该标准建议进行系统的数据质量评估，包括完整性、一致性、准确性、及时性和代表性。
当AI系统输出影响未来输入时，会出现反馈循环风险，可能导致失控效应。推荐系统和算法交易是经典例子。该标准要求对闭环动力学进行专门分析。
伦理风险识别不应是事后考虑。该标准建议在设计阶段进行伦理风险评估，而不是在部署之后。这对于高风险AI应用尤其关键。
2. 风险分析与评估方法
ISO/IEC 26135 规定了一种半定量风险分析方法，同时考虑 AI 系统故障造成潜在损害的可能性和严重性。该标准引入了“风险源”的概念——单独或组合可能产生风险的元素或元素组合。对于 AI 系统，风险源包括训练数据、模型架构、学习算法、部署环境和人机交互设计。评估阶段根据基于组织风险偏好和监管要求预先确定的风险标准，确定残余风险（在现有控制措施之后）是否可接受。
| 风险类别 | 风险源示例 | 潜在危害 | 典型控制措施 |
|---|---|---|---|
| 技术风险 | 模型架构、训练数据、超参数 | 错误输出、系统故障 | 验证测试、监控、回退 |
| 运营风险 | 部署环境、API依赖、扩展 | 服务降级、停机 | 冗余、负载测试、回滚计划 |
| 伦理风险 | 有偏训练数据、不公平特征选择 | 歧视、声誉损害 | 偏差审计、公平约束、透明度 |
| 监管风险 | 不合规数据处理、文档不足 | 罚款、法律诉讼、强制停运 | 合规审查、审计追踪、法律监督 |
| 社会风险 | 关键决策自动化、就业影响 | 公众反对、监管干预 | 利益相关者参与、影响评估 |
该标准提供了适用于 AI 系统的风险估计技术的详细指导，包括定量方法（例如概率建模、蒙特卡洛模拟）、定性方法（例如风险矩阵、专家判断）和新兴的 AI 特定技术（例如模型不确定性量化、分布偏移检测）。方法的选择应与 AI 系统的复杂性和应用领域的关键性相称。对于高风险 AI 系统，该标准建议使用多种互补的估计技术。
危险：切勿在未经 ISO/IEC 26135 规定的文档化风险评估的情况下，部署对人类福祉产生影响的自主决策 AI 系统。缺乏正式的风险管理过程会在全球新兴 AI 法规下产生重大法律责任风险。绕过这一步骤的组织不仅面临监管处罚，还可能面临难以恢复的声誉损害。
3. 风险处理与持续监控
该标准确定了四种主要的风险处理选项：风险规避（终止 AI 系统或功能）、风险降低（实施额外控制措施，如人工监督、模型约束或验证关卡）、风险转移（通过保险或合同安排转移风险）和风险保留（在经过知情决策后接受残余风险）。对于 AI 系统，通过人在回路中（HITL）或人在回路上（HOTL）监督进行风险降低是一种特别重要的处理策略。该标准要求风险处理计划被记录、实施并定期审查有效性。持续监控是强制性的，重新评估的触发因素包括重大模型更新、数据分布变化、新的法规要求和事件发生。
人工监督是AI系统的关键风险处理方法，但它不是万能药。监控AI输出的人类可能出现警觉性下降、自动化偏见和疲劳。设计考虑这些人为因素的监督机制。
考虑分层风险处理策略：预防性控制（例如输入验证、模型约束）、检测性控制（例如监控、告警）和纠正性控制（例如回滚、覆盖）。没有单层是足够的。
该标准建议以足够详细的信息记录风险决策，以便审计和监管审查。这包括谁做出了决策、考虑了哪些信息、评估了哪些替代方案以及选择处理方式的理由。
部署后监控不是可选项。该标准要求对风险指标进行系统监控，包括性能下降、数据分布变化、可解释性指标漂移和新故障模式的出现。
常见问题
Q: ISO/IEC 26135 与欧盟 AI 法案的风险分类有何关系？
A: 欧盟 AI 法案将 AI 系统分为不可接受风险、高风险、有限风险和最小风险类别。ISO/IEC 26135 提供了可用于证明高风险系统符合法案要求的操作风险管理过程。这两个框架是互补的。
A: 欧盟 AI 法案将 AI 系统分为不可接受风险、高风险、有限风险和最小风险类别。ISO/IEC 26135 提供了可用于证明高风险系统符合法案要求的操作风险管理过程。这两个框架是互补的。
Q: ISO/IEC 26135 是否与 ISO 31000 保持一致？
A: 是的。ISO/IEC 26135 遵循 ISO 31000 的原则和框架，同时增加了 AI 特定的风险考虑。已经使用 ISO 31000 的组织会发现流程结构熟悉，并增加了额外的 AI 特定风险识别和分析技术。
A: 是的。ISO/IEC 26135 遵循 ISO 31000 的原则和框架，同时增加了 AI 特定的风险考虑。已经使用 ISO 31000 的组织会发现流程结构熟悉，并增加了额外的 AI 特定风险识别和分析技术。
Q: ISO/IEC 26135 与 NIST AI 风险管理框架有何区别？
A: 两者都旨在管理 AI 风险，但结构不同。ISO/IEC 26135 遵循传统的 ISO 风险管理过程（识别、分析、评估、处理），而 NIST AI RMF 围绕四个功能组织：治理、映射、测量、管理。组织可以根据其监管暴露和运营背景选择实施其中一个或两者。
A: 两者都旨在管理 AI 风险，但结构不同。ISO/IEC 26135 遵循传统的 ISO 风险管理过程（识别、分析、评估、处理），而 NIST AI RMF 围绕四个功能组织：治理、映射、测量、管理。组织可以根据其监管暴露和运营背景选择实施其中一个或两者。
Q: 该标准是否适用于生成式 AI 系统？
A: 是的。尽管该标准于 2023 年发布，但其风险管理框架足够广泛，足以涵盖生成式 AI 风险，包括幻觉、有害内容生成和知识产权问题。然而，从事生成式 AI 工作的组织可能需要补充针对大语言模型的额外指导。
A: 是的。尽管该标准于 2023 年发布，但其风险管理框架足够广泛，足以涵盖生成式 AI 风险，包括幻觉、有害内容生成和知识产权问题。然而，从事生成式 AI 工作的组织可能需要补充针对大语言模型的额外指导。
Q: 该标准是否要求第三方风险评估？
A: 对于高风险 AI 应用，该标准强烈建议由合格的第三方进行独立验证和确认。对于较低风险的应用，内部评估是可以接受的，但仍应遵循规定的方法并接受内部审计。
A: 对于高风险 AI 应用，该标准强烈建议由合格的第三方进行独立验证和确认。对于较低风险的应用，内部评估是可以接受的，但仍应遵循规定的方法并接受内部审计。
