當 AI 開始「動手做事」，誰來負責？企業 AI Agent 必須建立的治理邊界

Who Is Accountable When AI Starts Taking Action?

人工智慧與機器學習｜約沛科技｜2026/08/20

AI Agent 正從回答問題的助手，逐漸成為可以查詢資料、操作系統、執行流程的「數位行動者」。當人工智慧開始真的修改客戶資料、建立訂單、發動工作流程，企業面對的問題也從「答案準不準」變成「它有權做什麼、誰允許它做、做錯了誰負責」。Microsoft、NIST 與 OWASP 近年的治理框架都指向同一件事：要讓 AI Agent 真正進入企業核心流程，身分、權限、決策邊界與稽核能力必須一起建立。

在 Microsoft 內部，人工智慧代理的治理已經不再只是資訊部門偶爾進行的一次性安全審查。隨著員工開始使用 Agent 執行多步驟工作、連接企業資料與自動觸發流程，Microsoft Digital 必須建立一套可以長期運作的管理制度，持續追蹤哪些 Agent 正在公司裡運作、由誰建立、可以使用哪些資料，以及它們採取了哪些行動。Microsoft 將這套治理建立在安全、治理、管理與可觀測性四個基礎之上，並開始把 Agent 當成一種需要正式管理的企業工作負載，而不是單純的聊天工具。

這個改變反映了 AI Agent 與過去生成式人工智慧最大的差異。過去員工要求人工智慧寫一封信、整理一份報告或分析一份文件，即使人工智慧產生錯誤，大多仍有一個人站在最後一步做確認。然而，Agent 可以持續運作，可以根據資訊自行選擇工具，可以跨系統完成一連串操作，甚至在沒有人逐步下達指令的情況下觸發後續工作。當人工智慧從「提供答案」跨入「採取行動」，風險的性質也隨之改變。

因此，Microsoft Entra 在 2026 年正式推出專門面向 AI Agent 的 Agent ID，讓 Agent 可以擁有不同於人類帳號與傳統應用程式的獨立身分。Microsoft 的文件指出，這些 Agent 身分可以被建立、授權、限制、管理生命週期，而且其驗證與活動都能留下稽核紀錄。這意味著企業開始接受一個過去不存在的前提：組織中的「身分」不再只有員工、合作夥伴與應用程式，未來還可能包含數百甚至數千個可以自主行動的人工智慧代理。

這也是為什麼 AI Agent 的管理方式不能只沿用聊天機器人的做法。若一個客服 Agent 只負責建議回答內容，錯誤可能是一段不正確的文字；如果同一個 Agent 能修改訂單、啟動退款、建立補償方案，錯誤就可能直接形成財務損失。Salesforce 在 2026 年談 Agent 治理時也特別強調，當人工智慧從回答問題走向執行交易，治理機制就必須從提示詞層級的「護欄」，升級成真正會約束行動的政策與資料控制。

隨著越來越多企業讓 Agent 進入客服、財務、採購、人力資源與資訊系統，治理因此不會只是人工智慧專案的一項附屬工作，而會逐步成為日常營運的一部分。真正的問題不再是「要不要相信人工智慧」，而是如何精確定義：哪些事情可以放心交給它、哪些事情只能讓它提出建議、哪些情況必須交還給人，以及整個過程如何被追蹤。

AI Agent 開始接手真正的工作

Microsoft 自己的 Agent 發展歷程就是這個轉變的實例。Microsoft Digital 表示，內部的 Agent 已被用來自動化多步驟任務、串接不同系統，以及簡化原本仰賴人工協調的工作。當 Agent 數量與自主程度增加後，Microsoft 發現過去分散在不同管理介面的控制方式已經不足，因此開始使用中央管理方式，集中了解 Agent 的建立者、使用者、可存取資料與運作情形。

這些能力看似都是技術管理問題，實際上與企業的責任制度密切相關。假設一個採購 Agent 發現某項原料低於安全庫存，自動向供應商詢價並建立採購單；這一連串動作可能完全符合商業流程，但企業仍然必須知道，這個 Agent 是以誰的授權執行、可以採購到什麼金額、哪些供應商可以使用，以及超過哪一個門檻之後必須交給人審核。只要其中一個界線沒有說清楚，人工智慧的自主能力就可能變成責任上的灰色地帶。

這也是 NIST 人工智慧風險管理框架一直強調「治理」必須貫穿人工智慧生命週期的原因。NIST 的生成式人工智慧風險管理文件不是把管理集中在模型建置階段，而是要求組織持續衡量、監控與管理人工智慧在實際使用環境中的風險，並依使用情境、風險容忍度與法律要求調整控制方式。對 AI Agent 而言，這種持續治理尤其重要，因為同一個模型一旦獲得不同工具與權限，能造成的實際影響就完全不同。

