简介ISO/IEC DIS 42001:2022草案是国际标准化组织与国际电工委员会联合发布的《信息技术—人工智能—管理体系》国际标准草案面向AI产品负责人、合规与信息安全从业者、体系审核员及高校研究人员用于解决人工智能系统在组织治理、风险管控与合规认证方面缺乏统一依据的问题。文件为单个PDF压缩包约1.98MB完整保留草案封面、ICS分类号、前言、引言与目次结构属于投票征求意见阶段的原文版本。已有399人学习下载。内容围绕组织与管理职责划分、AI风险管理、数据质量与安全、系统访问控制、可持续演进五条主线提出要求并给出评估与认证的对应条款可支撑制造业、金融、医疗等场景的体系搭建。读者可据此梳理AI管理体系的条款脉络对照内部制度做差距分析或作为审核与培训的原始依据。1. 拿 27001 的体系文件改个抬头就交上去是我见过最快的翻车有个团队把信息安全管理体系的文件目录整体复制把“信息安全”全局替换成“人工智能”然后拿去参加内部评审。评审问到“你们做过 AI 系统影响评估吗”全场沉默。手上这份 ISO/IEC 42001 草案全称是信息技术—人工智能—管理体系2022 年 11 月 9 日开始投票、2023 年 2 月 1 日截止它确实复用了通用的高阶结构但在通用骨架之外单独补充了 AI 系统影响评估、数据资源、AI 系统生命周期这几项必须完成的内容。这份草案适合三类人被要求提交 AI 治理材料的团队负责人、要给模型上线做过程记录留存的算法工程师、接 AI 项目却没有过程资产的外包团队。提示一句草案就是草案可以做体系设计不能当认证依据。2. 条款骨架拆开看4 到 10 章各自要交出什么东西2.1 它为什么长成高阶结构的样子这份草案的正文从第 4 章到第 10 章用的是管理体系标准通用的高阶结构组织环境、领导作用、策划、支持、运行、绩效评价、改进。这个结构的好处是能和质量、信息安全那几条体系线整合到一套文件里不需要另开一套管理流程。坏处也很直接很多人看到熟悉的编号就以为内容也是熟悉的直接套模板。真正需要留意的是它在通用骨架里额外增加的内容。第 6 章策划里出现了三个并列动作AI 风险评估6.1.2、AI 风险处置6.1.3、AI 系统影响评估6.1.4。前两个在信息安全体系里也有对应条款第三个是新增的而且它评估的对象不是组织的信息资产是 AI 系统对个人、群体和社会造成的后果。这是整套文件里最容易被漏掉、也最容易被审计追问的一块。再看第 8 章运行8.2、8.3、8.4 又把这三件事重写了一遍。同一件事写两遍不是重复是刻意区分阶段第 6 章是“策划时怎么做、多久做一次、谁批准”第 8 章是“按策划真的执行了、结果落在哪”。我见过不止一个团队只做了第 6 章的文件第 8 章只有一句“按计划执行”被问到最近一次评估的日期和输出物时就说不出来。这种“有制度没有记录”的状态在体系审核里是最常见的失分点。还有 6.3 变更的策划单独占一节。AI 项目变更频率高换模型、换数据源、换供应商、改提示词策略都算草案要求变更前先判断对风险评估和影响评估的影响。这条如果没落地后面所有评估都会变成一次性工作做完就放进档案再也不更新。2.2 七章条款与交付物的对照把条款翻译成交付物是落地第一步。下面这张表是我自己项目里用的版本左列是条款中间是必须存在的输出右列是常见的“假交付”形态供你对照自查。条款应产出的东西常见的无效交付4.1 理解组织及其环境内外部因素清单含 AI 相关的技术、数据、供应链、舆情因素抄一段行业趋势4.2 相关方需求与期望相关方清单加需求转化记录只写“客户要求高质量”4.3 范围声明明确到 AI 系统、场景、地点、边界写成公司简介5.2 AI 方针一页纸含原则、红线、责任承诺八页套话6.1.2 AI 风险评估风险源、事件、后果、可能性、等级只列风险名称6.1.3 AI 风险处置处置措施与 Annex A 控制项的映射措施与控制项对不上6.1.4 影响评估对个人、群体、社会的影响判断与结论写成模型性能报告6.2 AI 目标可测量目标加达成计划“提升 AI 应用水平”7.2 能力岗位能力要求加培训记录只有签到表7.5 成文信息创建、更新、控制的规则目录里一堆无版本号的文档8.1 运行策划与控制运行准则、过程控制点只有流程图9.1 监视与测量指标定义、采集方式、分析结论只有指标名没有数据9.2 内部审核审核方案、检查表、不符合项一次会议纪要10.2 不符合与纠正不符合描述、原因分析、措施、验证只写“已整改”表格右列这些形态本质都是“有文件、无证据”。体系运行的核心不是文档数量是每个声称都能追到一份带日期、带责任人、带结论的记录。你在设计阶段就该按这个标准自检一遍不要等到内审才发现一半条款没有对应的实物。2.3 范围声明与相关方清单最容易写虚的两份文件范围声明4.3看起来只是写一段话实际决定了后面所有工作的边界。写得太宽比如“覆盖公司全部人工智能相关业务”等于给自己挖坑审核时随便挑一个边缘项目就能问倒你写得太窄只写“某推荐算法”又会漏掉支撑它的数据平台、标注团队和第三方模型供应商风险评估就会缺一块。我一般的写法是三层系统层列清楚纳入的 AI 系统或系统族场景层说明这些系统服务的业务场景和部署形态支撑层说明纳入的数据、工具、算力和人力范围以及明确排除的部分及排除理由。排除项一定要写理由比如“实验性研究项目不纳入因不对外提供服务另行按研发流程管理”。有理由的排除叫边界没理由的排除叫遗漏。相关方清单4.2的常见错误是把相关方写成客户名单。实际要识别的是“谁会被这个 AI 系统影响、谁对它提要求”。我通常分四类内部业务方与运维方、外部客户与最终用户、受系统输出间接影响的个人或群体、供应链上的数据与模型提供方。每一类后面要跟一条“期望转化为要求”的记录比如最终用户期望“输出可解释”转化成要求就是“高风险场景必须提供决策依据说明”再往下就能挂到 Annex A 的控制项和具体验收标准上。这两份文件加起来通常不到五页但它们是后面风险登记表、影响评估表、控制项适用性声明的输入。省这一步后面所有表格都得返工这就是典型的“图快反而慢”。3. Annex A 控制项与 Annex B 指南控制目标怎么挑才不被反问3.1 八组控制项与适用性声明Annex A 是规范性附录给的是参考控制目标和控制措施Annex B 是配套的实施指南逐组解释这些控制项该怎么实施。草案里 Annex B 的章节编号基本与 Annex A 对齐从 B.2 与 AI 相关的方针、B.3 内部组织、B.4 AI 系统的资源、B.5 评估 AI 系统影响、B.6 AI 系统生命周期一路铺下去B.4 下面还细分成资源文档化、数据资源、工具资源、系统与计算资源、人力资源五类。这个细分很有用它等于告诉你资源这块要准备五份不同的证据而不是一份“资源充足”的说明。把 Annex A 的控制项分组看大致落在这么几个方向上方向关注点典型证据方针AI 方针的制定、评审、与其他制度对齐方针文件加评审记录内部组织角色职责、关切上报渠道职责矩阵、上报记录资源数据、工具、算力、人力的文档化资源清单与来源说明影响评估影响识别、评估过程、结论影响评估报告生命周期各阶段准入准出、变更管理阶段评审记录数据来源、质量、偏差、授权数据卡与授权凭据利益相关方信息对外说明的准确性对外材料评审记录使用使用范围限制、滥用防范使用条款与技术限制适用性声明SoA是这份草案落地时最容易出问题的一份文件。做法本身不复杂逐个控制项写“适用或不适用、理由、实施状态、证据在哪”。真正的问题是很多人把“不适用”当成省事的捷径理由栏写“公司暂无此场景”。审核时对方只要举出一个反例整份声明就要重做。我的做法是反过来先默认全部适用然后对每个想标“不适用”的项要求提出人给出书面论证至少包含“该控制项针对的风险在本组织不存在或被其他机制完全覆盖”的说明。这样筛下来真正能标不适用的通常不超过五六项而且每一项都有经得起追问的理由。这个流程看着麻烦但比事后被逐条质疑要省事得多。3.2 AI 系统影响评估从“会不会出事”到可打分的表6.1.4 的 AI 系统影响评估是这份草案区别于其他管理体系标准的核心。它不是问“模型准不准”而是问“系统跑起来之后对人和群体产生什么后果”。这两件事经常被混为一谈最典型的表现是拿一份准确率、召回率的评测报告充当影响评估。下面是我实际在用的评估表字段按维度拆开维度字段取值示例影响对象个人、特定群体、社会某类用户群体影响类型隐私、公平性、自主性、人身安全、信息完整性公平性严重程度1 到 54发生可能性1 到 53可逆性可逆、部分可逆、不可逆部分可逆影响规模受影响人数区间万级现有缓解已实施的控制输出审核、人工复核残余判断可接受、需缓解、不可接受需缓解几个实操要点。第一影响类型不要只写“安全”要拆到具体后果上比如“推荐结果导致某类内容被系统性压低曝光”这种描述才能推导出控制措施。第二可逆性这一列很关键同样是中等严重程度可逆和不可逆的处理优先级差一个量级涉及人身安全、资格判定、资源分配的场景基本都落在不可逆那一侧。第三评估结论要能落到具体动作上“需缓解”后面必须跟一条措施、一个责任人、一个截止时间否则这张表就是归档材料。评估频率也要在文件里写死。草案的逻辑是策划阶段定规则、运行阶段执行所以你要在 6.1.4 里写清楚触发条件首次上线前必做、重大变更前必做、固定周期比如每半年复评、发生相关事件后追加。这四个触发条件写全了8.4 的执行记录才有依据。3.3 数据资源与生命周期证据链要留到哪一层Annex B 把资源拆成数据、工具、系统与计算、人力四类其中数据资源的文档化最容易被敷衍。很多团队的数据说明只有一句“数据来源合法合规”。这句话在体系审核里等于什么都没说。我一般要求每个进入训练或推理的数据集至少留这几项数据来源与采集方式、授权依据与有效期、覆盖人群与采集时间段、标注规则与标注人员管理方式、质量指标缺失率、重复率、标注一致性、偏差评估结论、保留期限与销毁方式、对外共享情况。这些内容写在一份数据卡里跟着数据集版本走。数据集换版本数据卡同步换版本两者版本号必须能对上。工具资源和系统与计算资源常被合并成一句“具备相应资源”。实际上这两类证据形式不一样工具资源要说明用了哪些框架、哪些第三方组件、许可证与漏洞跟踪机制系统与计算资源要说明训练和推理环境的隔离方式、算力配额、日志留存。第三方模型或 API 也要算进资源范围并且要有一份供应商评估记录写清楚对方提供了哪些说明材料、你验证了哪些。生命周期这块草案给的是一条从概念到退役的线。我不建议照抄阶段名称而是按自己团队真实的研发流程映射比如“需求与可行性—数据准备—训练与评测—上线评审—运行监控—变更—退役”。映射完之后每个阶段补两个东西准入条件进入这个阶段前必须有什么和准出证据离开这个阶段时留下什么。准出证据是最有价值的部分。举几个实际的数据准备阶段的准出是数据卡加授权凭据训练与评测阶段的准出是训练配置、数据集版本号、评测报告上线评审阶段的准出是影响评估结论加审批签字运行监控阶段的准出是监控指标的一段连续数据退役阶段的准出是模型与数据处置记录。把这些串起来就是一条能被抽查的证据链。血泪经验是别指望上线后再补训练配置和数据集版本号这类东西一旦丢了就找不回来模型重跑一遍结果也未必一致。4. 把条款变成台账风险登记表与文档化信息的三层结构4.1 风险登记表的字段怎么定风险登记表是整套体系的枢纽。它往上是 6.1.2 的输出往旁挂 Annex A 的控制项往下派生 8.2 和 8.3 的执行记录。字段设计得不好后面所有关联都会断。我用的结构大致是这样写成 YAML 便于版本管理# risk_register.yaml —— AI 风险登记表字段按项目实际情况裁剪 - id: RA-2024-011 # 唯一编号供处置记录与内审抽样引用 ai_system: 某内容分发系统 # 关联到范围声明中的系统标识 risk_source: 训练数据时效性不足 # 风险源不是风险本身 event: 模型对新出现的类别持续误判 # 可能发生的事件 consequence: 部分内容被错误降权创作者收益受损 # 后果落到人和业务 likelihood: 4 # 可能性1-5 impact: 3 # 影响程度1-5 level: 12 # 等级通常取乘积后映射到高/中/低 annex_a_control: [数据, 生命周期] # 映射到 Annex A 的控制方向 treatment: 建立数据新鲜度监控超过阈值触发重训 # 处置措施 owner: 算法组 # 责任人必须具体到角色 due: 2024-09-30 # 截止时间 residual: 中 # 处置后的残余风险判断 evidence: EV-2024-033 # 证据编号指向实际记录这份台账有几个细节值得说明。risk_source和event一定要分开写混在一起会导致措施失焦——风险源是“数据时效性不足”措施就该是监控数据新鲜度如果只写“模型效果下降”措施只能写成“优化模型”等于没写。annex_a_control这一列是把风险和 Annex A 接上的关键它让适用性声明里的每一项控制都能反向找到对应的风险内审时这条双向索引非常好用。evidence存编号而不是文件路径因为文件会移动、会改名编号不会。这张表还要配两条规则。第一条任何等级为高的风险处置措施必须落到具体版本或具体配置上不能停在“加强管理”。第二条残余风险判断要有人签字签字人不能是措施执行人本人。这两条写进程序文件能挡掉大部分“措施写了但没人认账”的情况。4.2 文档化信息的受控版本、状态与保留期限7.5 这一条容易被当成行政要求但它决定了你所有证据的可信度。我见过最离谱的情况是风险评估报告有四个文件名不同的版本内容互不相同谁也说不清哪份是最终版。这种状态下就算内容做得再好审核也没法采信。受控要做的事不复杂落到三个属性上版本号、状态、保留期限。版本号建议用“主版本.次版本”主版本变更是结论变了次版本变更是文字修订状态只有四种——草稿、评审中、已批准、已作废作废件不删除但标记清楚保留期限按用途定评估报告和审批记录一般要覆盖两个审核周期运行日志按系统和数据敏感度分别设定。再补一个容易忽略的点外部来源文件也要受控。供应商给的模型说明、第三方评测报告、客户提供的场景约束这些进了你的证据链就得登记来源、接收日期和版本。否则一旦对方更新了文档你手里的那份立刻失去效力而你连什么时候失效的都不知道。4.3 用一段脚本做条款覆盖度自查体系文件写到一定规模人工核对条款覆盖度就不现实了。我一般的做法是维护一份条款清单把每条条款和证据编号关联起来然后用脚本扫一遍空项和过期项。import csv from datetime import date # clauses.csv 三列clause(条款号), evidence(证据编号可空), expiry(证据失效日期可空) def audit(pathclauses.csv): today date.today() missing, expired, ok [], [], [] with open(path, newline, encodingutf-8) as f: for row in csv.DictReader(f): ev (row.get(evidence) or ).strip() exp (row.get(expiry) or ).strip() if not ev: missing.append(row[clause]) # 完全没有证据 continue if exp: y, m, d (int(x) for x in exp.split(-)) if date(y, m, d) today: expired.append((row[clause], ev)) # 有证据但已过期 continue ok.append(row[clause]) total len(missing) len(expired) ok print(f条款总数 {total}有证据 {len(ok)}缺证据 {len(missing)}证据过期 {len(expired)}) print(缺证据条款, , .join(missing) or 无) print(过期证据, expired or 无) if __name__ __main__: audit()这段代码的价值不在技术含量在于把“体系覆盖度”变成一个可以每周跑一次的数字。逻辑很直白逐行读条款清单证据编号为空就记缺失失效日期早于今天就记过期剩下的算通过。参数上唯一要调的是expiry的填写口径我的习惯是按证据类型给默认有效期评估报告 12 个月、培训记录 24 个月、审批签字跟随系统版本超过就自动进过期清单逼着你去复评。跑出来的结果直接对应整改动作缺证据的条款优先补因为这是硬伤证据过期的次之通常只需要复评一次并更新日期。这个脚本我一般挂在每周的例行检查里比等到内审前一周突击要轻松得多。5. 避坑草案落地时五个最容易返工的地方5.1 版本与依据类的两个坑把草案当认证依据。现象是有人拿着这份草案的条款号去跟客户或审核方确认“我们符合 42001”。原因是没注意到草案扉页那段声明——文件还在征求意见和表决阶段在正式发布前不能作为国际标准引用而且内容随时可能变化。解决方式很直接内部体系设计可以用草案做骨架对外表述一律改成“参照 42001 草案框架建立的管理体系”并在文件里标注所依据的草案版本和日期等正式版出来再做一次差异比对。我自己会额外留一份“条款变更跟踪表”记录哪些条款在草案里是这样写的避免以后翻旧账时说不清。拿其他体系的文件整体套用。现象是风险评估表、适用性声明、内审检查表全套沿用只换了标题。原因是高阶结构看起来一样就以为内容可以平移。实际翻车点集中在三处影响评估没有对应模板、数据资源没有被拆成五类、生命周期阶段跟自己的研发流程完全对不上。解决方式是做一次条款级差异比对把新增和改写的条款单独拉一张清单逐条确认有没有对应的模板和责任人其余通用条款再复用。这个比对花半天能省后面两周的返工。5.2 评估与证据类的两个坑影响评估写成性能报告。现象是提交上来的影响评估里全是准确率、F1、响应时间问到最后对谁有影响、影响多大答不上来。原因是团队把“评估”理解成技术评测没有建立“后果”这个视角。解决办法是换表按影响对象、影响类型、严重程度、可逆性、规模、残余判断重新设计模板并且要求每条高风险结论后面必须挂一条措施和一个责任人。模板换完还要做一次校准找两个已上线的系统按新表重做一遍看看能不能得出跟实际一致的结论不一致就说明字段定义还有歧义。证据只留结论不留过程。现象是每件事都能拿出一个“已完成”的说明但拿不出配置、日志、评审记录。原因是把体系当成写文档忽略了证据要能被追溯。最常见的三个断点数据集版本号和训练配置对不上、上线审批没有对应的评测报告、运行监控只有截图没有连续数据。解决办法是在每个阶段的准出条件里写死“必须留下什么”并且在风险登记表的evidence字段里强制填编号。我一般会在项目启动会上就把这条规则讲清楚后面补录的成本是当场记录的三倍以上。5.3 组织与执行类的一个坑角色职责写成部门名。现象是职责矩阵里写着“算法部负责模型风险”“合规部负责影响评估”真出事的时候两边都说不是自己的事。原因是把组织单元当成了责任人而体系要求的是可追溯的具体角色。解决办法是把每个控制项落到岗位上比如“模型风险评估由模型负责人编制、由独立评审人复核、由业务负责人批准”三个人三个动作缺一环就是不符合。同时把关切上报渠道Annex B 里明确提到的那条单独建起来允许一线人员绕过直属上级直接上报并且要有收到、处理、反馈的记录。这条渠道平时用不上但一旦出现模型上线后的严重问题它就是你的后悔药。6. 用草案跑一次内审演练差距分析的抽样与打分内审9.2在草案里要求建立审核方案很多人第一次做就卡在“从哪抽”。我的做法是三个维度交叉抽每个维度抽固定数量保证覆盖面。抽样维度抽什么建议数量检查重点按条款4 到 10 章各抽一条关键条款7 条有无对应输出物、日期是否在有效期内按系统范围声明里的 AI 系统2 个风险登记表、影响评估、生命周期证据是否齐全按证据风险登记表中等级为高的条目3 条措施是否落地、残余判断是否有签字按条款抽是为了看体系完整性按系统抽是为了看执行一致性按证据抽是为了看真实性。三个维度都过一遍基本能发现八成的实质问题。打分我不用百分制用四级符合、部分符合、不符合、不适用。打分之后不按分数排序按“影响乘以整改成本”排优先级。影响大、成本低的先改比如补一份数据卡、补一次影响评估复评影响大、成本高的单独列项比如重建生命周期阶段划分这种要单独立项排期不能塞进日常整改。部分符合的项最容易拖因为它“看起来有”实际缺关键要素我一般要求这类项必须写明缺哪一项要素避免整改时又变成补文字。差距分析做完要出一份清单每条包含条款号、现状、差距、整改动作、责任人、期限、验证方式。验证方式这一列别写“检查文件”写成具体动作比如“抽查最近一次上线评审的三份记录确认影响评估结论在审批之前”。从那以后我每次启动一个新的体系项目都会先花半天把条款清单和证据编号的映射搭起来哪怕当时一条证据都没有也要先把空位留出来。空位本身就是提醒比事后回忆哪条漏了靠谱得多。这套方法我在几个模拟项目上跑过返工次数明显下降。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/11/4 20:15:38 · 阅读 1.2k ISO/IEC 42001草案落地：AI管理体系与影响评估证据链
简介ISO/IEC DIS 42001:2022草案是国际标准化组织与国际电工委员会联合发布的《信息技术—人工智能—管理体系》国际标准草案面向AI产品负责人、合规与信息安全从业者、体系审核员及高校研究人员用于解决人工智能系统在组织治理、风险管控与合规认证方面缺乏统一依据的问题。文件为单个PDF压缩包约1.98MB完整保留草案封面、ICS分类号、前言、引言与目次结构属于投票征求意见阶段的原文版本。已有399人学习下载。内容围绕组织与管理职责划分、AI风险管理、数据质量与安全、系统访问控制、可持续演进五条主线提出要求并给出评估与认证的对应条款可支撑制造业、金融、医疗等场景的体系搭建。读者可据此梳理AI管理体系的条款脉络对照内部制度做差距分析或作为审核与培训的原始依据。1. 拿 27001 的体系文件改个抬头就交上去是我见过最快的翻车有个团队把信息安全管理体系的文件目录整体复制把“信息安全”全局替换成“人工智能”然后拿去参加内部评审。评审问到“你们做过 AI 系统影响评估吗”全场沉默。手上这份 ISO/IEC 42001 草案全称是信息技术—人工智能—管理体系2022 年 11 月 9 日开始投票、2023 年 2 月 1 日截止它确实复用了通用的高阶结构但在通用骨架之外单独补充了 AI 系统影响评估、数据资源、AI 系统生命周期这几项必须完成的内容。这份草案适合三类人被要求提交 AI 治理材料的团队负责人、要给模型上线做过程记录留存的算法工程师、接 AI 项目却没有过程资产的外包团队。提示一句草案就是草案可以做体系设计不能当认证依据。2. 条款骨架拆开看4 到 10 章各自要交出什么东西2.1 它为什么长成高阶结构的样子这份草案的正文从第 4 章到第 10 章用的是管理体系标准通用的高阶结构组织环境、领导作用、策划、支持、运行、绩效评价、改进。这个结构的好处是能和质量、信息安全那几条体系线整合到一套文件里不需要另开一套管理流程。坏处也很直接很多人看到熟悉的编号就以为内容也是熟悉的直接套模板。真正需要留意的是它在通用骨架里额外增加的内容。第 6 章策划里出现了三个并列动作AI 风险评估6.1.2、AI 风险处置6.1.3、AI 系统影响评估6.1.4。前两个在信息安全体系里也有对应条款第三个是新增的而且它评估的对象不是组织的信息资产是 AI 系统对个人、群体和社会造成的后果。这是整套文件里最容易被漏掉、也最容易被审计追问的一块。再看第 8 章运行8.2、8.3、8.4 又把这三件事重写了一遍。同一件事写两遍不是重复是刻意区分阶段第 6 章是“策划时怎么做、多久做一次、谁批准”第 8 章是“按策划真的执行了、结果落在哪”。我见过不止一个团队只做了第 6 章的文件第 8 章只有一句“按计划执行”被问到最近一次评估的日期和输出物时就说不出来。这种“有制度没有记录”的状态在体系审核里是最常见的失分点。还有 6.3 变更的策划单独占一节。AI 项目变更频率高换模型、换数据源、换供应商、改提示词策略都算草案要求变更前先判断对风险评估和影响评估的影响。这条如果没落地后面所有评估都会变成一次性工作做完就放进档案再也不更新。2.2 七章条款与交付物的对照把条款翻译成交付物是落地第一步。下面这张表是我自己项目里用的版本左列是条款中间是必须存在的输出右列是常见的“假交付”形态供你对照自查。条款应产出的东西常见的无效交付4.1 理解组织及其环境内外部因素清单含 AI 相关的技术、数据、供应链、舆情因素抄一段行业趋势4.2 相关方需求与期望相关方清单加需求转化记录只写“客户要求高质量”4.3 范围声明明确到 AI 系统、场景、地点、边界写成公司简介5.2 AI 方针一页纸含原则、红线、责任承诺八页套话6.1.2 AI 风险评估风险源、事件、后果、可能性、等级只列风险名称6.1.3 AI 风险处置处置措施与 Annex A 控制项的映射措施与控制项对不上6.1.4 影响评估对个人、群体、社会的影响判断与结论写成模型性能报告6.2 AI 目标可测量目标加达成计划“提升 AI 应用水平”7.2 能力岗位能力要求加培训记录只有签到表7.5 成文信息创建、更新、控制的规则目录里一堆无版本号的文档8.1 运行策划与控制运行准则、过程控制点只有流程图9.1 监视与测量指标定义、采集方式、分析结论只有指标名没有数据9.2 内部审核审核方案、检查表、不符合项一次会议纪要10.2 不符合与纠正不符合描述、原因分析、措施、验证只写“已整改”表格右列这些形态本质都是“有文件、无证据”。体系运行的核心不是文档数量是每个声称都能追到一份带日期、带责任人、带结论的记录。你在设计阶段就该按这个标准自检一遍不要等到内审才发现一半条款没有对应的实物。2.3 范围声明与相关方清单最容易写虚的两份文件范围声明4.3看起来只是写一段话实际决定了后面所有工作的边界。写得太宽比如“覆盖公司全部人工智能相关业务”等于给自己挖坑审核时随便挑一个边缘项目就能问倒你写得太窄只写“某推荐算法”又会漏掉支撑它的数据平台、标注团队和第三方模型供应商风险评估就会缺一块。我一般的写法是三层系统层列清楚纳入的 AI 系统或系统族场景层说明这些系统服务的业务场景和部署形态支撑层说明纳入的数据、工具、算力和人力范围以及明确排除的部分及排除理由。排除项一定要写理由比如“实验性研究项目不纳入因不对外提供服务另行按研发流程管理”。有理由的排除叫边界没理由的排除叫遗漏。相关方清单4.2的常见错误是把相关方写成客户名单。实际要识别的是“谁会被这个 AI 系统影响、谁对它提要求”。我通常分四类内部业务方与运维方、外部客户与最终用户、受系统输出间接影响的个人或群体、供应链上的数据与模型提供方。每一类后面要跟一条“期望转化为要求”的记录比如最终用户期望“输出可解释”转化成要求就是“高风险场景必须提供决策依据说明”再往下就能挂到 Annex A 的控制项和具体验收标准上。这两份文件加起来通常不到五页但它们是后面风险登记表、影响评估表、控制项适用性声明的输入。省这一步后面所有表格都得返工这就是典型的“图快反而慢”。3. Annex A 控制项与 Annex B 指南控制目标怎么挑才不被反问3.1 八组控制项与适用性声明Annex A 是规范性附录给的是参考控制目标和控制措施Annex B 是配套的实施指南逐组解释这些控制项该怎么实施。草案里 Annex B 的章节编号基本与 Annex A 对齐从 B.2 与 AI 相关的方针、B.3 内部组织、B.4 AI 系统的资源、B.5 评估 AI 系统影响、B.6 AI 系统生命周期一路铺下去B.4 下面还细分成资源文档化、数据资源、工具资源、系统与计算资源、人力资源五类。这个细分很有用它等于告诉你资源这块要准备五份不同的证据而不是一份“资源充足”的说明。把 Annex A 的控制项分组看大致落在这么几个方向上方向关注点典型证据方针AI 方针的制定、评审、与其他制度对齐方针文件加评审记录内部组织角色职责、关切上报渠道职责矩阵、上报记录资源数据、工具、算力、人力的文档化资源清单与来源说明影响评估影响识别、评估过程、结论影响评估报告生命周期各阶段准入准出、变更管理阶段评审记录数据来源、质量、偏差、授权数据卡与授权凭据利益相关方信息对外说明的准确性对外材料评审记录使用使用范围限制、滥用防范使用条款与技术限制适用性声明SoA是这份草案落地时最容易出问题的一份文件。做法本身不复杂逐个控制项写“适用或不适用、理由、实施状态、证据在哪”。真正的问题是很多人把“不适用”当成省事的捷径理由栏写“公司暂无此场景”。审核时对方只要举出一个反例整份声明就要重做。我的做法是反过来先默认全部适用然后对每个想标“不适用”的项要求提出人给出书面论证至少包含“该控制项针对的风险在本组织不存在或被其他机制完全覆盖”的说明。这样筛下来真正能标不适用的通常不超过五六项而且每一项都有经得起追问的理由。这个流程看着麻烦但比事后被逐条质疑要省事得多。3.2 AI 系统影响评估从“会不会出事”到可打分的表6.1.4 的 AI 系统影响评估是这份草案区别于其他管理体系标准的核心。它不是问“模型准不准”而是问“系统跑起来之后对人和群体产生什么后果”。这两件事经常被混为一谈最典型的表现是拿一份准确率、召回率的评测报告充当影响评估。下面是我实际在用的评估表字段按维度拆开维度字段取值示例影响对象个人、特定群体、社会某类用户群体影响类型隐私、公平性、自主性、人身安全、信息完整性公平性严重程度1 到 54发生可能性1 到 53可逆性可逆、部分可逆、不可逆部分可逆影响规模受影响人数区间万级现有缓解已实施的控制输出审核、人工复核残余判断可接受、需缓解、不可接受需缓解几个实操要点。第一影响类型不要只写“安全”要拆到具体后果上比如“推荐结果导致某类内容被系统性压低曝光”这种描述才能推导出控制措施。第二可逆性这一列很关键同样是中等严重程度可逆和不可逆的处理优先级差一个量级涉及人身安全、资格判定、资源分配的场景基本都落在不可逆那一侧。第三评估结论要能落到具体动作上“需缓解”后面必须跟一条措施、一个责任人、一个截止时间否则这张表就是归档材料。评估频率也要在文件里写死。草案的逻辑是策划阶段定规则、运行阶段执行所以你要在 6.1.4 里写清楚触发条件首次上线前必做、重大变更前必做、固定周期比如每半年复评、发生相关事件后追加。这四个触发条件写全了8.4 的执行记录才有依据。3.3 数据资源与生命周期证据链要留到哪一层Annex B 把资源拆成数据、工具、系统与计算、人力四类其中数据资源的文档化最容易被敷衍。很多团队的数据说明只有一句“数据来源合法合规”。这句话在体系审核里等于什么都没说。我一般要求每个进入训练或推理的数据集至少留这几项数据来源与采集方式、授权依据与有效期、覆盖人群与采集时间段、标注规则与标注人员管理方式、质量指标缺失率、重复率、标注一致性、偏差评估结论、保留期限与销毁方式、对外共享情况。这些内容写在一份数据卡里跟着数据集版本走。数据集换版本数据卡同步换版本两者版本号必须能对上。工具资源和系统与计算资源常被合并成一句“具备相应资源”。实际上这两类证据形式不一样工具资源要说明用了哪些框架、哪些第三方组件、许可证与漏洞跟踪机制系统与计算资源要说明训练和推理环境的隔离方式、算力配额、日志留存。第三方模型或 API 也要算进资源范围并且要有一份供应商评估记录写清楚对方提供了哪些说明材料、你验证了哪些。生命周期这块草案给的是一条从概念到退役的线。我不建议照抄阶段名称而是按自己团队真实的研发流程映射比如“需求与可行性—数据准备—训练与评测—上线评审—运行监控—变更—退役”。映射完之后每个阶段补两个东西准入条件进入这个阶段前必须有什么和准出证据离开这个阶段时留下什么。准出证据是最有价值的部分。举几个实际的数据准备阶段的准出是数据卡加授权凭据训练与评测阶段的准出是训练配置、数据集版本号、评测报告上线评审阶段的准出是影响评估结论加审批签字运行监控阶段的准出是监控指标的一段连续数据退役阶段的准出是模型与数据处置记录。把这些串起来就是一条能被抽查的证据链。血泪经验是别指望上线后再补训练配置和数据集版本号这类东西一旦丢了就找不回来模型重跑一遍结果也未必一致。4. 把条款变成台账风险登记表与文档化信息的三层结构4.1 风险登记表的字段怎么定风险登记表是整套体系的枢纽。它往上是 6.1.2 的输出往旁挂 Annex A 的控制项往下派生 8.2 和 8.3 的执行记录。字段设计得不好后面所有关联都会断。我用的结构大致是这样写成 YAML 便于版本管理# risk_register.yaml —— AI 风险登记表字段按项目实际情况裁剪 - id: RA-2024-011 # 唯一编号供处置记录与内审抽样引用 ai_system: 某内容分发系统 # 关联到范围声明中的系统标识 risk_source: 训练数据时效性不足 # 风险源不是风险本身 event: 模型对新出现的类别持续误判 # 可能发生的事件 consequence: 部分内容被错误降权创作者收益受损 # 后果落到人和业务 likelihood: 4 # 可能性1-5 impact: 3 # 影响程度1-5 level: 12 # 等级通常取乘积后映射到高/中/低 annex_a_control: [数据, 生命周期] # 映射到 Annex A 的控制方向 treatment: 建立数据新鲜度监控超过阈值触发重训 # 处置措施 owner: 算法组 # 责任人必须具体到角色 due: 2024-09-30 # 截止时间 residual: 中 # 处置后的残余风险判断 evidence: EV-2024-033 # 证据编号指向实际记录这份台账有几个细节值得说明。risk_source和event一定要分开写混在一起会导致措施失焦——风险源是“数据时效性不足”措施就该是监控数据新鲜度如果只写“模型效果下降”措施只能写成“优化模型”等于没写。annex_a_control这一列是把风险和 Annex A 接上的关键它让适用性声明里的每一项控制都能反向找到对应的风险内审时这条双向索引非常好用。evidence存编号而不是文件路径因为文件会移动、会改名编号不会。这张表还要配两条规则。第一条任何等级为高的风险处置措施必须落到具体版本或具体配置上不能停在“加强管理”。第二条残余风险判断要有人签字签字人不能是措施执行人本人。这两条写进程序文件能挡掉大部分“措施写了但没人认账”的情况。4.2 文档化信息的受控版本、状态与保留期限7.5 这一条容易被当成行政要求但它决定了你所有证据的可信度。我见过最离谱的情况是风险评估报告有四个文件名不同的版本内容互不相同谁也说不清哪份是最终版。这种状态下就算内容做得再好审核也没法采信。受控要做的事不复杂落到三个属性上版本号、状态、保留期限。版本号建议用“主版本.次版本”主版本变更是结论变了次版本变更是文字修订状态只有四种——草稿、评审中、已批准、已作废作废件不删除但标记清楚保留期限按用途定评估报告和审批记录一般要覆盖两个审核周期运行日志按系统和数据敏感度分别设定。再补一个容易忽略的点外部来源文件也要受控。供应商给的模型说明、第三方评测报告、客户提供的场景约束这些进了你的证据链就得登记来源、接收日期和版本。否则一旦对方更新了文档你手里的那份立刻失去效力而你连什么时候失效的都不知道。4.3 用一段脚本做条款覆盖度自查体系文件写到一定规模人工核对条款覆盖度就不现实了。我一般的做法是维护一份条款清单把每条条款和证据编号关联起来然后用脚本扫一遍空项和过期项。import csv from datetime import date # clauses.csv 三列clause(条款号), evidence(证据编号可空), expiry(证据失效日期可空) def audit(pathclauses.csv): today date.today() missing, expired, ok [], [], [] with open(path, newline, encodingutf-8) as f: for row in csv.DictReader(f): ev (row.get(evidence) or ).strip() exp (row.get(expiry) or ).strip() if not ev: missing.append(row[clause]) # 完全没有证据 continue if exp: y, m, d (int(x) for x in exp.split(-)) if date(y, m, d) today: expired.append((row[clause], ev)) # 有证据但已过期 continue ok.append(row[clause]) total len(missing) len(expired) ok print(f条款总数 {total}有证据 {len(ok)}缺证据 {len(missing)}证据过期 {len(expired)}) print(缺证据条款, , .join(missing) or 无) print(过期证据, expired or 无) if __name__ __main__: audit()这段代码的价值不在技术含量在于把“体系覆盖度”变成一个可以每周跑一次的数字。逻辑很直白逐行读条款清单证据编号为空就记缺失失效日期早于今天就记过期剩下的算通过。参数上唯一要调的是expiry的填写口径我的习惯是按证据类型给默认有效期评估报告 12 个月、培训记录 24 个月、审批签字跟随系统版本超过就自动进过期清单逼着你去复评。跑出来的结果直接对应整改动作缺证据的条款优先补因为这是硬伤证据过期的次之通常只需要复评一次并更新日期。这个脚本我一般挂在每周的例行检查里比等到内审前一周突击要轻松得多。5. 避坑草案落地时五个最容易返工的地方5.1 版本与依据类的两个坑把草案当认证依据。现象是有人拿着这份草案的条款号去跟客户或审核方确认“我们符合 42001”。原因是没注意到草案扉页那段声明——文件还在征求意见和表决阶段在正式发布前不能作为国际标准引用而且内容随时可能变化。解决方式很直接内部体系设计可以用草案做骨架对外表述一律改成“参照 42001 草案框架建立的管理体系”并在文件里标注所依据的草案版本和日期等正式版出来再做一次差异比对。我自己会额外留一份“条款变更跟踪表”记录哪些条款在草案里是这样写的避免以后翻旧账时说不清。拿其他体系的文件整体套用。现象是风险评估表、适用性声明、内审检查表全套沿用只换了标题。原因是高阶结构看起来一样就以为内容可以平移。实际翻车点集中在三处影响评估没有对应模板、数据资源没有被拆成五类、生命周期阶段跟自己的研发流程完全对不上。解决方式是做一次条款级差异比对把新增和改写的条款单独拉一张清单逐条确认有没有对应的模板和责任人其余通用条款再复用。这个比对花半天能省后面两周的返工。5.2 评估与证据类的两个坑影响评估写成性能报告。现象是提交上来的影响评估里全是准确率、F1、响应时间问到最后对谁有影响、影响多大答不上来。原因是团队把“评估”理解成技术评测没有建立“后果”这个视角。解决办法是换表按影响对象、影响类型、严重程度、可逆性、规模、残余判断重新设计模板并且要求每条高风险结论后面必须挂一条措施和一个责任人。模板换完还要做一次校准找两个已上线的系统按新表重做一遍看看能不能得出跟实际一致的结论不一致就说明字段定义还有歧义。证据只留结论不留过程。现象是每件事都能拿出一个“已完成”的说明但拿不出配置、日志、评审记录。原因是把体系当成写文档忽略了证据要能被追溯。最常见的三个断点数据集版本号和训练配置对不上、上线审批没有对应的评测报告、运行监控只有截图没有连续数据。解决办法是在每个阶段的准出条件里写死“必须留下什么”并且在风险登记表的evidence字段里强制填编号。我一般会在项目启动会上就把这条规则讲清楚后面补录的成本是当场记录的三倍以上。5.3 组织与执行类的一个坑角色职责写成部门名。现象是职责矩阵里写着“算法部负责模型风险”“合规部负责影响评估”真出事的时候两边都说不是自己的事。原因是把组织单元当成了责任人而体系要求的是可追溯的具体角色。解决办法是把每个控制项落到岗位上比如“模型风险评估由模型负责人编制、由独立评审人复核、由业务负责人批准”三个人三个动作缺一环就是不符合。同时把关切上报渠道Annex B 里明确提到的那条单独建起来允许一线人员绕过直属上级直接上报并且要有收到、处理、反馈的记录。这条渠道平时用不上但一旦出现模型上线后的严重问题它就是你的后悔药。6. 用草案跑一次内审演练差距分析的抽样与打分内审9.2在草案里要求建立审核方案很多人第一次做就卡在“从哪抽”。我的做法是三个维度交叉抽每个维度抽固定数量保证覆盖面。抽样维度抽什么建议数量检查重点按条款4 到 10 章各抽一条关键条款7 条有无对应输出物、日期是否在有效期内按系统范围声明里的 AI 系统2 个风险登记表、影响评估、生命周期证据是否齐全按证据风险登记表中等级为高的条目3 条措施是否落地、残余判断是否有签字按条款抽是为了看体系完整性按系统抽是为了看执行一致性按证据抽是为了看真实性。三个维度都过一遍基本能发现八成的实质问题。打分我不用百分制用四级符合、部分符合、不符合、不适用。打分之后不按分数排序按“影响乘以整改成本”排优先级。影响大、成本低的先改比如补一份数据卡、补一次影响评估复评影响大、成本高的单独列项比如重建生命周期阶段划分这种要单独立项排期不能塞进日常整改。部分符合的项最容易拖因为它“看起来有”实际缺关键要素我一般要求这类项必须写明缺哪一项要素避免整改时又变成补文字。差距分析做完要出一份清单每条包含条款号、现状、差距、整改动作、责任人、期限、验证方式。验证方式这一列别写“检查文件”写成具体动作比如“抽查最近一次上线评审的三份记录确认影响评估结论在审批之前”。从那以后我每次启动一个新的体系项目都会先花半天把条款清单和证据编号的映射搭起来哪怕当时一条证据都没有也要先把空位留出来。空位本身就是提醒比事后回忆哪条漏了靠谱得多。这套方法我在几个模拟项目上跑过返工次数明显下降。希望帮到你。本文还有配套的精品资源点击获取