高敏感業務上AI，別隻裝模型：還要有一張“業務隔離卡”

一份合同、一段客戶郵件、一次合規檢索，表面上都是“讓 AI 幫忙讀一讀”的小事；可一旦智能體能跨文件庫找材料、調用專業系統、生成可交付的工作成果，真正決定它能否進生產環境的，就不再只是模型回答得是否漂亮。它能看到哪一個事項？引用了哪一版制度？這次判斷能否被同事複核？答案若説不清，效率越高，風險反而越快被放大。

8月25日，Google Cloud 發佈 Gemini Enterprise for Legal 預覽版。這個面向法律服務與企業法務的產品，把領域技能、可信業務系統連接、可執行的智能體和開放生態放在同一套受治理的環境中。值得關注的並非“AI 進入法律行業”這句口號，而是它把高敏感工作流裏原本容易被忽略的三件事放到了枱面上：專業規則、既有權限和可驗證依據，必須隨着任務一起運行。

高敏感場景的關鍵，不是讓智能體“懂得更多”，而是讓每一份輸出都能回答：基於什麼資料、在什麼權限內、由誰承擔最終判斷。

從“萬能助手”到受約束的專業工作流

法律、財務、醫療、研發等場景有一個共同點：資料不是普通上下文，而是帶着業務歸屬、保密等級、有效期限和責任邊界的工作證據。用一個通用對話框把資料全塞進去，或讓服務賬號以高權限連接全部系統，短期看部署很快，長期卻會製造新的“資訊黑箱”。當同一智能體服務不同客戶、項目或部門時，原本由人員、事項和系統共同維持的邊界，很容易在一次跨系統調用中被抹平。

Google Cloud 在此次發佈中強調，連接文檔管理、案件資料、研究服務和行業應用的 MCP 連接器，應繼承底層系統已有的用戶權限與訪問控制；其受治理控制面則用於實施安全策略、私有數據隔離，以及帶可追溯引用的內容依據。換句話説，智能體不是再造一套“誰都能看”的知識庫，而是在已有業務邊界內完成檢索、歸納和執行。

真正要沉澱的，是“業務隔離卡”

我認為，企業不必等到部署一套完整行業平台後才開始治理。更實際的起點，是為每一類高敏感智能體建立一張業務隔離卡：它不是一份籠統的安全制度，而是一組能被工作流讀取、檢查和復盤的業務事實。

第一欄寫清任務邊界：它服務哪個事項、客戶、產品線或項目；允許處理哪些文件類型；哪些動作只能生成草稿，哪些動作必須由具備資格的人確認。第二欄寫清資料邊界：權威來源在哪裏、文檔版本如何識別、過期材料如何處理、跨項目檢索是否預設禁止。第三欄寫清權限接力：發起人是誰，智能體代誰訪問，連接器在哪一層再次校驗，拒絕訪問後是提醒申請、轉人工，還是直接終止任務。

最後一欄是證據與處置：輸出中哪些結論必須附來源，哪些修改需要保留差異，人工採納、駁回或糾正後如何回寫。這樣做的價值不在於多一張表，而在於讓“邊界”從口頭要求變成可執行的輸入。日後發生爭議時，團隊能回到具體的事項範圍、權限記錄、引用材料和人工決定，而不是在聊天記錄裏猜測模型為什麼這樣説。

三個先問的問題，決定能否從試用走向生產

準備上線高敏感智能體時，我建議業務負責人先不問“它能不能做得更快”，而是連續問三個問題。第一，**它在替誰工作？**如果回答只是“替法務部”或“替銷售團隊”，粒度還不夠；應落實到事項、角色和當次委託。第二，**它憑什麼得出結論？**關鍵輸出應能回指到受許可的來源、版本和必要的引用，而不是隻給一段流暢的摘要。第三，**它越界時誰接手？**對權限不足、資料衝突、高風險條款或事實不充分的情況，要預先定義暫停、升級和人工批准路徑。

這三個問題同樣適用於合同審閲、客戶方案、產品安全評估和財務分析。模型可以替企業壓縮檢索與整理的時間，卻不能替企業消除責任。越是專業、越是敏感的流程，越需要把“人、資料、權限、證據”四件事綁定在一次任務裏，而不是在結果出現後再補救。

星盒視角：把隔離邊界變成可複用的工作資產

在 星盒看來，企業搭建專屬 AI 工作站，不應只配置提示詞和知識庫。組織層需要明確業務委託、風險等級、審批責任和留存規則；BOX 層沉澱事項字典、權威資料、角色範圍、連接器邊界與引用模板；智能體層則只在本次卡片允許的資料和動作範圍內執行。再將權限拒絕、人工改寫、來源缺失和異常升級等反饋迴流，隔離卡才會從靜態清單成長為持續改進的工作資產。

高敏感業務不會因為接入 AI 而變得簡單，但可以變得更清楚：哪些工作值得自動化，哪些邊界不能被效率穿透，哪些結論必須留給人作最後確認。企業真正要建設的，也許不是一位無所不能的 AI 助手，而是一支始終知道自己該看什麼、不能看什麼、依據什麼工作的智能體隊伍。