ISO/IEC 42001落地：AI管理体系范围、风险评估与内审

简介：ISO/IEC 42001:2023标准原文面向人工智能合规与治理场景，为组织建立、运行并持续改进人工智能管理体系（AIMS）提供统一框架，适合信息安全管理人员、AI研发团队成员、企业决策层以及质量管理体系建设者参考。压缩包共1个PDF文件，约1.18MB，正文按管理体系条款展开，系统覆盖组织背景与相关方需求识别、治理架构、风险管理、运行支持、绩效评价和持续改进，附录还给出参考控制目标、实施指南及风险评估方法，便于按条款检索。已有454人学习，说明其在AI治理与合规领域具有一定关注度。读者可据此梳理AIMS落地路径，明确角色职责与透明度要求，结合风险预防措施提升内部运作效率，并对照标准条款搭建政策与流程文件，为负责任地应用AI技术、兼顾合规性与预期收益提供可操作的参考依据。

1. 客户安全评审扔来一张表，你手里只有模型卡

上一季度，某公司的智能客服准备上线，客户的安全评审发来一份问卷，其中一栏写着：“请提供贵方人工智能管理体系的范围声明与风险评估记录。”团队翻遍资料库，能拿出来的只有模型卡、一份隐私政策和几页提示词规范，风险评估是散的，范围更是没人写过。这类场面在 2024 年之后越来越常见，而 ISO/IEC 42001:2023 就是补这块的材料——第一版，2023 年 12 月发布，正文 10 章加 4 个附录，把“人工智能管理体系”（AIMS）拆成可审计、可留证的条款。它不教你训模型，管的是你有没有把 AI 的风险、职责、证据链组织成一套能被人查的东西。适合三类人：要给客户交体系材料的 AI 产品负责人、要把 AI 塞进既有质量与信息安全体系的质量岗、以及想给项目留后路的算法负责人。

2. 拆骨架：10 章正文和 4 个附录各自管什么

拿到这份 PDF 从第 1 页顺读，读到术语定义基本就困了。更省时间的读法是先看目录，把 10 章按“谁在什么节点要交出什么”贴到自己的研发流程上，再回头补细节。第 4 章到第 10 章其实是一条完整的 PDCA 主线：4 到 6 章是策划，7 到 8 章是支持与运行，9 章是检查，10 章是改进。理解这条主线之后，你会发现条款不是十个并列的清单，而是一个环，每一环都在为下一环产出输入。

2.1 正文 10 章对应到证据清单

先给一张对照表，把条款、主题、要留下的证据和常见责任人放在一起。做差距分析时直接拿这张表逐行打勾，比对着目录空想有效得多。

第一次读最容易绕晕的是 6.1 和 8.2/8.3/8.4 的关系。它们不是两套动作，而是同一套动作在两个时点的执行：规划期做首次评估，运行期按触发条件（新系统、用途变更、重大数据变更、事件发生后）再跑一遍。写文件时可以把模板做成一份，只区分“首次评估”和“运行期复核”两个入口，避免维护两套表格最后对不上。

2.2 Annex A/B 是规范性，C/D 是资料性

四个附录的性质不一样，用错顺序会浪费很多时间。

规范性和资料性的差别很实际：Annex A 和 Annex B 是审核时会被对着问的，Annex C 和 Annex D 是帮你把事想全的，引用时可以写“参考”，但不能拿它当合规依据。实操顺序我一般是这样：先读 4 到 10 章把骨架立住，再用 Annex A 对照现状找差距，差距项去 Annex B 找实施细节，识别风险时用 Annex C 的风险源清单补盲区。反过来先啃 Annex B，没有上下文，读到第十条就开始机械翻页了。

2.3 范围声明：一句话写错，后面全白做

4.3 要求确定 AIMS 的边界和适用性，这份输出通常叫范围声明。它看起来只是一段话，实际上决定了后面所有证据的有效性。范围写太大，审核时无法界定覆盖程度；写太小，客户会怀疑你在规避。合格的写法至少要包含五个字段：

1. 组织单元：哪几个部门、哪条产品线在范围内。
2. AI 系统清单：具体到产品或系统名称，不要写“所有 AI 相关系统”。
3. 生命周期阶段：开发、提供、使用三个阶段覆盖了哪几个。
4. 物理与逻辑边界：含不含云环境、含不含外包团队。
5. 接口与依赖：外采模型、第三方数据源、外部标注服务。

反例是“本公司所有人工智能相关活动”，这句话在评审现场基本等于没写。正例可以写成：“某公司智能客服产品线，覆盖模型训练、部署、线上运营三个阶段，包含外采的语音识别组件，不含内部研发使用的代码补全工具。”边界一清二楚，后面做风险评估时也知道该问谁。

提示：范围声明不是一次写完就锁死的文件，业务变化时要走变更策划（6.3），并在管理评审里过一遍。

2.4 AI 方针写到什么颗粒度才够用