換句話說，企業不能只替 Agent 設定一句「請勿執行未授權的操作」，然後期待語言模型自行遵守。Microsoft 在談授權型 Agent 架構時就明確指出，在受監管或高安全需求的環境裡，權限應由身分與授權系統真正執行，而不是只依賴提示詞告訴模型什麼不能做。這是一個重要的治理原則：安全邊界必須存在於模型之外。

重新定義責任歸屬

要讓 AI Agent 持續創造成效，企業首先必須重新定義責任歸屬。在過去，人工智慧計畫往往由資訊部門、資料團隊或創新部門主導，事業單位只是提出需求；然而，當 Agent 實際執行的是客服、財務、採購或業務工作時，負責該工作的事業單位就不能把 Agent 的結果完全視為資訊部門的責任。

例如，一個客服 Agent 最後是否可以退款、什麼情況需要上呈主管、什麼樣的回答符合公司的服務標準，這些都不是資訊工程師可以單獨決定的問題。技術團隊可以建立權限、整合系統、留下紀錄，但真正理解哪些決策合理、哪些行動會傷害客戶關係的人，仍然是客服單位本身。人工智慧執行的是誰的業務流程，誰就必須參與定義它的行為邊界。

Microsoft 在自己的治理架構中，也採取跨部門而非單一資訊部門主導的方式。Microsoft Digital 建議企業成立跨職能的 AI 治理或卓越中心，讓資訊、安全、法務、資料治理與事業單位共同定義原則，再依 Agent 的使用範圍、資料來源、能採取的行動與風險程度建立不同層級的管理方式。這種治理不是為了讓所有 Agent 遵守一模一樣的規則，而是讓風險較高的 Agent 接受更嚴格的控制。

定義四道治理邊界

我們綜合 Microsoft 的企業實務、NIST 的人工智慧風險管理框架，以及 OWASP 對 Agentic AI 攻擊面的研究，可以把企業最核心的 AI Agent 治理問題整理成四道邊界。這四道邊界不是技術產品的功能清單，而是企業在允許 Agent 接觸正式系統之前，至少必須能回答的四組問題。

1. 身分邊界：它究竟是誰？
   每一個正式執行工作的 Agent，都應該有可以辨識的身分、負責人與生命週期。企業必須知道 Agent 是誰建立、代表誰執行、目前是否仍有效，不能長期使用某位員工的共用帳號或一組來源不明的憑證。
2. 權限邊界：它可以看到什麼、使用什麼？
   Agent 不應該因為「可能用得到」就取得整套系統的完整權限。負責查詢庫存的 Agent 不需要修改庫存；負責建立報價草稿的 Agent，也不必然需要正式送出報價的權限。最小權限原則在 Agent 時代反而變得更加重要。
3. 決策邊界：它可以自主做到哪裡？
   有些工作可以完全自動執行，有些工作只能提出建議，有些則必須在特定金額、風險或條件出現時停下來等待人工核准。這個「人應該在哪裡重新進入流程」的設計，是 AI Agent 能否安全擴大的關鍵。
4. 稽核邊界：事情發生之後能不能還原？
   企業必須能回答某個 Agent 在什麼時間、接受什麼任務、使用哪些資料、呼叫哪些工具、做出哪些變更，以及是否曾經由人核准。沒有完整的紀錄，就很難建立真正的責任制度。

這四道邊界其實與企業管理真人員工時採取的基本邏輯相當接近。員工進公司時會取得一個帳號、被分配職務權限、受到授權層級限制，離職後帳號會被停用，重要操作也會留下紀錄。差別在於，Agent 可以大量複製、持續運作，而且能在短時間內進行遠比人類更大量的操作，所以企業需要把這些傳統治理原則變得更自動化、更即時。

成熟的 AI Agent 治理具備哪些能力

我們認為，能夠真正把 Agent 帶入企業正式環境的治理制度，就像過去企業建立資訊安全管理、身分管理與開發維運制度一樣，必須同時兼顧控制與營運效率。單純把所有行動都禁止，Agent 就失去價值；完全依賴模型自行判斷，又會讓企業暴露在無法接受的風險中。成熟的制度至少需要具備六項能力：

1. 可識別的 Agent 身分：每個 Agent 都有自己的識別、擁有者與負責單位，並且能與建立它的使用者或服務建立明確關係。Microsoft Entra Agent ID 已經將這類身分管理正式納入企業身分系統。
2. 細緻的存取控制：權限應該依使用者、Agent、工具與資料範圍決定，而不是只靠單一共用金鑰決定一切。
3. 風險分級：只查詢公開知識的 Agent，與可以修改企業資源規劃系統資料的 Agent，不應該接受完全相同的審查流程。Microsoft 的內部治理也依 Agent 的開發工具、分享範圍、資料來源與行動能力採取不同強度的治理。
4. 人機交接機制：當 Agent 遇到高金額、低信心、敏感資料或規則例外時，系統必須知道什麼時候停下來交給人，而不是無限嘗試。
5. 完整可觀測性：除了系統是否成功執行以外，還要能看到 Agent 使用量、工具呼叫、錯誤、異常行為、人工上呈比例與實際商業成果。
6. 生命週期管理：Agent 建立之後不應永久存在。負責人離職、專案結束、工具被替代或長期無人使用時，都應該有下架、重新審核或撤銷權限的機制。

