生成式 AI 資料外洩不只發生在員工把機密貼進聊天框。敏感資料也可能從附件、RAG 知識庫、模型輸出、外掛工具、系統日誌或第三方服務邊界流出。企業需要同時管理「誰能輸入、模型能讀什麼、輸出能去哪裡」，才能安全使用 AI。
生成式 AI 為什麼會洩漏機密？
大型語言模型擅長重新組合上下文，但不會自動理解企業的機密分級與授權規則。如果應用程式把過多文件交給模型、RAG 檢索沒有依使用者過濾、工具權限過大，或日誌完整保存提示與回答，敏感資料就可能越過原本的存取邊界。
OWASP LLM02:2025 說明敏感資訊可能因輸出、訓練資料或應用整合而暴露；NIST AI RMF Playbook 則強調以治理、盤點、衡量與管理方式處理 AI 風險。
七條常見外洩路徑
- 提示與附件：員工為了摘要或改寫，直接貼入客戶資料、合約、程式碼或未公開財務內容。
- RAG 權限錯置：檢索只看文件相關性，沒有依使用者身份、部門與案件權限過濾。
- 模型輸出：回答引用不該顯示的段落，或把敏感內容帶入報告、Email 與公開頁面。
- 外掛與工具：AI 把上下文傳給搜尋、翻譯、CRM、郵件或其他第三方 API。
- 日誌與追蹤：除錯、監控、Prompt history、快取與分析平台保存完整資料，存取權卻比原系統更寬。
- 供應商邊界：資料保存位置、模型訓練政策、次處理者、刪除期限與事件通報不清楚。
- Shadow AI：員工自行使用未核准服務，企業無法知道輸入了什麼，也無法要求刪除或調查。
企業情境：內部知識庫為何可能跨部門洩漏？
假設公司把人資、業務與法務文件放進同一套向量資料庫，只靠語意相似度找資料。業務同仁詢問合約範本時，系統可能同時檢索到員工薪資附件或未公開爭議案件。即使原始檔案在共享磁碟有權限，若建立索引時沒有保留 ACL，AI 回答就可能跨越部門邊界。
修正重點不是要求模型「不要洩漏」，而是在檢索前驗證使用者身份，依文件權限過濾候選資料，並讓輸出保留來源與敏感等級，必要時遮罩或拒絕回答。
七道可落地的防線
1. 資料分類與盤點
先定義公開、內部、機密、個資與受法規限制的資料，盤點哪些 AI 功能會接觸各類資料，指定擁有者與保存期限。沒有分類，就無法決定哪些內容能進入模型。
2. 清楚的輸入政策
告訴員工哪些服務已核准、哪些資料禁止輸入，並在介面提供提示與必要的偵測阻擋。政策要搭配可用的企業工具，否則員工仍可能轉向 Shadow AI。
3. 最小權限與身份傳遞
AI 不應使用一個可讀取全公司的共用帳號。查詢、RAG 與工具呼叫都要傳遞目前使用者身份，限制資料範圍、動作與有效時間。
4. RAG 存取控制
索引必須保留文件 ACL、部門、案件與敏感標籤；檢索前先做授權，再做語意排序。文件權限改變或撤回時，索引也要同步更新。
5. 輸出檢查與人工核准
在回答送出、寄信、建立工單或公開發布前，檢查個資、金鑰、機密標籤與目的地。高影響動作由人員確認，不讓模型自行判斷是否可以外傳。
6. 日誌去敏感化
日誌只保留調查必要欄位，遮罩內容、分離身份、限制查詢權限並設定刪除期限。除錯模式不應長期在 production 保存完整 Prompt 與附件。
7. 供應商治理與事件應變
確認資料是否用於訓練、存放地區、保留時間、次處理者、加密、刪除與通報條款；預先準備停用連線、撤銷金鑰、刪除資料與通知關係人的程序。
誰應該負責這七道防線？
AI 資料保護不能只交給資訊部門。資料擁有者負責分類與使用目的，IT 負責身份、權限與日誌，資安負責威脅模型、監控與事件處理，法務與採購確認供應商條款，業務部門則決定哪些輸出需要人工核准。每個 AI 使用案例都應有一位可對風險與停用決策負責的服務擁有者。
企業可以從小範圍開始：先允許公開或低敏感資料、預設不連接高權限工具，通過測試後才逐步增加能力。這比一開始把所有資料接入，再靠員工自行判斷是否能問，更容易維護也更容易稽核。
上線前檢查表
- AI 功能可讀取哪些資料？是否超過目前使用者權限？
- RAG 索引是否保留並強制執行文件 ACL？
- Prompt、附件、回答與工具參數會保存在哪些日誌？
- 資料是否會傳給第三方模型、外掛或次處理者？
- 是否能阻擋機密輸出並讓高風險動作人工核准？
- 發生外洩時，能否追查、撤銷、刪除與通知？
結論：把 AI 納入既有資料治理
生成式 AI 資料外洩不是單一模型問題，而是身份、權限、資料流、日誌與供應商共同形成的風險。企業應先縮小資料範圍，再逐步開放功能。若需要盤點資料流與權限，可參考 AiLab 的解決方案，或先閱讀諮詢指南整理需求。