简介：ISO/IEC 42001:2023 是国际标准化组织与国际电工委员会联合发布的首版人工智能管理体系国际标准，面向 IT 安全管理从业者、AI 研发团队成员、企业管理层以及负责质量管理体系建设的人员。该标准围绕人工智能管理体系（AIMS）的建立、运行、维护与持续改进展开，涵盖组织背景与相关方需求识别、治理架构确立、风险管理规划、运行支持以及持续改进等关键环节；附录还给出参考控制目标、实施指南与风险评估方法，可用于合规实施、风险缓解以及角色职责划分。压缩包内共 1 个 PDF 文件，约 1.18MB，是完整的英文标准正文，含前言、目录、条款与附录，便于检索和打印传阅。已有 450 人学习下载。读者可据此对照条款梳理自有 AI 管理流程、搭建控制项清单与风险评估表，并为内部制度编写和审核准备提供统一框架参照。

1. 一套管理标准为什么能约束人工智能系统

翻完 ISO/IEC 42001:2023 正文，头一个反直觉的地方是：这份关于人工智能的标准，几乎不讨论模型。它不给精度阈值，不规定训练数据规模，也不评价哪种架构更安全；十个条款里，绝大多数篇幅在讲谁批准、谁复核、什么时候重新做评估、记录留多久。原因不难理解——同一个模型放在简历筛选和内容推荐里，出错的方式和受损方完全不同，任何写死在标准里的技术指标都会迅速过时。42001 换了条路：不管模型怎么算，只把 AI 的不确定性变成组织能反复审计的管理对象。搞懂这层映射，比背条款号有用，它决定了你手上的 AI 管理框架到底只是一摞文件，还是一套真能运行起来的机制。

2. AIMS 的骨架：十个条款为什么连成一条闭环

2.1 高阶结构：42001 和质量管理、信息安全体系长得一样

ISO/IEC 42001 的第 4 到第 10 章顺序是固定的：4 组织环境、5 领导作用、6 策划、7 支持、8 运行、9 绩效评价、10 改进。读过 ISO 9001 质量管理体系或者 ISO/IEC 27001 信息安全体系的人会发现，这个顺序一模一样。这不是巧合，它们共用一套高阶结构，条款号都能对齐：4 都是组织环境，5 都是领导作用，6 都是策划，9 都是绩效评价，10 都是改进。

这么设计有明确的动机。管理体系标准描述的实际上是把某件事持续做对的可重复性，并不描述具体技术。一家公司如果已经运行着质量体系和信息安全体系，再叠加一个 AI 管理框架，结构不同就要重写一整套文件、另找一套内审员、管理评审还得单独开会。结构一致的话，AIMS 可以直接挂到原有的体系上：共用文件控制程序、共用内审计划、共用纠正措施流程，只在 6.1 和 8.x 这几个 AI 特有的节点上新增内容。

代价也很明显：为了能被复用，标准必须对“AI 是什么”保持中立。它不管你用的是大模型还是决策树，不管你是自研还是调用第三方接口，第 4 到第 10 章一个字不提具体技术。这种克制让它几年内不会过时，但也让它看起来像一份“什么都能往里装”的管理文件——这是很多人第一次翻完的失望点。

真正的 AI 属性集中在那两处：第 6 章里的 AI 风险与影响评估，以及附录 A 的参考控制。前者决定你评什么，后者决定你控什么。这两块没搭起来，第 4 到第 10 章就只是一个空壳。

2.2 第 6 章和第 8 章写了两遍评估，这不是冗余

标准在 6.1.2、6.1.3、6.1.4 里写了一遍 AI 风险评估、风险处置和系统影响评估，然后在 8.2、8.3、8.4 里又几乎原样写了一遍。第一次读很容易当成排版失误，甚至怀疑是不是文档合并的时候复制粘贴错了。

