简介ISO/IEC 42001:2023 是国际标准化组织与国际电工委员会联合发布的首版人工智能管理体系国际标准为使用或开发AI产品与服务的组织提供建立、运行并持续改进AIMS的统一框架。文件面向信息技术安全管理从业者、AI研发团队、企业决策层及质量管理体系人员帮助组织在合规前提下负责任地落地AI应用明确角色分工与责任边界。压缩包内共1个PDF文件约1.18MB为完整标准正文含前言、引言、条款与附录便于检索引用。正文从理解组织背景与相关方需求出发依次覆盖治理架构确立、风险管理规划、支持与运行控制并给出持续改进建议附录补充参考控制目标、实施指南及风险评估方法可作为编制内部制度、开展影响评估与审计自查的对照依据。已有454人学习。1. 第一版 2023-12 落地AIMS 到底该管住什么这份 2023 年 12 月发布的第一版 ISO/IEC 42001:2023标题写的是「信息技术 — 人工智能 — 管理体系」。它不是模型评测规范也不是算法公平性白皮书而是一套和 ISO 9001、ISO/IEC 27001 同构的 AI 管理框架组织环境、领导作用、策划、支持、运行、绩效评价、改进七段骨架一条不少后面再挂上附录 A 的九个 AI 专属控制目标和附录 B 的逐条实施指南。真正稀缺的内容在 6.1.4 和 8.4——它把「AI 系统影响评估」写成了必须闭环、必须留证据的动作而不是一句「应关注伦理风险」。适合谁正在把模型塞进产品、又被人追问「你凭什么说这套系统是可控的」的团队负责人、信息安全与质量管理岗以及要给 AI 项目立规矩的技术管理者。2. 拆条款十章正文加四个附录怎么读成一张骨架图很多人拿到这份文档先翻附录 A从 A.2 一路打勾到 A.10打完就觉得「体系建完了」。这是最典型的翻车姿势。正确的读法是把它当成一条流水线4~6 章决定你要管什么、谁拍板、依据什么准则7~8 章决定日常怎么跑9~10 章决定你怎么证明它还在跑。附录 A 只是这条流水线上的控制点清单脱离前面四章的范围声明和风险评估控制点是悬空的。我在拆这类体系文档时习惯先做一张「条款—产出物—责任人」的三列表把每个条款翻译成一个能被审的东西。翻译不出来的条款基本就是后面要出问题的地方。2.1 第 4~6 章上下文、领导作用与策划空话最容易堆在这第 4 章四小节是一条递进线。4.1 要求理解组织及其环境落到 AI 场景里就是那几件具体事训练数据从哪来、算力在哪、模型是自研还是采购、业务上依赖哪家基础模型供应商、外部对AI 的合规预期变没变。这些不是写作文是后面风险识别的输入源写虚了6.1.2 就无从下手。4.2 要识别相关方及其要求除了客户和监管别忘了被模型输出影响的那部分人——他们往往不在你的合同关系里却是影响评估的主体。4.3 定范围是整个体系里最容易划水也最要命的一节边界必须写到「哪些系统、哪个生命周期阶段、哪些法人主体、哪些地域」边界外的东西要明写「不适用及理由」并留档。第 5 章讲领导作用5.1 承诺、5.2 AI 方针、5.3 角色职责权限。别把方针写成一页漂亮口号它至少要包含三样可被验证的内容组织对负责任 AI 的基本立场、目标框架对应 6.2、以及谁有权在什么条件下叫停一个 AI 系统。5.3 我一般要求输出一张 RACI 表把「AI 治理委员会 / 系统负责人 / 数据负责人 / 风险与合规 / 内审」五个角色在风险评估、影响评估、上线审批、事件响应四件事上的 R、A、C、I 标清楚。没有这张表内审时你没法回答「谁批准了这个模型上线」。第 6 章是整份标准的重心。6.1.1 要求策划应对风险和机遇的措施6.1.2 是 AI 风险评估6.1.3 是 AI 风险处置6.1.4 是 AI 系统影响评估6.2 是目标及其实现策划6.3 是变更策划。这里有一个设计上的关键点常被忽略6.1.3 要求处置措施与附录 A 的控制目标做对照并判断哪些适用、哪些不适用、不适用为什么——这份东西就是通常说的适用性声明。它不是附录 A 的复印机而是「我的场景为什么不需要这条」的论证记录。2.2 第 7~10 章支持、运行、绩效评价与改进怎么转起来第 7 章支持五个小节里最实的是 7.5 文件化信息。7.5.1 要求体系包含标准明确要求的文件和记录以及组织自己判断必要的那些7.5.2 管创建和更新落到标识、格式、评审、批准7.5.3 管控制落到分发、访问、检索、留存、变更、作废。这三节合起来其实是一套文档管理规则后面第 4 节我会给具体目录骨架。7.2 能力容易被写成「我们培训了」。合格的写法是岗位能力矩阵每个与 AI 相关的岗位需要哪几项能力、怎么证明具备、缺口怎么补、补完怎么记录。7.3 意识要求人员知道方针、知道自己的工作如何影响 AI 目标、知道不符合要求的后果。7.4 沟通要写清沟通什么、何时、和谁、由谁沟通——模型上线对外披露口径就属于这一条。第 8 章运行。8.1 要求按准则实施过程并控制变更落到工程上就是把控制嵌进既有流程需求评审、数据准入、模型验收、上线审批、监控告警、退役归档。8.2 和 8.3 是风险评估与处置的「运行时副本」不是 6.1 的重复抄写而是「定期或触发式再跑一遍」。触发条件建议写死在文件里模型重大版本更新、训练数据分布明显变化、新数据源接入、使用场景扩展、发生安全或质量事件、外部规则变化。第 9 章绩效评价。9.1 要定监视测量的对象、方法、时机指标不能只有准确率至少要有三类系统性能类、风险控制有效性类比如告警命中率、人工复核比例、过程合规类评估按期完成率、纠正措施关闭率。9.2 内审要写方案明确频次、方法、审核准则、审核员独立性9.3 管理评审要写输入输出。第 10 章持续改进与不符合、纠正措施10.2 的关键是「原因分析」不能停在「人员疏忽」否则纠正措施永远是再培训一遍。2.3 附录 A 与附录 B 的对应九个控制目标怎么落到证据附录 A 是规范性附录按控制目标组织下面挂三十余条控制措施附录 B 同样是规范性附录逐条给实施指南告诉你这一条在工程上大致长什么样。附录 C 是资料性附录给的是 AI 相关的组织目标与风险源参考附录 D 是资料性附录讲这套体系跨行业跨领域怎么用。四个附录的性质不同用的时候别混规范性附录的内容是审核依据资料性附录是参考素材。控制目标关心的问题常见证据形态主要责任角色A.2 与 AI 相关的方针立场与边界是否公开、是否被遵守方针文件、发布记录、例外审批治理委员会A.3 内部组织角色、职责、汇报线是否清晰RACI 表、任命文件、会议纪要管理层A.4 AI 系统相关资源数据、算力、工具、人是否够用资源清单、容量评估、预算记录系统负责人A.5 AI 系统影响评估对个人、群体、社会的影响是否评估影响评估报告、评审结论风险与合规A.6 AI 系统生命周期各阶段是否有准入与验收阶段评审记录、验收单研发负责人A.7 AI 系统数据来源、质量、权限、留存是否受控数据字典、血缘记录、授权凭证数据负责人A.8 相关方信息对外说明是否充分、可理解模型说明、用户告知、变更公告产品负责人A.9 AI 系统使用使用是否符合预期用途使用规范、滥用监控、事件记录业务负责人A.10 第三方与 AI 关系供应商与外部模型是否被管住供应商评估、合同条款、接口清单采购与合规这张表的价值在于把「控制目标」翻译成「审核员会要什么」。A.6 尤其容易空转因为生命周期本身就是研发流程如果研发流程里没有阶段准入单独为体系造一套评审会最后一定是两张皮。常见做法是把体系要求嵌进已有的需求评审、代码评审、上线审批节点只在节点上增加 AI 专属检查项。3. 风险评估与影响评估两套动作、一张登记册体系跑不动八成是卡在这里风险登记册建了没人更新影响评估写了不知道给谁看。要解决这个问题先得搞清楚 6.1.2/6.1.3 和 8.2/8.3 为什么被拆成两组条款。3.1 6.1.2 / 6.1.3 与 8.2 / 8.3 为什么写成两组条款6.1 属于「策划」是建立体系时的一次性基线动作输出的是方法论、准则、可接受风险水平和处置计划8.2/8.3 属于「运行」是在体系运行期间按策划的频次和触发条件重复执行同一套方法论输出的是滚动更新的评估记录。标准把它们拆开本质是在说风险评估不是一个项目阶段而是一个持续过程。很多组织只做前者审核时被问「上一次模型更新后你重跑评估了吗」答不上来。所以工程上要落两样东西一套写死的评估方法论放在体系文件里规定识别、分析、评价的步骤和准则一份滚动的登记册每条风险有触发来源、当前状态、处置措施、剩余风险、复核日期。方法论变更要走变更控制登记册更新是日常动作。方法论里最需要定死的是评价准则。建议用「可能性 × 影响」的双维度各分 1~5 级乘积落 1~25分档写清哪一档必须处置、哪一档可接受、哪一档需要管理层签字接受。不要用「高/中/低」三档口头判断那种打分表三个月后连填表的人都解释不了当时为什么打「中」。3.2 AI 系统影响评估的六个维度和 1~5 分量表影响评估和风险评估是两个视角。风险评估问「这事对我们有什么损失」影响评估问「这个系统对个人、群体、社会产生什么后果」。混成一张表是审得最多的问题第 5 节会专门讲。我一般按六个维度拆一是对个人的自主性与知情权影响比如是否在用户不知情时做自动化决策二是公平性与差别对待比如不同人群的错误率差异三是隐私与数据最小化四是安全与滥用可能性包括被恶意使用的门槛五是对特定群体的可及性影响六是可追溯与可解释程度即出问题时能否定位到数据、模型版本和决策路径。每个维度打 1~5 分1 表示几乎无影响5 表示影响不可逆或波及面广。维度1 分3 分5 分需要的附加动作自主性与知情仅辅助建议影响排序与推荐直接决定个人权益人工复核 明确告知公平性无人群区分输出有分组但未验证差异已观测到显著差异分组指标验证 缓解方案隐私不涉及个人数据涉及但已脱敏涉及敏感个人信息单独影响评估 授权链安全与滥用内部只读工具对外可用需登录可被批量调用生成内容滥用监测 速率与内容约束可及性面向内部专业用户面向一般用户面向公众或脆弱群体可及性测试 替代通道可追溯性全链路留痕部分留痕黑匣子补齐日志与版本绑定打分不是目的目的是让「5 分项必须做附加动作」成为一条硬规则。没有附加动作的高分项等于没评。3.3 用 YAML Python 生成可审的风险登记册登记册用表格维护迟早会散。我倾向让风险条目以 YAML 存放一条一个文件或一个列表项用脚本做校验和导出。校验的作用是把「缺字段」「没写处置措施」「没有复核日期」这类问题在提交时就拦住而不是等内审。# risks/risk-0007.yaml id: R-0007 system: 某图像处理Demo # 关联的 AI 系统名称内部代号 lifecycle_stage: 运行 # 需求/数据/训练/评估/部署/运行/退役 source: 8.2 定期复核 # 触发来源6.1.2 基线 / 8.2 运行 / 事件驱动 description: 训练集来源单一对特定光照条件样本覆盖不足 likelihood: 4 # 1~5 severity: 3 # 1~5 control_ref: [A.7, A.6] # 对应附录 A 控制目标 treatment: 补充采集并做分层验收验收未过不发布 residual_likelihood: 2 residual_severity: 3 owner: 数据负责人 review_due: 2025-06-30 status: open # open / mitigated / accepted / closed# aims_register.py # 用途校验风险条目必填字段计算风险值并导出 CSV 登记册与控制目标覆盖统计 import csv import pathlib import sys import yaml REQUIRED [id, system, lifecycle_stage, source, description, likelihood, severity, control_ref, treatment, owner, review_due, status] CONTROL_TARGETS [fA.{i} for i in range(2, 11)] # A.2 ~ A.10 def load_risks(folder: str) - list[dict]: items [] for path in sorted(pathlib.Path(folder).glob(*.yaml)): with path.open(encodingutf-8) as fh: data yaml.safe_load(fh) data[_file] path.name items.append(data) return items def validate(items: list[dict]) - list[str]: errors [] for item in items: missing [k for k in REQUIRED if not item.get(k)] if missing: errors.append(f{item[_file]}: 缺少字段 {missing}) for key in (likelihood, severity): value item.get(key) if not isinstance(value, int) or not 1 value 5: errors.append(f{item[_file]}: {key} 必须是 1~5 的整数) for ref in item.get(control_ref) or []: if ref not in CONTROL_TARGETS: errors.append(f{item[_file]}: 控制目标 {ref} 不在 A.2~A.10 范围内) return errors def export(items: list[dict], out_csv: str) - None: fields [id, system, lifecycle_stage, source, likelihood, severity, risk_score, level, control_ref, treatment, residual_likelihood, residual_severity, owner, review_due, status] with open(out_csv, w, newline, encodingutf-8-sig) as fh: writer csv.DictWriter(fh, fieldnamesfields) writer.writeheader() for item in items: score item[likelihood] * item[severity] level 高 if score 15 else (中 if score 8 else 低) row {k: item.get(k, ) for k in fields} row[risk_score], row[level] score, level row[control_ref] ;.join(item.get(control_ref) or []) writer.writerow(row) def coverage(items: list[dict]) - None: used {ref for item in items for ref in (item.get(control_ref) or [])} for target in CONTROL_TARGETS: mark 已引用 if target in used else 未引用需在适用性声明中说明 print(f{target}\t{mark}) if __name__ __main__: risks load_risks(sys.argv[1] if len(sys.argv) 1 else risks) problems validate(risks) for line in problems: print(line, filesys.stderr) export(risks, risk_register.csv) coverage(risks) sys.exit(1 if problems else 0)用法是python aims_register.py risks/输出同目录的risk_register.csv和控制目标覆盖情况。逻辑上有三处值得说校验函数把必填字段、分值范围、控制目标编号三件事一次拦住退出码非零方便挂到提交钩子里导出时把「可能性 × 影响」和分档规则写死在代码里避免各人 Excel 各算一套覆盖统计会打印出「未引用」的控制目标这份清单正是适用性声明要逐条解释的对象比人工回忆可靠得多。参数上最常改的是分档阈值。15/8 这两个数是按 5×5 矩阵取的如果你们的分值范围改过阈值要同步改别只改一边。另外control_ref用列表而不是单值因为一条风险通常同时牵涉数据和生命周期两个控制目标单值会逼着人做取舍。4. 文件化信息目录骨架、命名规则与版本控制体系评审现场最尴尬的场面不是缺文件是文件都在、但没人说得清哪一版在生效。7.5 三小节讲的就是这件事落到实操上就是目录、命名、版本、权限四件事。4.1 7.5 要求的最小文件集合标准明确要求保留的文件化信息大致可以归成四类边界类AIMS 范围、适用性声明、规则类AI 方针、方法论、职责权限、证据类风险评估与影响评估结果、监测记录、审核记录、事件与纠正措施、结论类管理评审输出、改进决定。除此之外组织自己判断必要的比如作业指导、模板、检查表。判断标准很朴素如果这件事换个人做会做出不同结果就该有文件如果审核时无法复现当时的判断依据就该有记录。文件归属条款性质更新触发AIMS 范围声明4.3受控文件组织或业务边界变化AI 方针5.2受控文件可对外战略或外部预期变化风险评估方法论与准则6.1.2受控文件准则或阈值调整风险登记册6.1.2 / 8.2滚动记录每次评估影响评估报告6.1.4 / 8.4记录系统变更或周期复核适用性声明6.1.3受控文件控制目标增删岗位能力矩阵与培训记录7.2记录人员或岗位变化内审方案与报告9.2记录每年或重大变更管理评审输入输出9.3记录每次评审不符合与纠正措施记录10.2记录每次发生4.2 用脚本初始化 AIMS 文档仓库目录按条款编号排比按部门排稳定得多——部门会重组条款不会。下面这段脚本一次把骨架建好顺便放几个占位文件避免新人不知道往哪写。#!/usr/bin/env bash # init_aims.sh —— 按条款编号初始化 AIMS 文档仓库骨架 set -euo pipefail ROOT${1:-aims-repo} mkdir -p $ROOT/{01-scope,02-policy,03-risk,04-impact,05-controls,06-competence,07-ops,08-audit,09-review,10-improve,templates} # 边界与规则类受控文件命名带版本号 : $ROOT/01-scope/AIMS-Scope_v1.0.md : $ROOT/02-policy/AI-Policy_v1.0.md : $ROOT/05-controls/Statement-of-Applicability_v1.0.md : $ROOT/03-risk/Risk-Methodology_v1.0.md # 记录类命名带日期不覆盖只追加 : $ROOT/03-risk/register/README.md : $ROOT/04-impact/README.md : $ROOT/08-audit/Audit-Programme_$(date %Y).md # 模板统一字段减少各写各的 cat $ROOT/templates/impact-assessment.md TPL # AI 系统影响评估 - 系统名称与版本 - 生命周期阶段 - 影响维度打分自主性/公平性/隐私/安全与滥用/可及性/可追溯 - 高分项及附加动作 - 结论与批准人 TPL # 每次变更留痕谁在什么时候改了什么 git -C $ROOT init -q 2/dev/null || true git -C $ROOT add -A 2/dev/null || true echo 初始化完成$ROOT这段脚本的关键不在建目录在把「受控文件」和「记录」分开存受控文件带_vX.Y版本号改动必须走评审和批准记录带日期只追加不覆盖这样 7.5.3 要求的「防止意外更改」和「保留与处置」才有落点。用 git 初始化是为了拿到变更历史谁在什么时候改了哪一版、改之前是什么样出事时这就是后悔药。参数ROOT可以传默认aims-repo多个项目并行时按项目各建一个仓库别全塞进一个。命名规则建议提前定死并写进体系文件受控文件用类别-名称_v主.次.md记录用类别-名称_YYYYMMDD.md跨年度的方案用类别-名称_YYYY.md。规则一旦公布就别允许例外例外一多检索就废了。4.3 内审与管理评审的输入输出对照9.2 的内审和 9.3 的管理评审是两件事别用一次会糊弄过去。内审看符合性和有效性评审看体系的持续适宜性并做决策。我要求内审报告固定回答四个问题审了哪些条款和系统、发现哪些不符合、根因是什么对应 10.2、上次不符合关没关。管理评审的输入则要覆盖风险评估与影响评估的当前状态、监测指标趋势、内审结果、相关方反馈与投诉、纠正措施状态、资源是否充分、外部变化。输出要落到具体决定改不改方针、加不加控制、调不调资源、下一次评估什么时候。提示内审员不审自己做的模块这条在人员紧张时最容易被破一旦破了9.2 的有效性就没法论证。5. 避坑五条从评审现场带回来的记录下面这些不是理论推演是这类体系第一次跑起来时反复出现的形态。每条按现象、原因、解决写。5.1 范围写成了「全公司所有 AI 相关活动」现象是范围声明里一句话带过问哪个系统在体系内、哪个不在答不上来。原因是把 4.3 当成了形式条款觉得写窄了显得体系不完整。实际后果是评估、内审、监控的范围永远算不清分母指标做得再漂亮也没意义。解决办法是把范围写成可枚举的清单系统名或内部代号、生命周期阶段、法人主体、地域、依赖的关键第三方再加一段边界外声明和理由。范围收窄不丢人说不清才丢人。5.2 风险登记册建好三年没一次在模型更新时被触发现象是基线的 6.1.2 做得很认真之后登记册再没动过模型改了四版评估报告还是第一版。原因是 8.2 的触发条件没写成可执行规则只写了「适当时重新评估」。解决是把触发器写成硬条件并挂到流程上模型主版本变化、训练数据来源新增、使用场景扩展、发生安全或质量事件、外部规则变化命中任一条件即开评估单未开单不允许上线。落地技巧是把它做成上线检查表的一行靠流程卡不靠自觉。5.3 影响评估和风险评估混成一张表现象是表头写着「风险评估」内容里既有「对组织声誉的影响」也有「对用户群体的影响」评审时被问「这条到底算哪一类」就卡住。原因是两张表看上去都是打分省事就合并了。解决办法是物理分开风险评估的后果主体是组织影响评估的后果主体是个人、群体、社会两份报告分别归入 6.1.2/8.2 和 6.1.4/8.4各自有独立的结论和批准人。合并的代价是两边都不合格。5.4 文件化信息只有受控、没有作废现象是目录里躺着_v1.0到_v2.3十几个版本没人标哪一版有效新人照着旧版写材料。原因是只做了 7.5.2 的创建更新没做 7.5.3 的控制。解决办法是加两道动作新版本发布时同步在受控目录留一份、旧版移入archive/并在文件名后加_obsolete同时维护一张受控文件清单写清当前有效版本号和生效日期。清单本身也是受控文件别做个 Excel 就不管了。5.5 把附录 A 当检查表逐条打勾现象是适用性声明里 A.2 到 A.10 全部标「适用」控制措施全部标「已实施」但问「A.7 数据这条你怎么做的」答「我们数据都存数据库里」。原因是把控制目标当成了待办清单而不是要论证的判断。解决办法是逐条写三件事这条控制在本组织具体对应什么动作、证据在哪、如果不适用理由是什么。写不出具体动作的就是没实施别打勾。附录 B 的实施指南这时候有用它给的是「这条控制大概长什么样」照着它把自己的做法描述出来比抄条款原文管用。6. 进阶用附录 C 的风险源做抽样验证体系跑到第二年最容易出现的退化是「记录齐全但内容趋同」——每次评估结论都差不多说明评估已经变成填空题。这时候我一般做一次反向验证拿附录 C 给的风险源参考清单当探针随机抽几条去问具体系统「这个风险源在你这儿成不成立、如果成立对应哪条登记项」。做法是三步。第一步从附录 C 里挑与自身业务相关的风险源落成一张固定的探针清单比如训练数据偏差、模型输出被滥用、供应商模型版本被动升级、使用场景超出预期用途、日志不足以复现决策。第二步按 9.2.2 的内审方案做分层抽样高风险系统全查中风险抽一半低风险抽两成抽样时确保覆盖不同生命周期阶段别全抽运行阶段。第三步对每个探针问三个问题并留痕——登记册里有没有对应条目、处置措施是否可验证、最近一次复核是什么时候。探针问题合格回答不合格信号登记册有无对应条目有条目且关联具体系统「这类风险我们一般不会有」处置措施可否验证能指出验收记录或监控指标只有「已加强管理」最近复核时间在约定周期内且触发条件命中过停在体系建设那年影响评估是否覆盖有维度打分与附加动作只写「影响较小」抽样结果不达标走的不是 10.2 的纠正措施单而是先改方法论——因为大面积趋同说明问题在准则不在执行。这一点很多人绕不过来结果开了一堆「加强培训」的纠正措施第二年抽样还是同样结果。我自己有个习惯每次内审前先把探针清单打印出来抽中的系统逐个对照抽不到的系统也要能说出为什么没被抽中。这个动作坚持下来最大的收益不是应付审核而是能在模型悄悄换了一版、数据源悄悄多了一个的时候第一时间发现评估没跟上。血泪经验是那些最后出问题的系统往往不是评估写得差的那个而是从来没被抽中过的那个。从那以后我每次定内审方案都强制给「上一年度未被抽中」的系统留出名额哪怕它的风险等级是低。希望帮到你。本文还有配套的精品资源点击获取