一、ISO/IEC 42001:2023 7.5 标准原文
7.5.1 总则：组织的人工智能管理体系应包括：a） 本标准要求的文件化信息；b） 组织确定的人工智能管理体系有效性所必需的文件化信息。
注：人工智能管理体系的文件化信息的范围可能因组织而异，原因如下：组织的规模及其活动、过程、产品和服务的类型；过程的复杂性及其相互作用；人的能力。
7.5.2 创建和更新文件化信息：在创建和更新文件化信息时，组织应确保适当的：标识和描述；形式和载体；评审和批准，以保持适宜性和充分性。
7.5.3 文件化信息的控制：人工智能管理体系和本标准要求的文件化信息应得到控制，以确保：a） 在需要的场合和时机，均可获得并适用；b） 予以妥善保护。为控制成文信息，适用时，组织应进行下列活动：分发、访问、检索和使用；储存和防护，包括保持可读性；变更控制；保留和处置。组织确定的人工智能管理体系策划和运行所需的外部来源的文件化信息进行适当识别和控制。
注：对成文信息的“访问”可能意味着仅允许查看记录信息，或者意味着允许查阅并授权修改。
二、条款解读说明
2.1 为什么文件化信息在AI管理体系里格外关键
人工智能管理体系的很多要求都依赖文件化信息来证明。例如，组织如何确定范围，如何做风险评估，如何选择控制，如何定义目标，如何分配职责，如何处理变更，如何开展验证确认，如何对用户提供说明，如何保留日志，如何复盘事件。如果这些信息没有被妥善记录、版本不清、来源不明、更新不及时，那么组织就很难证明自己的AI治理是真实存在且持续运行的。更重要的是，AI系统本身往往变化快、依赖多、链路长，很多关键判断如果没有留痕，几个月后连内部团队都可能说不清当时为什么这么做。
因此，7.5条在42001中既是“文档控制条款”，也是“治理证据条款”。它要求组织不仅保存标准明确要求的文件，还要保存自己认为对AIMS有效性必要的文件化信息。这一点很重要，因为AI治理的复杂性差异极大，不同组织需要保留的证据深度也不同。高影响AI系统显然需要更细致的风险、验证、沟通和运行记录，而低风险内部辅助应用可以适度简化。关键不在于文档数量，而在于是否足以支撑治理判断与责任追溯。
2.2 7.5条的核心要求可以分成三层
| 层次 | 标准要求 | 在AI治理中的含义 | 常见证据 |
|---|---|---|---|
| 需要什么文件 | 标准要求的文件 + 组织认为必要的文件 | 建立完整而不过度的AI治理证据范围 | 制度、流程、台账、记录、报告 |
| 如何创建和更新 | 标识、形式、载体、评审和批准 | 确保文件准确、适用、版本清楚 | 编号、版本、审批、发布日期 |
| 如何控制 | 访问、检索、保护、变更、保留和处置 | 确保信息在需要时可用、在不应暴露时受保护 | 权限、归档、版本记录、保留规则 |
2.3 AIMS中的文件化信息不只是制度文件，还包括运行证据
组织在实施7.5时，经常会把重点放在制度和程序文件上，但AI治理最能说明问题的往往是运行证据。比如：具体AI系统的风险评估记录、影响评估结果、模型验证确认结果、供应商评审记录、用户告知版本、事件日志、变更审批记录、管理评审纪要、目标监视数据、纠正措施闭环记录。这些内容如果没有被妥善控制，组织可能会有一套看上去很完整的制度，却无法证明制度是否真正应用到了具体系统和具体场景。
另外，AI管理体系还有一个特殊点，就是外部来源文件的重要性很高。第三方模型说明、供应商技术文档、外部法规要求、行业规则、客户协议、数据集许可条款等，都可能直接影响组织如何开发或使用AI系统。7.5.3特别强调外部来源文件也要适当识别和控制，正是因为这些外部材料往往会决定组织的责任边界，不能只存在某个人的邮箱或聊天记录里。
三、实施要点
3.1 先定义AIMS需要哪些文件化信息
- 组织应梳理标准明确要求保留的文件，并补充本组织认为对AIMS有效运行必要的文件。
- 建议至少包括方针、范围、目标、风险评估、影响评估、适用性声明、控制实施记录、变更记录、审核和评审记录等。
- 文件范围不清，后续控制就会陷入随意。
3.2 统一文件标识、版本和审批规则
- 所有关键文件都应有清晰标题、版本、日期、责任人和审批状态，避免同名不同版、旧版误用和来源不明。
- 对AI系统说明、风险记录和用户告知等高频变更内容，版本控制尤为重要。
- 版本可追溯是审核和事件追查时最核心的基础能力之一。
3.3 把外部来源文件纳入受控范围
- 不要只控制内部制度文件。供应商文档、外部法规、客户要求、数据许可条件和技术指南，只要会影响AIMS运行，都应纳入识别和更新机制。
- 应明确谁负责收集、评审、更新和归档这些文件。
- 外部文件控制不到位，往往会导致组织依据过期或错误信息做决策。
3.4 兼顾可用性与保护性
- 真正有效的文件控制不是把文件锁起来，而是确保需要的人在需要时能用到正确版本，同时未经授权的人不能任意查看或修改。
- 对不同类型文件可设置不同权限，例如制度可广泛查看，风险评估和日志记录则应限制访问。
- 按需可得、按权访问是7.5控制设计的核心。
3.5 建立保留和处置规则，避免信息失控
- 不同文件应依据法律、合同、业务和审核要求设定保留期限，过期后按规则归档或处置。
- 事件日志、影响评估、供应商文件和用户告知记录通常需要较长保留期。
- 没有保留规则会导致要么找不到关键证据，要么积累大量无效旧版本增加风险。
四、常用工具与实施方法
| 工具/方法 | 适用目的 | 实施建议 | 输出成果 |
|---|---|---|---|
| 文件清单与主索引 | 定义AIMS文件范围 | 区分制度文件、运行记录和外部文件 | 主控清单 |
| 版本控制规则 | 防止错用旧版文件 | 统一编号、审批和发布规则 | 版本管理规范 |
| 权限分级管理 | 兼顾可用性和保护性 | 按文件敏感度设置查看和修改权限 | 访问权限表 |
| 外部文件监控表 | 管理法规、供应商和客户来源文件 | 指定责任人和更新频次 | 外部文件台账 |
| 保留与处置规则 | 明确保存周期和归档方式 | 与法律、合同和事件要求对齐 | 保留计划 |
五、典型案例
案例一：风险评估做过，但半年后谁也找不到最终版本
- 背景：某项目上线前完成了风险评估和验证确认。
- 问题：审核时团队只能找到多个草稿版本，无法确认哪个是批准后的最终版本。
- 改进：组织建立统一版本规则和主索引，对关键文件实行受控发布。
- 结果：后续评估记录可追溯性显著提升。
案例二：供应商文档在个人邮箱里，离职后彻底丢失
- 背景：某AI服务的重要接口说明和限制条件长期由项目经理个人保存。
- 问题：项目经理离职后，团队无法确认系统使用限制和日志能力。
- 改进：组织把供应商技术文件纳入外部文件台账和集中归档。
- 结果：第三方依赖信息不再依赖个人记忆。
案例三：对外用户说明更新了，内部客服仍在用旧版话术
- 背景：产品界面更新了AI使用说明，但客服知识库未同步。
- 问题：用户咨询时收到与界面不一致的解释。
- 改进：组织将用户告知材料纳入受控文件，并设置变更后联动更新要求。
- 结果：内外口径一致性明显提升。
六、成文信息管理要求
7.5条本身就是成文信息控制条款，因此组织应把“哪些文件需要控制、如何控制、如何证明控制有效”作为核心设计内容。对AI管理体系而言，文档控制的重点不仅是制度文件，更包括运行证据和外部来源文件。
| 建议文件或记录 | 关键内容 | 用途 |
|---|---|---|
| AIMS文件主清单 | 文件类别、编号、版本、责任人、状态 | 证明文件范围被识别和控制 |
| 文件创建和审批记录 | 作者、评审人、批准人、发布日期 | 证明文件适宜且充分 |
| 访问与权限控制记录 | 访问级别、修改权限、授权方式 | 证明文件被妥善保护 |
| 外部文件台账 | 法规、供应商文档、客户要求、更新责任 | 证明外部来源信息被识别和控制 |
| 保留与处置记录 | 保留期限、归档位置、作废与销毁方式 | 证明文件生命周期可追溯 |
七、常见误区及踩坑提醒
| 误区 | 问题表现 | 正确做法 |
|---|---|---|
| 只控制制度，不控制记录 | 运行证据散乱，无法证明体系真的执行 | 把评估、日志、变更和沟通记录纳入控制 |
| 版本标识不清 | 多个文件并行流转，现场不知道该用哪个 | 统一编号、版本和审批规则 |
| 外部文件不纳入受控范围 | 供应商文档、法规要求和客户条款无人维护 | 建立外部文件台账和更新责任 |
| 过度开放访问权限 | 敏感评估和日志可被任意查看或修改 | 按文件敏感度实施分级访问控制 |
| 没有保留和处置规则 | 关键证据丢失或旧版文档长期混用 | 设定保留期限和处置机制 |