三種手法的本質差別

偵測完之後，要決定怎麼處理。三種主要手法：

遮罩（Masking／Redaction）

A123456789  →  **********
              或  [身分證字號]

原值被破壞性替換。資訊完全消失，不可還原。

概化（Generalization）

1985-03-17           →  1985 年
台北市中山區民生東路三段 XX 號  →  台北市中山區
新臺幣 1,234,567 元    →  100 萬–200 萬元

保留部分資訊、降低精確度。同樣不可還原——你無法從「1985 年」回推到 3 月 17 日。

Token 化（Tokenization／Pseudonymization）

A123456789  →  B847263915
王小明       →  林建成

原值被替換成另一個值，對應關係存在別的地方。可還原，前提是你有 Vault 和金鑰。

這個差別為什麼重要

因為它決定了「還原一致性」的邏輯上限，而這是一個非常容易在需求討論裡被搞混的點。

假設有人提出這樣的需求：

系統應支援三種去識別化手法，且經去識別化之資料應能還原至原始內容。

這個需求在邏輯上是不可能滿足的。遮罩把原值刪掉了，概化把精確度降低了，兩者都沒有保留還原所需的資訊。你不可能從 ********** 回推出 A123456789，除非你偷偷把原值存在某個地方——但如果你存了，那它就不是遮罩，而是「顯示成星號的 Token 化」。

我在實務上遇過這種需求好幾次。正確的回應不是硬做，而是把需求拆開：

• 需要還原的欄位 → 使用 Token 化，還原經授權流程
• 不需要還原的欄位 → 使用遮罩或概化，且明確記錄為不可還原
• 系統應能在還原時，正確標示哪些欄位不可還原，而非回傳錯誤或空值

第三點很重要。使用者請求還原一份文件時，系統應該回傳「這 5 個欄位還原了，這 3 個欄位是遮罩處理不可還原」，而不是整個失敗。

怎麼決定用哪一種

決策依據是兩個問題：

問題一：LLM 完成任務需不需要這個資訊？ 問題二：使用者看結果時需不需要看到原值？

舉幾個實例：

身分證字號 → LLM 不需要知道具體號碼，但律師看結果時需要知道是誰 → Token 化。

當事人姓名 → LLM 需要區辨「王小明」和「陳美玲」是不同人（否則摘要會混淆），律師需要看到真名 → Token 化，而且要人名替換成人名，不能替換成 [PERSON_1]（原因見 D10）。

地址 → LLM 可能需要知道管轄地區，但不需要門牌 → 概化到行政區。

健康資訊 → LLM 不需要、律師通常也不需要（案件本身的敘述已足夠） → 遮罩。而且它是特種個資，能不留還原路徑就不留。

金額 → 通常需要精確值來做法律判斷 → 不去識別（金額本身不是個資，除非結合其他欄位）。

三種手法的組合

實務上一份文件會同時用到三種。以合成範例示範：

原文：

立約人王小明（身分證字號 A123456789，民國 74 年 3 月 17 日生，
戶籍地址：台北市中山區民生東路三段 XX 號 5 樓，行動電話 0912-345-678），
因罹患慢性腎病無法工作，向本行申請展延還款，借款餘額新臺幣 1,234,567 元。

處理後：

立約人林建成（身分證字號 B847263915，民國 74 年生，
戶籍地址：台北市中山區，行動電話 0987-654-321），
因【健康資訊已遮蔽】無法工作，向本行申請展延還款，借款餘額新臺幣 1,234,567 元。

• 姓名、身分證字號、電話 → Token 化（可還原）
• 出生日期 → 概化到年（不可還原）
• 地址 → 概化到區（不可還原）
• 健康資訊 → 遮罩（不可還原）
• 金額 → 保留原值

送給 LLM 的是下面這份。模型仍然能做摘要、判斷法律爭點、擬定回覆草稿——因為它需要的資訊都還在。

一個常見的錯誤：全部遮成佔位符

很多實作圖省事，把所有東西都替換成 [PERSON]、[ID]、[PHONE]。這會造成三個問題：

一、指代混亂。 一份文件裡有借款人、保證人、配偶三個人，全部變成 [PERSON]，模型無法區辨，摘要會把三個人的行為混在一起。

二、格式破壞。 文件的語言結構被破壞，模型表現下降。「立約人[PERSON]（身分證字號[ID]）」讀起來就不像自然語言。

三、還原困難。 如果同一份文件有 20 個 [PERSON]，還原時你得靠位置對應，一旦模型改寫了句子順序就對不回去。

正確做法是同型替換：人名換成合理的人名、身分證字號換成格式正確的假號碼、電話換成格式正確的假電話。這就是 D10 要談的 Format-Preserving Encryption，也是我在 VeilCapybara 裡採用的核心設計。

記住一句話

可還原是一個成本，不是一個功能。

每一個你決定 Token 化的欄位，都在 Vault 裡留下一筆明文對應。Vault 越大，D3 說的那個「高風險集中點」就越大。

所以預設應該是不可還原，只有在明確證明業務需要時才開放還原。這跟權限設計的最小權限原則是同一件事。

明天談 FPE：為什麼假的身分證字號要長得像真的。

關於作者

我是 Fngi，專注在 AI 資安、LLM 紅隊與 AI 治理框架落地。
IG：

@aid3fend

有想討論的架構細節或不同意見，留言或私訊都歡迎。