这其实是 PDCA 在文本结构上的体现。第 6 章是策划阶段，要求你在体系建立阶段完成一次完整的评估：把所有 AI 场景过一遍，建立风险基线，定处置措施，给出影响评估结论。第 8 章是运行阶段，要求你在实际运行中按规则重新执行这些评估。同一组动作，一个是初次或周期性策划，一个是触发式执行。少了第 6 章，体系没有基线；少了第 8 章，体系会在上线那一天冻结，此后再也不会更新。

标准没有规定“什么算触发”。这是它一贯的风格——给出义务，不给阈值。实践中一般由组织自己定义触发条件，常见的写法包括：

• 新模型上线，或者现有模型重训、更换基座模型
• 训练数据来源、范围或采集方式发生变更
• 使用场景扩展，比如同一个模型从内部工具变成对外服务
• 组织外部环境变化，比如相关方要求、法规或行业惯例调整
• 发生 AI 相关事件或接近失误
• 到达规定的周期性复核时间

把这六条写成一份《AI 变更触发评估清单》，8.2 和 8.4 才有可能真正执行；写不出来的话，最后往往变成“上线时评估一次，之后再也没人动”——这是最典型的一种运行失效。

提示：6.3 单独有一条“变更的策划”，很多人只记住它，却忘了 8.2 到 8.4 才是变更之后的执行动作。两条要一起看，否则策划完就没有下文了。

再补一句容易被忽略的：8.1 运行策划和控制是这三条评估的执行上下文。它要求组织对 AI 系统的运行做策划、实施控制，并保留必要的文件化信息。换句话说，8.2 到 8.4 中那些评估动作，即使有人写了文件，如果没有纳入日常运行流程，也很难被真正执行。

2.3 附录 A 是规范性附件：「参考」不等于「可选」

附录 A 的标题里有 reference 这个词，译作“参考控制目标和控制措施”，读起来像建议。但它是规范性附录，不是资料性附录。

规范性意味着：组织如果要声明自己的 AI 管理体系符合这份标准，就必须对附录 A 里的每一个控制目标作出判断——应用，还是不应用，不应用要给出理由。这和 ISO/IEC 27001 里那份适用性声明是同一个思路。它不是“我挑了几个做”，而是“每一个我都看过，并且能解释为什么做或不做”。审计问的是后者。

附录 A 的控制目标大致分成这几类：

真正的工作量不在“知道有哪些控制”，而在逐条做适用性判断并留下理由。附录 B 是实施指南，告诉你每条控制在实践中可以怎么落地；附录 C 是目标与风险来源的参考清单；附录 D 讲一套体系怎么跨业务域复用。四份附录的关系是：A 定要求，B 给做法，C 给输入，D 给边界。

这里还藏着一个常见误读：附录 A 的结构是“控制目标 + 控制措施”，目标是上层，措施是下层的实现示例。审核看的是控制目标是否被满足，而不是措施是否原样照抄。把附录 A 当成打勾清单逐条抄进体系文件，是最省事也最没有价值的做法——文件是齐的，风险却没被真正识别。

3. 双轨评估：风险评估和影响评估到底差在哪

3.1 一张表看清两者为什么不能合并

这两个评估经常被合并成一张表，因为名字太像。但标准把它们放在 6.1 的不同子条款里，一个是 6.1.2 和 6.1.3，一个是 6.1.4，说明这是两件事。

一句话区分：风险评估问的是“这个系统会不会偏离我们的目标”，影响评估问的是“它运行起来之后，会对谁产生什么后果”。前者站在组织视角，代价和可能性可以排序、可以权衡；后者站在受影响方视角，有些后果根本不该被概率稀释。

最后一行是关键：风险可以接受，影响不能接受。一条低概率但不可逆的后果，在风险评估里可能被评为“低”，因为概率低；在影响评估里却是“不可接受”，因为它一旦发生就无法挽回。两张表合并之后，影响评估几乎一定会被风险等级吃掉——这就是为什么很多组织的影响评估表，填完看起来和风险登记表长得一模一样。

