一、ISO/IEC 42001:2023 8.4 标准原文

二、条款解读说明

2.1 为什么8.4是AI治理中最具“现实校准”价值的条款之一

在第6.1.4条，标准已经要求组织建立人工智能系统影响评估过程，用来评估系统开发、提供或使用可能对个人、群体和社会产生的潜在后果。第8.4条进一步要求组织在运行阶段按计划间隔或重大变化时继续开展影响评估。这说明标准并不把影响评估视为立项前的一次性“伦理审查”，而是视为需要随着系统运行、使用环境和相关方反馈不断更新的治理机制。

之所以要单独强调这一点，是因为AI系统的许多影响只有在真实运行中才会逐渐显现。例如，某个模型在测试环境中表现良好，但上线后面对更复杂人群时可能暴露偏差；某个内部辅助工具在小范围试点时影响很小，但推广到更广泛岗位后可能改变决策方式和问责结构；某个对外服务在设计阶段被认为风险较低，但运行中用户并不理解其局限，结果产生误用和不公平体验。这些都说明，影响评估如果不能持续更新，就会很快失去现实意义。

2.2 8.4与8.2的区别：一个看风险，一个看影响

2.3 运行期影响评估要特别关注哪些变化

在运行阶段，影响评估最需要关注的通常不是模型性能小幅波动，而是与受影响对象和使用方式有关的变化。比如，使用场景扩大到新的业务环节，自动化程度提高，人类监督减少，输出被用作更关键的决策参考，服务对象扩展到新的人群，外部沟通方式变化，或社会舆论和监管预期明显变化。这些变化可能不一定马上表现为技术故障，却会显著改变对个人、群体和社会的影响路径。

此外，8.4特别强调“保留所有影响评估结果的文件化信息”，意味着组织需要保留历史评估结果和更新记录。这不仅有助于审计，也有助于组织自身理解影响判断如何变化。例如，为什么某一阶段需要引入人工监督，为什么某一类用户需要额外告知，为什么某次场景扩展触发了新的缓解措施。能够回答这些问题，才说明影响评估真正参与了治理。

三、实施要点

3.1 设定影响评估的周期和触发条件

• 组织应为不同类型AI系统定义影响评估复核频率，并设定重大变化触发条件。
• 高影响系统通常需要更短周期和更敏感的触发门槛。
• 周期机制保证不遗忘，触发机制保证不滞后。

3.2 以“受影响对象”为中心更新评估

• 每次复评都应重新确认哪些个人、群体或社会层面主体可能受到影响，以及影响方式是否发生变化。
• 与其只问“模型有没有更新”，不如多问“现在谁会因为这个系统承受新的后果”。
• 受影响对象视角是8.4最核心的判断框架。

3.3 把真实运行反馈纳入影响评估

• 用户反馈、投诉、申诉、人工监督发现、事件调查和外部评价，都应作为影响评估的重要输入。
• 这些信息能帮助组织识别设计阶段未充分看到的影响后果。
• 缺少运行反馈，影响评估就容易变成纸面推演。

3.4 评估结论要回流到控制和沟通

• 如果影响评估发现某类人群受到更高影响，组织应相应调整控制措施、监督强度、用户告知和反馈机制。
• 影响评估不是单独存档的报告，而应直接影响8.3风险处置和7.4沟通安排。
• 评估回流决定了8.4是否真正有用。

3.5 为历史结果建立对比和更新机制

• 保留所有结果的同时，建议记录本次相较上次有哪些变化、变化原因是什么、后续动作有哪些。
• 这样可以帮助组织判断影响是在改善、稳定还是恶化。
• 历史可比较，比单次评估更有管理价值。

四、常用工具与实施方法

五、典型案例

案例一：小范围试点没问题，规模化后影响显现

1. 背景：某AI辅助决策工具初期只在一个团队试点。
2. 问题：推广到全公司后，不同岗位开始过度依赖系统建议，人工判断明显弱化。
3. 动作：组织按8.4重新评估影响，新增人工复核和岗位培训要求。
4. 结果：系统使用方式被重新校准，避免了“工具替代判断”的偏差扩大。

案例二：用户群变化带来新的群体影响

1. 背景：某评分系统原服务于稳定客群，后扩展到新地区和新人群。
2. 问题：原影响评估未覆盖新群体特征，部分解释机制也不再适用。
3. 动作：组织在扩展前重做影响评估，新增群体差异分析和沟通方案。
4. 结果：避免了老评估在新场景下失效。

案例三：运行反馈揭示设计阶段未发现的社会影响

1. 背景：某公共服务AI系统上线后，社会媒体对其透明度提出持续质疑。
2. 问题：初始影响评估更关注效率收益，没有充分评估外部感知和信任影响。
3. 动作：组织把舆情和用户反馈纳入8.4复评，更新对外说明和人工监督机制。
4. 结果：影响评估从内部判断转向更贴近外部真实感知。

六、成文信息管理要求

8.4明确要求保留所有人工智能系统影响评估结果的文件化信息。组织应确保不仅保留最终报告，还能保留触发原因、输入信息、变化说明和后续动作，形成完整证据链。

七、常见误区及踩坑提醒