简介：ISO/IEC DIS 42001:2022 是国际标准化组织与国际电工委员会联合发布的草案版国际标准，围绕信息技术—人工智能—管理体系展开，面向从事 AI 产品研发、算法治理、合规审查与信息安全管理的技术人员与企业管理者，适合需要建立 AI 治理框架、开展合规自查或筹备第三方认证审核的团队。文件为投票征询阶段的 DIS 草案，正文按国际标准体例排版，涵盖术语与定义、组织环境与领导职责、风险评估与处置、数据与信息安全管理、运行控制、绩效评价与持续改进等条款框架，并附有前言、引言与目次结构，便于按条款逐项对照搭建管理体系文件。压缩包内为 1 个 PDF，体积约 1.98MB，轻巧便携，适合离线阅读、检索与打印批注。目前已有 399 人学习，可作为企业导入 AI 管理体系、准备内审与认证、撰写治理制度时的条款级参考底稿，也便于对照了解 ISO/IEC 42001 正式版前后的条款演进。

1. 一句话说清：ISO/IEC 42001 到底是一份什么文件

做过 AI 项目的人多半遇到过这种场面：模型指标挺好看，上线也跑通了，可一旦有人追问“这套系统的风险谁评估过、训练数据从哪来、出了问题怎么追溯、谁来签字负责”，会议室立刻安静。ISO/IEC 42001 就是来消除这份安静的。用一句话说：它是一份关于人工智能管理体系（AIMS）的标准，不教你怎么把模型训得更准，而是规定一个组织该怎样建立、运行、检查和改进一套“管住 AI”的机制，并且让这套机制经得起外部逐条对照。你手里这份是 2022 年对外征求意见的国际标准草案，编号里的 DIS 就是 Draft International Standard，意思很直白：草稿，可以被质疑，还不能被称作正式国际标准。它的分量恰好在这里——第一次把“AI 该被怎么管”写成了一份可以打勾、可以挑错、可以拿去开会吵架的清单。

2. 为什么 AI 需要一份管理体系标准：从“技术能跑”到“组织能管”

2.1 传统软件的质量手册，为什么套不住 AI

传统软件工程的假设很朴素：需求定下来，设计画出来，代码写出来，测试跑过去，交付。行为主要由代码决定，同样的输入给同样的输出，验收标准是“符合规格”。质量手册管的正是这条流水线上每一道工序有没有按规矩走，规矩清楚，结果就可预期。

AI 系统把这条链子打断了。代码往往只是一个容器，真正决定行为的是喂进去的数据和训练过程。同一份代码，换一批标注数据、换一个采样策略，出来的系统脾气完全不同。输出还是概率性的，没有唯一的正确答案，只有“在什么分布下、错误率多少、错了代价多大”。打个比方，传统软件更像盖楼，图纸定了、验收标准也定了；AI 更像养一株会自己长的植物，你得隔一阵子去看它有没有长歪，而不是竣工那天拍张照就完事。质量手册那套“按图施工”的思路，遇到一个会随环境变化的对象，天然就打滑。

2.2 三个躲不开的麻烦：进料口、概率性、外部性

第一是进料口。数据从哪来、有没有授权、标注质量如何、样本里有没有系统性偏差，这些在传统软件里属于边缘问题，在 AI 里直接决定系统性格。一个招聘筛选模型如果训练样本里某类人群本来就少，它的判断会安静地偏，而且不会报错。

第二是概率性。传统系统出错通常有明确报错，AI 系统出错是“大部分时候对”。它不会在出错的那一刻通知你，只会在统计上慢慢显现。这就逼着管理动作从“验收一次”变成“长期监测”。

第三是外部性，也是最容易被忽略的一条。传统软件的质量问题一般止于使用者，AI 的影响却常常落到没同意、也不知道自己被处理的人身上——被简历筛选刷掉的应聘者、被图像识别误判的路人、被评分模型打了低分的申请人。这些人不在你的用户名单里，却是实打实的受影响方。

