企业官网建设流程全解析

简介：ISO/IEC DIS 42001:2022（draft）是面向人工智能治理、合规与标准化研究人员的国际标准草案文本，适合AI产品负责人、信息安全与风险管理岗位、咨询顾问及企业架构师研读。文件围绕人工智能管理体系（AIMS）展开，涉及组织职责与治理结构、风险识别与处置、数据正确性与安全、访问控制与敏感信息保护、可持续发展，以及体系评估和认证准备等要点，可用于搭建企业AI治理框架、开展内部差距分析或对照条款梳理认证材料。压缩包内含1个PDF文件，约1.98MB，保留草案的目录、前言、术语与条款层级，便于按章节检索、引用和做批注。已有399人学习，可作为AI管理体系落地与合规审查的案头参考。

1. 反直觉：这份 AI 标准里，找不到一行关于模型指标的要求

第一次翻开 ISO/IEC DIS 42001 的人，多半带着一个错误预期：以为能在里面找到关于人工智能模型的准确率、鲁棒性、可解释性门槛。翻完目录会发现，一个数字都没有。它管的是组织——谁批准、谁评估、谁留证据、出了问题谁来复核。

这份草案的正式名字是「信息技术 — 人工智能 — 管理体系」，落脚点在「管理体系」四个字上。它把 AI 带来的不确定性，翻译成一组可被外部审计的组织动作：识别相关方、界定范围、评估风险、评估影响、保留成文信息、定期复评。模型好坏不在它的射程内；能不能说清楚「当初为什么这么决定、依据是什么、谁签的字」才是。技术团队常常觉得自己在写一堆文档，实际上是在补一条将来能救命的证据链。

2. 十个条款的骨架：为什么 AI 这种新东西能塞进一套通用模具

2.1 从条款 4 到条款 10，其实是一个 PDCA 环

把目录摊平看，真正承载要求的只有条款 4 到条款 10，前面的范围、规范性引用、术语定义三章是元数据，负责划定边界和统一语言。这七章的顺序是固定的：组织环境、领导作用、策划、支持、运行、绩效评价、改进。换成工程师熟悉的说法，就是先搞清楚「我们在什么位置、要达成什么」，再谈「怎么做、做的时候需要什么资源」，最后是「怎么证明做到了、没做到怎么修」。

这套顺序不是为 AI 单独发明的。管理体系类标准长期共用一套高阶结构，目的是让一个已经跑着质量管理、信息安全管理、业务连续性管理的组织，能把方针评审、内部审核、管理评审、纠正措施这些公共部件直接搬过来复用。所以草案里会大量出现「能力」「意识」「沟通」「成文信息」这种看起来跟人工智能毫无关系的词——它们服务的是体系的通用性，不是 AI 的特殊性。理解这一点，后面看到附录 A 里那些「角色职责」「资源文档化」的控制项，就不会觉得跑题。

反过来说，通用性也带来一个副作用：条款本身不会告诉你「AI 风险长什么样」。它只规定你必须有一台能产出风险结论的机器，至于原料从哪来、结论怎么算，得靠条款 6 和附录 B 去填。这是读这份草案最容易踩空的地方——把骨架当成了内容。

2.2 「shall」不是修辞：可审计性来自要求被写成二值判断

草案里的要求动词是分层的：shall 是必须，should 是建议，may 是可以。看目录时容易一带而过，但这个区分决定了整份文件能不能被用来做认证。以 6.1.2 的 AI 风险评估为例，它没有说「建议组织评估 AI 风险」，而是要求组织定义风险评估的过程、建立风险准则和可接受准则、并保留成文信息。这三件事都是可判定的：过程文件在不在、准则写没写、记录留没留。

这就是管理体系能被第三方审核的根本原因——它把「你的模型靠不靠谱」这种无法当场判定的问题，转换成了「你有没有一套可复现的判定过程」这种可以现场取证的问题。审核员不问模型的 F1 是多少，他问的是：这次评估用的准则和上次是不是同一套，结论是谁批的，批准人有没有这个权限。

我一般会把一条要求的证据理解为三个文件：

# 一条「要求」在审核视角下的最小证据包 requirement: "6.1.2 AI 风险评估" evidence: - id: PRC-AI-RA-01 # 过程文件：评估方法、风险准则、可接受阈值 type: procedure owner: "AI 治理负责人" # 对应 5.3 定义的角色，不能是空头衔 - id: REG-AI-RA-2024Q3 # 记录文件：本次识别出的风险源与结论 type: record fields: [风险源, 触发场景, 可能性, 影响, 等级, 处置项, 责任人] - id: APR-AI-RA-2024Q3 # 批准记录：谁认可了这套可接受准则 type: approval signer_role: "对风险有处置权限的角色"

