隔離必須從身分開始，而不是從提示詞開始
多租戶 AI 助手最危險的假設，是認為在系統提示詞中寫下「只能回答目前公司的資料」就能形成安全邊界。提示詞只是模型行為指引，不是存取控制。真正的邊界應在模型看到資料之前就完成：入口服務先驗證使用者身分，依可信的登入憑證解析租戶，再建立不可由前端任意覆寫的租戶上下文。API 請求帶入的 tenant_id 只能用來比對，不應成為授權依據。
這個租戶上下文必須一路傳遞到關聯式資料庫、向量檢索、物件儲存、快取、訊息佇列、工具呼叫與稽核紀錄。任何漏接的元件都可能成為跨租戶資料通道。例如，向量資料雖然寫入正確的租戶欄位，但檢索時忘記套用篩選；對話摘要雖然分開儲存，卻使用未含租戶鍵值的共用快取；ERP 工具查詢雖有權限檢查，背景工作卻沿用服務帳號的完整權限。工程上應把租戶範圍設計成必要參數，缺少時直接拒絕執行，而不是退回全域查詢。
共享或獨立部署，要依風險與營運成本決定
常見架構可分為共享資源搭配邏輯隔離、每租戶獨立資源，以及兩者混合。共享資料庫與向量索引通常較容易營運，也能降低小型租戶的基礎設施成本，但每一次查詢、索引與清除作業都必須正確套用租戶條件。獨立資料庫、索引或雲端帳號提供更清楚的故障與權限邊界，代價則是佈署、升級、監控及容量管理更複雜。
選擇隔離層級時，不要只看租戶數量。更重要的是資料敏感度、法規與資料落地要求、租戶是否持有自己的加密金鑰、整合系統的權限模型，以及單一租戶的負載是否可能影響其他租戶。實務上常採分級策略：一般知識庫使用共享平台與強制租戶篩選，高敏感資料或特殊合約則配置專屬儲存與運算資源。
- 資料層：資料表、向量文件、檔案路徑與備份都要帶有可驗證的租戶歸屬；刪除租戶時也必須涵蓋衍生索引與摘要。
- 金鑰層：依需求使用租戶專屬金鑰或至少分開秘密值，避免某個整合憑證能存取其他組織的 ERP、CRM 或雲端資源。
- 運算層：設定租戶配額、並行限制與逾時，避免大量文件匯入或長時間代理任務壓縮其他租戶的服務容量。
- 工具層：工具清單應依租戶與使用者角色動態產生；模型不應看見無權使用的工具，更不能自行提供租戶識別碼繞過授權。
- 觀測層：日誌、追蹤與成本紀錄需要租戶標籤，但應遮蔽提示內容、個資、存取權杖與檢索到的敏感文件。
上下文不是把所有記憶塞進提示詞
良好的上下文管理，重點是決定此刻需要哪些資訊，而不是累積最多資訊。建議把內容拆成數個生命週期：只在單次請求存在的執行狀態、屬於目前對話的短期記憶、經使用者確認的個人偏好，以及由企業文件或系統資料形成的租戶知識。這些資料應使用不同的保存期限、寫入規則與刪除流程。對話摘要尤其不能在未驗證前被當成事實，因為摘要可能保留先前回答中的推測或錯誤。
每次請求可透過固定的組裝管線建立上下文：先驗證租戶與角色，再載入必要的對話狀態，依查詢重新檢索授權資料，最後才加入工具結果。為各部分設定明確的 token 預算，優先保留目前問題、權限資訊及可追溯來源；較舊的對話可摘要或淘汰。檢索到的文件應保留來源與權限中繼資料，並視為不受信任的內容，不能讓文件中的指令覆蓋系統規則。若使用長期記憶，寫入前還應判斷其是否必要、是否含敏感資訊，以及使用者能否查閱與刪除。
用跨租戶測試驗證邊界，也要管理非同步流程
一般功能測試只能證明系統在正常路徑可用，無法證明租戶隔離成立。測試資料應刻意建立容易辨識的租戶專屬內容，再從其他租戶嘗試透過關鍵字檢索、語意近似、對話續接、共享檔名、快取命中、工具參數與提示注入取得它。除了回答文字，也要檢查引用來源、模型輸入、工具呼叫、串流事件與追蹤紀錄，因為資料可能沒有出現在最終答案，卻已經被送進模型或寫入日誌。
文件解析、嵌入建立、對話摘要與代理工作通常在背景執行，也是最容易遺失租戶上下文的地方。工作佇列應攜帶經簽署或可重新驗證的租戶與使用者資訊，執行端重新取得最小權限，而不是直接信任任務內容。上線前還要演練租戶停用、資料刪除、金鑰輪替、索引重建與備份還原，確認衍生資料不會殘留或被還原到錯誤邊界。若系統同時串接 LINE、ERP、CRM 與雲端服務，讓整合團隊共同審查端到端資料流，通常比只檢查聊天介面更能找出真正的隔離缺口。