管理层关心的东西跟工程师不一样：这事谁签字、出了事找谁、花了多少资源、下次怎么不再犯。这些问题技术答不了，只能由一套组织机制来答。管理体系标准存在的理由，就是把这几个问题变成有固定答案的流程。

2.3 管理体系的本质：把“某个人心里有数”变成“组织里有账”

管理体系标准这一类文件的思路很统一：不规定你用什么技术、什么架构、什么模型，只规定你必须有哪些角色、哪些流程、哪些记录、多久复核一次。核心循环就是常说的 PDCA——策划、执行、检查、改进。它像一个组织的操作系统，具体跑什么应用不管，但进程怎么调度、日志怎么留、出问题怎么回滚，得说清楚。

这套思路对 AI 特别合适，因为 AI 的风险不是一次性消灭的，是持续判断的。今天模型表现正常，不代表三个月后数据分布变了它还正常。管理体系给的正是那个“定期回头看”的机制：谁定期看、看什么指标、看到异常走哪条路。

这里有个容易被误读的概念，叫“成文信息”（documented information）。很多人一听就以为要写一屋子文档。它真正要求的是让关键判断留下痕迹——为什么选这个数据源、为什么接受这个残余风险、谁批准的。打个通俗的比方，它不是让你写日记，而是让你在动手术前签知情同意书。平时嫌麻烦，真出事那天，这张纸就是唯一的后悔药。

3. 这份草案的骨架：十章主线与三个 AI 专属动作

3.1 第 4 到第 10 章：一条谁都能看懂的 PDCA 主线

翻开草案目录，第 4 章到第 10 章的顺序几乎是教科书式的管理循环，没有任何花哨：

这个骨架不是 42001 独创的。它是管理体系标准通用的“协调结构”，所以你会发现它跟质量管理的 9001、信息安全的 27001 章节顺序几乎一模一样。这不是偷懒，是刻意设计：一个组织如果已经跑过别的体系，审计员、文件编号、评审会议都能直接复用，不用从零再搭一套。对读者来说这也是个好消息——你以前被质量管理体系折磨过的那些经验，在这里大部分能直接搬过来。

真正属于 AI 的部分，是从这个骨架上长出来的枝节。

3.2 三个 AI 专属动作，为什么在策划和运行里各出现一次

仔细看目录会发现一个有意思的细节：第 6 章策划里有 6.1.2 AI 风险评估、6.1.3 AI 风险处置、6.1.4 AI 系统影响评估；到了第 8 章运行，又出现了 8.2 AI 风险评估、8.3 AI 风险处置、8.4 AI 系统影响评估。同样三件事，写了两遍。

这不是排版重复，而是一种态度声明：这三件事不是上线前盖个章就完事的一次性审批，而是周期性重复的动作。策划阶段做的那一遍，是系统还在图纸上的时候，凭设想判断它会带来什么；运行阶段做的那一遍，是系统已经在真实环境里跑起来之后，拿实际数据重新判断一遍。两次的判断结果很可能不一样，而标准要求你把两次都留下。

拿一个内容推荐系统举例。策划阶段你判断的主要风险是“推荐不准，用户流失”。等它真跑起来，运行阶段才可能发现另一层：某个创作者群体的曝光被系统性压低。这种问题在图纸上根本看不见，只能靠运行阶段的复查捞出来。

3.3 附录 A 与附录 B：一份是清单，一份是说明书

草案正文后面挂着两个规范性附录，分工很清楚。

附录 A（Reference control objectives and controls）是控制目标和控制的参考清单。你可以把它理解成体检表：一行一条，左边写“要防什么”，右边写“用什么手段防”。它给的是条目，不给解释。

附录 B（Implementation guidance for AI controls）则是那份说明书的角色，逐条告诉你附录 A 里每一条到底怎么落地。草案里能看到它的展开顺序：B.2 讲 AI 相关政策以及政策与其他组织政策的对齐和复审；B.3 讲内部组织，包括 AI 角色职责、疑虑上报渠道；B.4 讲 AI 系统需要的资源，往下细分成数据资源、工具资源、系统与计算资源、人力资源四类；B.5 讲 AI 系统影响评估的流程、记录方式，以及对个人、群体和社会影响的分别评估；B.6 进入 AI 系统生命周期。

