数据血缘现在是法律要求——你准备好了吗？

数据血缘——能够将任何训练数据从其最终形式通过每次转换追溯到其原始来源的能力——一直是最佳实践。根据欧盟 AI 法案，它现在是高风险 AI 系统的法律义务。

这不是理论上的担忧。如果监管机构询问特定训练示例如何最终出现在你的数据集中，你需要能够展示完整的链条：它来自哪里、如何被清洗、谁标注了它、通过了什么质量检查，以及所有这些发生的时间。

大多数企业数据管道无法做到这一点。

数据血缘在实践中意味着什么

AI 训练数据的数据血缘是数据点从源到训练就绪格式所经历的每次转换的记录历史。单个训练示例的完整血缘记录可能如下：

这就是完整血缘的样子。现在考虑大多数企业管道实际捕获了什么。

在典型的多工具数据管道中，血缘在工具之间的每个边界都会断裂：

摄取 → 清洗边界：Docling 从 PDF 中提取文本。输出进入 Python 脚本进行清洗。脚本处理文本但不记录每个清洗后记录来自哪个 Docling 输出文件，或清洗脚本更改了什么。

清洗 → 标注边界：清洗后的数据上传到 Label Studio。Label Studio 记录谁标注了什么，但不知道清洗历史。如果记录在清洗过程中被修改，该上下文会丢失。

标注 → 质量评分边界：标注数据从 Label Studio 导出并馈入 Cleanlab 进行质量评分。Cleanlab 标记问题，但解决这些问题的操作员在单独的流程中操作——解决方案没有链接回原始标注决策。

质量 → 导出边界：最终数据由 Python 脚本组装，选择满足质量阈值的记录。选择标准和具体包含/排除的记录由代码决定，但决策没有以监管机构可以审查的格式记录。

这些边界中的每一个都是血缘缺口。单独来看，它们似乎是小问题。总体而言，它们意味着你无法将训练示例追溯到其来源。

在欧盟 AI 法案之前，血缘缺口是质量问题。无法将数据问题追溯到来源的团队有更困难的调试会话。但没有法律后果。

根据第 10 条，数据治理实践必须覆盖完整的准备管道。根据第 30 条，技术文档必须包含有关数据来源、收集方法和准备方法的信息。这些条款共同要求你能证明你的训练数据是如何产生的——而不仅仅是断言它。

当市场监督机构要求你的技术文档时，"我们用 Python 脚本清洗了数据"不是答案。他们会要看日志。

血缘缺口不是由粗心的工程造成的。它们是由架构造成的。当你的管道由独立工具组成时，每个工具只知道自己的操作。没有工具有完整的管道视图，所以没有工具能提供完整的血缘。

你可以用自定义日志修补这个问题——编写一个包装器，在每个阶段记录输入和输出并存储在中央数据库中。但这种方法很脆弱：

为满足欧盟 AI 法案的血缘要求，你的管道架构需要：

当整个管道在单个系统中运行时，这从根本上更容易。像 Ertas Data Suite 这样的平台将血缘作为核心架构特性维护——每个阶段共享相同的日志基础设施，所以没有边界缺口。任何导出训练示例的血缘记录都会自动通过每次转换追溯到原始源文件。

如果你当前的管道存在血缘缺口，你有两个选择：

选项 A：在现有工具链上改造日志。 这可行但需要自定义工程、持续维护，以及接受跨工具血缘始终是近似的。

选项 B：迁移到原生处理血缘的统一管道。 前期努力更大，但永久消除了结构性问题。

无论如何，2026 年 8 月的截止日期意味着这个决策需要尽快做出。数据血缘不再是锦上添花——它是法律。