一、ISO/IEC 42001:2023 8.1 标准原文
原文：为满足要求，并实施第6条中确定的措施，组织应通过以下措施对所需的过程进行策划、实施和控制：制定过程准则；按照准则实施过程控制。
组织应实施根据6.1.3确定的与人工智能管理体系运行相关的控制措施（如人工智能系统开发和使用生命周期相关控制措施）。
应监测这些控制措施的有效性，如果未达到预期结果，则应考虑采取纠正措施。附录A列出了参考控制，附录B提供了实施指南。
文件化信息应在必要的范围内可用，确信过程按策划进行。
组织应控制策划的变更，评审非预期变更的后果，必要时，采取措施减轻不利影响。组织应确保外部提供的与人工智能管理体系相关的过程、产品或服务受到控制。
二、条款解读说明
2.1 为什么8.1是运行阶段最核心的落地条款
第6章解决的是组织应当如何策划风险、目标和变更，第8章则要求把这些策划转化成具体运行动作。其中8.1是整个运行章节的起点，因为它要求组织把“所需的过程”策划出来、实施起来、控制起来，并持续监测控制措施的有效性。换句话说，8.1不是单纯关注某个AI系统上线与否，而是要求组织把AI治理要求嵌入开发、采购、部署、使用、监督、更新、外部协作等日常流程中。
这条在AI场景下尤其重要，因为人工智能系统常常跨越多个团队和外部资源。模型可能是第三方的，数据可能来自客户或外部平台，开发和部署可能分属不同团队，运行还可能依赖外包支持。只要这些过程之间没有清晰的过程准则和控制点，AIMS就会出现断层。典型表现包括：上线标准不一致、变更后没人复核、监控只看性能不看风险、外部供应商提供的服务没有被纳入控制、问题发生后只能追责却无法追溯流程。8.1的目标，就是防止这种“治理设计很好、运行执行失控”的局面。
2.2 8.1条要求组织在运行层面做好哪些事
| 要求 | 标准关键词 | 在AI治理中的含义 | 典型输出 |
|---|---|---|---|
| 过程策划 | 制定过程准则 | 明确哪些过程需要控制、按什么规则运行 | 流程图、准则、放行标准 |
| 过程实施 | 按照准则实施控制 | 把策划内容变成真实操作，不靠临时判断 | 执行记录、工单、审批留痕 |
| 控制监测 | 监测控制有效性 | 检查控制是否真能产生预期结果 | 监测指标、抽查结果、复盘报告 |
| 变更控制 | 控制策划的变更 | 防止运行过程因变化而偏离原有治理安排 | 变更记录、影响分析、补救措施 |
| 外部控制 | 外部提供过程、产品或服务受到控制 | 第三方也要纳入AIMS运行边界 | 供应商要求、评审和监督记录 |
2.3 AI运行控制最大的难点，是把“纸面控制”变成“现场控制”
许多组织在实施AIMS时会碰到一个很现实的落差：制度里写得很完整，实际运行中却经常绕过。例如，制度要求模型上线前必须完成验证确认，但项目赶进度时只做了局部测试；制度要求重大变更必须评审，但业务团队认为只是“小改动”就直接上线；制度要求供应商提供必要文档，但采购完成后没有人继续追踪；制度要求监控控制有效性，但现场只盯着准确率和响应时间，却没有看用户投诉、异常输出、日志完整性和人工监督执行情况。
这类问题都说明8.1没有真正落地。运行策划和控制的本质，不是画一张流程图，而是让过程准则进入实际工作节奏，让控制点成为默认动作。对AI系统来说，真正重要的运行控制通常包括准入控制、数据和模型变更控制、上线放行控制、运行监控、事件升级、外部依赖控制和纠正措施闭环。能把这些动作嵌进项目和运维日常，8.1才算有效。
三、实施要点
3.1 明确AIMS运行过程清单和关键控制点
- 建议围绕AI系统生命周期梳理关键过程，如需求确认、数据准备、开发验证、部署上线、运行监控、事件响应、变更管理和停运退出。
- 每个过程都应有准则、输入输出、责任角色和记录要求。
- 没有过程清单，运行控制就会依赖个人经验。
3.2 让6.1.3确定的控制真正进入运行环节
- 风险处置中选定的控制措施，应明确落到哪个流程、由谁执行、用什么证据证明执行。
- 例如，人工监督要求应进入操作规程，用户告知要求应进入产品发布清单，日志要求应进入运维基线。
- 控制措施落点清晰，8.1才不会沦为概念条款。
3.3 建立控制有效性监测机制
- 不要只证明“控制存在”，还要定期检查“控制是否有效”。
- 可通过抽样检查、运行指标、事件分析、用户反馈和内审发现来判断控制效果。
- 若控制未达到预期结果，应及时触发纠正措施。
3.4 对运行中的变更和意外偏差保留补救动作
- 8.1要求控制策划的变更，也要求评审非预期变更的后果。对AI系统来说，很多偏差并不是计划内发生的。
- 因此，组织应预设对异常输出、供应商变更、数据漂移、规则失效等情形的补救机制。
- 非预期变更后果评审是AI运行控制中非常关键的动作。
3.5 把外部提供的过程和服务纳入同样严肃的控制
- 只要第三方提供的模型、数据、平台、运维或标注服务会影响AIMS运行，就应纳入控制要求、接口要求和监督机制。
- 组织不能因为功能来自外部，就默认治理责任也外包出去。
- 外部依赖失控是AI运行条款中最常见的薄弱点之一。
四、常用工具与实施方法
| 工具/方法 | 适用目的 | 实施建议 | 输出成果 |
|---|---|---|---|
| AI过程地图 | 梳理运行阶段关键过程和接口 | 覆盖内部和外部过程 | 流程图和责任矩阵 |
| 放行与运行检查清单 | 确保关键控制点被执行 | 结合上线、变更和周期检查场景使用 | 检查记录 |
| 控制有效性指标 | 监测控制是否达到预期结果 | 除技术指标外纳入监督和沟通指标 | 监测仪表盘 |
| 外部依赖控制清单 | 管理第三方提供的过程、产品和服务 | 与供应商管理、合同和验收联动 | 第三方控制表 |
| 异常与偏差补救流程 | 处理非预期变更后果 | 预设升级、缓解和回滚动作 | 补救方案和记录 |
五、典型案例
案例一：控制清单存在，但上线过程仍然经常跳步
- 背景：某企业已经制定AI上线控制清单。
- 问题：项目赶时间时经常跳过用户告知和风险复核，只保留技术测试。
- 改进：组织将关键控制点嵌入发布流程，未完成则无法放行。
- 结果：控制执行一致性明显提升。
案例二：供应商模型更新后，内部监控完全失效
- 背景：第三方模型供应商调整了输出格式和日志接口。
- 问题：组织未把外部服务变更纳入运行控制，导致原有监控和审计流程失灵。
- 改进：将外部服务变更纳入8.1过程控制和供应商通知要求。
- 结果：第三方变更开始被及时识别和处置。
案例三：只看模型性能，忽略人工监督执行质量
- 背景：某高影响AI系统运行稳定，性能指标良好。
- 问题：人工监督岗位长期未按要求复核关键输出，但组织一直没有监测该控制有效性。
- 改进：增加监督执行率、升级上报及时性等运行指标。
- 结果：组织终于看见了运行控制中的真实薄弱点。
六、成文信息管理要求
8.1条强调文件化信息应在必要范围内可用，以确信过程按策划进行。这意味着组织至少应能够证明：过程已定义、控制已执行、有效性已监测、变更已评审、外部依赖已纳入控制。
| 建议文件或记录 | 关键内容 | 用途 |
|---|---|---|
| AI运行过程清单 | 过程名称、准则、责任、输入输出 | 证明过程已策划 |
| 控制实施记录 | 控制点执行情况、审批、检查结果 | 证明控制已落实 |
| 控制有效性监测记录 | 指标、抽查、复盘、问题发现 | 证明有效性被持续监测 |
| 运行变更与补救记录 | 非预期变更、影响分析、缓解措施 | 证明偏差得到处理 |
| 外部过程控制记录 | 第三方服务要求、评审、监督和异常处理 | 证明外部依赖受到控制 |
七、常见误区及踩坑提醒
| 误区 | 问题表现 | 正确做法 |
|---|---|---|
| 把8.1理解为普通运维条款 | 只管系统运行，不管治理控制是否被执行 | 将风险处置和治理控制嵌入运行过程 |
| 只证明控制存在，不验证效果 | 控制执行了，但没人检查是否有用 | 建立有效性监测和纠正机制 |
| 变更发生后才补流程 | 异常已经扩散才开始追问谁批准 | 提前设计变更控制和补救路径 |
| 第三方不纳入运行控制 | 外部模型或平台变化导致内部控制失效 | 把外部过程、产品和服务纳入AIMS边界 |
| 只看技术KPI | 忽略用户沟通、人工监督和日志等控制 | 综合监测技术与治理双重效果 |