AI

什么是文档义务的实际内容

第11条和附录IV规定了高风险系统的文档内容。该包涵盖了预期目的、设计选择、开发和测试历史、性能声明以及实际运行的风险管理措施。欧盟委员会将该法案总结为一个基于风险的框架，对高风险使用场景有更重的义务；在创建自定义模板之前，请从该框架开始（欧盟委员会 — AI法案）。

具有约束力的文本是EUR-Lex上的法规本身（欧盟条例2024/1689）。次要的博客和幻灯片只有在您可以指出支持每个声明的文章和附录行之后才有用。我将文档视为一个存储在版本控制下的活文件集，而不是在演示前一周导出的一次性PDF。

生命周期，而不是静态快照

如果模型发生变化、训练集被刷新或安全控制被重新连接，文档必须显示差异。更改记录、所有者和日期与第一次编写一样重要。当部署者询问"周二生产环境中哪个版本？"时，您应该从支持符合性的同一记录中回答，而不是从Slack线程中回答。

我们在称一个包为"ready"之前使用的步骤工作流

- 在创建文档树之前，确认系统是否在Article 6 / Annex III下属于高风险（或将被视为高风险）。如果不是高风险，请不要在销售副本中夸大Annex IV的完整性。 - 打开Annex IV，并为每个主题创建一个文件夹或票据：一般描述、设计规格、开发过程、数据、风险管理、测试、监控和人工监督。 - 为每个主题分配一个单一的所有者。没有名字的共享所有权会导致部分保持空白。 - 与产品和工程团队一起草拟。法律部门审查声明；工程师提供证据路径（配置、仪表盘、测试报告）。 - 将每个声明链接到一个文物：数据集摘要、日志记录方案、运行手册、风险注册表行。未链接的散文是有问题的。 - 将包与实时系统进行比较：日志记录配置是否与Article 12声明匹配？UI中的覆盖路径是否与Article 14文本匹配？ - 安排一个刷新触发器：模型版本更新、重要数据集更改、新部署类或严重事件近距离错过。

数据集摘要团队跳过（第10条）

第10条预计数据管理：训练、验证和测试数据应与预期目的相关且具有代表性，并检查偏差和缺陷，这些缺陷会损害系统影响的人的性能。审计员查找使用的数据和检查方法的摘要——而不是带有三个形容词的营销模型卡。

检查列表中的一行说“数据已审查”，但后面没有摘要，这将无法通过第一次严肃的审查。请写下摘要，以便新工程师可以回答：源域、时间窗口、已知偏差、排除规则以及标签的产生或审计方式。如果个人数据位于管道中，请保持您的GDPR角色和基础与您在其他地方描述处理方式的一致性；EDPB指导库是该语言的实用交叉检查（EDPB指南和最佳实践）。

检查列表 — 数据证据

- 训练/验证/测试集的清单，包括所有权和最后刷新日期 - 与预期目的相关的代表性说明（谁在范围内，谁不在范围内) - 偏差和错误检查方法 — 即使不完善 — 并声明残余风险 - 标记或注释过程，包括质量控制 - 数据集本身的保留和访问规则

人类监督设计（第14条）

第14条要求有意义的人类监督：允许人员监控、解释和在需要时覆盖输出的接口和控制。"人类保持在循环中"并不是一种机制。记录具体的覆盖路径、谁可以执行它、系统如何发出信号以提示人类干预以及当人类不可用时会发生什么。

在代理产品中，这通常意味着在采取重大行动之前进行硬停止（发布招聘短名单、发送信用决策、更新案件文件），而不是装饰性的批准按钮，它会在三秒后自动触发。将UI描述与运行时策略配对：哪些角色、哪些环境、哪些审计事件在覆盖时触发。

检查清单 - 监督证据

- 命名的监督角色和升级路径 - 实际暂停或逆转AI操作的UI或API控制 - 调用人类审查的信号/阈值 - 为监督人员提供的培训或运行手册 - 证明覆盖事件被记录的证据

