模型輸出不是已授權的後端指令
企業 AI 助理開始連接 ERP、CRM、LINE、工單或 IoT 平台後，工具呼叫就不再只是聊天功能。模型可能建立訂單、修改客戶資料、發送訊息、控制設備，或查詢受限制的營運資訊。即使模型輸出的 JSON 符合格式，也不代表內容正確、使用者有權執行，或目前系統狀態允許這項操作。
工程上應把每一次工具呼叫視為來自外部的不可信請求。提示詞與工具說明可以降低模型犯錯的機率，但不能取代後端驗證。模型可能誤解日期、混淆客戶代碼、沿用過期對話，也可能受到提示注入影響。可靠的邊界必須設在模型與正式系統之間，由確定性的程式邏輯做最後判斷。
先驗證結構，再驗證資料的真實含義
第一層是結構驗證。每個工具應使用明確且封閉的輸入 schema，定義必要欄位、型別、長度、格式、列舉值與是否允許額外欄位。金額不要接受任意文字，時間必須指定時區與格式，識別碼應符合系統規則。對未知欄位採拒絕策略，通常比默默忽略安全，因為欄位可能來自模型幻覺，也可能是企圖繞過控制的輸入。
但 schema 只能回答資料長得對不對，不能回答操作合不合理。通過結構檢查後，仍須執行語意與業務驗證，例如客戶是否存在、料號是否可銷售、出貨日是否落在允許區間、退款金額是否超過原交易，以及設備指令是否適用於該機型。跨欄位條件也很重要：付款方式、幣別、稅別與公司別往往必須一起判斷。
- 型別與格式：拒絕無法解析的日期、模糊數字、過長文字及非預期物件。
- 允許值：狀態、角色與操作類型使用白名單，不讓模型自行創造選項。
- 資源存在性：從可信資料源重新查詢客戶、訂單、設備與產品，不相信對話中的舊資料。
- 業務不變量：檢查金額、庫存、流程狀態與欄位間關係，維持既有系統規則。
- 輸出正規化：在驗證後統一時區、電話、地址與識別碼格式，避免下游各自猜測。
權限必須綁定使用者、資源與動作
工具是否可見，不等於每位使用者都可執行。驗證層應使用由應用程式建立的身分與權限資訊，而不是接受模型傳入 userId、role 或 tenantId。後端需要同時檢查誰在操作、要操作哪一筆資源，以及要執行什麼動作。多租戶系統尤其要從登入工作階段推導租戶範圍，避免模型參數造成跨組織存取。
權限檢查也應考慮風險層級。唯讀查詢可以在完整授權後直接執行；發送外部訊息、修改主資料或建立低風險草稿，可要求使用者確認預覽；付款、退款、刪除、批次變更及設備控制，則適合加入明確核准、雙人覆核或人工流程。確認畫面必須呈現實際將送出的關鍵欄位，而不是只問「是否繼續」。
把執行器設計成可重試但不重複執行
通過驗證後仍可能遇到逾時、重送或部分失敗。AI 應用常會因網路錯誤重新呼叫工具，因此具有副作用的操作要使用冪等鍵，並在後端記錄請求指紋、執行狀態與結果。同一項已完成的動作再次送達時，應回傳既有結果，而不是再次建立訂單或重複通知。
對涉及多個系統的流程，不要假設分散式操作能自然保持一致。可採用先建立待處理紀錄、再由工作佇列執行的方式，並為每一步設定可辨識的狀態與補償策略。日誌應保存工具名稱、已正規化參數、呼叫者、驗證決策、核准紀錄及後端回應，但敏感資料與憑證必須遮罩。這些紀錄同時支援除錯、稽核與事件調查。
失敗要安全，也要讓模型有機會修正
驗證失敗時，不應把資料庫錯誤、內部欄位或堆疊資訊直接交給模型。回應應使用穩定的錯誤代碼，指出可修正欄位與允許範圍，例如日期缺少時區、訂單狀態不允許退款，或使用者沒有該資源的操作權。只有可安全重試的錯誤才交由模型補參數；權限拒絕、風險操作或反覆失敗應停止自動重試並轉交使用者。
測試不能只涵蓋正常範例。團隊應準備缺欄位、額外欄位、極端長度、錯誤租戶、過期資源、重複請求、提示注入及後端逾時等案例，並確認任何失敗都不會產生副作用。上線後則觀察各工具的拒絕原因、重試模式與人工核准結果，以調整 schema 和提示詞；但安全邊界仍應留在後端。若 AI 助理需要串接多個企業系統，先統一這套驗證與執行介面，通常比為每個工具個別補洞更容易維護。