3.2 风险登记条目长什么样

标准不会规定表结构，但字段的语义要对齐评估逻辑。下面是一条典型的登记记录：

# 一条 AI 风险登记记录的常见字段结构，字段名可以自定，语义要对齐 risk_id: AI-R-014 scenario: 简历初筛模型对候选人自动打分 # 记录的是场景，不是模型本身 risk_source: 历史招聘数据中的群体分布偏差 # 对应附录 C 的风险来源分类 likelihood: 高 consequence: 特定群体初筛通过率系统性低于基准 # 后果要写到可观测的程度 affected_parties: [候选人, 招聘团队, 用人单位] # 影响评估的入口字段 existing_controls: [数据偏差检测, 人工复核抽样] inherent_risk: 高 treatment: 降低 # 降低 / 规避 / 转移 / 接受 treatment_plan: 分层抽样复核，偏差指标纳入上线门槛 owner: 模型负责人 + 业务负责人 # 双签，避免单一责任人 residual_risk: 中 review_due: 2025-06-30 # 到期强制复核，不靠自觉 evidence_ref: [IA-2025-003, DQ-118] # 指向影响评估与数据质量报告

几个字段值得单独说。scenario 记录的是场景，并非模型本身，因为同一个模型换一个用途，风险完全不同，把模型当登记粒度会导致一条记录覆盖多个风险，最后没人说得清它到底在管什么。affected_parties 是风险评估和影响评估的连接点：风险评估阶段填它，是为了知道后果落到谁身上；影响评估阶段展开它，是为了判断这个后果本身是否正当。

residual_risk 和 review_due 是最容易被省略、也最容易被审计追问的两个字段。前者证明你评估过处置之后还剩多少风险，后者证明你打算什么时候回头看。没有这两个字段，风险登记表就只是一份“我们识别过风险”的声明，而不是一份持续运行的任务队列。

提示：evidence_ref 不是装饰。内审时最常问的一句话是“这条风险你依据什么判断它降到了中”，答不上来这条记录基本就作废了。

3.3 附录 C 把「AI 特有的不确定性」变成可枚举项

附录 C 给的是潜在的组织目标和风险来源清单。它的机制价值常被低估：如果每次评估都从白纸开始，团队会本能地只写自己熟悉的那几项，风险识别的覆盖面取决于个人经验；给一份参考清单，等于把“该想到什么”从个人记忆变成组织资产。

典型的 AI 风险来源大致覆盖这些方向：数据质量与代表性不足、训练数据的来源合法性与授权、模型漂移与性能衰减、可解释性不足导致无法追责、自动化偏见、人机交互设计带来的误用、对第三方模型或组件的依赖、使用场景漂移、恶意使用与滥用。这些不是技术故障清单，而是“AI 系统在组织里运行时可能出问题的地方”。

用法上有个细节：清单是用来做减法的，不需要逐条勾选。评估时先对照清单问“这一类在我们这里成不成立”，不成立就写一句理由跳过，成立才展开。这样一份二十来项的清单，落到具体场景上往往只筛出五六项，但剩下的五六项是真正相关的，而不是拍脑袋想出来的。

还有一个反向用法：把附录 C 当作设计评审的检查表。在立项评审时对照清单过一遍，比上线前才发现数据授权有问题要便宜得多。这套思路在质量管理体系里叫先期质量策划，AI 场景只是换了个对象。

4. 文档化信息：AIMS 的运行时其实在证据链里

4.1 两个动词：保持与保留

标准在 7.5 里反复用两个动词，中文翻译很接近，机制上完全不同。

“保持”是运行态，“保留”是证据态。一份 AI 方针要“保持”，意思是它得是最新的、被批准过的、员工能拿到的；一次风险评估要“保留”，意思是它发生过、谁做的、结论是什么、什么时候做的，这些信息要能复原。

