生成式 AI 客服如何保護個資？

情境

先感受問題：AI 客服洩漏了用戶電話

「電通電信」的 AI 客服小組剛完成 beta 測試，卻發現一個嚴重問題：當測試人員問「上個月我的帳單」，AI 有時會生成「您好，陳大明先生，您的電話 0912-345-678 上月費用 1,280 元……」這類回覆，把其他用戶的資訊也帶出來了。

這是典型的「訓練資料記憶洩漏（Memorization Leakage）」問題：語言模型從訓練資料裡「背住」了真實個資，在特定提示下吐出來。

法務部門亮紅燈：這樣的系統違反個資法，上線前必須解決。

舊方法

不做源頭處理，只靠後端防護有什麼問題

1. 模型已記憶，擋不完：語言模型在訓練後就把個資「燒進」了參數，靠輸出過濾每次都要人工審查，漏網機率高，成本極大。
2. 關鍵字過濾容易繞過：只設定「不顯示姓名」，模型用拼音、暗語或間接描述仍可能洩露；攻擊者只需稍微換個問法就能繞過。
3. 強化學習不能根除記憶：用強化學習「懲罰」洩漏行為，是行為層修正，不能消除模型已記住的敏感資訊；且容易過度限制，讓客服回覆失去正常功能。
4. 同態加密不適合 NLP 生成任務：同態加密讓計算在加密域進行，但語言模型需要理解文字語意才能生成，加密後語義完全消失，無法訓練也無法生成有意義回覆。
5. 合規缺口仍在：若訓練資料中仍保有原始個資，即使最後輸出被擋下，資料持有本身就已違規，個資法要求的是「不持有不必要的個人識別資訊」，不只是「不輸出」。

新方法

源頭匿名化加輸出稽核，雙層防護

電通電信的正確做法分兩層：

第一層（訓練前）：對所有訓練資料做匿名化或偽匿名化處理。把真實姓名換成「用戶_001」，電話換成亂碼，交易金額做模糊化。模型訓練後，參數裡就不含原始個資，洩漏風險從根源消除。

第二層（輸出後）：建立稽核機制，用正則表達式或 NLP 過濾器掃描每次輸出，若偵測到疑似個資格式（11 位數字、email 格式等）就攔截並記錄。

雙層防護才能真正符合個資法「資料最小化（Data Minimization）」原則。

這就是選項 A 講的：在訓練資料前進行資料匿名化（Anonymization）或偽匿名化（Pseudonymization）處理，並建立輸出內容稽核機制。

錯選項

為什麼其他選項是錯的

變形題

同個考點下次怎麼變形

延伸

想再往下看，這 5 個

• 資料隱私（Data Privacy）
  個資保護的核心概念，規範如何合法收集、使用、保護個人識別資訊。
• 差分隱私（Differential Privacy）
  在訓練時加入統計雜訊，防止模型記住個別訓練樣本的隱私保護技術。
• 同態加密（Homomorphic Encryption）
  允許在加密資料上直接計算，但對語言模型的語義任務目前不具實務可行性。
• 聯邦學習（Federated Learning）
  讓模型訓練在本地進行，不上傳原始資料，是另一種兼顧隱私的 AI 訓練方案。
• AI 治理（AI Governance）
  制定 AI 系統的合規框架與審查機制，確保系統符合法規與倫理要求。