ISO/IEC 42001解读：AI治理与AI管理体系怎么落地

简介：这份资源是 ISO/IEC DIS 42001:2022 人工智能管理体系国际标准草案的原文 PDF，由 ISO 与 IEC 联合制定、JTC 1/SC 42 归口，面向 AI 治理负责人、合规与内审人员、企业架构师及标准化研究者，用于在正式版发布前了解 AI 管理体系的框架要求与合规要点。压缩包内为 1 个 PDF 文件，共 1.98MB，内容涵盖前言、引言、术语定义、组织与治理结构、风险管理、数据管理、安全性、可持续发展以及评估与认证要求等章节，另附 ICS 分类号与投票时间等文档信息，正文保留了草案阶段的批注说明，可用于逐条比对条款、搭建体系文件与编写风险清单。已有 399 人学习下载，说明其在 AI 合规圈内具备一定参考度。读者可据此梳理组织职责划分、构建数据与安全控制措施、提炼审核证据链，为后续 ISO/IEC 42001 正式版落地与第三方认证做准备。

1. 到底什么是 ISO/IEC 42001：一份给 AI 立规矩的管理体系草案

有人问过一个挺要命的问题：公司里那套用来自动审批额度的模型，是谁批准上线的？IT 说是业务提的需求，业务说是数据团队训练的，数据团队说模型是从外部接进来的……这套系统没坏，可它长期处在一种“人人都在用、却没人对它负责”的状态。

ISO/IEC 42001 就是冲着这类状态来的。它的全名很朴素——“信息技术——人工智能——管理体系”，2022 年以 DIS（国际标准草案）的形态在委员会内流转，投票期从 2022 年 11 月 9 日开到 2023 年 2 月 1 日。这份文件从头到尾关心的不是模型准不准、参数多不多，而是一件更靠前的事：一个组织在引入、运行、修改、停用人工智能时，有没有一套能被检查、能被追溯的管理安排。搞懂它，你才知道“AI 治理”这个词底下，缺的到底是哪块板。

2. 为什么需要它：AI 系统的“黑匣子”问题不在算法里

多数人第一次听说人工智能管理体系，反应是“又一个认证”。但如果把这份草案的目录从头翻到尾，会发现它几乎没提具体模型、没规定准确率阈值、也没要求用什么框架。它花大量篇幅在谈组织、职责、风险、文档、审核。这种“不谈技术”的写法不是偷懒，而是因为它要解的压根不是技术问题。

2.1 传统软件确定，AI 系统不确定

传统软件的输入输出关系是写死的：付款金额超过 5 万就走二级审批，这条规则可以被人读、被人改、被人测试。AI 系统的行为是从数据里学出来的，同一个输入在不同版本、不同数据分布下可能给出不同结果，而中间那层“为什么这么判断”，连训练它的人都未必说得清。这就是常说的黑匣子。

黑匣子本身不致命，致命的是它周围没有配套的流程。系统做错了判断，谁去发现？发现之后谁有权下线？下线前的过渡方案在哪？这些问题不属于算法工程师的职责范围，也不属于运维，它们悬在部门之间的缝隙里。草案的 4.1 和 4.2 两条，要求组织先理解自己所处的情境、再理解相关方的需求和期望，说白了就是逼你把缝隙里的人找出来：用户、员工、监管方、合作方，谁会被这套系统影响，他们的期待是什么。

我见过一个说法很到位：AI 出问题，九成不是模型崩了，是流程崩了。模型只是把一个原本就模糊的决策流程，放大成了一条流水线。

2.2 为什么“事后补救”在 AI 上特别贵

普通软件出了 bug，回滚版本通常能解决问题。AI 系统不行，因为它有三重外溢。

第一重是数据外溢。模型训练用过的数据，可能包含大量个人信息、内部记录、第三方内容，这些数据一旦进入模型，就再也无法“回滚删除”。第二重是决策外溢。一个信贷模型或筛选模型产生的判断，会真实地作用在人身上，事后纠正只能弥补一部分，错误的印象已经留下。第三重是声誉外溢。等到外部提出问题再来解释，成本要高出几个量级。

