AI Agent 能不能碰業務資料？先看這 5 條安全邊界

現在很多公司都卡在同一個問題上：

AI Agent 到底能不能碰業務資料？

不讓它碰，它只能寫寫文案、總結會議紀要，永遠進不了真正的業務現場。讓它碰，又擔心它看了不該看的客戶、改了不該改的訂單、把敏感資料帶出邊界。

所以真正的問題不是“能不能碰”，而是：

它以誰的身份碰？碰到什麼程度？每一步有沒有邊界、記錄和剎車？

如果這幾個問題說不清，AI Agent 越強，風險越大。如果說得清，它就不再只是一個聊天框，而可以成為真正參與業務系統的數字同事。

下面這 5 條安全邊界，是企業把 AI Agent 接入 CRM、ERP、工單、訂單、合同、財務或內部自研系統之前，必須先劃清的底線。

邊界一：AI 必須以“使用者身份”訪問，而不是擁有超級許可權

很多 AI 專案一開始就走錯了路：為了方便整合，直接給 Agent 一個後臺賬號、資料庫賬號，甚至管理員許可權。

這樣做短期很爽，長期很危險。

因為一旦 Agent 拿的是超級許可權，它看到的就不是“某個員工被允許看到的資料”，而是“系統裡所有資料”。銷售只能看自己的客戶，但 Agent 能看全公司客戶；客服只能看自己佇列裡的工單，但 Agent 能翻所有工單；區域經理看不到另一區域的報價，但 Agent 可以直接查出來。

這不是智慧，這是越權。

企業級 AI Agent 的第一條規則應該是：

Agent 不能凌駕於使用者之上。它必須代表某個已登入使用者行動，並繼承這個使用者已經擁有的許可權。

這意味著：

使用者看不到的記錄，Agent 也看不到；
使用者不能編輯的欄位，Agent 也不能編輯；
使用者不能執行的動作，Agent 也不能執行；
使用者離職、轉崗、許可權變更後，Agent 的能力也隨之變化。

不要把安全寄託在提示詞上。提示詞可以提醒 Agent “不要訪問敏感資料”，但真正可靠的邊界，必須在執行時由許可權系統強制執行。

邊界二：先只讀，再寫入；先觀察，再行動

讓 AI Agent 直接改業務資料，是很多團隊最緊張的地方。這個擔心是對的。

但“能不能寫”不應該是一個一次性開關。更合理的路徑，是分層放行：

第一階段，只讀。

Agent 可以查詢客戶、商機、庫存、工單、合同狀態，但不能修改任何記錄。它可以回答“哪些客戶三個月沒跟進”“哪些訂單可能延期”“哪些工單超過 SLA”，但不會改變業務系統裡的任何資料。

第二階段，建議。

Agent 可以生成操作建議，比如“建議把這個商機階段改為風險中”“建議給這 20 個客戶建立跟進任務”。但真正落庫之前，需要人確認。

第三階段，受控寫入。

只有在明確授權的物件、欄位和動作上，Agent 才能寫入。例如只能建立跟進任務，不能修改合同金額；只能更新工單狀態，不能刪除記錄；只能在低風險流程中自動執行，高風險動作必須人工審批。

這個順序很重要。很多公司不是不能上 AI，而是太早讓 AI 進入“自動執行”階段，跳過了觀察、建議和確認。

一個安全的 Agent 系統，應該允許你把每個物件、每個動作、每類使用者分別配置為：

不能訪問；
只讀訪問；
可建議但需確認；
可自動執行；
高風險時升級審批。

這才是從試點走向生產的節奏。

邊界三：不要把整庫塞給 AI，只給它完成任務所需的最小資料

很多人一聽“AI 接業務系統”，腦子裡想的是：把資料庫匯出來、丟給大模型、讓它自己分析。

這條路非常危險，也非常低效。

業務系統裡的資料不是一團可以隨便餵給模型的文本。裡面有客戶電話、合同金額、員工資訊、審批記錄、供應商報價、財務口徑和大量內部備註。Agent 每次執行任務時，真正需要的往往只是其中很小的一部分。

所以第三條邊界是：

Agent 不應該直接擁有資料庫。它應該通過受控工具按需查詢，並且只拿到完成當前任務所需的資料。

比如使用者問：

“把這個客戶最近 90 天的未關閉工單總結一下。”

Agent 需要的是這個客戶、最近 90 天、未關閉工單的有限欄位，而不是整個工單表，更不是整個 CRM 資料庫。

這背後有兩個關鍵設計：

第一，業務資料要先被建模成清晰的物件。客戶是什麼、商機是什麼、工單是什麼、哪些欄位敏感、哪些關係可以查詢，都應該被明確描述，而不是讓 Agent 自己猜。

