AI Agent 治理框架:上線前必備的權限、稽核與責任歸屬清單

一個 AI agent 治理框架,是一套讓自主 agent 在生產環境裡「可被授權、可被追蹤、可被喊停、出事有人扛」的制度與技術控制點。它回答的不是「這個 agent 聰明嗎」,而是「當它在半夜自動退款、自動改單、自動寄出兩千封信時,誰授權的、留了什麼證據、多久能停、責任算誰」。

我們去年收拾過一個現場。某零售客戶把一個訂單處理 agent 接上了 ERP 與金流,測試環境跑得漂亮。上線第九天,它把一批「疑似重複下單」的訂單自動取消並退款,金額六位數。事後追查花了三天——因為沒有人知道那個 agent 用的是誰的帳號、憑什麼有退款權限、也沒有一條完整的操作日誌能重建它的決策路徑。系統本身沒壞。壞的是它上線時,治理是空的。

Agent 跟傳統軟體不一樣的地方在於:它會自己決定下一步做什麼、呼叫哪個工具、傳什麼參數。傳統系統的行為你寫死在程式碼裡,agent 的行為在執行當下才長出來。這意味著你不能只審程式碼,你得治理它的「行動空間」。以下是我們每次上線前都會逐項打勾的清單,給 CIO 直接拿去用。

身分:每個 agent 都要有自己的戶籍

第一條鐵律:agent 不准共用人的帳號,也不准全公司共用一把 API key。每個 agent 實例要有獨立、可辨識的機器身分(service account 或 workload identity),而且這個身分要能回溯到「哪個團隊、哪個負責人、為了什麼業務目的」而存在。

為什麼重要?因為當日誌裡出現一筆可疑操作,你要能在三秒內回答「這是誰」。共用帳號的代價是,出事那天你面對的是一團無法歸因的黑霧。

最小權限:預設拒絕,逐項開通

我們看過太多 agent 被授予「方便起見」的寬鬆權限——能讀整個資料庫、能寫所有欄位、能呼叫所有內部 API。這在 demo 階段沒事,上線後就是一顆定時炸彈。

正確做法是預設拒絕,再依實際任務逐項開通。一個負責「查詢庫存並回覆客戶」的 agent,不該有寫入訂單的權限,更不該碰得到退款。牽涉金錢、刪除、對外發送的高風險動作,要額外加一道人工核准關卡(human-in-the-loop),不是全自動放行。權限清單要定期複審,任務結束就收回。

稽核軌跡:能重建每一個決策

這是最常被忽略、卻在事故當下最救命的一項。你要記錄的不只是「agent 做了什麼」,而是完整的決策鏈:它收到什麼輸入、檢索到哪些內容、呼叫了哪些工具與參數、模型回傳什麼、最後採取什麼行動。理想狀態是任何一筆操作,你都能離線把它「重播」一次。

日誌要不可竄改、要有時間戳、要能關聯到前面說的 agent 身分。沒有這條軌跡,你的事後調查就只能靠猜。

事故應變:先想好怎麼喊停

上線前先回答一個問題:出事的時候,誰有權力、透過什麼機制,在幾分鐘內讓這個 agent 停手?我們要求每個 agent 都要有一個隨時可觸發的「kill switch」,而且停用的路徑不能依賴 agent 自己正常運作。同時預先設定行為護欄——單筆金額上限、每小時操作次數上限、異常模式自動熔斷。應變流程要事前寫成 runbook,而不是事發當天現場開會想。

責任歸屬:白紙黑字寫清楚誰扛

技術控制做滿了,還缺最後一塊:當 agent 造成損失,責任在誰?這條在多數導入案裡是空白的,也是最容易在事後演變成部門互踢皮球的地方。每個上線的 agent 都該有一位掛名的業務負責人(business owner)與技術負責人,白紙黑字寫明:誰核准它上線、誰負責監控、誰有權停用、出事誰對外負責。

下面這張表把五項濃縮成一頁,可以直接貼進你的上線審查文件:

治理不是上線前的一次性動作

最後提醒一件事:agent 的行為會隨著模型更新、資料變化、prompt 調整而漂移。今天守規矩的 agent,三個月後可能因為一次上游模型升級就開始亂來。所以治理不是上線前打完勾就結束,而是要配上持續的監控與定期的重評測——把權限複審、日誌抽查、行為評測排進固定週期。

我們在客戶現場導入 agent 時,治理清單跟功能開發是同一份工單裡的東西,不是上線後才補的文件。因為對我們來說,demo 跑得漂亮從來不算數;一個沒人能喊停、出事沒人扛的 agent,不管多聰明,都還沒準備好上線。