建構符合GDPR的RAG管線：編輯、同意與向量資料庫中的被遺忘權

檢索增強生成已成為企業AI系統在專有資料上回答問題的預設架構。模式很簡單：將文件分塊，嵌入到向量儲存中，在查詢時擷取相關區塊，然後將其傳遞給語言模型進行合成。

問題在於這種模式是為準確性設計的，而非隱私。向量資料庫儲存來源文字的密集數值表示，這些表示可以編碼個人資料——姓名、電子郵件地址、醫療詳情、金融識別碼——以事後幾乎無法選擇性移除的方式。如果你正在建構一個涉及歐盟居民個人資料的RAG管線，你需要從一開始就建立一個符合GDPR的RAG管線，而不是事後補加的合規改造。

為什麼向量儲存會產生GDPR問題

GDPR賦予資料主體一系列權利，這些權利與大多數RAG系統的建構方式直接衝突。理解摩擦點是解決它們的第一步。

刪除權（第17條）。 當資料主體請求刪除其個人資料時，你必須能夠將其移除。在關聯式資料庫中，這意味著刪除列。在向量儲存中，個人資料與其他語義內容一起編碼在嵌入向量內。你無法從一個同時編碼了周圍段落含義的1536維向量中精確地移除一個人的姓名。你的選擇是刪除整個區塊（遺失有用的非個人上下文）或重新嵌入不含個人資料的區塊（大規模操作時成本高昂且容易出錯）。

同意追蹤（第6條）。 系統中的每筆個人資料都必須有合法的處理依據。向量儲存沒有同意記錄的原生概念。它們儲存向量和選擇性的中繼資料——沒有內建機制來記錄你為什麼被允許處理特定嵌入，或在之後使該許可無效。

目的限制（第5(1)(b)條）。 為某一目的收集的個人資料不能在未獲得額外同意的情況下被重新利用。當你將客戶支援對話記錄嵌入RAG系統用於產品改進時，你可能正在違反資料最初收集的目的。向量儲存不追蹤目的——它只是儲存嵌入。

儲存限制（第5(1)(e)條）。 個人資料不得保留超過必要的時間。向量儲存在設計上傾向於追加。大多數團隊從不刪除嵌入。沒有TTL機制，沒有自動過期，沒有內建的保留策略執行。

資料主體存取請求（第15條）。 當有人詢問你持有他們哪些個人資料時，你必須能夠回答。在向量儲存中搜尋「與張三相關的所有資料」不是一個簡單的查詢——嵌入是語義化的，不是結構化的。相似性搜尋可能會顯示相關區塊，但不能保證完整性。

建構帶有PII編輯的RAG的最佳方式

最有效的策略是確保個人資料從一開始就不進入向量儲存。如果你的嵌入不包含PII，那麼刪除請求就無需擦除任何內容，向量層的同意追蹤變得不必要，針對向量儲存的資料主體存取請求不會傳回任何個人資訊。

這就是「先編輯後嵌入」模式，它改變了整個管線的合規態勢。

架構概覽

管線有四個階段，編輯插入在擷取和嵌入之間。

階段1——文件擷取。 來源文件從任何來源進入管線——檔案上傳、API整合、資料庫匯出。此時，文件包含明文個人資料。你將原件儲存在受控的、存取受限的文件儲存中，並有完整的稽核日誌。

階段2——PII編輯。 在任何分塊或嵌入發生之前，每個文件都經過PII編輯層。該層識別並移除個人資料——姓名、地址、電話號碼、電子郵件地址、國家識別碼、金融帳號和健康資訊。編輯引擎將每個識別的實體替換為佔位符標記。佔位符標記與原始值之間的對應關係單獨儲存在加密查詢表中，並有嚴格的存取控制。

這就是Ertas PII編輯器在架構中的位置。它在本地運行，因此文件在編輯過程中永遠不會離開你的基礎設施。沒有向第三方編輯API的跨境資料傳輸。編輯器產生每個已識別和已編輯實體的稽核記錄，這是你向監管機構證明GDPR合規所需的。