三个文件的角色不一样。过程文件回答「方法是什么」，记录文件回答「这次算出了什么」，批准记录回答「谁认账」。缺第一个，结论无法复现；缺第二个，等于没做；缺第三个，责任悬空。参数上最容易被忽略的是 signer_role 这一项——很多团队填的是具体人名，但草案 5.3 要求的是角色与权限的对应关系，人走了角色还在，记录才站得住。

2.3 成文信息：黑匣子的反面

7.5 这一条看起来最枯燥，实际上是整个体系的存储层。它分三段：创建和更新时要保证标识、格式、评审和批准；控制时要保证在需要的地方可获得、适用、防泄密、完整、可分发、可留存；变更时要留下版本痕迹。

放在 AI 场景里，这条的价值会突然变得具体。模型会漂移，数据分布会变，训练脚本三个月后没人记得为什么那么写，当初拍板「这个偏差可以接受」的人也早就调岗了。真出了事要复盘，唯一可信的东西就是当时留下的记录。没有成文信息，整个体系就是个黑匣子——你能看到输入和输出，中间那一大段决策过程全凭回忆，而回忆在追责场景里一文不值。

这里有个实操上的分寸：草案要的是「必要的成文信息」，不是把所有东西都打印出来归档。判断标准是这条记录将来能不能支撑一个决定——能，就留；不能，就是负担。我在项目里通常按「会不会被问到」来筛：这个决定如果半年后被内审、被客户、被监管问到，我拿什么回答？拿得出来的才值得进受控库。

3. 风险与影响的双轨：为什么一份风险评估撑不起 AI 治理

3.1 AI 风险评估：主语是组织

6.1.2 要求建立 AI 风险评估过程，8.2 要求在运行中实际执行。这两条是同一个机制在策划期和运行期的两次落点。评估本身的思路和成熟的风险管理没有本质差别：识别风险源、判断可能性和影响、分级、给出处置方向、留下记录。真正需要抠的是「风险」这个词的主语——在 6.1.2 的语境下，它指的是对组织目标的偏离。

所以一份合格的 AI 风险登记表，条目大多长这样：模型输入校验缺失导致异常数据进入生产链路、供应商停止维护导致推理服务中断、训练数据授权链条不清导致后续无法商用。它们共同的锚点都是「组织会损失什么」。评分也围绕这个锚点展开，可能性乘影响，落到等级，再决定处置。

# 风险条目：主语是组织 risk_id: R-014 statement: "推理前置校验缺失，异常输入直接进入模型" affected: [交付承诺, 服务质量, 返工成本] likelihood: 3 impact: 4 treatment: "在推理入口增加字段校验与拒绝策略，异常样本落盘待查" owner: "推理服务负责人"

字段里没有「谁会因此受损」这一项，因为在这个视角下它不重要。一个组织完全可能算出一份「整体风险可接受」的结论，同时对某类人造成持续伤害——这不是评估做错了，是评估的坐标系本来就不覆盖那一块。

3.2 AI 系统影响评估：主语换成个人、群体和社会

6.1.4 和 8.4 单独立了一条线：AI 系统影响评估。附录 B.5.2 描述了它的流程形态——识别受影响的个人与群体、识别潜在影响、评估严重程度与发生条件、形成结论、决定是否需要处置，B.5.3 要求把过程文档化，B.5.4 和 B.5.5 分别指向对个体的影响和对社会层面的影响。

这条线和风险评估最大的区别不在流程，在坐标系。影响评估问的不是「组织会损失什么」，而是「如果这个系统按设计运行，谁的权利、机会或处境会被改变」。一个准确率很高的筛选系统，对组织来说是可控风险，对被筛掉的群体来说可能是系统性排斥。这两件事可以同时成立，所以两份记录必须分开建，字段也长得不一样。

# 影响条目：主语是受影响的人 impact_id: I-014 statement: "评分模型对某一人群的通过率系统性偏低" affected_parties: [申请者群体A, 人工复核岗] severity: 高 reversibility: "个体可申诉，但周期长、举证成本高" decision: "抽样复核 + 阈值区间调整 + 保留人工兜底通道"

对比两份记录能看出机制差异：风险条目问 likelihood 和 impact，影响条目问 severity 和 reversibility。前者关心「会不会发生、损失多大」，后者关心「发生了能不能挽回、谁承担」。可逆性这个字段在风险评估里几乎不出现，但在影响评估里是关键——不可逆的伤害和可逆的伤害，处置策略完全不同。

我一般会这么理解这条设计：风险评估是目标导向的，影响评估是权利导向的。前者防止组织亏钱，后者防止系统伤人。把两者合并，实际上等于取消了后者，因为组织的账本里天生没有「受影响方」这一栏。

3.3 两条轨道在处置环节汇合

