简介这份资源是 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参考控制目标与控制措施和附录 BAI 控制的实施指南都明确标注为规范性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 用于对人的筛选、评级优先做影响评估后果直接作用于个人事后弥补成本高多个部门各自引入 AI先统一方针与职责分散状态下风险无人兜底需要向外部证明管理能力按附录 A 搭控制措施控制目标是可被审核的抓手内部试验、无外部影响记录基本事实即可完整体系收益低于执行成本数据台账尚不健全先补数据治理体系建在流沙上没有意义还有一条边界需要说清楚草案不是法规它不能替代任何强制性要求也不能保证合规。它的作用是提供一套组织自己可以检查、外部也可以检查的框架。把体系证书当成免死金牌是最典型的使用错误。我自己的教训是早年在做一个跨部门的数据项目时风险评估和影响评估被合并成一张表填得很顺谁也没觉得有问题。半年后模型在一个小群体上的表现明显偏离追溯时才发现当初那张表里根本没有“受影响方”这一栏。从此以后我每次启动涉及人的判断的项目都会强制走一遍影响评估哪怕只是填几个字段也要逼自己把“谁会因为这件事吃亏”写下来。这一条坚持下来比任何模板都管用。希望这份梳理能帮到你把“AI 治理”这个听起来很虚的词落到一张能填、能查、能复评的表上。本文还有配套的精品资源点击获取