这两份附录的关系，很像建筑规范里的“强制性条文”和“条文说明”。前者告诉你必须做到什么，后者告诉你别人通常是怎么做到的。审图的人只看前者，干活的人离不开后者。

把第 4 到第 7 章的要求抽象成文档结构，大概是这个样子：

# 按标准章节顺序抽象的 AIMS 文档骨架示意，非标准原文 aims: context: # 对应第 4 章 scope: "本体系覆盖的 AI 系统清单与边界" interested_parties: ["客户", "受影响个人与群体", "监管方", "内部团队"] leadership: # 对应第 5 章 ai_policy: "一页纸，说明组织对 AI 的态度与红线" roles: ["AI 负责人", "数据负责人", "影响评估责任人"] planning: # 对应第 6 章 risk_assessment: "风险清单 + 等级 + 触发条件" risk_treatment: "处置措施 + 残余风险 + 批准人" impact_assessment: "受影响方 + 影响类型 + 缓解方案" support: # 对应第 7 章 documented_information: "谁在什么时候因为什么留下了这条记录" operation: # 对应第 8 章 recheck_cycle: "季度 / 触发式，任选但要写死" evaluation: # 对应第 9 章 metrics: ["准确率漂移", "申诉量", "误判率分层统计"] improvement: # 对应第 10 章 nonconformity_log: "不符合项 → 原因 → 纠正 → 验证"

这段结构只是把章节顺序翻译成可填写的槽位，不代表标准原文措辞。它的用处是让你一眼看出：哪些槽位你现在是空的。空的那个，就是下次内审会被问住的地方。参数上唯一需要留意的是recheck_cycle——标准不会替你定周期，它只要求你定下来并写明触发条件，比如“指标漂移超过阈值即触发”，写死了才算数。

4. 三个 AI 专属动作：风险评估、风险处置、影响评估到底差在哪

4.1 AI 风险评估：先看“可能出什么事”

风险评估回答的是一个很朴素的问题：这套系统可能出什么事，多大概率，多严重。它的视角站在组织自己这边——哪些目标会被拖累，哪些资源会白花，哪些承诺会兑现不了。

做这件事的难点不在方法，在“敢不敢往下想”。多数团队的第一版风险清单都写得太客气，全是“模型精度不足”“数据质量不佳”这类技术话。真正该写进去的是“如果这个模型对某类用户系统性偏低，我们有没有能力发现”“如果上游数据源改了授权条款，我们多久会知道”。这些不是技术指标，是组织能力的缺口。

草案把这个动作放在 6.1.2，意味着它属于策划阶段的一部分，输出应该是可以拿去过会的材料：风险条目、等级、责任人、复审时间。写成一段散文没人认，写成表格才有人认。

4.2 AI 风险处置：决定“拿什么换”

评估完了必然面对一个现实：风险不可能清零。处置这一步做的不是消灭，是交换——用多少成本，换掉多少风险，剩下的那部分谁签字认了。

常见处置路径无非几类：规避（不做这个功能）、降低（加人工复核、加阈值、缩小适用范围）、转移（合同条款、保险）、接受（明确记录并批准）。标准不会替你选，但它会盯着你有没有把“接受”的那部分写清楚。这里的血泪经验是：绝大多数翻车不是因为没做处置，而是因为“接受”这一步没人签字，出了事所有人都在说“我以为”。

残余风险这个概念值得单独说一句。它指的是处置措施上完之后还剩下的那部分风险。很多团队的评估表里只有“处置前”和“处置后”两栏，看起来风险从高降到低，很漂亮，但没人写“剩下的这部分如果发生，我们认不认”。少了这一句，整张表就是装饰。

