欧盟 AI 法案第 10 条：训练数据要求

EU AI Act 于 2024 年 8 月生效时，多数解读集中在被禁止的 AI 实践（第 5 条）和高风险系统要求（附件 III）上。真正管住高风险 AI 系统所用数据的那一条，也就是第 10 条，反而少有人细看。这是个问题：第 10 条对训练数据、验证数据和测试数据提出了具体且可强制执行的要求，而多数企业 AI 团队目前都达不到。

高风险 AI 系统的完全适用截止日期是 2026 年 8 月 2 日。如果你正在法案覆盖的任一领域里构建 AI，留给你把数据治理实践调整到合规状态的时间窗口已经很窄了。

哪些系统受第 10 条约束

第 10 条适用于附件 III 所定义的“高风险 AI 系统”的提供者。附件 III 的清单涵盖以下场景中使用的 AI：

关键基础设施（公用事业、交通、供水）
教育与职业培训（入学资格、成绩评定）
就业与人力资源（招聘、晋升、工作管理、解聘）
基本服务（信用评分、保险风险、紧急服务调度）
执法（风险评估、测谎、证据可靠性判断）
移民与边境管控（风险评估、证件核验）
司法（辅助法院工作的 AI）
医疗器械（依据 EU MDR 被归类为医疗器械的 AI）

如果你所在的组织在上述任一领域开发或部署 AI，并把它投放到欧盟市场，第 10 条即适用。要注意的是，“提供者”也包括企业内部的开发团队：即便不对外销售 AI，在法案意义上同样是提供者。

如果一时判断不了自己的系统算不算高风险，欧盟委员会已发布相关指引；更稳妥的做法是，只要 AI 会对人作出或参与作出有实质后果的决定，就先按高风险对待。

第 10 条到底要求什么

第 10 条的标题是“数据与数据治理”，管的是整条数据链路，而不止于最终的训练集。

第 1 款：数据管理实践

提供者必须建立数据治理与管理实践，覆盖以下方面：

数据层面的设计选择（纳入什么、为什么纳入）
数据收集流程
相关的数据准备处理操作（清洗、打标、丰富、聚合、注释）
数据与 AI 系统预期用途之间的对应关系

这些实践必须在开发过程中就已落地，监管看的是当时的做法本身，而不是事后补写的一份说明。也就是说，你现在正在跑的数据准备流程，本身就已经落在监管范围内。

第 2 款：数据质量标准

训练、验证与测试数据集必须满足四项标准：

相关：数据必须与 AI 系统的预期用途相关
有代表性：数据必须足以代表系统实际运行时所处的条件
无错误：在可能的范围内做到，这要求主动开展质量评估，而不能默认数据本来就没问题
完整：就实现该用途所必需的特征或属性而言是完整的

“在可能的范围内”这个限定语有它的分量：它承认完美的数据并不存在。同时它也意味着，你必须能拿出证据，说明自己主动排查并处理过数据质量问题。

第 3 款：偏见审查

必须审查数据集是否存在可能影响 AI 系统输出、进而危及健康、安全或基本权利的偏见。一旦发现偏见就必须处理；无法完全消除的，则必须把残余偏见记录在案，并通过其他手段加以缓解。

这需要一套专门设计的审查流程；仅凭“我们的数据应该没什么偏见”这样的笼统判断，达不到条款的要求。审查所用的方法和得出的结果都必须形成文档。

第 4 款：敏感数据

在检测和纠正偏见确有必要时，第 10 条第 4 款允许收集和处理特殊类别的个人数据（即 GDPR 第 9 条所指的种族、健康、政治观点等数据），但须满足严格条件，包括采取适当的保障措施并遵守目的限制。

这一款常被误读为普遍放行敏感数据的使用。它给出的是一项范围很窄的例外，专用于偏见检测，并附带相应义务。

第 5 款：与运行环境的相关性

代表性要求一直延伸到 AI 实际运行所处的具体地理、行为和功能环境。训练数据必须反映部署现场的真实条件。

第 11 条：技术文档

第 10 条的数据要求还有配套条款。第 11 条要求提供者编制技术文档，证明其高风险 AI 系统符合法案；附件 IV 规定了这份文档必须包含哪些内容。

就数据治理而言，技术文档必须包含：

训练方法与所用数据的说明
训练数据的特征、局限与前提假设
已采用的数据治理与管理实践的说明
所使用的任何数据增强技术的记录
数据审查与质量评估流程的说明

