文件分級必須能驅動實際控制
分級制度若只存在於政策文件或檔名標籤，對知識庫幾乎沒有保護作用。工程上真正需要的是一個可被系統判斷的欄位，以及每個等級對應的處理規則。常見做法可從公開、內部、機密與高度限制四級開始，但名稱不是重點；重點是誰能讀取、能否下載、能否進入搜尋索引、是否允許交給外部模型處理，以及多久後必須重新審查。
分級應由最了解內容風險的資料擁有者負責，平台團隊則負責把規則轉成技術控制。完全依賴員工逐份標記容易產生遺漏，完全依賴自動分類又可能誤判。較實際的做法是以來源系統、資料夾或文件類型設定預設等級，再針對例外文件覆寫；自動偵測個資、合約條款或憑證等內容可以提供建議與警示，但高風險降級仍應要求人工核准。
- 公開：可對外揭露，但仍需確認著作權、版本與發布責任。
- 內部：限組織成員使用，通常可搜尋與摘要，但不應出現在公開連結。
- 機密：依部門、專案或職務授權，並限制匯出、分享及模型處理範圍。
- 高度限制：採明確名單或屬性授權，預設不建立一般搜尋索引，必要時使用隔離環境。
權限必須一路延伸到搜尋、向量索引與 AI 回答
企業知識庫通常從 SharePoint、Google Drive、檔案伺服器、CRM、ERP 或內部系統同步資料。匯入流程不應只複製文字，還要保留穩定的文件識別碼、版本、來源、擁有者、分級、存取名單、保存期限與刪除狀態。若來源端的權限無法準確轉換，最安全的選擇是暫停收錄或套用更嚴格的預設值，而不是先開放再等待使用者回報。
在 RAG 架構中，權限檢查必須發生在內容進入模型上下文之前。先找出所有相關片段、再於畫面隱藏無權限結果，仍可能讓敏感文字進入提示、快取或追蹤資料。較可靠的流程是先驗證使用者身分與群組或屬性，再以文件 ACL 過濾可搜尋範圍，最後才進行相似度排序與回答生成。文件被切成向量片段後，每個片段都應繼承原文件的分級、版本及權限；摘要、預覽、引用與快取也不能因為是衍生資料就自動降級。
- 以身分提供者的群組與職務屬性作為授權來源，避免在知識庫另建一套長期失真的帳號表。
- 同步離職、轉調與專案結束等事件，使撤權能傳遞到索引、快取和既有分享連結。
- 對下載、批次匯出、外部分享與 API 存取設定比一般閱讀更嚴格的權限。
- 將模型供應商、資料處理區域與資料保留設定納入分級規則，而非只檢查使用者權限。
取用紀錄要能回答事件調查的問題
只記錄登入成功或 API 回傳正常，無法支援真正的稽核。每筆取用事件至少應包含使用者或服務身分、動作、文件識別碼與版本、當時分級、時間、來源管道、授權結果及拒絕原因。對 AI 助理還要區分使用者提出查詢、系統檢索到候選片段、實際送入模型、答案引用，以及使用者下載原文等不同階段。這些事件的風險不同，不能合併成一筆模糊的聊天紀錄。
紀錄本身也可能包含敏感資訊。原始查詢、提示內容與文件片段不宜無條件長期保存，可依調查需求採用遮罩、代碼化、雜湊識別或受控的短期留存。日誌應集中傳送到限制修改的儲存區，使用一致時間來源與關聯識別碼，並將查閱日誌的行為再次記錄。保存期限應根據法規、契約、事件調查與儲存成本決定，不應用無限期保存取代明確政策。
- 某位使用者在特定期間讀取、搜尋、下載或分享了哪些文件？
- 一份文件被重新分級或撤權後，哪些索引、快取或衍生內容仍可存取？
- AI 回答引用了哪些版本與片段，當時的授權判斷依據是什麼？
- 大量下載、跨部門存取或反覆遭拒，是正常工作流程還是需要調查的異常？
用可驗證的治理流程逐步上線
實作時可先盤點資料來源與主要風險，再挑選一個權限結構清楚、擁有者明確的領域試行。先定義少量但可執行的分級，建立文件擁有者與例外核准流程，接著測試正常授權、跨部門拒絕、離職撤權、文件改級、刪除同步及 AI 引用等情境。測試應檢查最終畫面，也要檢查搜尋結果、模型上下文、快取與日誌是否符合預期。
上線後需要持續處理未分類文件、失效擁有者、過大的群組權限、同步錯誤及長期未複核的例外。告警應聚焦於可採取行動的事件，例如短時間大量匯出、服務帳號跨越既定資料邊界，或高度限制文件被非預期管道呼叫；若每次讀取機密文件都告警，營運團隊很快就會忽略訊號。緊急取用機制則應有時效、理由、核准與事後審查，不能成為永久後門。當身分、文件平台與 AI 系統由不同產品組成時，整合團隊的價值就在於把同一套治理規則落實到每一個資料流與執行點。