三十天的一句話總結

如果只能留一句話：

去識別化不是一個功能，是一個貫穿資料流每一段的邊界設計； 而它的價值上限，取決於你怎麼處理「偵測一定會失敗」這件事。

前半句是 D2 的結論——先畫資料流，再選工具。後半句貫穿了 D8、D21、D25：偵測的 Recall 不會是 100%，所以架構必須在「漏抓已經發生」的前提下仍然能保護資料。

通用架構圖

┌────────────────────── 受控邊界（行內） ──────────────────────┐
│                                                              │
│  ① 上傳          原始檔                                       │
│     ↓            ├─ 格式分流（原生/掃描/DOCX/EML/圖片）        │
│  ② 解析          └─ 完整性檢查（防靜默失效）                   │
│     ↓                                                        │
│  ③ 偵測          ├─ 規則層（regex + 檢查碼 + hotword）        │
│     ↓            ├─ 語意層（Encoder NER，不執行指令）          │
│     ↓            ├─ 金絲雀驗證（確認偵測器存活）               │
│     ↓            └─ 合理性檢查 ── 異常 → 【擋】                │
│     ↓                                                        │
│  ④ 去識別化      ├─ Token 化（FPE，無狀態）                   │
│     ↓            ├─ 查表替換（自由文字）→ Token Vault         │
│     ↓            ├─ 概化（地址、日期）                        │
│     ↓            └─ 遮罩（特種個資，不可還原）                 │
│     ↓                                                        │
│     ├──────────────→ 【Token Vault】                         │
│     ↓                 · 加密儲存 + CMEK                       │
│     ↓                 · scope 派生金鑰                        │
│     ↓                 · 網路隔離 · 身分隔離                   │
│     ↓                 · 生命週期 + crypto-shredding           │
└─────┼────────────────────────────────────────────────────────┘
      ↓ 只有去識別化文字通過
┌─────┼──────────── VPC Service Controls ─────────────────────┐
│  ⑤ 護欄（輸入） → ⑥ LLM 推論 → ⑦ 護欄（輸出）                │
└─────┼────────────────────────────────────────────────────────┘
      ↓
┌─────┼────────────────── 受控邊界（行內） ────────────────────┐
│  ⑧ 還原          ├─ 權限檢查（RBAC + 條件式）                 │
│     ↓            ├─ 理由代碼 + 核准（超量時）                 │
│     ↓            ├─ 速率限制 + 異常偵測                       │
│     ↓            ├─ write-ahead audit                        │
│     ↓            └─ 不可還原欄位明確標示                      │
│     ↓                                                        │
│   使用者                                                     │
└──────────────────────────────────────────────────────────────┘

橫貫全流程：稽核軌跡（不可竄改、可歸屬、可串接、獨立專案）

三十天的核心結論清單

架構

1. 先畫資料流，標註每段的資料狀態、位置、可存取者（D2）
2. 攻擊面在去識別化引擎和 Vault，不在雲端模型（D3）
3. 關鍵路徑上放不會執行指令的元件（D6、D22）

偵測 4. 規則層與語意層互補，取聯集不取交集（D5） 5. False Negative 才是要命的，用 F-beta 或 Recall 底線（D8） 6. 分子集報告，不要只看總體數字（D8）

去識別化 7. 只有 Token 化可逆，遮罩與概化不可逆（D9） 8. 可還原是成本不是功能，預設不可還原（D9） 9. 同型替換優於佔位符（D10） 10. FPE 無狀態，能用就用，Vault 越小越好（D11）

隔離 11. scope 級一致性：案件內一致，跨案件不可關聯（D16、D18） 12. crypto-shredding 讓「刪除」變得可證明（D18） 13. 「需要關聯」和「需要還原」用兩套識別碼滿足（D18）

失效處理 14. fail-closed 是預設，fail-open 是需要簽核的例外（D21） 15. 金絲雀檢查每次呼叫都驗證偵測器存活（D21） 16. 降級而不是關閉，並提供有記錄的例外通道（D21）

驗證 17. 七項重大失敗一票否決，不與其他指標相抵（D25） 18. 紅隊產出應該是測試案例，不是報告（D26） 19. 每次事故先寫一個會失敗的測試（D26） 20. Adversarial 子集測的是失效處理，不是偵測能力（D27）

可以複製到哪些場景

這套架構的核心不是「法務部」，而是**「敏感文件 + 外部推論服務」這個組合**。所以它可以直接搬到：

人資部門。 履歷、考績、離職面談紀錄、健康檢查報告。個資密度跟法務部同級，而且特種個資比例更高（健檢資料）。

客服中心。 通話逐字稿、客訴紀錄。額外的挑戰是即時性——通話中的分析需要低延遲，這會壓縮偵測的時間預算。

授信與徵信。 財力證明、聯徵報告、擔保品資料。這裡的準識別碼問題特別嚴重，因為財務數字本身就是很強的識別特徵（D17 提過的金額問題）。

理賠審查。 保險理賠涉及大量醫療資訊，幾乎全是第 6 條特種個資。這個場景的正確答案很可能是「不要上雲」，而這套架構能幫你論證這個結論。

內部知識庫的 RAG。 這是最容易被忽略的一個。把內部文件做成向量索引供全公司查詢時，D18 的 scope 隔離會變成關鍵——沒有它，檢索會跨越原本的權限邊界。

這套架構不適合的場景

誠實地講幾個：

需要極低延遲的場景。 完整的偵測管線有延遲成本。即時對話、串流處理可能撐不住。

資料本身就是識別碼的場景。 例如「查詢某個客戶的所有交易」，你沒辦法去識別化查詢對象本身。

需要模型記住個資的場景。 例如個人化助理。去識別化跟個人化在目標上是衝突的。

遇到這些場景時，正確的答案通常是改變架構（例如全地端）而不是弱化防護。

如果你要開始做

我的建議順序：

1. 先畫資料流（D2）。不要先選工具。
2. 確認邊界定義（D29）。三種「不出境」是哪一種，跟法遵確認。
3. 列出重大失敗模式（D25）。在寫程式之前就定義好什麼叫失敗。
4. 建評測集（D8）。四個子集，特別是 Adversarial。
5. 實作規則層（D5、D7）。快、可解釋、先有基準線。
6. 加語意層（D6）。補規則的洞。
7. 設計 Vault 與隔離（D12、D18）。
8. 做 fail-closed 與金絲雀（D21）。
9. 做稽核軌跡（D20）。
10. 把紅隊變 CI（D26）。

第 3 步的位置是刻意的。在寫程式之前先定義失敗，會讓後面每一個技術決策都有判準。

最後

三十天寫下來，我自己最有感的是 D21 那個金絲雀技巧和 D25 的七項重大失敗。

前者是因為它成本極低、效果極好，卻很少在架構文件裡看到。後者是因為它改變了整個專案的溝通方式——當你把「什麼叫做失敗」講清楚，關於「這樣做夠不夠」的爭論會少一大半。

如果這三十篇裡只有一件事被帶走，我希望是這句：

不要假設偵測會成功。架構的品質，取決於它在偵測失敗時做了什麼。

感謝一路看到這裡。

關於作者

我是 Fngi，專注在 AI 資安、LLM 紅隊與 AI 治理框架落地。
IG：@aid3fend
有想討論的架構細節或不同意見，留言或私訊都歡迎。