上市后监控和日志记录（第12条和第72条）

第12条要求自动日志记录足以实现可追溯性，高风险系统的最短保留期为六个月。第72条增加了严重事件报告义务。团队记录模型并忘记运行时证据计划。将文档与实际日志配置相结合，使两者保持一致。

如果您已经运行GenAI可观测性，请将跨度和事件映射到上市后审查将要问的问题：哪个输入类，哪个模型版本，哪个策略决策，哪个人类操作。OpenTelemetry的GenAI约定是跨服务一致命名这些字段的实用工程参考（OpenTelemetry — GenAI可观测性）。该法案不要求OTel；一致的跟踪只是使第12条声明更容易辩护。

主题 | 条款/附录挂钩 | 常见错误 | 证据 一般描述和目的 | 第11条/附录IV | 市场推销而不是预期目的 | 目的声明+范围外使用 数据管理 | 第10条 | "数据集已审查"，但没有总结 | 数据集清单+偏见检查笔记 风险管理 | 第9条 | 去年静态风险PDF | 活动注册表+残余风险所有者 日志记录 | 第12条 | 声称日志，但保留时间<6个月 | 模式+保留配置截图/导出 人类监督 | 第14条 | 没有覆盖路径的口号 | UI/运行手册+角色矩阵 上市后/事件 | 第72条 | 没有严重事件播放手册 | 触发定义+报告联系人

文档包中常见的错误

- 为宣传册而写，而不是为附录。漂亮的图表从不引用附录IV主题，浪费审查时间。 - 复制US RMF工作表并将其重命名为"AI Act包"。NIST的AI风险管理框架（NIST AI RMF）对于流程词汇很有用，但它不能替代第11条/附录IV的内容。 - 记录昨天的模型。生产已经转移；包没有。 - 留空部署者指令。第13条对部署者的透明度很容易被忽略，当提供者团队只与自己交谈时。 - 将清单称为"认证"。这种语言夸大其词。清单可以减少遗漏风险；它们不能保证符合性。

决策标准：发布包还是继续草拟

当以下任何条件为真时，将包视为高风险发布的阻塞因素:

- 没有第三方可以遵循的数据集摘要 - 没有与真实控制相关的描述性人工监督机制 - 日志保留时间少于六个月，或者无法重构决策的日志 - 没有残余风险所有者的风险登记册 - 预期目的过于模糊，无法进行Annex III映射

您仍然可以发布内部原型，这些原型永远不会接触到EU高风险使用。请在书面形式中诚实地说明范围。模糊的"我们在精神上遵守"语言比明确的"尚未达到高风险/尚未进入EU市场"状态更糟。

什么这不是

此页面不是法律建议，不是通知机构的评估，也不是保证您的系统符合欧盟2024/1689条例。VendorVet不声称100%的覆盖率，不会发明客户的赢率，也不会取代律师或合格的评估人员。检查清单可以帮助您汇总和验证主题；但是，强制的义务仍然是由您的组织中合格的人员拥有并描述在第11条和第四附录中的文件。

结束

从官方期刊文本开始，将Annex IV主题映射到所有者，然后填补审计员首先打开的三个空白：数据、监督和日志记录。将包版本与系统一起保持一致。当模型或数据集移动时，将文档移动到同一版本中。对于所有这些上游的风险等级决策，请阅读我们关于EU AI Act风险等级的姊妹教程。

参考文献

- 条例（EU）2024/1689（EUR-Lex） - 欧洲委员会 — AI 法案 - EU AI 法案 — 实施时间表 - NIST AI 风险管理框架 - 欧洲数据保护委员会 — GDPR 指南和最佳实践 - OpenTelemetry — GenAI 可观测性

相关文章

- EU AI 法规风险等级：从业者入门指南 (2026) - 探索完整的 AI 微 SaaS 主题矩阵 →