非結構化文件的個資怎麼抓：PII 偵測與去識別化

顧問業務手上會累積大量客戶與公司內部的文件：勞動契約、薪資清冊、申訴紀錄、工作規則、人事規章。這些文件要拿去餵 RAG、要當對外案例、要委外標註之前，都得先做去識別化。

這篇整理的是「怎麼做」的前半段：先把要處理的東西盤清楚，再決定每一類用什麼手法。規則以台灣為主，跨國情境（目前面對的是越南）另闢第四節處理。

一、資料分類：七類與對應手法

分類的軸不看「資料多敏感」，看「用什麼方法抓得到」。因為手法決定成本：正則抓得到的可以全自動、零人審；只能靠語意判斷的，就得付模型跟人工的錢。

1. 強格式直接識別碼

有固定格式，部分還有檢查碼可驗。誤判率最低，可以全自動處理。以下是台灣的規則集；這一類的規則屬於地區資料，換個國家就換一套，流程本身不動。

出生年月日最容易漏抓：同一份文件裡「85.03.12」「民國85年3月12日」「1996/3/12」三種寫法並存是常態，正則要一起吃掉。

A → 10，所以 N1=1、N2=0
​
1×1 + 0×9 + 1×8 + 2×7 + 3×6 + 4×5 + 5×4 + 6×3 + 7×2 + 8×1 + 9×1
=  1 +  0 +  8 + 14 + 18 + 20 + 20 + 18 + 14 +  8 +  9
= 130
​
130 ÷ 10 整除 → 通過

LETTER = {c: 10 + i for i, c in enumerate("ABCDEFGHJKLMNPQRSTUVXYWZIO")}
​
def is_valid_twid(s: str) -> bool:
    n = LETTER[s[0]]
    total = n // 10 + (n % 10) * 9
    total += sum(int(d) * w for d, w in zip(s[1:9], range(8, 0, -1)))
    return (total + int(s[9])) % 10 == 0

位置   4  5  3  9  1  4  8  8  0  3  4  3  6  4  6  7
乘2    ×2    ×2    ×2    ×2    ×2    ×2    ×2    ×2
結果   8  5  6  9  2  4  7  8  0  3  8  3  3  4  3  7
                        ↑16-9              ↑12-9  ↑12-9
​
8+5+6+9+2+4+7+8+0+3+8+3+3+4+3+7 = 80
80 ÷ 10 整除 → 通過

def luhn(s: str) -> bool:
    digits = [int(c) for c in s if c.isdigit()][::-1]
    total = 0
    for i, d in enumerate(digits):
        if i % 2 == 1:
            d *= 2
            if d > 9:
                d -= 9
        total += d
    return total % 10 == 0

2. 弱格式直接識別碼

沒有格式特徵，正則抓不動，得靠詞典或 NER。誤判率高，要設人審門檻。

輸入：本公司林口分公司之陳美玲於 113 年 3 月申請留職停薪
​
NER 輸出：
  林口分公司   ORG
  陳美玲       PER
  113 年 3 月  DATE

3. 特種個資（個資法 §6）

法律上另有一套更嚴的蒐集處理限制。這一類幾乎都沒有格式，只能靠語意判斷，是 LLM 真正該上場的地方。勞資顧問手上的案件文件，這類內容不少。

4. 人事與薪酬敏感資料

法律上不全屬個資，但在顧問情境下常常需要處理，條件見第三節。特點是很多是「數字」而非「識別碼」，所以手法通常是泛化成區間而不是整個遮掉。

5. 準識別碼

單獨看都不是個資，組合起來卻能還原到個人。這是最容易整桶漏掉的一類，也是重識別風險的主要來源。

處理原則是 k-匿名任一組準識別碼的組合，在資料集中至少要對應到 k 個人；不足就往上泛化，直到達標。，實際做起來要跨文件統計，沒辦法單份文件獨立處理完。

6. IT 憑證與技術識別

7. 載體層：影像與檔案 metadata

這不是一種資料類型，是一整個容易被漏掉的層，前面六類都可能藏在這裡。

二、遮掉名字就夠了嗎？

姓名、身分證字號都拿掉之後，薪資、考績這些留著到底有沒有差？

多數情況下這個判斷成立，因為薪資、出勤、考績是敏感「屬性」，不是「識別碼」。一份沒有名字的薪資數字，就只是一個數字。反過來說，數字全遮掉，那份文件拿去做分析或 RAG 也就沒意義了。

但有兩種情況會讓這個判斷翻車，而且在中小企業客戶身上很常見。

三、最低限度：用文件形態決定處理強度

每份文件都把七類跑滿，錢多半是白花的。比較省的做法是先判斷文件形態，再決定跑到第幾層。

三種文件形態

三層處理強度

1. 01

   Tier 0：一律做，全自動零人審

   第 1 類強格式識別碼、第 6 類 IT 憑證、第 7 類 metadata 與檔名。

   正則就解決，成本極低，沒有不做的理由。

