RAG 部署資料流：六層處理、外部傳輸與營運權責

選擇 RAG 元件的地點之前，先畫出資料流。原文、切片、向量、查詢、檢索內容、模型輸出和日誌，可能送到不同服務；其中一層留在內網，不代表其他處理也留在內網。

這篇提供元件與權限的檢視方式。需要比較託管方案和完整成本時，閱讀地端與雲端方案比較。

六層清單要連起來看

部署選項會互相影響。Embedding 服務可能接收文件切片；生成服務可能接收查詢與檢索段落；日誌又可能留住輸入或輸出。不要把六層當成互不相關的地點開關。

對每個傳輸記錄來源、目的地、實際處理者、地點、內容、用途與保留期限。管理、支援、備份和觀測服務也要列入，不能只看主資料庫。

先確認資料與用途的適用條件、契約及負責角色。敏感資訊需要評估，但不直接推論一定得用地端模型。反過來，公開文件集合也不表示查詢、混入的附件或日誌必然都是公開內容。

金融機構委外規範於 2026 年 4 月 13 日修正，其涵蓋機構的境外與雲端委外有具體條件及管理責任。依機構、作業、資料與條文確認，不把它改寫成所有金融與醫療資料禁止出境，也不據此核准本案傳輸。

依個人資料保護法確認目的、個人與醫療資料條件、接收者及保護措施。去識別化片段、網路隔離或認證名稱，都不能單獨代替這項確認。

NIST 的雲端定義區分服務控制與部署模型，私有雲也可能由第三方營運、位於外部。VPC 不是「沒有第三方」的證明；地端設備也可能呼叫外部 API。

2023 年 EMNLP 的原始研究在特定模型與資料中展示文字重建及個人資訊風險。它支持保護 embedding 與檢查暴露，不表示所有向量都能反推，也不提供某家客戶或當前系統的重建比例。

不要因為去掉姓名、改存向量或使用加密，就推論資料一定無法識別個人。評估實際內容、存取、接收者及可能的重建風險；也不把「絕對不能反推」寫成這些來源未建立的通用法律測試。

假設一套核准的內部手冊查詢，需要限制可見文件並禁止部分段落送給外部服務。檢查實際檢索、提示與日誌，不只測正常回覆；也測存取被撤回、來源移除、服務失效或錯誤路由時的行為。這是待驗證的設計，不是已有自動安全功能。

日誌只保留工作需要的內容，控制敏感輸入與輸出，不把「完整可回溯」解讀成無限制保存所有資料。確認誰能查看、何時刪除，以及事件調查的合法需要。

把核准資料流、控制、依賴及未解問題帶到現有RAG 知識系統規劃。每項控制有接受證據與責任人，版本或供應商條件改變後查看受影響範圍。稽核、日常使用、答案品質與營運接受分別判斷；混合或全地端的名稱不替你完成這些工作。