简介ISO/IEC DIS 42001:2022draft是信息技术—人工智能—管理体系方向的国际标准草案英文文本面向 AI 合规、算法治理、信息安全及体系认证相关的从业者、企业管理者和标准研究者。草案围绕人工智能管理系统的组织与职责划分、风险管理、数据质量与安全、访问控制与敏感信息保护、可持续发展及评估认证等要求展开并结合制造、金融、医疗等行业给出落地思路可用于搭建 AI 治理框架、准备体系认证和开展合规自查。资源包内含 1 个 PDF 文件压缩包约 1.98MB为标准草案完整正文含目次、前言、引言与各条款章节便于按条款检索与引用。目前已有 399 人学习下载适合需要对照原文梳理条款要点、编写内部管理文件或研究 AI 管理体系标准的读者。1. 从一张 PDCA 地图开始ISO/IEC 42001 草案管的是什么很多人第一次翻开 ISO/IEC 42001 草案DIS 版会下意识地找算法、找模型评估指标、找数据清洗流程然后翻三页就发现通篇没有一行公式。它本质上是一份人工智能管理体系标准管的是组织怎么把 AI 这件事装进一个可计划、可执行、可检查、可改进的闭环里而不是告诉你模型该怎么训。草案正文十章加两个规范性附录十章严格按 PDCA 铺开第 4 到第 7 章是计划与支撑第 8 章是运行第 9 章是检查第 10 章是改进。适合两类人一是在组织里被推着去搭 AI 治理框架、写体系文件的二是复习备考、需要把条款和证据对上号的。先记住这张地图后面每个模块都是往这四个格子里填东西。2. 条文骨架十章正文的 PDCA 归属与术语底座草案的行文顺序不是随便排的它沿用了管理体系标准惯用的高阶结构所以第一遍读的时候最容易犯的错是把它当成一份「AI 技术规范」逐条抠细节结果读完记不住任何东西。正确的读法是先认骨架哪几章在定义边界哪几章在定规则哪几章在记录执行哪几章在验证效果。骨架认清楚后面附录 A 的控制目标和附录 B 的实施指南才有地方挂。2.1 十章正文怎么归到 PDCA 四个格子把目录摊开看十章的分工其实非常齐整。第 1 到第 3 章是范围、规范性引用和术语定义属于「底座」第 4 章组织环境是「定边界」回答这套体系覆盖谁、覆盖到哪第 5 章领导、第 6 章策划属于 Plan第 7 章支撑、第 8 章运行属于 Do第 9 章绩效评价属于 Check第 10 章改进属于 Act。章号主题PDCA 归属这一章真正要产出的东西4组织环境边界体系范围声明、相关方清单5领导PlanAI 方针、角色与职责矩阵6策划Plan风险评估结果、处置计划、影响评估、AI 目标7支撑Do资源清单、能力记录、沟通计划、成文信息8运行Do运行准则、过程记录、重做的评估9绩效评价Check监视测量数据、内审报告、评审记录10改进Act不符合项与纠正措施这张表的价值在于它决定了你写体系文件时的目录结构。很多人踩坑就踩在这里把第 6 章的策划和第 8 章的运行写成两份互不相干的文档导致风险评估做完了没人用运行记录和当初的处置计划对不上一审核就露馅。2.2 第 3 章术语最该先啃的几组区分术语章在正文里占的页数不多大致落在第 1 页到第 5 页之间但它是整份草案的口径来源。梳理下来会发现真正需要在复习时建立清晰区分的只有三组。第一组是「AI 系统」和「AI 管理体系」。前者是被管理的对象后者是管理它的那套组织结构、职责、流程和资源。草案里几乎每一条要求都能落到这两个词上第 8 章管的是系统的运行第 4 到第 7 章管的是体系本身。搞混了就会出现「我们给模型加了个监控面板所以体系建好了」这种自欺欺人的结论。第二组是「风险」和「影响」。这两个词在草案里是并列的两条线第 6 章里风险评估6.1.2和影响评估6.1.4是两个独立小节第 8 章里又各自重做一次8.2、8.4。风险指向组织目标的不确定性影响指向 AI 系统对个人、群体和社会造成的后果。两者不能互相替代这是后面易错点一章要重点说的。第三组是「成文信息」和「记录」。草案第 7.5 条统一用「成文信息」这个说法但实际使用中有两种形态一种是规定怎么做的文件方针、程序、准则需要评审和批准另一种是做过什么的证据评估结果、审核记录、会议纪要需要防止篡改和丢失。区分的意义在于前者要控制版本后者要控制留存两者的管控动作完全不一样。2.3 第 4 章组织环境范围界定的三个动作第 4 章只有四个小节容易被快速翻过去但它决定了整套体系的地基。4.1 要求理解组织及其环境4.2 要求理解相关方的需求和期望4.3 要求确定 AI 管理体系的范围4.4 要求建立体系本身。落地时这三个动作有先后。先做 4.1 和 4.2把内外部因素和相关方列出来再做 4.3在相关方的基础上划边界最后 4.4 才是把体系搭起来。顺序颠倒的典型症状是范围声明写得很漂亮一问相关方是谁就答不上来审核时被追问两句就撑不住。范围界定这里有个反复出现的难点写大了兜不住写小了没意义。常见的稳妥做法是把范围写成三个维度的交集即「哪些业务线 哪些 AI 系统 哪些生命周期的环节」。比如只覆盖某个业务线里用于辅助决策的那一类系统从数据准备到上线后监控这一段。这样写的好处是后面附录 A 的控制项你能一条条对得上而不是对着一堆控制目标发愁「这个算不算我们范围内」。提示草案明确写了这份文件在正式发布前不能作为国际标准引用正式复习时要留意版本别把草案条款当成最终定稿背。2.4 第 5 章领导方针和职责这两件事第 5 章三小节5.1 领导作用与承诺、5.2 AI 方针、5.3 角色职责权限。5.1 看起来最虚实际审核时最实。它要求的是最高管理者对体系的有效性负责并且把 AI 管理要求融进组织的业务过程里。换句话说如果 AI 治理只是某个技术团队自己在推业务部门完全不知道这一条就不成立。5.2 的 AI 方针是整套体系的「宪法」通常要覆盖几件事组织对 AI 的定位和原则、与业务战略的关系、满足适用要求的承诺、持续改进的承诺、以及一个给目标提供框架的表述。写方针最容易犯的错是写成宣传口号全是「负责任」「可信」这类词没有一条能被验证。可行的检验方式是拿方针去对照第 6 章的 AI 目标如果目标没法从方针里长出来方针就是空的。5.3 的角色职责权限落到实操就是一张表。谁负责风险评估、谁批准处置计划、谁有权叫停一个上线中的系统、谁对外沟通 AI 相关事项这些都要写清楚。血泪经验是这张表如果只写部门不写岗位执行时就会变成「都负责等于都不负责」。3. 双评估与运行控制第 6、8 章的执行链怎么串第 6 章策划和第 8 章运行是整份草案里技术要求最集中的两章也是复习时最容易背串的地方。原因很简单两章的标题高度重复——6.1.2 叫 AI 风险评估8.2 也叫 AI 风险评估6.1.3 叫风险处置8.3 也叫风险处置6.1.4 和 8.4 都是影响评估。如果不理解这个重复背后的设计意图会觉得标准在凑字数理解了就会发现这恰恰是管理体系「策划—运行」循环的体现第 6 章是第一次做第 8 章是在实际运行中按需重做。3.1 风险评估与影响评估两条不能互相替代的线先把两条线的分工摆清楚。维度AI 风险评估6.1.2 / 8.2AI 系统影响评估6.1.4 / 8.4提问方式这件事可能让我们的目标达不成吗这个系统会让人或社会付出什么代价关注对象组织自身的目标、过程、资源个人、群体、社会典型输出风险清单、等级、处置优先级影响识别结果、严重程度、缓解建议谁更关心管理层、业务负责人合规、法务、外部相关方何时做体系策划时、重大变更时系统设计阶段、上线前、运行中定期最容易忽略的是右边这一列。很多人做完了风险评估就以为大功告成影响评估要么跳过要么用风险清单改个标题交差。但在草案的结构里影响评估是独立小节并且在附录 B 里对应 B.5 整组实施指南B.5.2 过程、B.5.3 文档化、B.5.4 对个人和群体的影响、B.5.5 对社会的影响分量一点不比风险评估轻。从 B.5 的结构能反推出一个实用的做法影响评估至少要分两层写。第一层是对个人和群体的影响比如某类用户被系统错误分类、某类人群的申请被系统性压低通过率第二层是对社会的影响比如某个领域的判断标准被自动化后产生的长期效应。第一层容易想到第二层经常被漏掉而恰恰是第二层在评审时最容易被追问。3.2 风险处置与运行控制从计划到准则6.1.3 要求针对识别出的风险制定处置措施8.3 要求在实际运行中执行这些处置。中间需要一个转换动作把处置措施翻译成运行准则。举个结构性的例子。假设风险评估识别出「训练数据来源不合规」这条风险处置措施写的是「建立数据来源审查机制」。这句话放进运行阶段就必须变成可执行的东西谁审、审什么字段、什么情况下拒收、拒收后怎么记录、多久复查一次。没有这个翻译动作处置计划就永远停在纸面上第 8.1 条要求的「运行策划和控制」也就无从谈起。8.1 还有一个容易被低估的要求对预期外的变更进行控制。实际项目里模型换了个版本、数据源扩了一个渠道、部署环境从自建换成托管这些通常被当成常规迭代没人把它当「变更」看待。但草案的逻辑是只要它可能影响 AI 系统的风险或影响就得走一遍评审。这一条在执行时最容易被绕过因为绕过它的成本很低被发现的概率也不高直到出问题才想起来没有后悔药。3.3 目标、变更与生命周期6.2、6.3 和附录 B.66.2 要求设定 AI 目标并规划如何实现。目标要可测量这一点和一般的质量目标没区别难点在于 AI 场景下的「可测量」不好定义。功能层面的准确率好测治理层面的东西不好测。可行的折中是拆成两层一层是过程指标评估覆盖率、处置完成率、评审及时率一层是结果指标重大影响事件数、外部投诉数。过程指标保证体系在转结果指标保证转得有意义。6.3 的「变更策划」只有一小段但它和第 8 章的运行控制是连着的。任何影响体系有效性的变更都要以受控的方式进行。实操中建议直接建一张变更登记表字段包括变更内容、触发原因、受影响的 AI 系统、是否需要重做风险评估、是否需要重做影响评估、批准人。附录 B.6 讲 AI 系统生命周期目录里这一节被截断了但从前后文的位置能看出它承接的是资源和影响评估之后的内容落点是生命周期各阶段的管理要求。复习时不必去背具体阶段名抓住一个判断标准就够了凡是有「输入变化、输出变化、使用场景变化」的节点都应该是生命周期里的受控节点。下面这份 YAML 是一份可直接抄走的评估记录结构把两条评估线的关键字段放在同一个文档里避免各写各的导致对不上# 单次 AI 系统评估记录风险 影响合卷 system_id: sys-001 # 系统唯一标识和资产清单对齐 version: 1.3 # 当前受评版本变更后必须重新记录 stage: pre_release # 生命周期阶段design / pre_release / in_service risk: items: - id: r-01 desc: 训练数据来源缺少授权凭证 level: high # 等级取值需在程序文件里预先定义 treatment: 补齐授权并建立入库审查 residual: medium # 处置后的残余风险必须重新评定 review_date: 2024-05-01 impact: individual: # 对个人与群体的影响对应 B.5.4 - desc: 错误分类导致部分申请被拒 severity: high societal: # 对社会的影响对应 B.5.5 - desc: 长期使用可能固化既有偏差 severity: medium approval: owner: AI 治理负责人 # 写岗位不写人名 date: 2024-05-06这份结构的关键在于三处。stage字段决定了这份记录属于第 6 章的策划阶段还是第 8 章的运行阶段同一系统在不同阶段会有多份记录靠它区分。residual字段强制你回答「处置之后还剩多少风险」这一栏空着基本等于没做处置。impact下面的两层分开列是为了防止只写个人影响、漏掉社会影响。字段名可以改但这三层的结构建议保留。4. 支撑与收口第 7、9、10 章加附录 A/B 的证据链如果说前面几章是在「定规则」那第 7、9、10 章就是在解决「规则怎么被记住、被检查、被修正」。这三章在复习时存在感偏低因为内容看起来都是管理动作不带技术色彩。但真到审核现场被问得最多的恰恰是这三章证据在哪、谁做的、多久做一次、上次发现问题改没改。4.1 第 7 章支撑五个抓手第 7 章五小节7.1 资源、7.2 能力、7.3 意识、7.4 沟通、7.5 成文信息。资源这块草案在附录 B.4 里做了非常细的展开分成 B.4.2 资源文档化、B.4.3 数据资源、B.4.4 工具资源、B.4.5 系统与计算资源、B.4.6 人力资源。这个分法本身就是一份资源清单模板实际建体系时可以直接照抄成五类台账。其中数据资源和工具资源是最容易被忽略的两类大家习惯统计人力和算力却忘了数据来源的合规凭证和第三方工具的使用记录也是资源。能力7.2要求确定岗位所需的能力、确保人员具备、保留证据。落到实操就是岗位能力矩阵加培训记录。这里有个细节能力不等于培训。上过课是培训记录能胜任才是能力证据两者在审核时的分量不同。意识7.3常被写成一纸通知。草案的要求是人员要知道方针、知道自己对体系有效性的贡献、知道偏离要求的后果。第三条最容易被跳过实际做法可以在培训材料里加一节「如果我们不做会怎样」的案例说明比空喊口号有用。沟通7.4要确定沟通什么、何时沟通、跟谁沟通、怎么沟通、谁沟通。AI 相关事项的对外沟通尤其敏感建议单独列一张沟通矩阵把「系统上线」「重大影响事件」「评估结论变化」这三类事项的对外口径提前定好。成文信息7.5分创建更新和控制两块。7.5.2 要求标识、格式、评审、批准7.5.3 要求可用、受保护保密性、完整性。落到实操就是文件命名规则、版本号规则、权限设置、备份策略。这一条最枯燥但也最容易在审核时掉链子。4.2 第 9、10 章监视测量、内审、评审、纠正9.1 要求监视、测量、分析和评价并且要确定监视什么、用什么方法、什么时候做、谁来做、结果怎么分析。这一条和 6.2 的 AI 目标是配对的目标定什么这里就监视什么。9.2 内部审核9.2.1 是总则9.2.2 是审核方案。审核方案要覆盖频次、方法、职责、报告。实操中最常见的做法是一年一轮全覆盖但更现实的是按风险分级高风险系统半年一次低风险的两年覆盖一次。9.3 管理评审9.3.2 列输入9.3.3 列输出。输入通常包括上次评审的措施状态、内外部变化、风险与影响评估的更新、目标达成情况、审核结果、相关方反馈、改进机会。输出要落到资源需求和体系变更的决策上。管理评审如果开成「各部门念 PPT」这一条就废了。10.1 持续改进和 10.2 不符合与纠正措施是 PDCA 的收口。10.2 的关键在于「原因分析」和「有效性验证」两步很多组织只做到「处置」就结束了没有回头确认问题是否真的不再发生。4.3 附录 A 的控制目标与附录 B 的实施指南两个附录都是规范性的normative这一点在复习时要特别注意规范性意味着它们是要求的一部分不是参考读物。附录 A 是参考控制目标与控制A.1 是总则后面按控制域组织。附录 B 是这些控制的实施指南从 B.2 到 B.6 的条目与附录 A 的控制目标基本一一对应。附录 B 小节对应的控制主题复习时的抓手B.2与 AI 相关的方针B.2.2 AI 方针、B.2.3 与其他组织方针的一致性、B.2.4 方针评审方针不能孤立存在要和其他管理制度对齐B.3内部组织B.3.2 AI 角色与职责、B.3.3 关注事项的报告报告渠道比职责表更容易漏B.4AI 系统资源文档化、数据、工具、系统与算力、人力五类资源台账B.5AI 系统影响评估过程、文档化、个人与群体、社会两层影响的写法B.6AI 系统生命周期生命周期受控节点B.3.3「关注事项的报告」值得单独说一句。它对应的是一条内部举报或反馈渠道组织里的人发现 AI 系统有问题能往哪报、报给谁、报了之后怎么处理。这条在草案里只是一小节落地时却经常缺失因为大家默认「有意见找主管」就够了。4.4 从控制项到证据一份可抄的归档结构附录 A 的控制目标最终都要落到证据上。审核的逻辑很简单你说你做了证据在哪。最省事的做法是在建体系之初就把目录结构定下来按条款编号归档。ai-ms-evidence/ ├── 04_context/ # 第 4 章范围声明、相关方分析 ├── 05_leadership/ # 第 5 章AI 方针、职责矩阵、任命文件 ├── 06_planning/ # 第 6 章风险评估、处置计划、影响评估、目标 ├── 07_support/ # 第 7 章资源台账、能力矩阵、培训记录、沟通记录 ├── 08_operation/ # 第 8 章运行准则、重做的评估、变更登记 ├── 09_evaluation/ # 第 9 章监视数据、内审报告、评审纪要 ├── 10_improvement/ # 第 10 章不符合项、纠正措施、验证记录 └── annex_a_controls/ # 附录 A按控制域分文件夹存放实施证据 ├── a_policies/ ├── a_organization/ ├── a_resources/ ├── a_impact/ └── a_lifecycle/这个结构有两处设计意图。一是前七个目录与正文条款号严格对齐找证据时不用记忆按条款号走就行。二是annex_a_controls单独开一棵子树因为附录 A 的控制项往往同时被多个条款引用塞进任何一个正文章节都会造成混乱。目录名用英文是为了跨平台兼容实际使用时换成中文也不影响逻辑。5. 易漏易错点五个最容易翻车的地方5.1 评估链上的三个漏点漏点一把影响评估当成风险评估的一部分。为什么漏两章标题太像6.1.2 和 6.1.4 又挨在一起读快了会以为是一件事的两个步骤。加上多数团队对「风险」这个词更熟悉自然就拿风险评估的模板套过去。怎么补在评估模板里强制分成两个独立段落风险部分回答「影响组织目标的可能性与后果」影响部分回答「对个人、群体、社会造成了什么」。两份结论分开签字谁也别想用一份糊弄过去。漏点二评估只在策划阶段做一次运行阶段不重做。为什么漏第 6 章做完评估文档看起来已经很完整了8.2 和 8.4 的要求藏在第 8 章中间很容易被当成重复条款跳过。加上重做评估需要成本没人主动提。怎么补把「触发重评」的条件写进程序文件至少覆盖三类系统发生重大变更、使用场景或用户群体变化、出现重大影响事件。然后在变更登记表里加一列「是否触发重评」让这个动作有入口。漏点三处置措施写完就完事没有残余风险和有效性验证。为什么漏6.1.3 和 8.3 都只说要处置处置的闭环感很强写完措施就有一种「做完了」的错觉。残余风险这个概念藏在对风险评估结果的再评价里不显眼。怎么补在处置记录里固定两栏——残余风险等级、验证方式与验证日期。残余风险如果还是高等级必须回到处置环节再来一轮不能带着高风险往运行阶段走。5.2 证据与边界上的两个漏点漏点四范围声明写成两种极端。为什么漏一种是把整个组织的所有 AI 相关活动都圈进来显得体系很完整实际根本管不过来另一种是只圈模型开发这一段把数据准备、部署、上线后监控全甩在外面。前者审核时一问细节就崩后者等于给自己开了个后门。怎么补范围按「业务线 系统类型 生命周期环节」三维写。写完之后做一次反向检验拿附录 A 的控制项逐条对照凡是范围内该有却没有的要么补进来要么在范围声明里写明排除理由。排除理由这一栏很多人不写恰恰是审核最爱问的。漏点五成文信息只建不控。为什么漏7.5.2 的创建更新做起来有成就感写文件、定格式、走审批一套下来很充实。7.5.3 的控制是维护性工作版本、权限、备份、留存期限枯燥且不出活自然被推后。怎么补把文件管控做成一次性的规则而不是每次手工维护。命名规则里带版本号和日期权限按角色分三档可读、可编辑、可批准留存期限写进程序文件。规则定完剩下的交给目录结构和权限设置比事后补救省力得多。6. 复习清单把 42001 草案过成一张可自测的检查表到了收尾这一步不建议再从头翻一遍条文。更有效的方式是拿一张清单自测答不上来的地方再回去定位条款。下面这张表按章节组织每一行都是一个可以自问自答的问题答得出来说明这一块过关答不出来说明只是看过、没进脑子。复习单元自测问题对应条款骨架十章分别落在 PDCA 哪个格子里4—10术语风险与影响的区别能否各举一例3边界范围声明覆盖哪三个维度排除项写了理由吗4.3领导方针能否推导出至少三条 AI 目标5.2、6.2评估风险评估和影响评估各自的输出物是什么6.1.2、6.1.4重评什么情况下必须重做评估8.2、8.4资源五类资源台账是否齐全7.1、B.4运行处置措施有没有翻译成运行准则8.1、8.3变更变更登记表有没有「是否触发重评」这一列6.3、8.1检查内审频次是按风险分级还是平均用力9.2收口纠正措施有没有做有效性验证10.2附录附录 A 的控制项能找到对应证据吗A、B自测的时候有个技巧不要只看能不能背出条款号要看能不能说出「这一条在我们这种场景下具体长什么样」。比如问「8.3 要做什么」答「执行风险处置计划」只算及格答「把处置计划里的每条措施对应到一个运行准则准则里写清谁执行、什么频率、异常怎么升级」才算过关。再给一组高频混淆点的速查对照考前扫一眼比翻书快容易混的两项一句话区分6.1.2 与 8.2同一个动作前者在策划期做后者在运行期重做6.1.3 与 8.3前者写计划后者执行计划6.1.4 与 8.4影响评估的策划与运行两阶段7.5.2 与 7.5.3前者管怎么创建和更新后者管怎么保护和留存9.2 与 9.3前者是内部审核后者是管理层评审10.1 与 10.2前者是主动提升后者是被动纠错最后说个自己的教训。最早接触这套条款时我习惯按章节顺序线性复习从第 4 章一路读到第 10 章读完感觉很顺一合上书就串不起来。后来改成按「一条业务线走一遍」的方式假装自己要从零上线一个 AI 系统从定范围开始一路问到上线后怎么监控每走到一个环节就回去翻对应条款。这样走两遍条款之间的连接关系就出来了比线性读五遍都管用。从那以后我每次复习管理体系类标准都强制走一遍「虚拟项目全流程」不按页码按场景。希望帮到你。这份草案的正文十章和两个规范性附录我都整理进了资料里需要对着原文逐条抠的时候可以直接翻配合上面的清单用效率会高不少。本文还有配套的精品资源点击获取