資料來源現在是法律要求——您準備好了嗎？

資料來源——追蹤任何訓練資料從最終形式，通過每次轉換，回溯到原始來源的能力——一直是最佳實踐。在歐盟 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 月的截止日期意味著這個決定需要盡快做出。資料來源不再是可選功能——它是法律。