Agent 治理框架：讓企業敢把 AI agent 接到真實業務上的那張安全網

從 PoC 到 Production：企業 AI Agent 系統工程第 11 / 12 篇

本篇是「從 PoC 到 Production：企業 AI Agent 系統工程」系列的第 11 / 12 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。

這是「從 PoC 到 Production：企業 AI Agent 系統工程」系列第 11 篇（共 12 篇）。上一篇：延遲、可靠性、成本的系統權衡。這篇整理的是治理設計框架（一份 reference / 設計提案），不是某個已導入系統的稽核報告。

前面十篇，安全和信任的機制是散落各處講的：第 5 篇的權限檢索、第 6 篇的工具邊界、第 9 篇的可觀測性。這一篇要做的，是把它們收斂成一張完整的治理框架——一張你可以攤在資安長、法遵、業務主管面前，回答那個關鍵問題的圖：

「我們憑什麼敢相信這個 AI agent，把它接到真實的客戶資料、財務系統、製造流程上？」

PoC 永遠回答不了這個問題，因為它根本沒想過。而這張圖，就是「能 demo」和「企業敢用」之間那道治理的牆。

一頁治理框架

Agent 治理框架：上層控制「誰能碰什麼」、中層控制「能做什麼」、底層橫跨一切持續監督（audit、eval、observability、cost）

治理框架的三層：上層管「誰能碰什麼」、中層管「能做什麼」、底層橫跨一切持續監督（audit / eval / observability / cost）。

八個元件，分三層：控制誰能碰什麼（①②）、控制能做什麼（③④）、持續監督（⑤⑥⑦⑧）。一個一個講它在治理上扮演什麼角色。

在逐項講之前，先講一件對資安和法遵很重要的事：這張圖不是我發明的。 它只是把 NIST AI RMF、ISO/IEC 42001、EU AI Act 對 AI 系統的共同要求，落到 agent 工程上。八個元件幾乎一對一對得上既有框架：

治理元件	NIST AI RMF	ISO/IEC 42001	EU AI Act（高風險）
① 資料分級	MAP	Annex A 控制	Art.10 資料治理
② RBAC/ABAC・最小權限	GOVERN	Annex A 控制	—
③ Tool Registry	MAP / GOVERN	Annex A 控制	—
④ Human-in-the-loop	GOVERN / MANAGE	PDCA	Art.14 人類監督
⑤ Audit Log	MEASURE	PDCA	Art.12 紀錄保存
⑥ Eval Harness	MEASURE	Check（PDCA）	—
⑦ Observability	MEASURE	Check（PDCA）	Art.12 / Art.72
⑧ Cost／持續監督	MANAGE	Act（PDCA）	Art.72 上市後監督

為什麼要花力氣對這層？因為當你把這張圖攤在法遵面前，他第一個問題不會是「你 RBAC 怎麼做的」，而是「這對得上我們要遵的哪一條」。對得上，框架的說服力就從「工程師畫的圖、聽起來有道理」，升級成「對得上稽核要求的圖」。

① 資料分級：先知道你在保護什麼

治理的起點不是技術，是盤點。哪些資料是公開的、內部的、機密的、個資 / 受法規保護的（個資法、營業秘密、客戶合約）？

沒有分級，後面的權限控制就沒有依據——你不知道哪些資料「碰了會出事」。這一步常常要跟法遵、資安一起做，是治理裡最不技術、卻最不能跳過的一步。分級的結果，會變成第 5 篇那些 chunk 上的權限 metadata 的來源。

② 身分與權限邊界：RBAC / ABAC

把「誰、能透過 agent、碰到哪些資料和工具」明確定義出來。這是第 5 篇（資料檢索）和第 6 篇（工具動作）的權限，在治理層的統一視角。

RBAC（角色為本）：依角色給權限。工程師能查工單、不能查薪資；主管多一些；HR 又不同。
ABAC（屬性為本）：更細，依屬性動態判斷（部門 + 機密等級 + 地區）。複雜場景用得上。

核心原則是最小權限：agent 代表某使用者行動時，只該有那個使用者該有的權限，一分不多。最該避免的反模式，就是第 2 篇警告過的——agent 用一個服務帳號的最大權限在跑，把自己變成權限放大器。

③ Tool Registry：能做的事，要有一份清單

第 6 篇講過，MCP / tool registry 把「agent 能做哪些動作」變成一份可盤點的清單。在治理層，這份清單要再標註：

每個工具的 action boundary（唯讀 / 寫入 / 危險）
需不需要 approval
哪些角色能用哪些工具

當資安問「你們的 agent 到底能對哪些系統做哪些事」，你掏得出這份清單——這就是治理的可稽核性。沒有 registry，你連自己的 agent 能做什麼都說不清楚，更別說讓資安放行。

④ Human-in-the-loop：高風險動作的剎車