2. 02

   Tier 1：一律做，需要模型

   第 2 類姓名與地址。

   誤判率高，要設人審門檻。

3. 03

   Tier 2：條件觸發

   第 3、4、5 類：特種個資、人事薪酬、準識別碼。

   只有文件被判為 B 型或 C 型才啟動。

實務上 A 型文件通常佔量最大，公司內部規則那一整批幾乎都是 A。這一刀切下去，多數文件只要跑 Tier 0 跟 Tier 1。

TF-IDF 在這裡的角色

判斷一份文件屬於 A、B 還是 C，正好是 TF-IDF 加線性分類器最擅長的事：不需要 LLM、不需要大量標註，訓練成本極低，而且判錯也不致命，把門檻設寬一點偏保守，誤判成高強度只是多花錢。

TF-IDF 在整條流程裡只做一件事：決定每份文件跑到第幾層。辨識工作交給正則、NER 與 LLM。

四、跨國：什麼會變，什麼不變

前三節的規則以台灣為主。業務跨到越南之後，七類的分類架構不用動，因為分類的軸是「用什麼方法抓得到」，這件事跟國別無關。真正要換的是規則集內容與法源。

規則集要抽出來

實作上把識別碼規則做成註冊表，一個 locale 對應一組 {pattern, validator, context_keywords}，偵測引擎讀註冊表跑，新增國家等於新增一筆資料，不改程式。

七類的跨國影響

越南：檢查碼會退化

台灣這邊之所以能把第 1 類設成 Tier 0 全自動零人審，是因為檢查碼幫機器確認抓對了。越南的號碼大多沒有這一層。

CCCD（12 碼身分證）目前的理解是沒有公開的檢查碼，只有結構：前 3 碼省市代碼、第 4 碼含世紀與性別、接著 2 碼出生年、後 6 碼流水。能做的是「結構驗證」，用省市代碼表與出生年合理性去篩，強度比檢查碼弱。稅號 MST 則有檢查碼。

結論是 Tier 0 的零人審前提在越南不成立，第 1 類在越南要往 Tier 1 靠，設抽樣人審。

跨境傳輸要先拍板

PDPD 對個資的跨境傳輸有申報要求。這件事決定越南的文件能不能送到雲端 LLM，比前面所有偵測細節都更早需要決定：如果不能，第 3 類的語意判斷就只剩地端模型一條路，成本與效果都要重估。

跨國情境下，這個問題要在動工前先問，不要等 pipeline 都搭好才發現整條路走不通。

五、先問要不要做

前面四節都在講怎麼做。這一節講什麼時候不用做。

三個條件同時成立才划算

技術去識別化要值得做，需要量大、接收方不可信、無法用權限控制，三個同時成立。少一個，通常有更便宜的解法。紙本時代的做法一直都是鎖檔案室跟借閱登記，很少有人真的把文件洗一遍。

情境一：內部 RAG

文件本來就全公司看得到的話，把它放進 RAG 並不會產生新的揭露。RAG 不改變資料的可見範圍，只改變取用的便利性；索引範圍跟原本的權限對齊，就沒有去識別化的問題。

這裡該做的是來源分級：確認每份進索引的文件原本給誰看，讓檢索結果照同一條線過濾。

但有三件事要留意。

1. 便利性本身會製造問題。 「全公司看得到」跟「全公司一秒查得到」是兩回事。原本要翻三小時檔案才拼得出「誰被記過」，現在一句話就有答案。這不見得違法，但員工觀感、工會反應、內部信任都會出事。
2. 來源清單常常混進不該全員看的東西。 工作規則的附件裡有簽核人手機、範本裡忘了刪的真實案例、公告 PDF 的 metadata 還留著人事主管姓名。審查的對象是來源清單，逐份確認它原本的可見範圍。
3. 雲端 embedding 也是傳輸。 如果向量化走的是雲端 API，文件其實已經出門了。「內部 RAG」這個名字很容易讓人以為資料沒離開公司。

情境二：餵雲端 LLM

這裡真正的問題是能不能送出去。去識別化只是繞過限制的其中一條路，而且是最貴的一條。

三個選項照優先序排：

1. 01

   地端模型

   文件不出門，問題直接消失。成本與效果要評估，但這是唯一能徹底解決的做法。

2. 02

   企業條款

   Azure OpenAI、Bedrock、Vertex 這類提供資料處理協議、不用於訓練、zero data retention 的方案，讓「送出去」這件事本身變成可接受的行為。

3. 03

   去識別化

   洗乾淨再送。排最後。

排最後有個理由：它的失敗模式不可逆。漏掉一筆，資料就真的出去了，沒有第二道防線。拿它當送出門的通行證，等於把整份合規責任壓在一個做不到 100% 的技術上。

前兩個選項失敗的代價是成本或談判破局，第三個失敗的代價是外洩。