草案在 6.1.2 和 6.1.3 里把这件事拆成两步：先做 AI 风险评估，识别风险并排优先级；再做 AI 风险处置，决定哪些风险要规避、哪些要降低、哪些要接受。这套动作的价值不在表格本身，而在于它把“事后补救”往前挪到了“上线之前”。后悔药这东西，做 AI 的团队最缺。

2.3 为什么长成“管理体系”，而不是一份技术规范

这是最容易看不明白的一点。既然要管 AI，为什么不直接写一份技术要求清单，规定模型必须可解释、数据必须脱敏、日志必须保留多少天？

因为技术清单会过期，而组织行为不会。模型架构两三年换一代，数据合规要求一年变几次，写死的技术要求很快会变成一纸空文。管理体系走的是另一条路：它规定的是“组织应该具备哪些能力”，而不是“系统应该满足哪些指标”。具体来说，它要求你有明确的方针、有清晰的职责分配、有定期的风险复评、有内部审核、有管理评审。这些能力一旦建立，无论技术怎么变，都能套上去用。

草案的结构也印证了这一点。它的第 4 章到第 10 章，用的是国际管理体系标准通行的高阶结构（HLS），与常见的质量管理体系标准、信息安全管理体系标准是同一套骨架：组织情境、领导、策划、支持、运行、绩效评价、改进。这套骨架的好处是，一个组织如果已经在跑质量或信息安全体系，AI 体系可以直接挂进去，不用另起炉灶。

3. 核心骨架：七个章节如何把 AI 管起来

一份标准的目录，往往比正文更能说明它的意图。ISO/IEC DIS 42001 的正文十个章节，是典型的 PDCA 循环切法：策划（Plan）落在第 6 章，运行（Do）落在第 8 章，绩效评价（Check）落在第 9 章，改进（Act）落在第 10 章。前面第 4、5 章是地基，后面第 7 章是补给。看懂这个排布，整份文件就不再是一堆条款。

3.1 组织情境与范围：先划清“管到哪儿”

第 4 章只有四条，但每一条都在逼组织回答一个尖锐问题。

4.1 要求理解组织及其情境：你所在的行业、业务模式、技术依赖、外部环境是什么。4.2 要求理解相关方的需求和期望：谁会因为这套 AI 系统受益，谁可能受损，谁有权提要求。4.3 要求确定 AI 管理体系的范围：这套体系覆盖哪些部门、哪些系统、哪些业务流程。

范围这一条最容易被敷衍，也最容易后来引发问题。很多组织的做法是“先把范围写小一点，好过审”，结果真正的核心系统被排除在外，体系成了摆设。反过来，范围写得过大，什么业务都往里装，执行成本会高到没人愿意配合。合理的做法是按 AI 系统的实际影响划界：凡是会直接作用于人的判断、会给组织带来实质性风险的系统，都该在范围内。

4.4 是 AI 管理体系本身的要求，相当于宣告：这套体系必须被建立、实施、维护并持续改进，不是一次性交差。

3.2 领导与 AI 方针：写下来才算数

第 5 章的标题是“领导”，但它的实质是“责任归属”。

5.1 讲领导作用和承诺，5.2 要求组织建立 AI 方针，5.3 要求明确角色、职责和权限。这三条串起来是一句话：AI 治理不能只靠技术团队的自觉，必须有组织层面的公开承诺。

AI 方针是这一章的核心产出。它不是宣传口号，而是一份能回答以下问题的文件：组织在什么场景下允许使用 AI，什么场景下禁止；对公平性、透明性、可解释性的基本立场是什么；由谁批准新系统的上线；发现问题的上报渠道是什么。方针由最高管理层签发，意味着它具备跨部门的约束力。