4.3 AI 系统影响评估：把镜头从组织转向人

这是 42001 里最不像传统 IT 标准的一个动作，也是最能体现 AI 治理特点的一个。风险评估问的是“这事对我们有什么损失”，影响评估问的是“这事对别人有什么后果”。

视角一换，结论常常完全不同。一个信贷评分模型，对放贷机构来说风险是“坏账率上升”，处置方式是调阈值；对被评分的申请人来说，影响是“某个群体整体被拒”，处置方式可能是人工复核通道、申诉机制、特征禁用。同一套系统，两张不同的表，谁也不能替代谁。

草案在 B.5 里把这个动作拆得比较细：要评估对个人的影响，也要评估对群体和社会的影响。对个人的影响好理解，无非是机会、隐私、尊严；对群体的影响更难，因为它往往是统计性的——不是某一个人被误判，而是某一类人的通过率系统性低几个百分点。这种偏差单看个体案例看不出来，必须分层统计才看得见。

4.4 三者的顺序与关系

用一段示意代码把三者的先后和依赖关系摆出来：

# 仅用于说明三个动作的先后与依赖，不是标准原文的算法 def aim_review(system, context): risk = assess_risk(system, context) # 6.1.2 站在组织视角 plan = treat_risk(risk) if risk.level > context.tolerance else None # 6.1.3 impact = assess_impact(system) # 6.1.4 站在受影响方视角 if impact.severe and plan is None: # 影响严重但风险可接受 plan = treat_risk(risk, force=True) # 必须补处置，不能只看组织损失 return {"risk": risk, "plan": plan, "impact": impact}

这段伪代码里，context.tolerance是组织自己定的风险容忍度，属于必须写进文件的参数，不是拍脑袋的常数；force=True那行表达的是关键逻辑：风险评估的结论是“我们能接受”，但影响评估的结论是“受影响方承受不起”，这时不能因为组织这边不疼就不动。两条线是并联的否决权，不是串联的优先级。

参数说明就一句：tolerance由组织在第 6 章策划阶段确定并记录，改它要走变更流程，不能每次评估前临时调松。

三者的差别可以压成一张表：

5. 常见误区与易混概念：五个最容易搞混的地方

5.1 误区一：把它当成技术标准

易混点：看到“人工智能”四个字，就以为里面写了模型该怎么设计、数据该怎么清洗。

为什么混：市面上叫“AI 标准”的文件确实有技术类的，术语、测试方法、性能指标都各有各的文档。名字挨得近，很容易一锅端。

怎么区分：看它要求你交付什么。技术标准要的是“系统达到某个指标”，管理体系标准要的是“组织留下某类记录”。42001 通篇不会告诉你用什么算法，只会问你有没有角色、有没有流程、有没有复核。它管的是“谁来管、怎么证明管过”，不是“怎么算”。

5.2 误区二：跟信息安全管理体系是一回事

易混点：两个都是管理体系标准，章节结构几乎重合，都讲风险、都讲控制措施，看起来像同一个东西换了个封面。

为什么混：因为它们共用同一套协调结构。第 4 到第 10 章的顺序、术语习惯、审核逻辑高度相似，粗看目录会以为拿错了文件。

怎么区分：抓两个差异点。第一是风险对象，信息安全管理体系护的是信息的机密性、完整性和可用性，AI 管理体系护的范围更宽，包括模型行为偏差、决策对个体的影响、对社会层面的外溢。第二是那个专属动作，信息安全管理体系里没有“系统影响评估”这一项，而这恰恰是 AI 管理体系最有辨识度的部分。实践上两者常常并行跑，很多组织会把 AI 体系挂靠在已有的信息安全体系下面复用文件框架，但影响评估那一块必须单独补，补不上就等于没做。

5.3 误区三：风险降到“低”就算完事

易混点：评估表上处置后风险等级变成绿色，大家松一口气，事情翻篇。

为什么混：表格的视觉暗示太强，颜色一变绿就像任务完成。但风险从来不会消失，只会转移或残留。