第 6 篇講過 approval flow 的機制，治理層要決定的是政策：哪些動作非要人類確認不可？

通常的分界：會造成重大、不可逆副作用的——大量資料異動、對外溝通、金流、改動生產設定——都該有 HITL 關卡。低風險唯讀的放行。這份「哪些要剎車」的清單，是治理的核心決策之一，要跟業務一起定，因為它直接影響效率和風險的平衡。

但 HITL 最常見的失效，不是沒放關卡，是放了卻變成橡皮圖章——當待核可的動作又多、又通常是對的，人會很快養成「一律點同意」的習慣，關卡還在、監督已經沒了。這正是 EU AI Act Art.14 想堵的洞：它要的是有意義的、能真正介入的人類監督，不是流程上多一個 approval 按鈕。對 agent 還有個額外的坑：當待核可項是模型生成的一段自然語言，審核者很難在幾秒內判斷它的副作用範圍。所以 HITL 的設計品質，取決於「呈現給人類的資訊，夠不夠讓他做出有意義的判斷」——這動作會改到哪些資料、影響多大、為什麼 agent 這樣選——而不只是「有沒有放一個確認關卡」。

⑤–⑧ 監督層：信任不是一次性的，是持續的

前面四項是「事前控制」，但治理的另一半是持續監督——因為信任會隨時間、隨模型更新、隨資料變化而流失。這四項都在前面章節建好了，治理層把它們組織起來：

⑤ Audit Log：誰、何時、透過 agent、存取了什麼、做了什麼動作。合規與事故調查的底線，出事時這是你唯一能還原真相的東西。兩個常被漏掉的細節：(1) 要留多久？ EU AI Act Art.12 已把高風險系統的「自動事件記錄」從最佳實踐升級成法定義務，Art.19 對 deployer 給的下限是至少保存六個月——audit log 不只要有，還要回答得出保存期限。(2) 對 agent，光記「呼叫了哪個工具」遠遠不夠，要連 prompt、檢索到的 chunk、工具的輸入輸出一起留，否則事故調查時最關鍵的中間決策過程是一片空白。這份資料跟第 9 篇 observability 的 trace 其實是同一份東西的兩種用途。
⑥ Eval Harness（第 9 篇）：品質有沒有偷偷掉？模型被供應商更新後行為有沒有漂移？這套持續監督的精神對應 NIST AI RMF 的 MEASURE / MANAGE；NIST 2024 年的 Generative AI Profile（NIST-AI-600-1）甚至把 confabulation（也就是幻覺）獨立列為一個風險類別，對 12 個 GenAI 風險領域給了 200+ 條建議行動，可以直接拿來當 eval 與監控清單的起點——它點名的第一個風險，正好就是這系列開頭的「鴻溝一：正確性沒有底線」。
⑦ Observability（第 9 篇）：每個決策可追、可重播，出包查得到根因。
⑧ Cost Monitor（第 9、10 篇）：花費透明、異常可告警。

這四項合起來回答的是：「我們有沒有在持續確認這套系統仍然值得信任？」 一個只做事前控制、卻沒有持續監督的 agent，就像一個通過了上線審查、之後就再也沒人看的系統——遲早出事。

怎麼落地：別想一次到位

這張框架完整，但不代表你要一次全做完。務實的導入順序：

先做 ①②（分級 + 權限邊界）：沒有這個，任何接觸真實資料的 agent 都不該上線。這是入場券。
再做 ③⑤（registry + audit）：讓「能做什麼」和「做過什麼」可盤點、可追。
接著 ④（HITL）：把最高風險的動作先用人類關卡保護起來。
持續強化 ⑥⑦⑧：監督層隨系統成熟逐步加深。

還有一個外部理由，讓「現在就做」比「等等再說」划算：法規時鐘已經在跑。 但這裡有個 2026 必須講對的眉角——EU AI Act 是分階段生效的：禁止性實務與 AI 素養義務已自 2025-02 適用、GPAI 義務自 2025-08 適用，這幾條都已生效。而大家最在意的高風險義務，原訂 2026 年 8 月起，在 2025 年底的 Digital Omnibus 提案後被往後推（討論中的新時程落在 2027–2028，截至本文撰稿仍待正式定案）。所以如果你還在網路上看到「2026 年 8 月高風險義務全面適用」，那是舊懶人包、已經過期了。給你的訊息很單純：日期會動，但別賭它會無限延。 分級、RBAC、audit、HITL 這套底層工程量大、牽涉法遵與業務，不是兩週能補完的——日期往後挪，剛好是讓你「提早做、做扎實」的窗口。

依風險排序：越是接觸機密資料、越是能造成不可逆動作的 agent，治理就要越完整；一個只查公開 FAQ 的內部小工具，不需要這整套。治理的強度應該對應風險的高度，這本身也是一種工程判斷。