这份文档必须在系统的整个生命周期内保持更新。训练数据有变动，或者模型重新训练之后，文档都要同步反映这些变化。

2026 年 8 月 2 日这个期限意味着：高风险 AI 系统的提供者要想持续合规，必须在该日期之前完成这份文档，并让它保持在最新状态。

“无错误”在实践中意味着什么

训练数据要“在可能的范围内无错误”，落到操作层面比字面读起来要吃力得多。它意味着：

主动的质量打分：你需要一套评估数据质量的方法，对完整性、一致性、准确性和相关性做系统化打分。

去重：重复记录会扭曲模型训练，本身也可能是数据质量出了问题的信号。流程中必须包含去重环节，并有成文的方法说明。

离群值审查：训练数据里的统计离群值，可能是真实存在、值得保留的边缘情况，也可能是需要剔除的数据错误。第 10 条要求你有意识地作出这个区分。

标注质量：在监督学习中，标注错误也是一种数据错误。标注流程的质量（标注者之间的一致性、标注规范、复核程序）同样属于第 10 条的合规范围。

审计记录要求

把第 10 条和第 11 条放在一起读，高风险 AI 系统的提供者必须有能力还原训练数据的历史：纳入了什么、排除了什么、做过哪些变换，以及为什么这样做。

这需要一条审计记录，把下列内容都记下来：

源文档及其来源出处
解析与抽取步骤
清洗与去重操作
脱敏与去标识化步骤
标注事件（谁在什么时间、依据哪一版规范标了什么）
增强操作（生成了哪些合成数据、用了什么参数）
导出操作（用于训练的是哪个数据集版本）

眼下多数数据准备流程都是把 Docling、Label Studio、Cleanlab 和一堆临时脚本拼在一起，彼此之间产生不了共享的血缘。Docling 解析完文件写进某个目录，Label Studio 做标注时与这些源文件之间没有结构化关联，清洗脚本跑完直接覆盖原文件。最后得到的训练数据集，没有可追溯的历史。

事后重建血缘，远比一开始就把它建进流程要难。到了 2026 年 8 月，事后重建这条路已经走不通，你需要的是当下就成立的合规状态。

达成第 10 条合规的实操步骤

第 1 步：给你的 AI 系统分类

先判断你的 AI 项目是否落入高风险类别。存在模糊地带时，一律先按高风险处理，直到有一份成文的风险评估说明它不属于高风险为止。

第 2 步：盘点现有的数据流程

把从原始数据到训练数据集的每一步都梳理出来，找出文档缺口：哪些环节没有日志、哪些工具不输出审计信息、哪些变换发生在无人记录的脚本里。

第 3 步：落实质量评估

为每个数据集定义质量标准，做系统化的质量打分，并把发现的问题和采取的处理措施都记录下来。

第 4 步：开展偏见审查

这一步要的是一次结构化审阅：把数据集的构成，与 AI 将要服务的人群对照起来看，而不必动用机器学习研究员。方法、发现和缓解措施都要写进文档。

第 5 步：建立审计日志

每一个变换步骤都必须产生一条日志：时间戳、操作人、动作、受影响的记录。日志必须留存，并且可以导出。

第 6 步：编写技术文档

把前面这些材料汇总成符合附件 IV 要求的文档，并在系统的整个生命周期内持续维护。

Ertas Data Suite 如何支撑第 10 条合规

Ertas Data Suite 从设计之初就把第 10 条合规当作一等要求。五个流程阶段（摄入、清洗、标注、增强、导出）中的每一次变换，都会连同时间戳和操作员 ID 一起记录下来。审计记录是结构化的导出产物，而不是一份纯文本日志，因此可以直接拿去写技术文档，不必再人工重排格式。

Clean 模块自动执行质量打分和去重，结果写入项目记录。Label 模块在单条记录的粒度上追踪标注事件。Export 模块在输出训练数据的同时生成数据集清单，记录版本历史和流程参数。

整条流程完全在本地部署环境中运行，数据不出域，因而也满足受监管行业在 EU AI Act 合规之外通常还要面对的数据主权要求。

对于要赶 2026 年 8 月这个期限的团队来说，真正要定的是：从一开始就把合规的数据治理内建进流程，还是试着把它硬套到既有的碎片化工具链上。