階段3——分塊和嵌入。 經過編輯的文件被分塊並嵌入到你的向量儲存中。由於PII已被移除，嵌入編碼的是不含個人資料的語義含義。你的向量儲存現在從建構上就符合GDPR——沒有需要刪除的個人資訊，嵌入層面無需追蹤同意，也沒有PII會在回應存取請求時被暴露。

階段4——查詢時擷取和再水化。 當使用者查詢RAG系統時，從向量儲存中擷取相關區塊。如果使用案例需要回應中包含原始個人資料（且使用者有授權），佔位符標記可以從加密查詢表中再水化。如果使用案例不需要個人資料，編輯後的區塊直接傳遞給語言模型。

處理資料主體存取請求

根據GDPR第15條，資料主體可以請求取得你持有的所有個人資料的副本。使用「先編輯後嵌入」架構，你的回應工作流程很清晰。

向量儲存不包含個人資料，因此被排除在DSAR範圍之外。加密查詢表包含佔位符與原始PII之間的對應關係——這可以按資料主體識別碼搜尋。原始文件儲存包含來源文件——這些可以透過標準資料庫查詢搜尋。你的稽核記錄準確顯示哪些文件被處理、編輯何時發生以及識別了哪些實體。

這比試圖在向量資料庫中搜尋「與此人相關的所有內容」要簡單得多，後者在技術上不可靠且在法律上不充分。

處理刪除請求

當資料主體根據第17條行使被遺忘權時，工作流程同樣直接。

從加密查詢表中刪除該主體的條目。從原始文件儲存中刪除或編輯該主體的資料。向量儲存不需要任何操作——它不包含個人資料。在稽核記錄中記錄刪除操作以備合規文件。

與替代方案對比：沒有預嵌入編輯，針對RAG系統的刪除請求意味著識別每個可能包含該主體資料的區塊（使用語義搜尋不可靠），刪除或重新嵌入這些區塊（成本高昂且可能破壞擷取品質），以及向監管機構證明你找到了所有內容（無法保證）。

同意追蹤和目的限制

同意管理屬於文件儲存層，而非向量儲存層。當文件進入管線時，記錄處理的合法依據、資料收集的具體目的、任何同意記錄或合法利益評估，以及保留期限。

這些中繼資料隨文件在管線中流轉。如果同意被撤回，你從來源儲存中移除文件，刪除查詢表中的相應條目，如果目的限制要求，還可以選擇從向量儲存中移除相關的（已經不含PII的）區塊。

由於編輯步驟被記錄，你可以向監管機構準確展示哪些文件在哪種合法依據下被處理，以及何時處理的。

儲存限制執行

在文件儲存層面實施保留策略。當文件的保留期到期時，從來源儲存和查詢表中刪除它。向量儲存中已編輯的嵌入可以保留更長時間，如果它們服務於合法目的——由於不包含個人資料，GDPR儲存限制約束會放寬。

這給你一個實際的平衡：你的RAG系統在嵌入有用的期間保留其知識庫，同時個人資料按照你的保留計畫自動清除。

RAG向量儲存GDPR合規實踐

合規RAG管線與不合規管線之間的區別不在於你選擇的向量資料庫或使用的嵌入模型。而在於個人資料是否到達了向量儲存。

在嵌入之前編輯PII消除了最困難的GDPR挑戰——從密集向量中選擇性刪除、跨分散式嵌入的同意追蹤，以及存取請求的完整性保證。當向量儲存根本不包含個人資料時，這些問題變得微不足道。

在本地運行編輯步驟，正如Ertas PII編輯器所支援的，消除了將個人資料傳送給第三方處理者進行編輯的次要合規風險。資料留在你的基礎設施邊界內，編輯在本地進行，稽核記錄在你的控制之下。

如果你正在建構一個將處理歐盟居民個人資料的RAG管線，首先設計編輯層。當向量儲存從一開始就是乾淨的，下游的一切都會變得更簡單。