怎么区分：看有没有“残余风险接受”这一栏，以及那一栏后面有没有名字。没有签字的接受不叫接受，叫没人管。另外一个自查办法：问一句“如果这条残余风险真发生了，我们第一反应是找谁”，答不上来就说明这一步是空的。

5.4 误区四：文档写得越多，体系就越扎实

易混点：一听说要留成文信息，立刻开始写手册、写规程、写记录模板，最后攒出一座文档山，没人看，也没人维护。

为什么混：审核现场确实会翻文件，文件多的团队看起来更“认真”。这是一种表演性合规的惯性。

怎么区分：看成文信息的判据是“这条记录将来会被谁在什么场合用到”。内审要用、管理评审要用、出问题追责要用，那它值得写。写了三年没人翻开过一次的，纯属负担。衡量标准不是厚度，是能不能在十分钟内回答“上季度那次风险复审的结论是什么”。

5.5 误区五：草案就是标准，可以照着做认证

易混点：手里拿着 DIS 版本，就以为可以按它去申请认证、对外宣称合规。

为什么混：文件本身很像正式标准，有编号、有目录、有规范性附录，格式上一应俱全。

怎么区分：草案首页那段大写声明说得很清楚——在正式发布之前，它不能被称作国际标准。DIS 之后通常还有一轮最终草案投票，再之后才正式发布。草案的价值在于提前看懂方向、提前搭框架、提前发现自己的缺口，不在于拿去当合规依据。真要对外声称，得等正式版本，并且以正式版本的条款为准。这个区别在商务场合尤其重要，一份草案撑不起合同里的“符合国际标准”这句话。

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

说了这么多，落到实际选择上，判断标准其实不复杂。

该用的场景，我总结成三类。第一类是已经有 AI 系统在真实环境里跑，并且开始被外部追问——客户尽调问卷里出现 AI 相关条目、合作方要求说明数据来源、招投标文件里提到治理能力。这时候你需要一套能被逐条对照的框架，草案的目录正好可以当自查表用，哪一章空着一目了然。第二类是组织里 AI 做法散落在各个团队，各写各的评估、各留各的记录，急需收拢成一套统一语言。第三类是准备做体系认证，想提前两三年搭框架、跑几个循环、攒点记录，等正式版本落地时不至于从零开始。

不该用的场景同样清楚。还在做算法选型、调参、验证可行性，整个团队就一两个人一个脚本，这时候谈管理体系纯属给自行车装航空管制系统。想靠它解决模型准确率问题的，也会失望——它一个字都不会提怎么调超参。还有一种情况最该警惕：把它当成一张“合规即可”的清单，逐条打勾，勾完就锁进抽屉。管理体系的全部价值在循环，勾一次就停，等于买了个跑步机当衣架。

有一件事我踩过坑，值得单独拎出来说。早些年我第一次接触这类管理体系文件，第一反应是把它当成一份“要填的表”，于是拉着团队花两周把所有章节对应的文档都补齐了，厚厚的几摞，看起来特别完整。三个月后内审，被问的第一个问题是“上次风险评估的结论，跟这次有什么变化，为什么变”。全场沉默——因为我们只做了“第一次”，从来没做“第二次”。那些文档不是体系，是一次性的作业。从那以后我每次碰这类框架，都先不看它要什么文档，先看它要求哪些动作是循环的、周期多长、触发条件是什么，把循环跑通一轮，再补文档。顺序反了，做的全是无用功。

所以对你手里这份草案，我建议的读法不是从头到尾通读，而是先翻到第 6 章和第 8 章，把那三组同名条款对着看一遍，理解“同一件事为什么要做两遍”，然后再回头补第 4、5、7 章的组织与资源部分。这个顺序读完，你对整套逻辑的印象会比顺序通读深得多。草案全文连同附录 A 的控制清单、附录 B 的逐条实施指南都在资料里，对照目录翻一遍，比看十篇二手解读都来得直接。希望帮到你。

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