条款 5.3 提到角色和权限，这一条在实践中经常被低估。一个 AI 系统从提出到退役，会经过业务方、数据方、算法方、安全方、法务方、运维方，如果不把每个节点的责任人和决策权写清楚，体系再完整，也只会停留在纸面上。这也是我特别认可这句标准的原因：写下来的职责，才是职责；没写下来的，只是默契。

3.3 策划：风险评估、风险处置、影响评估三件套

第 6 章是整份草案技术含量最高的部分，也是三个最容易混淆的概念同时出现的地方。

6.1.2 的 AI 风险评估，问的是“这套系统会给组织带来什么风险”：模型失效、数据泄露、供应商中断、决策失误带来的业务损失。它的视角站在组织内部。

6.1.3 的 AI 风险处置，问的是“这些风险怎么处理”：规避、降低、转移还是接受，处理完之后剩余风险是否可接受。

6.1.4 的 AI 系统影响评估，视角完全变了，问的是“这套系统会对外部的人和社会产生什么影响”：对个人权利、对特定群体、对社会整体的潜在影响，包括那些不违反任何规则但依然值得警惕的后果。

风险评估是向内看的，影响评估是向外看的。这两件事经常被合并成一张表，结果是内部风险和外部影响都不清楚。草案把它们拆成独立条款，正是为了让组织分开思考。

6.2 的 AI 目标与规划，要求把方针转化成可测量的目标；6.3 的变更策划，要求任何影响体系的变更都要有计划。变更这一条看起来不起眼，实际上覆盖了 AI 生命周期里最危险的动作，比如换模型版本、换训练数据、换部署环境。

3.4 支持、运行、评价、改进：闭环怎么转

第 7 章“支持”列了五样东西：资源、能力、意识、沟通、成文信息。这条线很清楚：没有预算和人手，体系跑不起来；没有培训，员工不知道规矩；没有沟通机制，问题传不上去；没有文档，一切无法追溯。

第 8 章“运行”把第 6 章的策划执行一遍：运行策划与控制、AI 风险评估、AI 风险处置、AI 系统影响评估。同一组名词出现两次不是重复，而是一个闭环的两端：策划阶段是“计划要做”，运行阶段是“实际做了，并且记录在案”。

第 9 章“绩效评价”包含监视测量、内部审核、管理评审。这一章是外部审核员最看重的部分，因为它能证明体系是活的，不是一次性写完的一摞文件。第 10 章“改进”处理不符合项和纠正措施，并要求持续改进。

4. 常见误区：五个最容易搞混的边界

围绕这份草案，误读往往集中在几个固定的位置。搞混这些，后面的判断基本都会跟着歪。

4.1 误区一：42001 是给 AI 产品发合格证

易混点：很多人一听“AI 标准”，以为通过认证就等于这个模型、这套算法、这个系统被国际认可了。

为什么会混：市面上大量认证确实是产品层面的，比如电器安全、通信设备入网，测的是具体物件。加上不少宣传口径把标准号和产品合格绑在一起说。

怎么区分：42001 认证的对象是组织，不是产品。审核员看的是组织的方针文件、风险评估记录、职责分配、内部审核报告，不会拿你的模型跑准确率测试。换句话说，它能证明“这家机构有管好 AI 的能力”，不能证明“这个模型没有缺陷”。这个区别很重要，因为它决定了你不能拿一张体系证书去回应“你的算法歧视了某类用户”这种具体质疑。

4.2 误区二：AI 风险评估就等于 AI 系统影响评估

易混点：两个词都带“评估”，都出现在第 6 章和第 8 章，很容易被当成同一件事的两种叫法。

为什么会混：中文里“评估”这个词范围太宽，翻译过来之后区分度进一步下降。而且两者的输入材料有重叠，都要用到系统描述和场景信息。

怎么区分：抓住“受益对象”和“受损对象”的主体。风险评估的主体是组织，问的是“我们会不会吃亏”，输出的是风险清单和处置方案，通常不进对外披露。影响评估的主体是个人、群体和社会，问的是“别人会不会因为我们吃亏”，输出的是影响识别、严重程度判断和缓解措施，很多时候需要留痕以备对外说明。一个向内，一个向外，两张表不能合并。