7.5.2 管的是创建和更新：标识、格式、评审、批准。7.5.3 管的是控制：可获得性、充分保护、分发、存储、保留、变更控制、处置。这两节合起来构成文件化信息的全生命周期，但实践中绝大多数组织的文件控制只做到了“有目录”，没做到“版本与批准可追溯”。

举个具体的失败模式：一次风险评估记录，上面写了结论“风险可接受”，但没写是谁发起的、谁复核的、依据哪版数据、什么时候该复核。这四件事缺任何一件，内审的时候这条记录就废了——不是结论错了，是它无法被验证。管理体系审计的本质是验证证据，而不是验证判断。

4.2 内审与管理评审怎么配合

9.2 内部审核和 9.3 管理评审是两套不同的机制，经常被混成一件事。内审是检查体系有没有按设计运行，管理评审是决策层判断体系还适不适用、要不要改。

内审的要求里有两个容易被忽略的点：审核方案要考虑过程的重要性和以往的审核结果，也就是说风险高的过程审得勤一点，上次出过问题的下次重点看；审核员不能审核自己的工作，这条在小团队里常常做不到，最后变成自己审自己，记录齐全但发现不了问题。

管理评审的输入是列举式的：前次评审的措施状态、体系相关的变更、目标的达成程度、不符合与纠正措施、监视测量结果、审核结果、相关方反馈、风险评估与影响评估的结果、改进机会。输出是改进机会、体系变更需求和资源需求。

这条链的闭合点在 10.2：管理评审提出的变更，要落到具体的纠正措施或改进项上，有责任人、有期限、有验证。缺了这一环，管理评审就退化成一年一次的汇报会，开完就结束，没人跟进。

4.3 附录 D：一套体系怎么覆盖多个业务域

附录 D 讨论的是在多个领域或行业中使用同一套 AI 管理体系。这在集团型组织里很实际：总部建一套 AIMS，下面几个业务单元各自做 AI，场景差别很大。

核心问题回到 4.3 确定范围。常见做法是“一个体系、多份适用范围声明”：第 4 到第 10 章的过程共享，比如同一套风险评估程序、同一套内审计划、同一个管理评审；附录 A 的控制措施按业务域做适用性差异，比如做医疗相关应用的单元要额外覆盖某些影响评估要求，做内部效率工具的单元可以裁掉一部分第三方关系控制。

这种结构的风险是范围声明写得太宽。写一句“公司全部 AI 相关业务”，听起来完整，实际上把没做评估的业务也圈了进来，一旦审计抽样抽到，就会暴露范围声明和实际运行之间的缺口。范围声明要写到能被验证的粒度——按业务单元、按系统、按场景都可以，前提是每一个都能指向对应的评估记录。

5. 落地时最常见的五个问题：踩坑记录与排查路径

5.1 现象：附录 A 的控制措施全打勾，风险登记表只有三行

原因通常是先做文件后做评估。团队拿到附录 A，逐条对照写体系文件，写完发现风险登记表还空着，于是补三条凑数。顺序反了——控制措施是为了处置识别出来的风险，没有风险输入，控制措施就只是照抄。

解决：把顺序倒过来，先跑一遍 6.1.2 的评估，哪怕只覆盖三五个真实场景，把风险登记表填出内容，再回到附录 A 做适用性判断。每一条“应用”的控制，要能指向至少一条风险或影响评估结论。指不上的，要么是确实不适用，写清理由；要么是漏了评估。

5.2 现象：风险评估表和影响评估表是同一张

原因是省事。两张表字段高度重叠，合并成一张看起来效率更高。

问题出在结论上。风险表允许“接受”，影响表不允许。合并之后，影响评估的结论会被风险等级覆盖，一个不可逆的后果因为概率低就被标成“可接受”，然后没人再管。