如果還是要做

定位成風險分流與人工複核輔助，產出是一份降低風險的文件加一張待審清單。

最省的一刀是分流。 高風險文件（B 型個案、C 型名冊）不進自動流程，或走人工通道，讓機器只處理它有把握的 A 型。這比把準確率從 95% 推到 99% 便宜太多，也可靠太多。

人工確認那一關要設計。 介面只放一個「請確認」按鈕的話，人會全部按過去，品管上叫橡皮圖章，等於沒有這一關。要讓它有效：只呈現模型信心低的片段、可疑項預設標紅並要求逐項處理、限制每次審查量避免疲勞、記錄誰在什麼時間確認了什麼。

最後一項是重點。誰按下確認，誰承擔。這把「系統有沒有 100%」的問題，轉成「有沒有盡到適當安全維護措施」，而後者才是法律真正在問的。

六、內部 RAG 的權限控管

第五節的結論是內部 RAG 不需要去識別化，需要的是權限對齊。這一節講怎麼對齊。

一句話原則：檢索結果的可見範圍等於來源文件的可見範圍。權限跟著文件走，不跟著索引走。

權限模型直接繼承來源系統

不要為了 RAG 另外發明一套權限。文件原本放在哪裡（SharePoint、Google Drive、檔案伺服器、HR 系統），就沿用那邊的授權設定，否則會養出兩套會不同步的權限，而且不同步的那一天你不會知道。

以 HRM 的情境，可見範圍大致是四層：

「本人」這一層是 HRM 特有的難題。前三層是文件層級的權限，一份文件對一群人開放，向量庫的 metadata filter 就能處理。但「本人」是資料列層級：同一份薪資清冊裡，每一列只有一個人能看，文件層的 ACL 模型撐不住。

過濾要做在檢索之前

後過濾的問題在於 top-k 會被高權限文件佔滿，篩完之後可能只剩兩三筆甚至是空的，而使用者無從得知答案是在殘缺的檢索結果上生成的。這種失敗是沉默的。

還有一個容易漏的細節：ACL 要帶到 chunk 層。文件切塊之後，每一塊存進向量庫時都要帶上權限 metadata。只在文件層記錄、chunk 沒帶的話，過濾條件根本套不上去。

權限會變，索引不會自己知道

調職、離職、專案結束，權限每天都在變，但索引裡的 ACL 是建檔當下的快照。

比較省事的做法是在 ACL 裡存群組：索引寫的是「業務二部主管群組」，成員異動由來源系統管理，索引完全不用動。真正需要即時查的只剩「這個人現在屬於哪些群組」，那是一次很輕的查詢。

離職當天要能立刻失效，這件事不能靠定期同步的排程。

生成階段還有四個洩漏面

檢索過濾做對了，資料還是可能從後面漏出去。

1. 答案要附引用來源。 這既是讓使用者判斷可信度，也是唯一能發現越權的方式。答案裡出現一份他不該看到的文件，只有標了出處才看得出來。
2. 聚合效應。 每一份來源都合法，組合出來的答案卻可能構成新的揭露。第五節提到的「全公司看得到」跟「一秒查得到」的差別，在生成階段會被放大。
3. 對話紀錄與快取。 語意快取如果跨使用者共用，會直接把 A 的答案送給 B。對話歷史被拿去做分析或給管理後台看，也是同樣的問題。查詢紀錄本身就很敏感，「某人連續三天在問資遣費怎麼算」這件事就是資訊。
4. 提示注入。 文件內容裡藏的指令可能誘導模型吐出 context 裡的其他內容。防線是讓 context 裡從頭到尾只有這個人有權看的東西，模型層不做第二次過濾。

沒有權限時怎麼回應

這裡有個容易忽略的洩漏：回「你沒有權限查看這份文件」，等於告訴對方這份文件存在。在人事情境下，光是「有一份關於你的調查報告」就是資訊。

保守做法是一律回「查無相關資料」。缺點是使用者會困惑、會重複問。折衷是依內容敏感度分級：一般文件可以提示「有 N 筆結果因權限未顯示，請洽人資」，調查案件與個案文件則完全不透露存在。

稽核紀錄

記錄誰在什麼時間問了什麼、命中哪些 chunk。這是合規要求，也是唯一能事後發現異常的方式。

但查詢紀錄本身要當敏感資料保管：設保存期限、限制誰能看、不要讓部門主管能翻自己下屬問過什麼。

權限撐不住的三種情況

回到去識別化的時機只有這三種：

1. 跨等級的聚合統計。 「全公司平均加班時數」需要讀所有名冊，但答案本身不敏感。這種要另外預先算好去識別化的彙總資料集，不要讓 RAG 直接讀原始名冊。
2. 對外或委外。 案例、教材、第三方標註。
3. 送出公司邊界。 包含雲端 embedding，見第五節。

除此之外，內部 RAG 的個資問題都是權限問題。