個資不是一個型別，是一個光譜

很多團隊做 PII 偵測的第一步是打開文件、開始寫 regex。這會做出一個看起來能動、但不知道自己漏了什麼的系統。

正確的第一步是分類。因為不同類型的個資，偵測難度、洩漏後果、法規要求都不一樣，處理方式也不該一樣。

三層分類法

我習慣分三層，這個分法後面會直接對應到去識別化的手法選擇（D9）。

第一層：直接識別碼（Direct Identifiers）
單獨一個就能鎖定到人。

第二層：準識別碼（Quasi-identifiers）
單獨看不出是誰，但組合起來可以。姓名、出生日期、地址、職業、任職單位、車牌。

經典的研究結論是：郵遞區號 + 出生日期 + 性別，這三個欄位就足以在人口資料中唯一識別出相當高比例的個人。所以準識別碼不能因為「這又不是身分證字號」就放過。

第三層：特種個資（個資法第 6 條）
病歷、醫療、基因、性生活、健康檢查、犯罪前科。

這一層的特殊之處在於：它幾乎不是欄位化的，而是敘述性的。 沒有一個 regex 能抓到「我因為長期洗腎無法工作」這句話裡的健康資訊。這是為什麼純規則式方案在法務場景會失效——D6 會處理。

檢查碼：可以大幅降低誤判的免費工具

身分證字號有檢查碼，用它可以把誤判率壓下來。演算法是首字母轉兩位數字，再加權求和：

def validate_tw_id(s: str) -> bool:
    if len(s) != 10:
        return False
    letter_map = "ABCDEFGHJKLMNPQRSTUVXYWZIO"
    idx = letter_map.find(s[0].upper())
    if idx == -1 or not s[1:].isdigit():
        return False
    n = idx + 10
    total = (n // 10) + (n % 10) * 9
    weights = [8, 7, 6, 5, 4, 3, 2, 1]
    for i, w in enumerate(weights):
        total += int(s[1 + i]) * w
    total += int(s[9])
    return total % 10 == 0

信用卡號用 Luhn，統一編號用它自己的加權規則。有檢查碼的一律加上驗證，這是免費的精確度提升。

但要小心一個陷阱：檢查碼只能提高 Precision，不能提高 Recall。一個被打錯的身分證字號（使用者手誤）過不了檢查碼，但它仍然是個資、仍然會洩漏當事人身分。所以在資料防護場景，檢查碼應該用來分級信心度，而不是用來排除候選。

法務文件的實際樣態

理論分類講完，來看實際上這些東西長什麼樣。以下全為合成資料：

立約人王小明（身分證字號：A123456789，戶籍地址：台北市中山區民生東路三段 XX 號 5 樓），茲向貴行申辦……連帶保證人陳美玲（Ａ２２３４５６７８９）……

注意第二個身分證字號是全形。這在實務上很常見——從 PDF 複製貼上、或使用者用全形輸入法打的。一個只寫了 [A-Z][0-9]{9} 的 regex 會完全漏掉它。

再看一個訴訟文件的片段：

被告辯稱其於 112 年間因心臟疾病住院治療達三個月，期間無收入來源，故未能依約繳款。被告之配偶林淑芬（0912-345-678）曾多次致電本行協商。

這段裡有：特種個資（心臟疾病、住院）、第三人姓名、電話（帶連字號）、時間資訊（可作為準識別碼）。regex 能抓到電話，抓不到其他任何一項。

分類完之後要決定什麼

每一類個資需要決定三件事，這張表後面會變成偵測政策的設定檔：

第三、四欄的邏輯在 D9 會完整說明。先記住一件事：特種個資預設不可還原。因為它幾乎不影響 LLM 完成法務任務，卻是洩漏後果最嚴重的一類。能直接抹掉就不要留還原的路。

明天寫規則式偵測，順便展示它會在哪裡失效。

關於作者

我是 Fngi，專注在 AI 資安、LLM 紅隊與 AI 治理框架落地。平常的 AI 攻防筆記發在 IG：

@aid3fend

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