企業 RAG 的 PII 與機敏資料怎麼處理?去識別化、遮罩與合規落地流程

去年底,我們幫一家區域性銀行做內部知識助理的驗收。工程師隨手問了一句「幫我查一下上季的授信覆審範本」,系統很聽話,連同某位客戶的完整身分證字號、帳號餘額,一併從被索引的內部文件裡撈了出來,顯示在對話框。

沒有人攻擊系統。它只是照實做了它被教會的事:檢索,然後回答。

問題出在源頭。企業把 RAG 當成「把文件丟進向量庫就能問」的魔法,卻忘了那些文件裡躺著多少不該被任意檢索的東西。真正的 RAG PII 機敏資料處理,不是在模型回答完之後才去攔,而是要在資料進入知識庫的那一刻,就決定哪些欄位該去識別化、哪些該遮罩、哪些根本不該進來。這篇把我們實際落地過的治理流程拆給你看。

RAG PII 機敏資料處理的四道關卡

我們把流程切成四段,順序不能顛倒:偵測 → 去識別化 → 遮罩 → 稽核。

第一關是偵測。你得先知道語料裡有什麼。台灣個資法第二條定義的個人資料,範圍比多數人以為的廣:姓名、身分證字號、病歷、財務情況、社會活動,甚至一段能間接指向特定人的描述都算。實務上我們用規則式比對(身分證字號的檢核碼、統編、信用卡 Luhn 校驗)搭配 NER 模型,兩者互補——規則抓格式固定的,模型抓「王先生上個月在北院的那件案子」這種要靠上下文才認得出來的間接識別。偵測要在資料切塊(chunking)之前做,不然一個人的資訊被拆到兩個 chunk,規則就漏了。

第二關是去識別化,決定「留不留得回去」。這是最常被混用的一步。

金融業要注意:假名化在個資法眼中「仍屬個人資料」,因為理論上可還原,所以對照表的金鑰管理等同機敏資料等級。醫療端受《人體生物資料庫管理條例》約束,去連結後的資料才算脫離個資範疇,泛化與 k-匿名往往比單純遮罩更站得住腳。

第三關是遮罩,而且要分層。同一份文件,對法遵人員可見完整內容,對一般客服只該看到遮罩版。我們的做法是在 metadata 標記每個 chunk 的敏感等級,檢索時把使用者角色一起帶進 filter,讓向量庫先做 pre-filtering 再回傳——而不是全撈出來、再靠 prompt 求模型「請不要說出身分證」。後者遲早會被繞過。

稽核:沒有紀錄等於沒做

第四關最容易被跳過,卻是合規落地的分水嶺。個資法第十八條要求公務與非公務機關採取「適當安全維護措施」,金管會的金融機構作業要點更明確要求存取軌跡可追溯。

所以每一次檢索都要留下:誰、什麼時間、問了什麼、命中哪些 chunk、有沒有觸發去識別化。這份 audit log 本身也含機敏資訊,要另存、加密、設保存期限。我們踩過的雷是——log 寫得很勤,卻和主資料庫放同一個權限層,等於把所有人問過的敏感問題集中成一個更大的靶。後來我們把稽核軌跡獨立到唯讀的隔離儲存,只有稽核角色能查。

真正上線後你會發現,難的從來不是選哪個去識別化演算法,而是有沒有人願意坐下來,逐一釐清每個資料來源的敏感欄位、每個使用者角色該看到什麼。這件事沒有現成套件能代勞。我們在客戶現場做 RAG 導入時,通常第一週不寫任何 pipeline,先陪法遵和資安一起把這張「欄位 × 角色 × 手法」的對照表填完——因為 Demo 裡能問出答案不算數,系統上線後不會把不該說的說出口,才算數。