5.2 要求最高管理者建立 AI 方针。很多团队写成价值观口号，诸如“负责任地使用人工智能”，这种话没法验证。方针至少要能回答四个问题：AI 用来做什么、明确不做什么、谁对什么负责、出了事走什么通道。把它拆成可验证的表述，比如“不将模型用于对个人进行自动化的高风险决策，除非经过影响评估并获得指定负责人批准”，这句话就能在流程里设卡。方针还必须与组织性质匹配，一家做工业质检的公司和一家做内容推荐的公司，方针里的禁用场景不可能一样，抄模板是行不通的。

3. 风险评估三件套：三张表别混成一张

6.1 下面挂着三个东西：AI 风险评估（6.1.2）、AI 风险处置（6.1.3）、AI 系统影响评估（6.1.4）。这是全文最容易被做歪的地方。我见过不少团队把三者合成一张 Excel，列名从“风险描述”一路加到“社会影响”，结果内审时被追问“影响评估的独立结论在哪”，当场卡住。三个评估回答的是三个不同的问题，输入输出和责任人都不同，合表省事但会丢掉可审计性。

3.1 三者的区别与触发条件

关键差异在最后一行。风险处置可以和技术团队一起做，影响评估最好由不直接对上线指标负责的人主持，否则很容易写成“风险已识别、影响可接受”的自我确认。规模不大的团队没法配专职评估人，至少让质量岗或法务岗签字，把独立性留在流程里。

3.2 风险登记表：字段、评分与阈值

一张能用的风险登记表，字段比格式重要。下面这套字段是我见过的版本里比较经得起追问的：

风险描述写成因果句是硬要求。“数据风险”这种写法在评审时一定会被追问到底指什么；写成“由于训练数据未做去标识处理，导致用户身份可被反推”，责任人和措施自然就出来了。评分不需要复杂模型，1 到 5 的乘法够用，但每一档要有文字锚点，比如影响程度 5 定义为“可能导致人身安全损害或大规模权益受损”，否则不同人打分能差出两档。

阈值策略建议直接写进程序文件，避免每次开会争论：

注意：阈值表一旦发布就按它执行，临时“这次特殊”的次数多了，整张表就失去约束力。

3.3 影响评估单独走：个体、群体、社会三层

影响评估最容易写成风险复述。区别在于视角：风险评估问“我们会受到什么损失”，影响评估问“系统之外的人会受到什么影响”。实操时可以按三层展开。个体层看权利与自主性，比如是否在不知情的情况下被评分、是否有申诉渠道；群体层看差别对待，比如某类口音、某类书写习惯的用户识别率是否显著偏低；社会层看信息生态与信任，比如生成内容是否可能被大规模误用。

触发条件要写死：新系统首次上线、用途发生实质变更、部署到新的人群或地区、发生重大事件之后。评估方法不必追求复杂，访谈加文档审查加小样本测试就能撑住大部分场景，关键是留下“谁评的、依据什么、结论是什么、谁批准”这四项。

3.4 处置四条路与选择准则

规避、降低、转移、接受，四条路没有优劣，只有适用。规避意味着砍功能或换方案，代价最大但最彻底；降低是加控制措施，最常见；转移在 AI 场景里主要是合同条款和保险，不能把合规责任转出去；接受必须带授权和期限，且只适用于低等级风险。选择时按这个顺序问自己：这个功能非做不可吗、能不能换更保守的实现、控制措施能不能在流程里卡住、接受的风险谁签字。四问走完还没结论，说明风险描述本身没写清楚。

4. 支持、运行与成文信息的最小闭环

体系落不下去，十有八九不是条款不理解，而是文件太多、流程太长、没人维护。这一章讲怎么用最少的文件撑住 7 章和 8 章的要求，再把 9 章和 10 章的检查与改进接上。原则只有一条：每份文件都要有人用，没人看的文件不如不建。

4.1 7.5 成文信息：必须有、可以合并、别硬造

标准要求保留的成文信息散在各章，实际做的时候可以合并，但不能缺项。下面这张清单可以直接当文件台账用：

“适用性说明”这份文件值得单独说。Annex A 的控制措施不是每条都适用，不适用要写理由，适用要写实现方式。这份说明做扎实，内审时能省掉一半问答。

4.2 8.1 运行策划：四个卡点把控制嵌进研发流程

运行控制不是另起一套流程，而是把控制点挂到已有的研发节点上。四个卡点最有效：

1. 需求评审：确认系统用途、受影响人群、是否触发影响评估。
2. 数据接入：确认数据来源合法性、去标识处理、标注质量控制。
3. 上线前：确认风险评估与处置完成、残余风险获批、监控指标就位。
4. 变更与退役：确认变更是否触发重评、下线后数据与模型如何处理。

每个卡点给一个明确的准入条件，比如上线前卡点的准入条件是“高风险项全部关闭或获批接受、影响评估报告已签署、监控看板已配置”。卡点不通过就不放行，这条规则要写进流程文件，否则第一次赶工期就会破例。

4.3 9.1 监视指标：选能采集的，别选好看的

指标选得漂亮但采集不到，等于没有。建议从体系运行的有效性出发，选五六项能自动或半自动取数的：

