企業 RAG 知識庫怎麼防資料外洩？從文件上架到權限稽核的 5 個實務

RAG 的風險不只在模型回答錯誤

RAG 讓 AI 可以依據最新的 SOP、合約、產品規格與內部資料回答問題，因此很適合作為企業知識庫的起點。不過，資料一旦經由上傳、同步或批次匯入進入檢索流程，也會帶來新的攻擊面：過期版本可能被取回、不同部門資料可能被混查，文件中甚至可能夾帶試圖改變模型行為的文字。

OWASP 將提示注入、敏感資訊揭露、資料與模型污染，以及向量與嵌入弱點列為生成式 AI 需要處理的風險。RAG 的價值在於提供資料依據，不代表它能取代授權、輸出驗證或資安治理。

第一步：文件上架必須有擁有者、版本與失效規則

每一份會進入知識庫的 SOP、報價、規章或技術文件，都應標示擁有單位、生效日期、版本與審核狀態。當制度更新時，舊版文件應下架、封存或明確標示為歷史資料，避免 AI 同時取回互相矛盾的規範。

• 指定文件擁有者與核准流程，避免任何人都能直接上架正式資料。
• 以文件類型、部門、有效期間與敏感等級建立中繼資料。
• 保留刪除、替換與重新建立索引的紀錄，讓答案可以追溯。

第二步：權限要在檢索前生效，而不是交給模型判斷

業務、財務與人資即使都在同一個 AI 系統中提問，也不應看到相同的文件集合。正確作法是沿用企業帳號、部門、角色或專案權限，在檢索階段先過濾可取回的內容；模型只處理使用者本來就有權閱讀的資料。

權限規則不能只寫在提示詞裡。提示詞可以協助引導回答，但真正的資料存取限制必須由身分驗證、資料庫查詢條件與文件存取控制共同執行。

第三步：把檢索到的文件視為不可信輸入

文件中可能包含看似正常、實際上卻要求 AI 忽略規則或執行外部動作的內容。系統應明確區分系統規則、使用者問題與檢索文件；檢索內容只能作為事實依據，不能擁有改寫權限、執行工具或覆蓋系統規則的能力。

若 AI 後續可建立訂單、修改主檔、付款或發送通知，模型建議更不應直接成為執行命令。高風險動作應具備獨立授權、欄位驗證與人工確認。

第四步：答案要附來源，找不到依據就拒答或轉人工

對制度、合約、報價與技術規格等重要問題，回答應能指出來源文件、版本與相關段落。若檢索結果不足、來源互相衝突，或問題超出知識庫範圍，系統應清楚說明無法確認，並提供人工窗口，而非以看似流暢的文字補足答案。

第五步：建立稽核與測試迴路，持續驗證權限邊界

上線前應以不同角色帳號測試：是否能檢索到其他部門、其他客戶或歷史失效資料；上線後則保留必要的查詢身分、時間、文件範圍與處理結果，用於異常追查與品質改善。記錄應遵循最小化原則，避免將完整敏感內容再次複製到日誌。