审计追踪缺口：大多数企业 AI 管道如何在不知情中未能满足 EU AI Act 合规要求

让大多数 AI 团队提供其训练数据的完整记录——数据从哪里来、做了什么处理、谁接触过这些数据、以及以什么形式用于训练模型——他们做不到。

不是因为他们疏忽大意。而是因为他们使用的工具不会生成这种记录。典型数据准备技术栈中的每个工具都在孤立运行，将输出写入一个共享文件夹，与之前的处理步骤没有任何关联。结果就是一个没有可追溯历史的训练数据集——没有数据血缘、没有审计追踪、没有影响数据的决策文档。

根据 EU AI Act 第10条，对于高风险 AI 系统，这不仅仅是一个技术缺陷，而是合规失败。根据 HIPAA，对于医疗 AI，这可能构成违反 Security Rule 审计控制要求。随着2026年8月2日的适用截止日期临近，许多企业 AI 团队将在最糟糕的时候发现这个问题。

---

AI 训练数据审计追踪必须包含的内容

在分析为什么大多数管道没有审计追踪之前，有必要明确合规审计追踪必须包含什么内容。

根据 EU AI Act 第10条以及第11条/附件IV的技术文档要求，高风险 AI 系统的数据治理文档必须使监管机构或审计员能够重建以下信息：

• 数据来源：训练文档来自哪里？什么系统、什么数据所有者、什么收集方法？
• 数据选择理由：为什么要包含这些数据？应用了什么标准来包含或排除记录？
• 预处理操作：在标注之前应用了哪些转换？解析、清理、去重、标准化——包括方法论和参数。
• 去标识化操作：检测到了哪些 PII 或敏感数据，删除了什么，使用什么方法，以及何时进行的？
• 标注事件：谁标注了每条记录，何时标注，使用了哪些标注指南？标注者间一致性的方法论是什么？
• 质量评估：应用了什么质量评分，结果是什么，以及如何处理低质量记录？
• 数据增强操作：是否生成了合成数据？使用什么模型、什么参数、从哪些源样本生成的？
• 数据集版本和导出：训练使用了哪个具体的数据集版本？其组成是什么？

根据 HIPAA 的 Security Rule (45 CFR §164.312(b))，审计控制必须记录和检查包含或使用电子 PHI 的信息系统中的活动。对于临床 AI 训练管道，这意味着对包含 PHI 的文档的每次访问和转换都需要有日志——谁、做了什么、什么时候、做了什么操作。

根据 GDPR 的问责原则（第5(2)条），控制者必须能够证明其遵守所有数据保护原则。对于 AI 训练，这包括证明处理具有合法基础、仅处理了必要的数据、以及数据按照声明的目的进行处理。

这些框架的综合要求汇聚到同一个操作需求：从源文档到导出数据集，对训练数据发生的一切进行结构化、完整且可导出的记录。

---

为什么大多数管道没有审计追踪

典型的企业 AI 数据准备管道不是一个单一系统。它是一系列独立工具的组合，每个工具解决一个问题，每个工具将输出写入共享文件系统，而且它们彼此之间互不感知。

一个代表性的管道如下所示：

Docling（或 Unstructured.io）解析源 PDF 并将 markdown 或 JSON 导出到一个目录。它不会记录解析了什么、做出了哪些解析决策（如何处理多列布局？从表格中提取了什么？），也不会记录源文档的来源信息。

清理脚本（自定义 Python、Cleanlab 或类似工具）读取解析后的文本，进行去重，并将清理后的记录写入另一个目录。它可能会生成一个摘要日志，但该日志通常是一个文本文件，存在于任何结构化记录之外，与特定源文档没有关联，也不以可查询的形式保存。

Label Studio 读取清理后的记录，让标注者进行标注。它维护自己的标注事件数据库，但该数据库与 Docling 输出中的源文档没有关联，不包含源文档和标注之间发生的转换信息，而且导出会剥离内部审计元数据。

数据增强脚本（Distilabel、自定义 LangChain 工作流、直接 API 调用）生成合成变体并将其写入目录。通常没有记录哪些源示例用于生成哪些合成记录。

导出脚本将标注记录和合成数据组合在一起，应用最终过滤，并写入可用于训练的 JSONL。每条记录的来源——它来自哪个源文档、经历了哪些转换、谁标注了它——在此过程中丢失了。

结果是：一个可以查询其内容但不能查询其历史的训练数据集。当监管机构询问"展示这条训练记录的审计追踪"时，没有答案。

---

共享血缘问题

核心问题不在于各个工具缺乏日志记录——大多数工具都有某种形式的内部活动日志。问题在于这些日志没有连接。没有共享标识符从源文档跟随记录经过解析、清理、标注、增强和导出。

没有共享标识符，你无法：

• 将训练记录追溯到其源文档
• 确定哪个标注者标注了特定记录
• 识别哪些记录是合成生成的，哪些来自真实文档
• 展示在源文档中检测到了哪些 PHI，并确认在记录被标注之前已将其删除
• 生成对特定记录执行的所有操作的完整时间线