4.3 误区三：附录是参考资料，可以跳过

易混点：正文十节是硬要求，后面 AnneX A 和 AnneX B 看着像附录，似乎是选读。

为什么会混：在其他技术标准中，annex 通常就是资料性的补充说明，读者习惯性略过。

怎么区分：这份草案里，附录 A（参考控制目标与控制措施）和附录 B（AI 控制的实施指南）都明确标注为规范性（normative），也就是说，它们是要求的一部分，不是可读可不读的注脚。附录 A 给出的是控制目标和控制措施的清单，附录 B 则逐条给出落地方式，从 AI 方针、内部组织、AI 角色与职责、问题上报，一直讲到资源、影响评估和生命周期。正文回答“该有什么”，附录回答“具体怎么搭”。只看正文不看附录，等于拿到了一份图纸却跳过了施工说明。

4.4 误区四：DIS 草案等同于正式标准

易混点：文件封面上印着 ISO/IEC 的编号，看起来和正式标准没有区别。

为什么会混：草案文本在格式上已经相当正式，有版权声明、有分类号、有完整目录，不仔细看声明部分很难发现差别。

怎么区分：这份文件的正文开头有明确声明，它是为征求意见和批准而分发的草案，可能发生变更，在正式发布前不得被称作国际标准。这意味着两件事：一是条款可能改，不能拿某一版草案去写合同条款；二是它释放的信号比条款本身更有价值，说明这个方向已经进入国际协调阶段。参考可以，当作定论不行。

4.5 误区五：有了管理体系，就不用管具体技术风险

易混点：既然标准不规定技术细节，是不是意味着建立体系之后，算法层面的问题就自动解决了。

为什么会混：管理体系的表述偏抽象，容易给人一种“流程跑通万事大吉”的错觉。

怎么区分：体系管的是“组织有没有能力发现和处理问题”，不能代替“问题被真正处理掉”。一个组织可以体系齐全、文档完备，同时模型依然有偏差。体系的价值在于让偏差更早暴露、让处理过程可追溯，它是一套基础设施，不是一剂万能药。把它理解成“组织级的免疫系统”比理解成“药”更贴切。

5. 附录里的控制措施：AI 全生命周期到底管什么

正文给出的是框架，真正能落地的是附录 A 和附录 B。附录 A 列控制目标与控制措施，附录 B 逐项给出实施指南。从 B.2 到 B.6，覆盖的顺序很讲究：先政策，再组织，再资源，然后影响评估，最后生命周期。

5.1 从政策到组织：先有章法，再谈执行

B.2 讲的是与 AI 相关的政策，包含 AI 方针本身、与其他组织政策的对齐、以及方针的定期评审。对齐这一条值得单说：AI 方针不能孤立存在，它必须和已有的信息安全、质量管理、人力资源政策接得上，否则会出现“AI 方针说数据要最小化，但现有流程要求全量留存”这种互相矛盾的局面。

B.3 讲内部组织，落在 AI 角色与职责、问题上报两条。上报渠道这条在实践中价值极高：它要求组织提供一个让人敢说话的通道，无论是员工发现模型行为异常，还是外部合作方发现数据使用越界，都能有明确的路径反映问题，而不是靠某个人的职业道德。

5.2 资源四件套：数据、工具、算力与人

B.4 是整份附录里最“技术”的一块，它把 AI 系统依赖的资源分成四类，并要求逐一形成文档。

数据资源：来源、采集方式、质量、合法性、留存策略。这一条直接对应很多组织最容易踩的坑——训练数据的来路没人说得清。

工具资源：开发框架、第三方模型、外部服务。这一条要求组织知道自己在依赖什么，以及这些依赖失效时怎么办。

系统与计算资源：运行环境、算力保障、可用性要求。

