三個常見的寫法問題

問題一：不可量測。

系統應能有效偵測個人資料。

「有效」是多少？誰判定？這種寫法在驗收時一定會變成爭論，而且爭論的結果通常是「看起來還行就過」。

問題二：不可能滿足。

D9 講過那個例子：要求三種去識別化手法都能還原。這在邏輯上不成立。

這類需求通常來自「把所有想要的功能都列上去」，沒有檢查彼此相容性。結果是廠商要嘛做不出來，要嘛用一個假的實作騙過驗收（例如「遮罩」其實偷偷存了原值）。

後者比前者危險。 因為驗收過了，但你的架構裡多了一個沒人知道的明文儲存點。

問題三：只有加權平均，沒有一票否決。

D25 講過。95 分但原文外洩過一次，不應該通過。

一個可用的結構

驗收標準
├── A. 功能完備性（可量測，加權計分）
├── B. 品質指標（量化門檻，未達即不通過）
├── C. 重大失敗模式（一票否決）
└── D. 文件與可稽核性（檢核表）

A. 功能完備性

用行為描述而不是形容詞：

A-1 系統應能處理下列格式：PDF（原生）、PDF（掃描）、DOCX、 XLSX、EML、JPG/PNG。對每一格式，應能正確抽取文字內容， 並在抽取失敗時明確回報錯誤而非回傳空結果。

測試方法：對每種格式各提供 10 份測試文件（含 2 份異常檔）， 檢查抽取字數與標準答案的差異率 < 5%，且異常檔皆回報錯誤。

每一條都包含：做什麼、怎麼測、通過標準。三者缺一，這條就不可驗收。

B. 品質指標

這是 D8 的成果。關鍵是分類型、分子集報告：

B-1 直接識別碼（身分證字號、護照、健保卡、信用卡、帳號） 　　Recall ≥ 0.99，於 Clean 與 Noisy 子集皆須達標。

B-2 準識別碼（姓名、地址、出生日期） 　　Recall ≥ 0.95（Clean）、≥ 0.90（Noisy）。

B-3 特種個資（健康、犯罪紀錄） 　　Recall ≥ 0.95。

B-4 誤判率：Negative 子集的 False Positive Rate ≤ 0.05。

B-5 Adversarial 子集：不設 Recall 門檻，但須提供完整結果， 　　且不得出現 F1（原文外洩）。

B-5 的設計值得說明。Adversarial 子集是刻意設計來規避偵測的，要求高 Recall 不合理——攻擊者總能想出新方法。

但不論偵測有沒有成功，都不能發生原文外洩。因為當偵測失敗時，fail-closed 應該接住它（D21）。所以 Adversarial 子集測的不是偵測能力，是失效處理能力。

這個區分很重要，也是這份驗收標準裡我最想強調的設計。

C. 重大失敗模式

直接引用 D25 的七項，加上測試方法與判定依據。

D. 文件與可稽核性

這一段常被當成形式，但它決定了系統上線後能不能被治理：

D-1 架構文件應載明：資料流每一段的資料狀態（明文／去識別）、 儲存位置、可存取身分。

D-2 應提供 fail 策略說明文件，載明每個環節失敗時的行為 （擋／降級／略過），並經資安單位簽核。

D-3 應提供金鑰管理說明：金鑰層級、輪替週期、輪替程序、 緊急撤銷程序。

D-4 應提供偵測政策的版本管理機制，且稽核日誌須記錄 每次處理所使用的政策版本。

D-5 應提供不可還原欄位清單，並說明系統在收到該欄位的 還原請求時的回應行為。

D-2 那個簽核要求是刻意的。讓 fail 策略成為一個有人負責的決定，而不是程式碼的副作用（D21 的結論）。

還原一致性：那個邏輯陷阱的正確寫法

回到 D9 的問題。正確的寫法是把還原能力依手法區分：

B-6 還原正確性

對於採用 Token 化（可逆）處理的欄位：

• 經授權還原後，應 100% 還原至原始值
• 同一 scope 內，同一原值應對應同一 Token（一致性）
• 不同原值不應對應同一 Token（無碰撞）

對於採用遮罩或概化（不可逆）處理的欄位：

• 系統應於還原回應中明確標示該欄位不可還原及其原因
• 不得回傳錯誤、空值或猜測值
• 不得於任何位置留存該欄位之原始值

測試方法：以 200 筆合成資料進行去識別化與還原， 逐欄位比對。可逆欄位比對還原值與原值；不可逆欄位 檢查回應格式，並以資料庫全文搜尋確認原值未被留存。

最後一句是關鍵：用全文搜尋確認不可逆欄位的原值真的不存在。這是防止「假遮罩」（實際上偷偷存了原值）的唯一方法。

驗收怎麼進行

建議三階段：

階段一：文件審查。 先看 D 項。文件不齊全就不進入測試——因為你無法驗證一個沒有規格的系統。

階段二：功能與品質測試。 A 和 B 項，用標準測試集跑。測試集應該由需求方提供，或至少需求方要能驗證。

階段三：對抗測試。 C 項，加上 Adversarial 子集。這一階段建議由獨立的第三方或內部紅隊執行，不要讓開發方自己測。

三個階段有先後順序，前一階段不過不進入下一階段。

最後一個建議：把測試集交給對方

有些採購會把測試集當成秘密，怕廠商針對測試優化。

我的看法相反：把 Clean、Noisy、Negative 三個子集公開給廠商，Adversarial 子集保留。

理由是：前三個子集代表的是「正常應該做到的事」，廠商本來就該針對它優化——那叫做把產品做好。保密只會讓廠商交出一個沒針對場景調校的通用產品。

Adversarial 保留，是因為那一組測的是「面對未知攻擊時的行為」，公開就失去意義。

明天談法規對應。

關於作者

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

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