一句话导读
ISO/IEC 42001 是全球第一部「人工智能管理体系（AIMS）」的可认证国际标准。它把 ISO 9001（质量）、ISO 27001（信息安全）那套 PDCA 管理体系骨架，套到一个新对象上：AI 系统的全生命周期治理。
它管的核心问题是 —— 「你们把 AI 管住了吗？能不能拿出证据？」，而不是「你的模型准不准」。中国已等同采用为国家标准
ISO/IEC 42001 是全球第一部「人工智能管理体系（AIMS）」的可认证国际标准。它把 ISO 9001（质量）、ISO 27001（信息安全）那套 PDCA 管理体系骨架，套到一个新对象上：AI 系统的全生命周期治理。
它管的核心问题是 —— 「你们把 AI 管住了吗？能不能拿出证据？」，而不是「你的模型准不准」。中国已等同采用为国家标准
GB/T 45081-2024（2024-11-28 实施）。
一、标准画像
| 项 | 内容 |
|---|---|
| 全称 | ISO/IEC 42001:2023《信息技术 — 人工智能 — 管理体系》 |
| 制定机构 | ISO/IEC JTC 1 / SC 42（人工智能分技术委员会） |
| 发布时间 | 2023-12-18（Edition 1，现行有效；2020-08 立项） |
| 性质 | 可认证的规范型标准 —— 正文用「shall（应）」写，非指南 |
| 适用对象 | 任何开发 / 提供 / 使用 AI 系统产品与服务的组织；不限规模、类型、行业 |
| 认证对象 | 管理体系（不是某个模型/产品） |
| 中国对标 | GB/T 45081-2024《人工智能 管理体系》（IDT 等同采用 · 2024-11-28 发布即实施） |
关键定位：它不是技术标准，是管理标准。它不评价模型性能，而是要求组织建立一套可审计的 AI 治理制度 —— 政策、角色、风险、影响、数据、生命周期、供应商、持续改进。
二、在标准家族中的位置
2.1 在 ISO 管理体系族里（横向 · 同骨架可整合）
| 标准 | 管什么 | 与本标准关系 |
|---|---|---|
| ISO 9001 | 质量 | 同骨架，多处流程可复用 |
| ISO/IEC 27001 | 信息安全（ISMS） | 最可类比 —— 已有 27001 者，领导力/能力/内审/管理评审四大流程可直接套用 |
| ISO/IEC 27701 | 隐私（PIMS） | 27001 的隐私扩展 |
| ISO 14001 / 45001 | 环境 / 职业健康 | 同骨架 |
一句话：懂 27001 的人，学 42001 最快 —— 差别只在「治理对象换成了 AI」＋两个 AI 专属要求（见第五章）。
2.2 在 AI 标准族里（纵向 · 配套标准）
| 标准 | 管什么 | 对谁有用 |
|---|---|---|
| ISO/IEC 42001:2023 | AI 管理体系（核心） | 全部 |
| ISO/IEC 42005:2025 | AI 系统影响评估（怎么做） | 要做影响评估者 |
| ISO/IEC 42006:2025 | 认证机构要求（谁能审你） | 选认证机构时看其是否获认可 |
| ISO/IEC 23894:2023 | AI 风险管理（把 ISO 31000 落到 AI） | 要做风险评估者 |
| ISO/IEC 22989:2022 | AI 概念与术语（规范性引用） | 统一语言 |
| ISO/IEC 23053:2022 | 机器学习框架 | 自训模型者 |
| ISO/IEC 5259 系列 | 数据分析与 ML 的数据质量（五部分） | 数据治理者 |
| ISO/IEC 38507:2022 | AI 与 IT 治理（给管理层/董事会） | 治理层 |
实务口诀：用 23894 跑风险评估；用 42005 跑影响评估；选认证机构看它是否按 42006 获认可。
三、标准结构总览
ISO/IEC 42001:2023
│
├─ 第 1–3 章 引言（范围 / 规范性引用 / 术语）—— 非要求
│
├─ 第 4–10 章 ★ 强制性要求（用 shall，"应"）—— 认证考试的正面
│ ├─ 4 组织环境 Context of the organization
│ ├─ 5 领导作用 Leadership
│ ├─ 6 策划 Planning
│ ├─ 7 支持 Support
│ ├─ 8 运行 Operation
│ ├─ 9 绩效评价 Performance evaluation
│ └─ 10 改进 Improvement
│
└─ 附录
├─ 附录 A（规范性）38 项参考控制项 · 9 大控制域 ★ 认证的另一面
├─ 附录 B（规范性）各控制项的实施指南
├─ 附录 C（资料性）可能的 AI 相关目标与风险源
└─ 附录 D（资料性）AIMS 跨领域/跨行业的使用
要点：条款 4–10 是「必答题」，附录 A 是「选答题」 —— 38 项控制依风险评估选用，并写进 SoA（适用性声明）；凡写进 SoA 的即成为你的义务。
常见误解：团队常盯着附录 A「AI 控制」，忽视条款 4–10 —— 而多数认证不符合项恰恰出在强制条款。
常见误解：团队常盯着附录 A「AI 控制」，忽视条款 4–10 —— 而多数认证不符合项恰恰出在强制条款。
四、强制性条款逐条（4–10）
| 条款 | 要什么 | 关键点 / 要产出 |
|---|---|---|
| 4 组织环境 | 理解内外部环境 → 识别相关方 → 确定 AIMS 范围 → 建立并运行 | ★ 4.1 确定 AI 角色（AI 提供方 / 生产方 / 使用方，依 ISO/IEC 22989）—— AI 专属要求；范围界定最易失分（嵌入式 AI、影子 AI 都可能在范围内）。产出：范围声明 · 相关方清单 · 环境分析 |
| 5 领导作用 | 最高管理层亲自展现承诺 → 制定 AI 方针 → 分派角色/职责/权限并传达 | 方针须文件化、可获取、传达；角色权限须明文指派；领导力不能代签。产出：批准的 AI 方针 · 已传达的职责权限 · 管理层实质参与证据 |
| 6 策划 （实质核心） |
建立 AI 风险评估（6.1.2）、风险处置 + SoA（6.1.3）、AI 系统影响评估（6.1.4）三类过程；设 AI 目标；受控策划变更 | ★ 6.1.4 影响评估 = AI 专属要求（评估对个人/群体/社会的影响）；风险准则须事先设定。产出：风险方法学 · 风险登记册 · SoA · 影响评估程序与记录 |
| 7 支持 | 资源 → 能力 → 意识 → 沟通 → 文件化信息 | 7.2 能力记录（岗位 AI 能力须具备并留证）；7.3 意识（AI 风险 / 伦理 / 隐私 / 偏见 / 人类监督）；7.5 文件控制程序 |
| 8 运行 （落地核心） |
把第六章的评估与处置真做出来：8.2 风险评估 · 8.3 风险处置 · 8.4 影响评估 | 覆盖 AI 系统生命周期（设计→开发→测试→验证→部署→监控→退役）· 数据治理 · 第三方管理 · 事件响应 |
| 9 绩效评价 | 监测/测量/分析/评价 → 内部审核 → 管理评审 | 认证前至少完成一次内审 + 一次管理评审。产出：监测计划 · 内审方案与报告 · 管理评审纪要 |
| 10 改进 | 持续改进 → 不符合与纠正措施 | 10.2 对 AIMS 不符合（AI 事件 / 偏见发现 / 数据治理失败…）作根因分析 + 纠正措施。产出：CAPA 程序 · 不符合登记册 |
五、★ 与 ISO 27001 的分水岭：双评估模型
这是 42001 最本质、也最值得借鉴之处 —— 它比 27001 多了一只「对外」的眼。
| 维度 | AI 风险评估（6.1.2 / 8.2） | ★ AI 系统影响评估（6.1.4 / 8.4） |
|---|---|---|
| 看谁 | 对内 —— 风险指向组织自身 | 对外 —— 影响指向个人 / 群体 / 社会 |
| 问什么 | 用 AI 会给我们带来什么风险（安全、性能、财务、声誉） | AI 系统对受影响的人/群体/社会造成什么影响（公平、自主、福祉、人权、环境） |
| 对应附录 | 除 A.5 外的风险项 | A.5.4（对个人影响）/ A.5.5（社会影响） |
| 27001 有无 | 有（信息安全风险） | 无 —— 27001 只有对内风险这一只眼 |
一句话：27001 只有「一只眼」（对内风险）；42001 有「两只眼」（对内风险 + 对外影响）。 这就是为什么 42001 不能被当成「换了 AI 词的 27001」。两项评估共同喂给控制项选择与 SoA。
六、★ 附录 A：38 项参考控制 · 9 大控制域
编号规则：每个域从
.2 起编 —— .1 位置是「控制目标」（不是控制项本身，无需实施）。A.6 额外拆为 A.6.1 / A.6.2，故其编号是四级。
6.1 九域总览
| 域 | 名称 | 项数 | 管什么 |
|---|---|---|---|
| A.2 | Policies related to AI · AI 相关方针 | 3 | AI 方针的批准、传达、评审、与其他方针协调 |
| A.3 | Internal organisation · 内部组织 | 2 | AI 角色与职责、关切上报（举报） |
| A.4 | Resources for AI systems · AI 系统资源 | 5 | 数据、工具、系统/算力、人力资源的文档化 |
| A.5 | Assessing impacts · 影响评估 | 4 | 影响评估过程、文档化、对个人影响、社会影响 |
| A.6 | AI system life cycle · 生命周期 | 9 | 目标→设计→需求→验证→部署→运行监控→技术文档→事件日志（最大域） |
| A.7 | Data for AI systems · 数据 | 5 | 数据管理、获取、质量、来源/血统、准备 |
| A.8 | Information for interested parties · 面向相关方信息 | 4 | 用户文档、对外报告、事件通报、相关方信息 |
| A.9 | Use of AI systems · 使用 | 3 | 负责使用过程、目标、预期用途 |
| A.10 | Third-party & customer relationships · 第三方与客户 | 3 | 责任分配、供应商、客户 |
| 合计 | 38 | ||
6.2 全 38 项控制清单（含「落在哪一层」）
| 编号 | 名称 | 落地层 |
|---|---|---|
| A.2.2 | AI policy（AI 方针） | Policy |
| A.2.3 | Alignment with other organizational policies（与其他方针协调） | Policy |
| A.2.4 | Review of the AI policy（方针评审） | Policy |
| A.3.2 | ★ AI roles and responsibilities（AI 角色与职责） | Organization |
| A.3.3 | Reporting of concerns（关切上报） | Organization |
| A.4.2 | Resource documentation（资源文档化） | Organization |
| A.4.3 | Data resources（数据资源） | Data |
| A.4.4 | Tooling resources（工具资源） | Application |
| A.4.5 | System and computing resources（系统与算力资源） | Infrastructure |
| A.4.6 | Human resources（人力资源） | Organization |
| A.5.2 | AI system impact assessment process（影响评估过程） | Policy |
| A.5.3 | Documentation of impact assessments（影响评估文档） | Policy |
| A.5.4 | ★ Assessing impact on individuals/groups（对个人影响） | Policy |
| A.5.5 | ★ Assessing societal impacts（社会影响） | Policy |
| A.6.1.2 | Objectives for responsible development（负责开发目标） | Policy |
| A.6.1.3 | Processes for responsible design & development（负责设计开发过程） | Application |
| A.6.2.2 | AI system requirements and specification（需求与规格） | Application |
| A.6.2.3 | Documentation of design and development（设计开发文档） | Application |
| A.6.2.4 | Verification and validation（验证与确认） | Application |
| A.6.2.5 | Deployment（部署） | Application |
| A.6.2.6 | ★ Operation and monitoring（运行与监控） | Gateway |
| A.6.2.7 | Technical documentation（技术文档） | Application |
| A.6.2.8 | ★ Recording of event logs（事件日志记录） | Gateway |
| A.7.2 | Data for development and enhancement（开发与改进用数据） | Data |
| A.7.3 | Acquisition of data（数据获取） | Data |
| A.7.4 | Quality of data（数据质量） | Data |
| A.7.5 | Data provenance（数据来源/血统） | Data |
| A.7.6 | Data preparation（数据准备） | Data |
| A.8.2 | System documentation and info for users（用户文档） | Application |
| A.8.3 | External reporting（对外报告） | Organization |
| A.8.4 | Communication of incidents（事件通报） | Organization |
| A.8.5 | Information for interested parties（相关方信息） | Organization |
| A.9.2 | Processes for responsible use（负责使用过程） | Gateway |
| A.9.3 | Objectives for responsible use（负责使用目标） | Policy |
| A.9.4 | ★ Intended use（预期用途） | Gateway |
| A.10.2 | Allocating responsibilities（责任分配） | Organization |
| A.10.3 | Suppliers（供应商） | Model provider |
| A.10.4 | Customers（客户） | Organization |
最难的 3 项（对外部模型使用者而言，因需运行期记录而非文档）：A.6.2.6（运行监控）· A.6.2.8（事件日志）· A.9.4（预期用途） —— 要的是「运行期证据」（如网关日志须显示"本次决策当时生效的方针 + 调用者身份"，而不只是"用户提交了一个提示词"）。
6.3 SoA（适用性声明）—— 最被审核盯住的文件
SoA 正式记录：① 哪些控制项适用；② 每条判定的理由；③ 适用者如何实施；还可记部分实施及目标完成日期。
允许排除控制项，但每条排除都必须对着风险评估讲得通。「我们不训练自己的模型」能支撑收窄某些数据控制；「那看起来工作量太大」在第二阶段审核活不过一分钟。
七、中国对标：GB/T 45081-2024
| 项 | 内容 |
|---|---|
| 标准号 | GB/T 45081-2024 |
| 名称 | 《人工智能 管理体系》（Artificial intelligence — Management system） |
| 采用关系 | IDT 等同采用 ISO/IEC 42001:2023 |
| 发布/实施 | 2024-11-28 发布即实施（现行） |
| 归口/发布 | 全国信息技术标准化技术委员会（SAC/TC 28）· 国家市场监督管理总局 + 国家标准化管理委员会 |
| 引用标准 | ISO/IEC 22989:2022（术语） |
| 篇幅 | 48 页 · 81 千字 · 大 16 开 |
意义：这套方法论在国内有国家标准背书（等同采用 = 技术内容与 ISO 一致）。要求与国务院「人工智能+」行动方向相契合；认证既能对接国内政策，也作为国际通用标准支撑对外竞争。
背景参考：百度 2024-09 获全球首张证书；此后用友、蓝凌、钉钉及其「悟空」平台等相继获证。
背景参考：百度 2024-09 获全球首张证书；此后用友、蓝凌、钉钉及其「悟空」平台等相继获证。
八、与 EU AI Act / NIST AI RMF 的关系
| 框架 | 性质 | 与 42001 的关系 |
|---|---|---|
| EU AI Act （欧盟人工智能法） |
法规（强制 · 分风险等级） | 42001 证书 ≠ 符合 EU AI Act。42001 不是 harmonised standard（协调标准），不产生合规推定；承担该角色的是 prEN 18286（尚未在欧盟官方公报引用）。两者互补不替代，重叠最强处在风险管理、数据治理、技术文档、上市后监测、质量管理 |
| NIST AI RMF 1.0 | 自愿框架（2023-01）· 四功能 GOVERN / MAP / MEASURE / MANAGE | 免费、结构好；已成企业 AI 问卷的通用语言。注意："法定强制"说法多源于已废止的 EO 14110（2025-01-20 撤销），框架本身仍自愿 |
三个框架可「建一次证据、挂三处标签」：风险与影响文档 / 数据治理 / 人类监督 / 事件监测 / 透明性文档 —— 这五个控制区反复出现，是重叠区。
九、认证路径与实务
9.1 认证流程
准备期（多数工作量在此）
差距评估 → 建 AIMS → 跑风险与影响评估 → 实施控制 + 写 SoA → 内审 + 管理评审
│
▼
Stage 1 文件评审（体系设计得对不对？文档齐不齐？）
│ ← 认证前须至少完成 1 次内审 + 1 次管理评审
▼
Stage 2 运行审核（体系真在跑吗？有证据吗？）★ 抽样查 SoA 中适用控制项
│
▼
发证 → 每年监督审核 → 3 年再认证（recertification）
9.2 常见不符合项（首次审核）
| # | 不符合项 | 教训 |
|---|---|---|
| ① | 范围不匹配 —— 在产的 AI 系统没进 AIMS 范围 | 范围界定要覆盖「影子 AI」 |
| ② | AI 方针太通用 —— 模板照抄，无组织特有承诺 | 方针要「像自己写的」 |
| ③ | 影响评估缺维度 —— 漏公平/环境/可预见误用 | 影响评估须全维度 |
| ④ | 第三方 AI 缺口 —— SaaS 内置 AI 功能未评估 | 供应商 AI 也是风险 |
| ⑤ | 管理评审证据弱 —— AI 议题被并入通用安全评审 | AI 议题须单列讨论 |
| ⑥ | 数据血统记录不全 —— 训练/验证集无来源、许可、质检 | 数据来源要可溯 |
业内经验：多数不符合项与技术无关 —— 而是范围太模糊、变更后风险评估没更新、方针"交付组织里没一个人知道"。准备期成本远大于审核那几天。
十、★ 与我方体系的映射与可借鉴之处
声明：以下为比对分析，不构成对我方体系的自动修改建议；凡涉及改动须走「先审再做」并经春哥审定。参考非依据。
| ISO 42001 要求 | 我方现状 | 对照 |
|---|---|---|
| §5 + A.3.2 角色/职责/权限明文指派 | CHR-001 §5 三层分离 · PRO-005 岗位说明书（含权限边界）· REC-004 岗位台账 | 🟢 结构已具备 —— 「定岗不定角色」与 A.3.2 同向；差别在 A.3.2 按「每个 AI 系统」指派，我方按「每个岗位」 |
| §6.1.4 / §8.4 AI 系统影响评估（对外） | 三判据/可逆性（对内行为约束）· 门禁（对内质量） | 🟡 对外影响评估维度是缺口 —— 可用「双评估模型」启发 |
| §7.2 + A.4.6 能力与人力资源 | PRO-005 第 4 章全生命周期 · REC-005 能力矩阵 · REC-006 配置档案 | 🟢 强项 —— AI 任职者六维模型（A/B/C/D/E/F）比 A.4.6 更细，可反哺 |
| A.6.2.8 / A.9.4 事件日志 / 预期用途 | 门禁留痕 · 会话记录 · 记忆 · 部署断言 | 🟡 有留痕但未按「用途/事件」结构化 —— 可作参考 |
| §9 内审 + 管理评审 | 周六审计 · audit_memory_versions.py · 门禁二十连 · PRO-002（拟） | 🟢 有实践 —— 与 §9 内审/管理评审功能等价，术语可对接 |
| §10 不符合与纠正（CAPA） | 事故处置 · 深坑停步汇报 · 记忆围栏 | 🟢 有实践 —— 「事故→调研→机制固化→写记忆」正是 CAPA |
| A.10 第三方关系 | 外部资料口径 · 开源许可（NOTICES）· 平台托管 vs 自建判断 | 🟡 部分有 —— 供应商 AI 治理可对接 A.10 |
| A.7 数据来源/血统 | 外部资料口径（先核实→入台账→定档）· 素材来源合规 | 🟢 方向一致 —— 与 A.7.5 精神相同 |
三条最值得借鉴的「新意」（我方当前较弱）：
- 双评估模型 —— 补上「对外影响评估」这只眼（A.5.4 / A.5.5）；
- SoA 式「适用性声明」 —— 我方规则多，但未系统记录「为什么选这些规则、不选那些」；
- 运行期证据 vs 文档证据 —— A.6.2.6 / 6.2.8 / 9.4 提示：治理的可信度最终靠运行期记录，而非政策文本 —— 与我方「门禁 + 留痕」思路高度同向。
⚠️ 本文为信息整理（🟢 基于 ISO/IEC 官方公开摘要与多方公开资料交叉核实），以 ISO/IEC 42001:2023 / GB/T 45081-2024 官方文本为准。标准正文受版权保护，本文为转述与整理，非原文复制。配套标准仍在演进，具体日期以官方发布为准。