指标之外还要定义“什么情况算异常”。没有阈值，报表就只是数字。9.2 的内审和 9.3 的管理评审都需要这些数据作为输入，平时不采，评审时只能靠回忆。

4.4 10.2 不符合与纠正措施：闭环五步

不符合的来源很杂：内审发现、事件复盘、客户投诉、监控告警。处理路径统一成五步，记录字段固定下来，就不会出现“改了但没验证”的情况。

1. 开具：写清现象、条款依据、发现人、日期。
2. 遏制：先控制影响，比如暂停功能、回滚版本。
3. 原因分析：区分直接原因和体系原因，后者才是纠正措施要解决的。
4. 纠正：明确措施、责任人、完成期限。
5. 验证：由提出方或内审员确认有效性，关闭记录。

体系原因经常被跳过。比如一次数据泄露的直接原因是权限配置错误，体系原因可能是上线检查表里根本没有权限核验这一项。只改配置不改检查表，同类问题还会再来一次。

5. 落地避坑：五类高频翻车现场与纠正动作

这一章的五条都来自实际项目里反复出现的场面，不是理论推演。每条按现象、原因、解决写，能对上号的直接改。

5.1 范围写成“全公司 AI 活动”

现象：范围声明只有一句话，覆盖所有部门和所有系统。内审时审核员要求提供范围覆盖证明，团队拿不出，只能临时补材料。

原因：写范围的人把范围当成表态，觉得写得大显得重视，忽略了范围是用来界定证据边界的。

解决：按 2.3 的五个字段重写，把不纳入的部分明确写出来并给理由。范围缩小不丢人，界定不清才丢人。重写后同步更新风险登记表和系统台账，确保三份文件口径一致。

5.2 风险登记表只登记不联动

现象：表格填得很满，但迭代计划里找不到对应任务，上线检查也不看这张表。评审时被问“这条高风险最后怎么处理的”，答不上来。

原因：风险管理和研发流程是两张皮，风险 owner 没有排期权限，登记完就搁置。

解决：把高风险项转成研发任务单，编号互相引用；上线卡点加一条“高风险项状态核验”；风险复核日期到了自动提醒 owner。三件事做完，表才活起来。

5.3 影响评估写成风险复述

现象：影响评估报告里写的全是“可能造成数据泄露、可能影响用户体验”，和风险登记表高度重合，看不出对个人和群体的具体影响。

原因：评估人直接复用风险清单，没有换视角，也没有接触受影响方。

解决：按个体、群体、社会三层重写，每层至少给一个具体场景和一个判断依据；评估人里加入不直接对上线负责的岗位；结论必须回答“影响是否可接受、依据是什么、谁批准”。

5.4 第三方与客户关系条款漏审

现象：外采模型或标注服务上线后，才发现合同里没有数据使用限制条款，也没有安全事件通报时限。

原因：采购流程和 AI 体系流程没有打通，第三方管理被当成法务单独的事。

解决：在供应商准入清单里增加 AI 相关条目，包括数据用途限制、模型再训练禁止、事件通报时限、审计配合义务；把外采组件登记进依赖清单，纳入年度复核。Annex A 里第三方相关的控制措施，落地时基本都落在这张清单上。

5.5 内审变成查文档、管理评审没输入

现象：内审员逐份文件看格式，报告里全是“文件齐全”；管理评审会上没人拿得出绩效数据，最后变成工作汇报。

原因：内审员按文件清单审，而不是按过程审；9.1 的指标平时没采集，评审自然空。

解决：内审按过程抽样，每个过程至少抽三个实例，追到记录；内审报告按严重、一般、观察项分级；管理评审提前两周把指标报表和风险状态发给参会人，会上只讨论偏差和资源决定。这一条改起来最慢，但收益最大。

6. 进阶验证：用一张内审检查表把体系压一遍

体系文件写完只是开始，能不能扛住一次认真地问，要靠内审来验证。我习惯用一张压缩版的检查表，按过程而不是按条款组织，每项都要求给出证据而不是口头回答。

抽样方法上，高风险项全查，中低风险按项目抽三个；每个项目追到具体记录，不接受“我们一直都是这么做的”这类回答。发现分级建议分三档：严重不符合指体系性缺失或高风险失控，一般不符合指单点执行偏差，观察项指有隐患但尚未造成影响。分级的意义在于决定整改资源和时限，不分级的话所有问题都同等紧急，最后哪个都改不完。

还有一个容易被忽略的技巧：把内审发现按条款回填到第 2 章那张对照表里，你会很清楚哪个条款反复出问题。连续两次内审都栽在同一条款上，说明不是执行问题，是流程设计有问题，该动的是流程而不是再培训一遍。

从那以后我每次接这类体系活，都先让团队把范围声明和风险登记表各写一页，写不出来就说明还没想清楚，后面的文件都是补出来的，补出来的东西经不起问。这份 PDF 我建议放在本地，按条款号检索比翻网页版快得多，做差距分析时直接对着条款号建自己的证据台账。你要复现上面这套流程，先把原件存好，再从第 2 章那张表开始逐行打勾，一步一步来。希望帮到你。

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