人力资源：具备相应能力的人员配置和培训。

四类资源都要有文档，这不是形式主义。资源文档的价值在于，当模型行为出现异常时，你能快速定位是数据变了、工具换了，还是人换了。没有这份文档，排查基本靠玄学。

5.3 生命周期与变更：最容易漏掉的那一段

B.5 讲 AI 系统影响评估的流程和文档要求，明确区分了对个人和群体的影响、以及对社会的影响两类评估视角。B.6 进入 AI 系统生命周期，覆盖从设计、开发、验证、部署到退役的全过程。

生命周期这一块，实际执行中最容易断在衔接处。开发阶段做的评估，到了部署阶段往往没有重新跑一遍；部署时的配置，到了运维阶段无人复核；系统退役时，训练数据和日志怎么处理，经常没人负责。

下面这份记录结构是我认为比较实用的最小模板，字段直接对应附录里的要求，可以直接拿去改：

# AI 系统影响评估记录（字段结构示例） system: name: 简历初筛辅助系统 # 系统名称，避免使用内部代号造成追溯困难 version: v1.2 # 版本号必须与部署版本一致，否则记录失效 lifecycle_stage: 部署前评估 # 设计/开发/验证/部署/退役，五个阶段分别留痕 scope: affected_parties: # 受影响方，对应 B.5.4 的评估视角 - 求职者 - 招聘团队 societal_impact: 低 # 对应 B.5.5 的社会影响判断 assessment: identified_impacts: # 识别出的影响，一条一行，不合并 - 特定群体通过率偏差 - 决策依据不可解释 severity: 中 mitigation: # 缓解措施必须落到可验证的动作 - 每季度做一次分组通过率对比 - 保留人工复核环节 residual_risk_accepted_by: 业务负责人 # 剩余风险的接受人，必须具名到岗位 review: next_review_date: 2024-06-30 # 复评日期，对应第 9 章的监视测量要求

这份结构的重点不在字段多少，而在三个约束：版本号必须和实际部署一致，缓解措施必须可验证，剩余风险必须有明确的接受人。缺任何一个，记录都会退化成一份谁也不会再看的文档。

6. 什么时候该用、什么时候别用：一份草案的适用边界

判断要不要认真对待这份文件，看两个维度就够了：你所在的组织是否已经在用 AI 做实质决策，以及外部是否已经开始追问这些决策。

适合优先对照的情形有三类。第一类是 AI 已经进入对人的判断环节，比如筛选、评级、分配资源，这类系统的错误会真实落到具体的人身上，影响评估几乎是必需品。第二类是组织规模到了一定程度，AI 分散在多个部门各自为政，没有统一的责任归属，这时候体系的作用是收敛。第三类是所处行业有较强的外部约束，需要向合作方或监管方证明自己有管理能力。

暂时不必投入太多精力的情形也有两类。一类是 AI 只是内部试验，不对外产生影响，团队规模小到口头沟通就能覆盖全部风险，这时建立完整体系属于过度设计。另一类是组织连基本的数据台账都还没有，先补数据治理的欠账比搭体系框架更实际。

还有一条边界需要说清楚：草案不是法规，它不能替代任何强制性要求，也不能保证合规。它的作用是提供一套组织自己可以检查、外部也可以检查的框架。把体系证书当成免死金牌，是最典型的使用错误。

我自己的教训是：早年在做一个跨部门的数据项目时，风险评估和影响评估被合并成一张表，填得很顺，谁也没觉得有问题。半年后模型在一个小群体上的表现明显偏离，追溯时才发现，当初那张表里根本没有“受影响方”这一栏。从此以后我每次启动涉及人的判断的项目，都会强制走一遍影响评估，哪怕只是填几个字段，也要逼自己把“谁会因为这件事吃亏”写下来。这一条坚持下来，比任何模板都管用。

希望这份梳理能帮到你，把“AI 治理”这个听起来很虚的词，落到一张能填、能查、能复评的表上。

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