分开评估不等于分开治理。6.1.3 的 AI 风险处置给出了经典的四选项：规避、降低、转移、接受。处置之后要算剩余风险，跟 6.1.2 定下的可接受准则比对，最后由 5.3 定义的有权限角色批准。影响评估的结论在这里会反向注入——如果某个影响被评为不可逆且严重，它通常会变成一条新的风险条目，逼着组织去动设计或者加约束。

时序上，这两条线在四个位置交汇。策划期做初评，形成基线；运行期按 8.2 和 8.4 定期复评；6.3 的变更策划要求任何影响体系的改动都要重新过一遍评估；9 的绩效评价则把评估结果当成输入，看处置措施到底有没有起作用。这个闭环里最容易断的是第三环——很多团队在系统上线后就不再触发评估，直到模型换了、数据源换了、业务场景扩了，登记表还停在半年前。

一个可操作的触发条件是：凡是改动会影响到「模型的输入分布」「输出被使用的决策场景」「受影响人群范围」这三者之一，就必须重新走评估。这三条比「重大变更」这种模糊表述好用得多，因为它能被具体的人当场判断。

4. 附录 A 的控制集：要求如何落成能查的证据

4.1 控制目标、控制、实施指南的三层结构

附录 A 是规范性的，A.1 总则交代了它的组织方式：控制按主题归到若干控制目标下，每条控制是一句可判断的陈述。附录 B 同样是规范性的，为每条控制提供实施指南，也就是「这条控制具体怎么做才叫做到」。两层合起来，形成「目标—控制—做法」的三段结构。

这个结构的妙处在于，它把「应该做什么」和「怎么证明做到了」拆开了。控制陈述保持抽象，好跨行业复用；实施指南给具体做法，好让不同规模的组织各自落地。B.2 管方针（含 AI 方针本身、与其他组织方针的一致性、方针的定期评审），B.3 管内部组织（AI 角色与职责、关切的报告渠道），B.4 管资源，B.5 管影响评估，B.6 管生命周期。每一组底下都挂着若干条具体控制。

做认证或者做自评时，绕不开的一步是逐条判断适用性，并把判断理由写下来。不适用的控制同样要写理由，而且理由要能被不懂你业务的第三方看懂。

# 控制适用性判断的最小记录 control: "A.x 数据质量要求" # 编号与名称以手中草案为准 applicable: true justification: "使用外部采购的标注数据，数据质量直接决定输出可靠性" implementation: - "数据接入环节校验字段完整性与分布偏移" - "每季度抽样复核标注一致性，偏差超阈值触发复标" evidence: [数据验收记录, 抽样复核报告] residual_risk: "低"

implementation 和 evidence 这两个字段是关键。前者说做法，后者说证据在哪。写了做法但指不出证据，等于没做；有证据但做法描述含糊，审核员没法判断这条证据是否覆盖了控制要求。控制编号在不同草案版本间可能调整，所以引用时最好带上控制名称，别只写编号。

4.2 资源与生命周期：控制点为什么卡在阶段边界

B.4 把 AI 系统的资源拆成四类：数据资源、工具资源、系统与计算资源、人力资源，并在 B.4.2 要求对资源做文档化。这个拆法很工程化，因为它对应的是实际会短缺的四样东西——没有好数据、没有顺手的工具链、没有算力、没有人。四类资源里任何一类断供，系统都会以某种方式退化，而退化往往不是突然崩掉，是慢慢变差，等你发现时已经积累了一批错误输出。

B.6 的生命周期视角则把这些控制点钉在阶段边界上。之所以钉在边界，是因为责任归属最容易在交接处断掉：需求阶段说「这个偏差可以接受」，设计阶段理解成「不用管偏差」，上线后监控阶段发现偏差扩大了，却没人认领。控制点卡在边界，本质是逼着每个阶段结束前留下一个明确的交接结论。

这张表不需要背，它的用处是当检查清单：任何一格空白，就是一个将来会被追问的缺口。

4.3 数据为什么被当成一等公民

B.4.3 单独给数据资源留了位置，这在传统 IT 管理体系里是少见的。原因很直接：对 AI 系统来说，数据不是燃料，是代码。模型结构几周就能换，数据管道和标注规范却会绑住团队好几年。数据一旦出错，模型再漂亮也是在错的基础上做优化。

所以数据的管法应该向代码看齐：有来源台账，有版本，有变更记录，有质量门禁。来源台账回答「这批数据授权到哪一步、能不能用于这个场景」；版本回答「三个月前那次效果回退，用的是哪一版数据」；变更记录回答「谁在什么时候改了标注规则」；质量门禁回答「什么样的数据不准进训练集」。这四样东西缺哪一样，出问题时都会变成玄学——你只能猜。

5. 落地排查：体系文件写得漂亮，审核为什么还是过不去

5.1 评估环节的两个坑

