企业官网建设流程全解析

简介：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.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 表示影响不可逆或波及面广。

打分不是目的，目的是让「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 = [f"A.{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(encoding="utf-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="", encoding="utf-8-sig") as fh: writer = csv.DictWriter(fh, fieldnames=fields) 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, file=sys.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 方针、方法论、职责权限）、证据类（风险评估与影响评估结果、监测记录、审核记录、事件与纠正措施）、结论类（管理评审输出、改进决定）。除此之外组织自己判断必要的，比如作业指导、模板、检查表。判断标准很朴素：如果这件事换个人做会做出不同结果，就该有文件；如果审核时无法复现当时的判断依据，就该有记录。

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 的纠正措施单，而是先改方法论——因为大面积趋同说明问题在准则，不在执行。这一点很多人绕不过来，结果开了一堆「加强培训」的纠正措施，第二年抽样还是同样结果。

我自己有个习惯：每次内审前先把探针清单打印出来，抽中的系统逐个对照，抽不到的系统也要能说出为什么没被抽中。这个动作坚持下来，最大的收益不是应付审核，而是能在模型悄悄换了一版、数据源悄悄多了一个的时候，第一时间发现评估没跟上。血泪经验是，那些最后出问题的系统，往往不是评估写得差的那个，而是从来没被抽中过的那个。从那以后我每次定内审方案，都强制给「上一年度未被抽中」的系统留出名额，哪怕它的风险等级是低。希望帮到你。

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