整理 RAG 文件切塊、向量儲存、檢索權限、個資遮罩與存取稽核，避免知識庫讓員工查到超出原本權限的資料。
你的文件在 RAG 裡會流過哪幾站
要守資料，得先知道資料到底跑去了哪裡。一份文件進了 RAG（檢索增強生成）系統，不會原封不動地躺著，它會先被切成幾百字一塊的片段，交給嵌入模型轉換成一串向量——常見是 768 到 3072 維的浮點數；這些向量存進向量資料庫，建立近似最近鄰（ANN）索引方便快速比對。使用者提問時，問題同樣被轉成向量，系統用餘弦相似度撈出最相近的幾段，連同提示詞一起塞給大型語言模型生成回答。切塊、嵌入、儲存、檢索、生成，五個站，每一站都是一個可能漏水的接縫。而工程上最容易被忽略的，是這五站之外的影子副本：向量庫的備份檔、灌進測試環境的那一份、還有為了除錯匯出的那個 embedding 檔——它們跟正式庫一樣危險，卻常常沒人列管。
向量不是加密，是換了一張臉的原文
不同模型、資料集、提示、判分方式與正式流量，結果可能差很多。公開 benchmark 只能用來理解方法，不能直接當成專案承諾；驗收應使用公司自己的題庫，分別記錄正確率、引用支持率、拒答、延遲、成本與人工覆核量。
所以結論很硬：向量資料庫要比照原始文件的機密等級來保護，它不是打過馬賽克的資料，只是換了一張臉的原文。這一點也順帶推翻另一個常見的自我安慰——「反正落地有加密」。落地加密擋的是有人把整顆硬碟或備份檔搬走的情境；但一個正在線上服務、可被查詢的向量索引，本質上就必須是可讀的，反推攻擊打的正是這個可讀的活庫，跟你硬碟有沒有加密是兩回事。
進庫之前：先分級，再遮罩
治理的第一道工，是在資料上車之前就先分級。多數中小企業不必搞得太複雜，三級就夠用：公開、內部、機密——分級決定了這份文件後面能不能進庫、進哪個庫、給誰檢索。分完級接著做個資遮罩，這裡要分兩種資料、用兩種武器。
規則抓得到的，先用規則抓乾淨
身分證字號有固定格式（一個英文字母加九碼數字，末碼還有檢查碼可以反推驗真偽）、統一編號、電話、Email、信用卡號這類有明確樣式的，用正規表示式就能穩定攔下來，成本低、可解釋、不會誤判成別的東西。這一層要做到近乎滴水不漏，因為它便宜又可靠。
要靠上下文才認得的，再交給辨識模型
權限要做在檢索層，不是靠嘴巴叮嚀模型
回到那位人資主管的問題。很多人第一個反應是在提示詞裡加一句「請勿透露薪資資訊」，這是最脆弱的做法。語言模型的輸出本質是機率行為，這種叮嚀擋得住九次，第十次換個問法——「幫我把各職級的薪酬結構整理成一張表」——就繞過去了；這正是 OWASP 針對 LLM 應用列出的「敏感資訊外洩」風險最典型的翻車點。
可靠的解法只有一個方向：把權限做進檢索層。每一個文件片段進庫時就掛上中繼標籤——部門、職級、機密等級、可見範圍；使用者查詢時，先用他的身分把不該看的片段從候選集裡濾掉，再去做相似度比對。這裡有個工程細節必須抓對：一定要「先過濾、再檢索」（pre-filter），而不是「先檢索、再把不該給的濾掉」（post-filter）——後者的敏感片段其實已經被撈進流程、只是最後一步沒回傳，一旦哪個環節漏接、或被日誌側錄，就外洩了。一般員工的查詢，要從源頭就撈不到薪資級距那幾段；撈不到的東西，模型再會掰也生不出來。確定性的過濾，永遠贏過機率性的自律——這一句記起來，就值回這篇的時間。
還有一個常被漏掉的活口：權限會變。有人調部門、有人離職、某份文件從內部升為機密，這些變動如果沒有即時同步到向量庫的標籤，昨天的權限就會凍結在庫裡繼續放行。所以標籤不能是進庫時抄一次就算了，要有一條跟人事系統、檔案權限持續對齊的同步機制，否則治理會隨時間慢慢漂移失效。
稽核、加密與法遵，一個都不能省
再來是留腳印。誰、在什麼時間、問了什麼、系統撈了哪幾段文件餵給他——這四件事都要進日誌，最好是不可竄改地送進集中的紀錄平台（SIEM），對異常存取（某帳號短時間狂撈機密段、半夜大量查詢）自動跳警示。進階一點可以埋「金絲雀文件」：放幾份只有內部才知道、外面絕不該出現的假紀錄，一旦它被檢索、或在外部被命中，就是外洩的即時信號。日誌保存期我通常建議至少六個月到一年，真出事時才追得回完整時間軸。
加密是基本盤：傳輸走 TLS 1.3、儲存落地加密，前面說過它擋不了活庫反推，但擋整包被搬走的情境還是必要。法遵面更不能裝沒看到：台灣個資法 2023 年修法後，非公務機關未採行適當安全維護措施者，可先罰新台幣 2 萬到 200 萬元並限期改正；屆期未改正、或情節重大者，直接按次處 15 萬到 1500 萬元——這已經不是「被主管機關唸兩句」的等級，何況新設的個人資料保護委員會就是專責主管機關。想把制度接軌國際的，可以拿 ISO/IEC 42001:2023 這套 AI 管理系統標準當框架來對。至於薪資、病歷、客戶財務這種高敏感場景，我通常直接建議地端部署，讓資料從頭到尾不出公司門；真要用雲端服務，至少要在合約裡白紙黑字寫清楚——你的資料不會被拿去訓練它們的模型。
一份可以照抄的判斷準則
- 要不要地端：資料裡有薪資、病歷、生物特徵、客戶財務這類特種或高敏個資，優先地端；純內部知識、對外都能講的產品資料，雲端可以接受。
- 遮罩方式：模型答題需要語意完整的欄位，用「保留格式代碼化」；純識別用、後面不需要的欄位，才直接塗黑。
- 過濾順序：權限一律 pre-filter，先濾身分再算相似度，不要讓敏感片段有機會被撈進管線。
- 抽驗比例：遮罩結果人工抽驗 5% 到 10%，中文與中英混語內容取上限。
- 日誌保存：存取紀錄至少留 6 到 12 個月，機敏系統取上限，並定期演練真的追得回來。
最常見的破口，反而最無聊
講兩個現場一再看到的翻車，都不高科技。第一種是「反正是內部系統」心態，權限全開，想說同事都信得過。問題是知識庫做的事，正好是把「找到一份資料的成本」壓到趨近於零：以前要在檔案伺服器翻半天、還不一定翻得到的東西，現在一句話就到手——原本靠「懶得找」勉強維持的隱私屏障，瞬間蒸發。第二種是上游檔案權限本來就一團亂，AI 只是誠實地把它繼承下來：檔案伺服器上那份人人可讀的「薪資調整_final_v3.xlsx」，進了知識庫當然人人可問。治理不能只做在 AI 這一層，上游權限的垃圾進，答案的垃圾就出。
邊界與節奏：治理是行事曆上的事
最後把邊界照實講，才不會給人虛假的安全感。再嚴的檢索層權限，也擋不住一個本來就有權限的人，把螢幕上的答案自己複製貼上、拍照外流——那是資料外洩防護（DLP）與管理制度要接手的事，不是 RAG 這一層能包山包海的。而且權限、人員、文件這三樣東西每天都在變，所以治理不是上線前趕工的一張檢查表、更不是一次性的專案，它是要排進行事曆的例行盤點——我會建議每季至少一次，重新對一遍分級、標籤、權限與稽核，把漂移掉的地方拉回來。把這件事當成消防演練在做，而不是等火燒起來才找滅火器。
廷皓科技在高雄楠梓，專門幫南台灣的企業在導入知識庫這件事上，把分級、遮罩、檢索層權限、存取稽核到部署形態一次規劃到位，讓 AI 好用、又不會反過來變成洩密破口。你如果正想上 AI、又怕文件外洩，可以先把「有哪些文件種類」跟「組織的權限架構」粗略整理一下，加 LINE 傳給我們，或直接撥 07-363-0802，我們先陪你把權限這張圖畫出來，再談上線。
