先界定資料邊界，而不是先寫遮罩規則
第一個工程問題不是如何辨識電子郵件，而是哪些資料在什麼情境下可以送往哪一個模型。姓名、電話、身分證字號與付款資訊通常容易歸類；企業內部的客戶編號、報價、設備序號、原始碼、合約條款及尚未公開的營運資訊，也可能同樣敏感。若只處理傳統個資，管線仍可能把具商業價值的內容完整送到外部服務。
建議先建立資料分類與目的矩陣，記錄資料類型、來源、允許的模型環境、是否可以遮罩、是否必須阻擋，以及回應後是否需要還原。內部部署模型、具企業資料條款的受控端點與一般外部 API，可以採用不同政策。決策應同時考量資料最小化、模型完成任務所需的語意、資料保存設定、區域要求與使用者權限，而不是讓所有請求共用同一套寬鬆規則。
偵測應採分層設計
單一偵測方法通常不夠可靠。正規表示式適合格式穩定的欄位，但容易誤判訂單編號，也可能漏掉加入空格、全形符號或換行的資料。命名實體辨識能找到自然語句中的人名與地址，卻未必理解企業特有代碼。較實用的流程會先正規化輸入，再組合格式規則、校驗邏輯、欄位結構、詞典、實體模型與上下文判斷。
- 格式層：偵測電子郵件、電話、IP、憑證、金融帳號及常見識別碼，並在可行時驗證校驗碼。
- 結構層：利用 JSON 欄位名稱、資料庫欄位、表單標籤與文件區段，提高判斷可信度。
- 語意層：辨識姓名、地址、醫療或人資敘述，以及沒有固定格式的商業機密。
- 企業規則層：維護產品代號、內部專案名稱、客戶代碼與禁止外傳詞彙。
每一筆命中應保留類型、原文位置、偵測器、信心等級與政策結果，但不應把原始敏感值寫入一般日誌。多個偵測器重疊時，先合併區間並採較嚴格的分類，避免重複替換造成文字損壞。對長文件則應在分段前後都保留位置映射，否則跨段落的地址或帳號可能被漏掉。
遮罩方式要配合任務
刪除所有敏感內容最安全，卻可能讓模型失去完成工作的必要關係。例如客服摘要需要知道同一位客戶在不同訊息中重複出現，但通常不需要真實姓名。此時可用穩定代碼替換，例如將同一請求中的姓名映射為 PERSON_1，並讓電話與訂單分別使用不同類型的代碼。模型仍能理解實體關係，又不會看到原值。
實務上可將處置分為允許、一般化、不可逆遮罩、可逆代碼化與阻擋。可逆對照表應只存在於受控服務，設定短效期限、加密保存，並綁定租戶、使用者與請求；模型不可取得還原工具。若任務只需要區域，可把完整地址一般化為縣市；若需要判斷付款問題，保留卡片類型與末段識別通常比傳送完整號碼合理。密碼、私鑰、存取權杖等憑證則應直接阻擋並觸發安全處理，不應嘗試讓模型繼續使用。
把防線放在所有模型入口
遮罩服務應位於應用程式與模型供應商之間的集中式閘道，而不是散落在各個聊天頁面。閘道接收文字、附件解析結果、RAG 擷取片段、工具參數與對話歷史，套用租戶政策後才建立模型請求。這能避免背景工作、批次摘要或新功能繞過前端檢查，也能一致管理 AWS、GCP 或不同模型端點。
RAG 需要特別處理兩個時間點：資料建立索引前，以及檢索結果送入生成模型前。若原始文件不應進入外部嵌入服務，就要在產生向量前遮罩，或改用受控的嵌入環境；查詢階段仍需再次檢查，因為權限變更、舊索引與文件組合都可能帶來新風險。工具呼叫也不能例外，寄信內容、CRM 查詢條件與 ERP 更新欄位在執行前都應重新套用資料政策。
以誤判成本與可觀測性維運
敏感資料偵測不是一次上線後就完成。測試集應涵蓋真實格式的合成資料、全形與半形字元、錯字、跨行內容、表格、OCR 雜訊，以及看似敏感但其實是產品或訂單代碼的負例。除了精確率與召回率，也要分資料類型觀察漏判、過度遮罩、阻擋原因與模型任務是否仍可完成。不同類別的錯誤成本不同：漏掉私鑰通常比把一般流水號誤判為帳號更嚴重。
營運日誌應記錄政策版本、命中類別、處置方式、模型目的地與延遲，不記錄原文；必要的稽核樣本則放在權限更嚴格、保存期明確的環境。規則更新應先以影子模式執行，觀察會阻擋哪些請求，再逐步啟用。最後，模型回應仍要做輸出檢查，因為提示內容、RAG 文件或工具結果都可能讓敏感資料在另一端重新出現。成熟的管線不是追求零誤判，而是讓每個例外都有明確政策、負責人與可驗證的處理路徑。