这就是数据血缘——在管道中向前和向后追踪数据的能力。这是数据目录工具为结构化企业数据提供的功能。对于 AI 训练数据管道，数据血缘几乎完全缺失。

---

为什么改造血缘比从一开始构建更难

当团队意识到需要审计追踪时，本能反应通常是改造：为现有脚本添加日志、为现有工具添加监控、在现有管道之上构建数据目录。

这种方法总是遇到问题：

追溯性日志是不完整的：你可以为未来的运行添加日志，但无法重建已经处理过的训练数据的历史记录。如果你的模型已经训练完成，现在正面临监管审查，你需要的历史记录并不存在。

工具 API 不公开内部决策：Docling 的输出不会告诉你它如何处理特定的布局歧义。Label Studio 的导出不会告诉你为什么跳过了某条记录。你可以记录某个工具运行了；但无法记录它内部做出的决策。

跨工具身份未被维护：如果你想将 Label Studio 中的标注记录链接到 Docling 输出中的源文档再到去重脚本中的清理记录，你需要一个在摄入时分配并在每个工具中传播的公共标识符。大多数工具不接受或不保留外部标识符。

工作量随工具数量增加：管道中每增加一个工具就多一个集成点，需要自定义监控。一个7工具管道不是7倍的日志工作量——而是7个潜在的故障点，每个都需要自定义开发，任何一个失败都会产生缺口。

从一开始就将血缘构建到管道中——使用一个在所有阶段维护来源记录的单一系统——在架构上比任何改造方法都更简单，并且能产生更完整的记录。

---

合规审计追踪导出实际上是什么样的

对于 EU AI Act 或 HIPAA 合规性，有用的审计追踪不是文本日志。它是一种结构化记录，可以被查询、过滤，并以可读格式呈现给审计员。

对于最终训练数据集中的每条记录，审计追踪应该能够回答：

对于受 HIPAA 约束的临床 AI 管道，PHI/PII 行需要额外的详细信息：发现了哪些标识符、使用什么方法检测、删除了什么，以及确认输出记录不包含残留的 PHI。

在数据集层面，审计导出应包括：

• 按来源统计的记录总数
• 质量评分分布
• 标注覆盖率和标注者间一致性（如适用）
• 合成记录百分比和生成参数
• 按类别、标签或文档类型划分的数据集组成

这就是第11条/附件IV"数据治理文档"在实践中的样子——决策和操作的结构化记录，而不是叙述性描述。

---

2026年8月的紧迫性

高风险 AI 系统必须在2026年8月2日之前满足 EU AI Act 要求。对于已部署的系统（"现有系统"），有过渡期——但对于在适用日期之后开发或重大更新的系统，从部署时即要求合规。

受监管行业的大多数企业 AI 项目不是一次性部署。它们涉及持续的数据收集、定期重新训练、模型更新和扩展范围。每次训练数据集的更新都是一个新的处理事件，需要符合第10条的数据治理。每个重新训练的模型版本都需要更新第11条技术文档。

等到2026年8月才考虑审计追踪要求的组织将发现自己处于困境：要么无法证明合规（因为历史记录不存在），要么必须推迟部署，同时构建本应从一开始就构建的合规基础设施。

---

Ertas Data Suite 如何弥合审计追踪缺口

Ertas Data Suite 在所有五个管道阶段——摄入、清理、标注、增强、导出——维护统一的项目记录。每个操作都写入共享审计日志：源文档标识符在摄入时分配，并在每个后续操作中传播。没有工具间的交接、没有共享文件系统缺口、没有跨工具身份问题。

审计日志导出包括记录级血缘（从源到最终训练记录）、操作级条目（谁在什么时候做了什么）以及数据集级摘要（组成、质量指标、标注覆盖率）。导出格式为技术文档使用而结构化，而不是需要手动编制。

Clean 模块记录每个 PII/PHI 检测事件——发现了什么、删除了什么、使用什么方法。Label 模块在记录级别记录标注事件，包含标注者 ID 和时间戳。Augment 模块记录哪些源记录用于生成合成变体。Export 模块在训练数据旁边包含数据集清单。

对于面临2026年8月 EU AI Act 截止日期——或今天就面临 HIPAA 审计要求的团队——审计追踪不是以后再添加的功能。它是合规运营的先决条件。

---

相关阅读

• EU AI Act 第10条：对你的 AI 训练数据意味着什么 — 详细解析第10条的数据治理要求以及审计追踪必须记录的内容。
• 本地化 AI 数据准备：受监管行业合规指南 — 涵盖 GDPR、HIPAA、EU AI Act 和数据主权的完整合规概述。
• 什么是企业 AI 中的数据血缘？ — 数据血缘的工作原理、为什么它对 AI 训练管道很重要，以及如何实现。