洞察 · AI · 2026 · 07 · 29

企業 AI 助手的權限設計:RBAC、資料遮罩與查詢範圍

企業 AI 助手會同時跨越文件、資料庫與外部系統,傳統的登入檢查並不足以保護資料。可靠的設計必須在檢索與工具執行之前完成授權,並讓每次回答都能追溯其資料範圍。

企業 AI 助手的權限設計:RBAC、資料遮罩與查詢範圍

把權限放在模型之外

企業 AI 助手不是單純的聊天介面。一次提問可能依序經過身分驗證、文件檢索、向量資料庫、SQL 查詢、模型生成,以及 ERP、CRM 或 LINE 等工具呼叫。只在前端判斷使用者是否已登入,代表後方每一層仍可能取得超出權限的資料。提示詞中寫著「不要顯示機密資訊」也不是安全控制;模型可能誤解指令,檢索內容也可能透過摘要、引用或追問間接外洩。

工程上的基本原則是先授權,再取資料,最後才交給模型。每個請求都應帶有可驗證的使用者身分、租戶、部門、角色與其他必要屬性。檢索器必須在搜尋階段套用過濾條件,SQL 層必須限制資料列與欄位,工具層則應再次驗證可執行的動作。不要先取回完整結果,再要求模型刪除不該看到的內容,因為資料一旦進入模型上下文,就已經越過安全邊界。

另一個常見疏漏是把讀取與執行視為同一種權限。能查詢客戶資料的人,不一定能修改聯絡人、建立報價或傳送訊息。建議把每個工具拆成明確能力,例如讀取、建立、更新、核准與傳送,並由後端根據當下身分重新授權。對高影響操作,還應加入人工確認、輸入摘要與執行後稽核,而不是讓一段自然語言直接轉成不可逆的動作。

以 RBAC 建立基線,但不要讓角色無限膨脹

RBAC 適合表達穩定、容易理解的職務邊界,例如業務可讀取所屬客戶,財務可檢視帳務欄位,系統管理員可設定資料來源。角色應由既有的身分提供者或企業目錄同步,避免 AI 系統另建一份長期失真的帳號與群組資料。權限決策也應預設拒絕,並明確定義拒絕規則是否優先於允許規則。

但若每個部門、專案、地區與資料敏感度的組合都建立新角色,很快就會出現角色爆炸。較實用的方式是以 RBAC 決定基礎能力,再用資料屬性補充範圍,例如使用者所屬組織、專案成員資格、資料擁有者、文件分類與有效期限。設計時可逐項確認:

  • 角色回答能做什麼:可以搜尋知識庫、查詢訂單,或呼叫哪些工具。
  • 屬性回答可以對什麼做:限所屬部門、指定專案、負責客戶或特定資料等級。
  • 資源保存可過濾的中繼資料:每份文件或每個資料列都要有租戶、組織、擁有者與敏感等級等標記。
  • 群組變更能快速生效:離職、轉調或專案結束後,不應等待重新建立整個向量索引才撤銷存取。
  • 服務帳號採最小權限:AI 後端不應使用一組可讀取所有企業資料的共用高權限憑證。

對 RAG 系統而言,文件權限最好繼承原始資料來源,並在切分成文字區塊時一併保存。若來源平台的 ACL 無法直接同步,至少要建立清楚的映射與失敗策略。權限資訊缺漏、過期或無法解析時,系統應停止回傳該資源,而不是為了提高搜尋命中率而放寬限制。

資料遮罩要處理原始值、語意與快取

遮罩不是把畫面上的姓名或電話替換成星號就結束。可以先區分三種目的:永久移除不應進入 AI 平台的資料、依角色顯示不同精度,以及只在回答時隱藏特定欄位。若某類個資沒有檢索需求,最安全的做法是在匯入或索引前刪除;若財務人員可以查看完整金額、其他角色只能看到區間,則應在查詢層依權限產生不同結果;只有顯示格式的需求,才適合在輸出層處理。

遮罩規則必須具備一致性與語境意識。同一個識別碼若每次替換成不同內容,模型難以整理跨文件關係;若固定替換,又要避免替代值成為可反推原始身分的索引。自由文字中的個資、附件內容、欄位名稱與文件摘要也都可能暴露資訊。特別要注意:即使最終文字已遮罩,使用原始敏感文字建立的向量、關鍵字索引或模型快取仍可能保留不必要的訊號。

快取必須納入權限設計。回答快取、檢索快取與工具結果不可只用問題文字作為鍵值,還要包含租戶、角色、資料範圍、遮罩版本與權限版本。否則,相同問題可能把高權限使用者的結果回傳給低權限使用者。權限撤銷或遮罩政策更新時,也要能精準失效相關快取與索引,而不是只清除瀏覽器畫面。

把查詢範圍做成可驗證的合約

查詢範圍應由後端產生,而不是交給模型自由決定。對向量搜尋,可將租戶、部門、專案、文件類型與敏感等級轉成必要的中繼資料過濾器;對 SQL,可使用資料列層級安全、受控檢視表與欄位白名單;對外部 SaaS 或企業 API,則使用代表目前使用者的短效權杖,或由代理層加入不可被模型覆寫的範圍條件。模型可以協助理解問題,但不能自行擴大授權範圍。

每次回答最好留下完整但不過度收集內容的決策軌跡,包括使用者與租戶識別、套用的角色、查詢範圍、命中的資源識別碼、遮罩政策、工具參數、允許或拒絕結果,以及政策版本。回答中的引用來源也應再次經過權限檢查;使用者沒有權限開啟的連結,不應只因模型引用就變成可見。稽核紀錄本身含有敏感資訊,因此也需要保存期限、存取控制與遮罩。

上線前不要只測試正常角色。測試矩陣應涵蓋跨租戶提問、轉調後的舊權限、同名文件、缺少中繼資料、提示注入、快取重用、索引更新延遲,以及工具呼叫被拒絕時的行為。故障時應採取封閉式失敗:寧可回答無法存取,也不要猜測或退回未過濾查詢。若系統整合跨越多個既有平台,先由工程與整合團隊共同定義一份權限合約,通常比在聊天介面完成後再補安全規則更容易維護。

開始

有類似的需求?

告訴我們你的產業、目前系統狀態與預算範圍。我們會在 2 個工作天內回覆,並安排 30 分鐘免費諮詢。