
向量儲存中的 PII:為什麼嵌入敏感資料是一個無法撤銷的合規責任
一旦個人資料被嵌入為向量,就無法選擇性地刪除、編輯或稽核。對該向量儲存的每次查詢都可能暴露 PII。唯一安全的方法是在嵌入之前進行脫敏。
目前企業 AI 團隊中正在蔓延一個根本性的誤解。大概是這樣的:「我們將文件嵌入到向量儲存中,如果我們需要刪除某人的資料,只需刪除相關的向量即可。」
這聽起來合 理。但這是錯誤的。基於這種假設行事的後果——建構將未脫敏的 PII 攝取到向量資料庫中的 RAG 管線——正在創造組織在不從頭重建整個檢索基礎設施的情況下根本無法逆轉的合規責任。
向量不是資料庫中的列
關聯式資料庫圍繞離散、可定址記錄的概念設計。你可以找到一列、更新它、刪除它。外來鍵讓你追蹤關係。稽核日誌讓你證明什麼被更改了以及何時更改的。這是大多數工程團隊帶入向量儲存工作的心智模型,但它並不適用。
向量嵌入是語義含義的高維數值表示。當你嵌入一個包含客戶姓名、醫療診斷和帳號的段落時,該資訊不是作為離散欄位儲存的。它被壓縮成一個單一的密集向量——一個在具有數百或數千維度的空間中的點。PII 不是坐在你可以置空的欄位中。它溶解在嵌入本身的幾何結構中。
這很重要,因為在 RAG 索引之前進行 PII 脫敏不僅僅是最佳實務。它是給你一個清晰合規態勢的唯一方法。一旦嵌入存在,個人資料就與該文字區塊中的每一個其他概念在數學上糾纏在一起。
語義痕跡在來源資料刪除後仍然存在
情況在這裡變得更糟。假設你發現一組包含病患記錄的文件被意外嵌入到你的 RAG 管線中。你刪除了來源文件。你甚至從向量儲存中刪除了相應的向量。問題解決了,對吧?
不一定。向量儲存使用索引結構——HNSW 圖、IVF 索引、乘積量化碼本——這些都是根據集合中所有向量的統計特性建構的。當你刪除一個向量時,你將其從查詢結果中移除,但由其存在塑造的索引結構仍然保留。根據實作方式,被刪除向量的語義鄰域仍然攜帶著它所代表資料的痕跡。
更實際地說,如果你將一個文件分塊並將其嵌入為多個向量,刪除一個分塊並不能消除滲入相鄰分塊的 PII 上下文。第三段中的病患姓名影響了第二段和第四段中擷取的語義含義。即使你識別並刪除了原始文件的每個分塊,之前檢索過這些分塊的任何 RAG 管線可能已經快取、記錄或使用它們來產生現在位於對話歷史、稽核軌跡或下游系統中的回應。
這就是為什麼在嵌入文件之前脫敏 PII 的原則如此關鍵。一旦資料進入向量儲存,合規事件的影響範圍遠遠超出儲存本身。
GDPR 被遺忘權問題
GDPR 第 17 條賦予資料主體要求刪除其個人資料的權利。這不是可選的。不是「盡力而為」。當收到 有效的刪除請求時,你必須能夠證明資料已從所有處理它的系統中刪除。
現在考慮這對一個嵌入了未脫敏客戶支援工單的 RAG 管線意味著什麼。一個客戶行使其刪除權。你的團隊需要:
- 在可能數百萬個向量中識別包含該客戶 PII 的每個分塊
- 刪除這些向量而不損壞索引
- 驗證相鄰分塊中沒有殘留語義痕跡
- 確認包含該 PII 的快取檢索或產生的回應不會持續存在於任何下游系統中
- 為監管稽核記錄所有這些
僅第一步通常就不可能。向量儲存不支援針對特定 PII 模式的基於內容的搜尋。你無法查詢向量資料庫並要求「展示從包含此電子郵件地址的文字產生的每個向量」。你需要維護一個並行的中繼資料索引,將每個來源文字對應到其向量 ID——大多數團隊直到為時已晚才建構這個。
理解 RAG 管線資料隱私的團隊從一開始就以不同的方式建構系統。他們將嵌入邊界視為合規邊界:沒有包含 PII 的內容在未經脫敏的情況下跨越它。
HIPAA 和最低必要標準
HIPAA 的最低必要標準要求受保護實體將受保護健康資訊的使用和揭露限制在完成預期目的所需的最低限度。這一原則與大多數 RAG 管線的運作方式直接衝突。
當你將臨床筆記嵌入向量儲存時,該筆記的全部語義內容變得可檢索。關於藥物劑量的查詢可能檢索到一個同時包含病患診斷、人口統計資訊和主治醫師的分塊。向量儲存不理解「最低必要」的概念。它按語義相似性檢索,而不是按存取控制策略。
這創造了一種情況,即對向量儲存的每次查詢都可能違反最低必要標準。嵌入不區分你需要的臨床事實和你未被授權存取的身份資訊。它們融合在同一個數學表示中。
嵌入前脫敏乾淨地解決了這個問題。在文字到達嵌入模型之前去除受保護的健康資訊。產生的向量編碼臨床知識而不包含病患身份。檢索透過設計變得合規,而不是透過事後過濾——後者是脆弱的且在稽核方面存在疑問。
為什麼檢索後過濾不夠
一些團隊試圖在下游解決這個問題。他們嵌入所有內容,然後在將檢索到的分塊呈現給使用者或輸入生成提示之前套用 PII 偵測。這種方法有三個致命缺陷。
首先,PII 仍然存在於向量儲存中。它在檢索過程中仍然被處理、儲存和傳輸。根據 GDPR,無論 PII 是否最終顯示給使用者,這種處理都需要法律依據。
其次,PII 偵測並不完美。命名實體識別模型根據領域和語言不同 ,大約會遺漏 2% 到 8% 的 PII 實例。每次遺漏都是潛在的資料外洩。當你在每天數千次查詢中進行檢索時過濾,即使 95% 的偵測率也意味著每天數十次 PII 暴露。
第三,它不解決被遺忘權問題。資料仍然在那裡。監管機構不會接受「我們在查詢時過濾掉它」作為刪除的等價物。向量儲存是一個處理系統,PII 就在其中。
重建稅
事後發現這個問題的組織面臨一個艱難的選擇。他們可以從脫敏後的來源文件重建整個向量儲存——重新分塊、重新產生嵌入、重新索引一切。對於大型企業 RAG 部署,這可能需要數週時間,僅運算成本就要數萬美元,還不包括驗證新儲存產生等效檢索品質的工程時間。
或者他們可以接受合規風險,希望沒有人提交刪除請求或觸發稽核。這不是假設場景。多個組織已經發現其向量儲存包含無法移除的嵌入 PII,而監管時鐘正在滴答作響。
嵌入前 PII 脫敏的成本相比之下微不足道。基於 NER 的現代脫敏管線在毫秒內處理文件。實體感知的分塊策略可以在去除身份資訊的同時保持語義連貫性。脫敏步驟為嵌入管線增加個位數百分比的額外負擔。跳過它的重建稅要高出幾個數量級。
原則:嵌入之前先脫敏
這裡的指導簡單明確,對於任何在隱私法規下營運的組織來說不可協商。
將嵌入邊界視為單向合規門。每個文件、每個分塊、每段將被轉換為向量的文字都必須先通過 PII 脫敏。姓名、地址、帳號、病歷號、出生日期、電子郵件地址、電話號碼——所有這些都在嵌入模型看到之前被去除或替換為一致的假名。
這不是一個限制。這是一個設計原則。一個經過良好脫敏的 RAG 管線檢索的是知識,而不是身份。它回答關於模式、政策和程序的問題,而不暴露相關個人。它可以被稽核,可以透過簡單地刪除來源文件來回應刪除請求,並且不會創造一個隨著你新增的每個文件而增長的廣泛合規責任。
今天正確建構 RAG 管線的組織是那些從一開始就理解這一點的組織:向量記住你餵給它們的一切,它們不提供選擇性遺忘的方式。
嵌入之前先脫敏。沒有撤銷的可能。
Turn unstructured data into AI-ready datasets — without it leaving the building.
On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.
Keep reading

Building a GDPR-Safe RAG Pipeline: Redaction, Consent, and the Right to Be Forgotten in Vector Databases
Vector databases were not designed for GDPR. They have no concept of consent tracking, purpose limitation, or selective deletion. Here is how to build a RAG pipeline that handles data subject rights from day one.

GDPR-Compliant RAG Pipeline: Right to Erasure, Data Minimisation, and Vector Store Implications
GDPR Article 17 gives individuals the right to have their data deleted — but once personal data is embedded in a vector store, deletion is not straightforward. Here is how to build a RAG pipeline that handles GDPR from the start.

Audit Trails for RAG Pipelines: What EU AI Act Article 30 Requires From Your Retrieval System
The EU AI Act mandates technical documentation and logging for high-risk AI systems. If your RAG pipeline feeds a high-risk application, every step from ingestion to retrieval needs an audit trail.