先更正一個名稱：Cloud DLP 已經不是官方叫法

如果你的簡報或文件裡還在用「Cloud DLP」當作主要名稱，需要更新一下：這項服務已經整合進 Sensitive Data Protection 這個產品家族，底層的 API 名稱維持不變（仍是 Cloud Data Loss Prevention API，DLP API），但對外的產品層級名稱已經是 Sensitive Data Protection。實務上兩個名稱現階段會混用一段時間，寫文件時建議用「Sensitive Data Protection（原 Cloud DLP）」這種寫法，兼顧新舊讀者的搜尋習慣。

為什麼 AI 資料流特別需要這一層

Week 2 的 IAM、Day13 的 VPC-SC 管的是「誰能存取」「資料能不能跨邊界」，但沒有回答「這份資料裡面到底有沒有不該存在的敏感內容」。訓練資料、RAG 知識庫、甚至使用者與 Agent 的對話記錄，都可能夾帶個資、財務資訊、醫療紀錄——如果沒有在資料進入 AI 系統前先做掃描與遮罩，前面所有的存取控制都只是在保護一份「本來就不該長這樣」的資料。

這正好呼應 Day5 提過的 12 項能力缺口裡的 D2：RAG 資料分層（索引權限、PII 脫敏）——Sensitive Data Protection 是落實這項能力缺口的具體工具。

核心能力：偵測、分類、去識別化

Sensitive Data Protection 提供超過 150 種內建的敏感資訊類型（infoType）偵測器，涵蓋信用卡號、身分證字號、健康紀錄等常見類型，也支援自訂偵測規則。偵測之後的處理方式包含：

• 遮罩（Masking）：把敏感字元替換成固定符號
• 紅字塗銷（Redaction）：直接移除敏感內容
• 格式保留加密（Format-Preserving Encryption）：把敏感資料加密，但保留原本的格式（例如身分證字號加密後長度、格式不變，方便下游系統繼續處理）——這跟你之前在 VeilClaw 探索過的 FF3-1 FPE 概念是同一個技術方向
• 日期位移（Date Shifting）：對時間序列資料做一致性的位移，保留資料的時間關聯性但模糊掉真實日期

AI 場景的兩個應用時機

訓練/微調前：資料進入訓練 pipeline 之前先跑一輪 Sensitive Data Protection 掃描，找出並處理個資，避免模型「記住」不該記住的敏感內容。

推論輸出後：對話記錄、Agent 輸出結果在寫入 log 或資料庫之前，先做一輪掃描遮罩，避免敏感資料透過日誌系統外洩——這一步經常被忽略，很多團隊只顧著保護輸入，卻讓輸出原封不動地寫進沒有存取控制的日誌系統。

待實測提醒：內建 infoType 偵測器的數量與涵蓋範圍會持續更新，發布前請對照 Sensitive Data Protection 官方文件 確認目前支援的偵測器清單是否符合你要保護的資料類型（尤其台灣本地的身分證字號、健保卡號等格式，需確認是否有對應的內建或自訂偵測規則）。

這篇的檢查清單

• [ ] 訓練/微調資料在進入 pipeline 前是否經過敏感資料掃描？
• [ ] 推論輸出寫入 log／資料庫前是否也做了遮罩處理，而非只顧輸入端？
• [ ] 是否已確認台灣本地格式（身分證字號等）的偵測規則涵蓋範圍？