第二，Agent 訪問資料必須經過受控的查詢層。它發起的是“查詢符合條件的記錄”，而不是“讀取一張表的所有內容”。過濾、排序、聚合應該儘量在資料庫側完成，返回給 Agent 的只是必要結果。

這會同時降低三類風險：資料洩露風險、幻覺風險和成本風險。

邊界四：高風險動作必須有人類確認、回滾和剎車

AI Agent 最有價值的地方，是它不只回答問題，還能推動流程。

但流程越靠近錢、客戶、合規和許可權，就越不能只靠“模型應該會判斷”。

這些動作必須預設進入高風險清單：

刪除記錄；
批次修改客戶、訂單、合同、庫存或財務資料；
修改金額、折扣、賬期、信用額度；
對外發送正式郵件、報價、通知或合同；
建立、關閉或升級審批；
修改使用者許可權、角色或組織關係；
呼叫會產生真實成本的外部服務。

對這些動作，系統至少要提供三層保護：

第一，執行前確認。 Agent 必須展示它準備做什麼、影響哪些記錄、為什麼這麼做，並等待有許可權的人確認。

第二，可回滾。 如果動作會修改資料，系統要記錄修改前後的狀態，至少能支援撤銷、補償或人工恢復。

第三，自動剎車。 一旦觸發異常閾值，比如一次要改 500 條記錄、金額超過上限、命中敏感客戶、連續失敗多次，Agent 必須停止並升級給人。

企業裡的 AI Agent 不能像個人工具那樣“試試看”。它進入的是生產系統，每一步都應該能解釋、能暫停、能追責。

邊界五：所有讀取、判斷和操作都必須可審計

很多系統只記錄人做了什麼，卻沒有準備好記錄 Agent 做了什麼。

這會讓 AI 專案在試點時看起來沒問題，一到生產就失控：出了錯誤，不知道 Agent 看過哪些資料、為什麼給出這個建議、呼叫了哪個工具、改了哪條記錄、是誰授權的。

所以第五條邊界是：

Agent 的每一次關鍵行為，都應該留下審計軌跡。

至少包括：

哪個使用者觸發了 Agent；
Agent 訪問了哪些物件和記錄；
使用了哪些工具或動作；
生成了什麼建議；
哪些動作被人確認，哪些被自動執行；
執行前後的資料變化；
失敗、拒絕、越權和升級審批的原因。

審計不是為了事後甩鍋，而是為了讓 AI 可以被治理。

沒有審計，企業只能在“完全不敢用”和“出了事再說”之間搖擺。有了審計，團隊才能逐步放寬邊界：先開放只讀查詢，再開放建議，再開放低風險自動化，最後把成熟流程交給 Agent 持續執行。

一個簡單判斷：你的 AI Agent 是助手，還是影子管理員？

判斷一個 AI Agent 系統安不安全，可以問 5 個問題：

它是不是以真實使用者身份訪問業務資料？
它是否預設只讀，並能按物件、欄位、動作逐步授權？
它是否只拿任務所需的最小資料，而不是直接讀取整庫？
它做高風險動作前，是否有人類確認、回滾和剎車機制？
它的每一次讀取、建議和修改，是否都能被審計？

如果答案大多是否定的，那它不是一個企業級 Agent，而是一個披著 AI 外衣的影子管理員。

影子管理員最可怕的地方，不是它會不會犯錯，而是它犯錯時沒人知道邊界在哪裡。

ObjectStack 的立場：AI 可以碰業務資料，但必須碰得有邊界

我們做 ObjectStack 時，預設接受一個現實：企業不可能永遠把 AI 擋在業務系統外面。

真正有價值的 AI，一定會走進客戶、訂單、審批、工單、合同和資料分析裡。它必須理解真實業務物件，必須能在許可權之下查詢資料，也必須能在被授權時推動流程。

但它不能繞過治理。

ObjectStack 的核心思路，是把業務系統描述成 AI 和人都能讀懂的物件、許可權、流程和動作，讓 Agent 通過這層結構工作，而不是直接鑽進資料庫或程式碼裡亂翻。這樣， AI 可以接近真實業務，但每一步都經過清晰的身份、許可權、資料範圍、動作邊界和審計記錄。

這不是讓 AI 變弱，而是讓它真正能進生產。

因為企業不缺會聊天的 AI。企業缺的是一個能安全碰業務資料、能被授權、能被審計、能隨時停下來的 AI。

如果你正在評估“老系統怎麼接 AI”，先別問模型選哪一個。先問這 5 條邊界有沒有。

邊界清楚，AI Agent 才能從演示走向業務現場。邊界不清楚，越智慧，越危險。