第一个坑：影响评估写成风险评估的复制件。现象是两份文档除了标题几乎一字不差，受影响方那一栏填的是「用户」。原因通常是起草时直接从风险模板复制，改了个名字就交。解决办法是把主键换掉——影响评估的每一条都要以「受影响方」开头，逐条写清楚如果系统按设计运行，这个群体会被改变什么、改变可不可逆、他们有没有申诉通道。写不出这三样，说明这条影响还没真正被识别。

第二个坑：风险登记表里清一色是技术风险。现象是清单上全是「模型精度不足」「数据泄露」「接口超时」，组织层面、供应链层面、人员能力层面的风险一条没有。原因多半是评估从工程视角出发，参与的人只有算法和开发。解决办法是先画业务链路图，从需求提出到输出被消费，逐环节问一句「这里的判断在多大程度上依赖模型输出」。依赖越重、人工兜底越薄的地方，就是风险该出现的地方，而这些位置往往不在代码里。

5.2 控制项与文档的两个坑

第三个坑：附录 A 的控制全部标「适用」。现象是适用性判断表一片「是」，看不到任何否定。原因很朴素——怕漏，索性全选。但全选等于没判断，审核时反而会被追问「这条控制在你的业务里对应什么」。解决办法是把「不适用」当成正常结论，写清楚为什么不适用，理由要具体到业务事实，而不是「本公司暂不涉及」。判断本身是有价值的产出，它证明你真的读过自己的业务。

第四个坑：方针版本失控。现象是审核现场能从三个人手里找出三个版本的 AI 方针，内容还不一致。原因是 7.5.3 的控制要求没落地，文件靠邮件和聊天工具传递。解决办法是设唯一受控库，所有对外引用只能指向库里那一份；变更留痕，旧版本明确标识作废但保留存档。这件事技术上毫无难度，难的是习惯——它需要有人在每次发文件时多花十秒钟去拿链接，而不是直接拖附件。

5.3 内审环节的一个坑：只审文档不审流程

第五个坑最隐蔽：内审记录通篇都是「文件齐全、格式规范、签字完整」。现象上无懈可击，但它审的是文档，不是体系。9.2 要的是符合性和有效性——有效性这三个字，文档检查是回答不了的。

解决办法是穿行测试：挑一个正在运行的 AI 功能，从需求提出一路追到上线后的监控记录，看每一步有没有对应证据，断在哪一环。具体走法可以按这个顺序：先要一份最近的变更记录，随机选一条；找到这次变更对应的风险评估和影响评估，看结论是否一致；再找上线批准记录，核对批准人是否有对应权限；最后调出上线后的监控数据，看有没有触发过告警、告警怎么处置的。中途任何一环拿不出东西，那里就是不符合项。这个方法一次能顶十次文档检查，因为它逼着体系回到真实业务上跑一遍。

提示：穿行测试选样时优先选「跨团队协作」的那条链路，责任断点几乎总在团队交界处，而不是在单个团队内部。

6. 设计取舍：为什么管 AI 选了「管理体系」而不是「技术验收单」

把这份草案读完，最值得琢磨的不是它写了什么，而是它选择不写什么。它不规定模型要多少参数、准确率要到多少、可解释性用什么方法，这些全留给技术标准和行业规范。它只规定一件事：组织必须有一台能持续产出判断、并且能被外部复核的机器。

这个取舍有它硬邦邦的理由。技术指标会过时，今天合理的阈值明年就是保守，写进国际标准等于给自己上锁；而组织的决策结构相对稳定，谁评估、谁批准、谁复核，这套东西换个模型照样成立。更关键的是可认证性：模型行为是概率性的，同一个输入两次调用结果可能不同，验收结论无法复现；但过程可以复现，同样的准则、同样的记录、同样的批准链，换个审核员来查，结论应该一致。管理体系之所以能发证书，靠的就是把不可复现的结果换成可复现的过程。

代价也很清楚。体系跑得漂亮、模型照样出问题，这种事一定会发生，因为过程合规和结果正确之间没有必然联系。更现实的风险是文档表演：所有记录都齐全，但没人为记录背后的判断负责，评估变成填空题，影响评估变成抄模板。这种体系在审核时能过，在真出事时一文不值。

我的判断法很简单：凡是「组织该不该做、谁来决定、留下什么证据」这类问题，交给体系；凡是「这个东西在特定场景下表现如何」这类问题，交给测试和技术标准。混在一起谈，两边都会失真。体系负责让错误在造成大规模后果之前被看见，技术负责让错误本身变少，谁也替代不了谁。

从那以后我每接一个 AI 相关的项目，都强制先把影响评估里的受影响方名单列出来，再谈模型和指标——名单列不出来，说明这个系统到底在影响谁还没想清楚，后面做什么都是碰运气。希望帮到你。

本文还有配套的精品资源，点击获取