這些能力也說明，AI Agent 治理並不是「資訊安全部門多加一項檢查」。它會同時牽涉企業的資訊架構、資料治理、部門責任與營運流程。OWASP 在 Agentic AI 的威脅模型中，把推理、記憶、工具、身分、人類監督與多 Agent 互動都列為攻擊面，就是因為 Agent 的風險已經不再集中於模型本身，而存在於整個系統之間的互動。

因此，企業未來衡量 Agent 是否管理得好，也不能只看「沒有發生資安事件」。真正成熟的治理還應該回答另一個問題：這些限制是否讓低風險 Agent 可以更快上線？如果每個 Agent 都要經過數個月審查，治理本身就成為創新的瓶頸。好的制度應該讓風險愈清楚，企業愈敢自動化。

如何建立 AI Agent 治理制度

企業開始建立 Agent 治理時，最容易犯的錯，是試圖一次制定一套涵蓋所有未來情境的完整人工智慧政策。Agent 技術的變化太快，很難靠一次性的文件解決所有問題。Microsoft 在自身的治理經驗中也強調，治理架構必須持續重新檢討，因為模型、工具、Agent 能力與企業採用方式都會變化。

比較實際的方法，是先從 Agent 清冊開始。企業首先要知道現在到底有哪些 Agent 正在使用、誰建立、服務什麼流程、使用什麼資料，以及是否可以採取行動。只有先讓 Agent 變得可見，才有可能進一步管理它。Microsoft Agent 365 與 AWS Agent Registry 近年都把「集中發現與盤點 Agent」列為企業 Agent 管理的核心能力，正反映這個問題正在快速形成。

第二步，是將 Agent 依風險分類，而不是依模型分類。一個使用最先進大型語言模型、但只查詢公司公開文件的 Agent，實際風險可能比一個使用較小模型、卻擁有修改薪資資料權限的 Agent 更低。治理應該依資料敏感度、行動權限、不可逆性、影響人數與財務風險決定，而不是問它使用 GPT、Claude 還是 Gemini。

第三步，是把真正的權限控制放到模型之外。Agent 可以負責理解需求與規畫下一步，但「它是否有權呼叫這個工具」應該由身分、授權與企業政策判斷。如此一來，即使提示詞受到攻擊、模型判斷錯誤，系統仍然存在第二層真正有效的邊界。Microsoft、OWASP 與 NIST 的相關建議，都逐漸朝這種「模型負責推理、外部控制負責限制」的方向靠攏。

最後，治理制度必須留下可以學習的資料。哪些 Agent 經常被人中止？哪些工具最容易失敗？哪些流程幾乎從不需要人工介入？哪些使用者一直要求超出權限的操作？這些資訊不只用來追究問題，更能幫助企業逐步重新調整人與 Agent 的分工。如果沒有這些回饋，治理只是靜態規則；有了這些資料，治理才會成為營運管理。

這也意味著，未來 AI Agent 的治理不應該只在專案上線前發生一次。它更像資安監控、網站可靠性工程或開發維運，是一個持續觀察、調整與改善的循環。模型更新、工作流程改變、資料來源增加，都可能改變一個 Agent 原本的風險，因此治理必須跟著產品本身持續演進。

AI 治理正在成為新的企業基本能力

隨著 Agent 開始進入企業核心系統，專門管理 Agent 的平台與制度也正在快速成形。Microsoft 已經把 Agent 身分與生命週期納入 Entra，Amazon Web Services 建立 Agent Registry 與 AgentCore Gateway，OWASP 則發布專門面向 Agentic AI 的安全風險分類。這些動作顯示，產業正在從「如何建立 Agent」，逐步走向下一個問題：「建立一百個 Agent 之後，企業要怎麼管理？」

因此，現在正是企業建立基本治理框架的時刻。等到公司裡出現數百個 Agent 之後才開始盤點，成本一定比一開始就設計身分、權限、紀錄與生命週期高得多。尤其當 Agent 開始具有真正的執行能力，治理不能等到第一次事故發生才建立。

科技本身不會替企業決定責任。模型可以推理、Agent 可以執行、系統可以自動化，但最後仍然必須由企業決定，誰有權把什麼工作交給人工智慧，以及人工智慧可以走到哪一步。當 AI 只會回答問題時，我們管理的是答案；當 AI 開始真正做事時，企業必須開始管理它的權力。