為 AI 訓練資料建構 PII 去識別化管道

PII 去識別化管道是一種自動化資料處理工作流程，用於在文件進入 AI 訓練資料集或檢索增強生成（RAG）系統之前檢測並移除個人可識別資訊。之所以至關重要，是因為在未去識別化資料上訓練的 AI 模型可能記憶並重現 PII——這違反了 GDPR、HIPAA 和歐盟 AI 法規，給服務提供商和最終客戶都帶來法律風險。

PII 類型：哪些需要去識別化

並非所有 PII 都具有相同的監管權重。下表將常見 PII 類型對應到監管框架，並提供偵測必須涵蓋的具體範例。

特別是對於醫療資料，HIPAA 的安全港去識別化方法要求在資料可被視為去識別化之前，移除全部 18 類受保護健康資訊（PHI）。對於歐盟資料主體，GDPR 要求將個人資料刪除或假名化，使重新識別在實際上不可行。

逐步操作：建構 PII 去識別化管道

以下步驟直接使用 Ertas Data Suite 的節點名稱。每個步驟對應管道畫布中的一個或多個節點。

第一步：檔案匯入節點——載入來源文件

配置檔案匯入節點，指向你的來源文件目錄。對於企業專案，這通常是網路共享、客戶系統上的掛載磁碟機或本地資料夾。

關鍵設定：

• 來源路徑：包含原始文件的目錄
• 遞迴掃描：啟用以處理子目錄
• 檔案類型篩選器：設定為客戶檔案中存在的格式（PDF、DOCX、XLSX、TXT）
• 批次大小：根據可用記憶體進行配置——對於 PDF/Word 混合檔案，每批 500–1000 個文件是典型值

檔案匯入節點將文件排入下游處理佇列，並將檔案中繼資料（路徑、名稱、大小、類型）連同原始內容一起傳遞。

第二步：解析文件

根據類型將每個檔案路由到適當的解析器節點：

PDF 解析器（Docling 整合）——處理帶嵌入文字的原生 PDF 和透過 OCR 處理的掃描版 PDF。佈局感知擷取保留表格結構和多欄佈局。對於掃描文件，配置 OCR 信心度閾值——低於閾值的記錄將在第四步由品質評分器標記。

Word 解析器——從 .docx 檔案中擷取文字，在存在的情況下保留章節結構和頁首/頁尾內容。

Excel 解析器——處理 .xlsx 檔案，將試算表資料攤平為列級文字記錄。在 PII 偵測之前解析儲存格參照。

解析後，無論原始格式如何，所有文件都以結構化文字記錄的形式進入管道。

第三步：PII 去識別化節點——配置實體類型和去識別化方法

PII 去識別化節點是管道的核心。根據具體客戶專案進行配置：

要偵測的實體類型——從可用類別中選擇：

• EMAIL — 電子郵件地址
• PHONE — 電話號碼（美國和國際格式）
• SSN — 社會安全號碼
• ADDRESS — 街道地址
• MEDICAL_ID — 醫療記錄編號和患者識別碼
• FINANCIAL — 信用卡號、IBAN、銀行帳戶號碼
• PERSON_NAME — 全名（情境偵測）
• DATE_OF_BIRTH — 常見格式的出生日期
• IP_ADDRESS — IPv4 和 IPv6 位址

去識別化方法——三種選項：

• 遮罩：用標籤替換偵測到的 PII（例如 [EMAIL]、[PHONE]）。保留文件結構，清楚顯示去識別化發生的位置。推薦用於 token 數量重要的訓練資料。
• 替換：用合成佔位符替代偵測到的 PII（例如 user@example.com 變為 contact@company.net）。適用於下游模型需要真實感範例的情況。
• 刪除：完全刪除偵測到的 PII 及其周圍情境。最為激進；用於最高敏感度資料。

信心度閾值——設定最低偵測信心度（預設 0.85）。信心度低於此閾值的 PII 偵測記錄將被標記為人工審核，而不是自動去識別化。

第四步：品質評分器——驗證去識別化完整性

品質評分器節點對每份處理後的文件進行去識別化後檢查：

• 殘留 PII 掃描：以較低信心度閾值重新執行偵測，捕獲主去識別化可能遺漏的 PII
• 完整性評分：根據偵測信心度、覆蓋率和任何標記的異常，計算每個文件的品質評分（0–1.0）
• 標記閾值：低於配置評分（預設 0.90）的文件被路由到審核佇列，而不是匯出步驟