解决：物理上分成两张表，哪怕字段重复一半。风险评估的结论是风险等级加处置方式，影响评估的结论是“该影响是否正当、是否需要额外控制或停止使用”，两套结论不能共用一个字段。

5.3 现象：内审不符合项的关闭日期比根因分析还早

这是典型的先关闭再补理由。审核发现记下来，责任人为了赶进度直接填一个关闭日期，根因那一栏写“人员疏忽”，纠正措施写“加强培训”。

解决：在 10.2 的流程里加一道卡点，根因分析未完成不允许填关闭日期。根因那一栏禁止出现“人员疏忽”“意识不足”这类词，必须落到具体机制上：是流程里缺了一步，还是某个检查项没有定义判定标准。纠正措施要能被验证——写“加强培训”的，要求附培训记录和效果抽检结果。

5.4 现象：范围声明写「公司全部 AI 相关业务」

听起来完整，实际上不可验证。审计抽样时问“某业务线的某个模型在不在范围内”，答不上来。

解决：范围声明按可枚举的粒度写，落到业务单元、系统名称或场景清单。声明里出现“全部”“相关”这类词时，追问一句“怎么证明”。写不全没关系，写清楚边界比写得宽更重要。

5.5 现象：模型迭代了三个版本，文档化信息还停在上线评审那一版

原因是变更没有触发评估。模型迭代在工程团队看来是日常操作，在体系里却是 8.2 的触发条件之一。

解决：把《AI 变更触发评估清单》嵌到发布流程里，模型版本变更、数据源变更、用途扩展都要走一次轻量评估。轻量不等于免做，评估可以只覆盖变化部分，但记录要有。这一条如果不嵌进工程流程，靠体系文件自觉执行，基本不会发生。

6. 设计取舍：为什么 42001 只给过程义务，不给结果指标

写到这里可以把最核心的设计取舍说清楚了：这份标准通篇不给指标。不给准确率下限，不给偏差阈值，不给响应时间要求，连“高风险”怎么划分都不定义。很多人第一次读会觉得它空，觉得一份 AI 标准怎么能连个数字都没有。

原因在于指标和场景强绑定。同一条偏差阈值，放在内容推荐里可能可接受，放在信贷审批里就是红线；同一个准确率，内部辅助工具和对外服务的要求差一个数量级。标准一旦写死数字，要么迅速过时，要么被当成万能挡箭牌——“我们达到了标准要求”。所以它选择只规定过程义务：你必须识别风险、必须评估影响、必须留下证据、必须定期复核、必须在不符合时采取纠正措施。至于阈值定多少，交回组织自己，由组织和它的相关方去谈。

这个取舍带来一个必须说清楚的后果：符合 42001 不等于 AI 系统安全。它证明的是组织具备持续发现和处理问题的能力，而不是系统本身没有问题。把认证当成安全背书，是对这套体系最常见的误用。它的定位更接近运行机制——一套让问题能被提出、被记录、被追责、被修复的机制。

那怎么验证这套机制真的在转？我一般用一条很笨的办法：随机抽一条风险登记记录，往前追。追它有没有对应的影响评估，追影响评估的结论有没有变成具体的控制措施，追控制措施有没有留下执行记录，追这条记录有没有按期复核过，追复核之后有没有产生变更或纠正措施。五步能追通，体系是活的；中间断在任何一步，前面那些文件就只是装饰。

我踩过这个坑。早些年做体系落地，习惯先把文件写漂亮，目录整齐、编号规范、封面统一，评审的时候一片好评。半年后一次内审，抽到一条风险评估记录，往前追到影响评估就断了——影响评估表存在，但填的是通用模板，和这条风险没有任何对应关系。那一刻很清楚：我们做的是一套文档，不是一套机制。从那以后，我每次启动这类体系工作，都强制先跑通一条完整的证据链，哪怕只有一条，再谈铺开。一条能追通的记录，比一百页写得漂亮的程序文件有用得多。希望帮到你。

本文还有配套的精品资源，点击获取