通過品質評分器的文件進入匯出環節。未通過的文件以其具體失敗原因記錄，並保留以供人工審核或重新處理。

這一步驟使你能夠向受監管行業的客戶聲明：「你的訓練資料集中的每份文件都經過了 PII 完整性驗證，任何未達到品質閾值的文件在納入之前均經過了審核。」

第五步：匯出乾淨的去識別化資料

根據下游用例選擇適當的匯出節點：

JSONL 匯出器——以大多數微調框架所需的格式每行輸出一個 JSON 物件。每條記錄包含去識別化後的文字、文件中繼資料以及第四步中分配的品質評分。

RAG 匯出器——輸出格式化為向量資料庫攝取的分塊去識別化文件。配置分塊大小（token 數）和重疊以符合檢索系統的要求。

兩個匯出節點都為每份文件追加一條處理日誌條目，記錄：來源檔案路徑、使用的解析器、偵測到的 PII 類型、應用的去識別化方法、品質評分和匯出時間戳記。這份日誌就是稽核追蹤。

對比：PII 去識別化方法

對受監管行業客戶而言，關鍵列是本地部署。雲端去識別化 API 在供應商伺服器上處理資料——對於受 HIPAA 保護的資料，這需要商業夥伴協議並引發資料駐留問題。對於歐盟資料主體的 PII，還會引發 GDPR 跨境傳輸問題。

本地執行消除了這兩個問題，資料永遠不會離開客戶的網路邊界。

合規考量

GDPR

根據 GDPR 第 4 條，個人資料包括與已識別或可識別自然人相關的任何資訊。第 25 條（資料保護設計原則）要求處理個人資料的系統從一開始就實施適當的技術措施。在資料進入訓練之前執行的 PII 去識別化管道是這一原則的直接實施。

GDPR 未指定特定的去識別化方法——遮罩、替換和刪除均可滿足要求，前提是結果是重新識別在合理上不可能實現。管道產生的稽核追蹤為監管機構的詢問提供了合規證據。

HIPAA

HIPAA 的安全港去識別化方法要求移除全部 18 類 PHI。在完全配置的情況下，PII 去識別化節點涵蓋全部 18 類。品質評分器的去識別化後檢查提供了 HIPAA 所要求的「無實際知識」標準——處理系統主動驗證閾值以上沒有殘留 PHI。

歐盟 AI 法規

歐盟 AI 法規第 10 條要求高風險 AI 系統的訓練資料受到適當的資料治理實務約束，包括對偏見和錯誤的審查。包含未去識別化 PII 的資料既代表錯誤（包含不應存在的資料），也代表偏見風險（模型可能學習到涉及個人特徵的關聯）。PII 去識別化是第 10 條下的直接合規行動。

常見問題

PII 去識別化發生在解析之前還是之後？

去識別化發生在解析之後。解析器（PDF 解析器、Word 解析器等）必須先從來源文件中擷取原始文字，PII 去識別化器才能偵測並移除敏感資訊。你無法對二進位 PDF 檔案執行去識別化——你是在該檔案擷取出的文字上執行去識別化。管道強制執行此順序：檔案匯入 → 解析器 → PII 去識別化 → 品質評分器 → 匯出器。

我可以自訂去識別化哪些 PII 類型嗎？

可以。PII 去識別化節點提供每種實體類型的開關。你可以根據客戶的監管背景啟用或停用個別類別（EMAIL、PHONE、SSN 等）。例如，金融服務客戶可能需要去識別化金融識別碼和社會安全號碼，但不需要去識別化 IP 位址。醫療客戶則需要全部 18 類 HIPAA PHI。配置儲存為管道範本的一部分，因此你可以為不同的監管背景維護特定於客戶的範本。

去識別化是否會記錄以供稽核？

是的。透過管道處理的每份文件都會產生一條日誌條目，記錄：來源檔案路徑、偵測到的 PII 類型、應用的去識別化方法、每次偵測的信心度評分、品質評分器分配的品質評分以及時間戳記。完整的管道執行日誌可匯出為 JSON 或 CSV。此日誌是合規稽核的主要證據材料。

支援掃描版 PDF 嗎？

支援。PDF 解析器節點對掃描文件使用 OCR。對於掃描版 PDF，首先應用 OCR 擷取機器可讀文字，然後流入 PII 去識別化器。OCR 擷取的文字帶有信心度評分；OCR 信心度低於閾值的文件由品質評分器標記。實際上，清晰的黑白掃描處理效果良好；低品質或大量標註的掃描可能需要對部分頁面進行人工審核。