iT邦幫忙

0

企業 AI Agent 不能是超級管理員:談 AI 治理與虛擬員工時代

  • 分享至 

  • xImage
  •  

參加 2026 年 3 月 10 日 Microsoft AI Summit Taipei 研討會,對其中 AI 治理議題特別有感:為什麼未來的企業 AI,應該被當成一位有編號、有職掌、受治理的虛擬員工來管理。

ai-agent


🚨 問題的起點:Agent 成了超級管理員

最近火熱的 AI Agent,本質上就是一個會很多技能(Skill)的自動化系統,使用者下命令,它來執行。這個模式用在個人開發者手上沒問題,但放進企業環境,問題馬上浮現:它成了一個不受拘束的「超級管理員」,理論上能存取一切、操作一切。

這不是技術問題,而是治理問題

相關研究數字說明了現況有多嚴峻:

  • 29% 的員工使用了未經核准的 AI Agent 執行工作任務¹
  • 只有 47% 的組織有針對 GenAI 部署實施特定的安全控管措施²
  • 企業中運行的 AI Agent 數量預計在未來五年內成長逾十倍³

¹ Microsoft 委託 Hypothesis Group 跨國調查,2025 年 7 月,1,725 位資料安全專業人員參與,發布於 Cyber Pulse: An AI Security Report
² Microsoft Data Security Index 2026,Microsoft Security,2026
³ IDC Worldwide Artificial Intelligence IT Spending Market Forecast(2025 年 8 月),Microsoft 發表場合引述為「2028 年超過 10 億個 Agent」,原始報告描述為「五年內呈對數級(10x)成長」

Microsoft 把失控 Agent 帶來的風險稱為「Double Agents(雙面諜)」:當 AI Agent 在沒有治理框架的環境中運行,一旦遭受 prompt injection 或模型污染攻擊,它可能從幫你做事的工具,變成對抗組織利益的風險源。


🔄 核心思維轉換:Agent 是虛擬員工,不是工具

這是企業 AI 治理最關鍵的概念轉變。現有的 Agent 框架把 AI 當作「強力工具」設計,給它最大權限,換取最大靈活度。但企業的 IT 治理邏輯,從來不是這樣運作的。

想像一個新員工入職的流程:有員工編號、隸屬組織、有職掌描述,IT 根據角色授與最小必要權限,只能看到跟工作相關的資料,操作行為有紀錄可查。這套流程已被 SOC 2、ISO 27001、金融法規驗證了幾十年。

那 AI Agent 為什麼不能套用同樣的框架?

面向 傳統 Agent 模式 企業治理 Agent 模式
身份 工具/服務,無獨立身份 虛擬員工,有 ID、有組織歸屬
權限 預設最大,事後再收 最小權限,入職時 IT 審核授權
工作空間 共用或無限制 專屬郵件、行事曆、儲存空間
職掌 什麼都能做 專職工作,聚焦職掌範圍
稽核 難以追溯 所有動作可查,供內外稽核
跨域存取 自行決定 需申請、需審核

每個 Agent 應視為一個虛擬員工:有員工編號、所屬組織、專職工作,跟新員工入職一樣,需要由 IT 授與權限、跑審核流程,只能看到授權給他的相關資料。專職化的另一個好處是成本控制:每個 Agent 只做份內的事,可以選用最適合該任務的模型,不需要每件事都動用最貴的旗艦模型。


🏗️ 治理框架的四個層次

一個可落地的企業 AI 治理架構,至少需要涵蓋以下四層:

身份層(Identity)
每個 Agent 有獨立的身份識別,等同員工的 AD 帳號。可套用 MFA、條件式存取、角色型權限(RBAC),並透過 Microsoft Entra Agent ID 等機制納入既有的 IAM 流程。

治理層(Governance)
統一清查組織內所有 Agent(包含第三方)的 Agent Registry,讓 IT 一眼看清有哪些 Agent 在運行、存取了什麼資源、行為是否符合政策。

工作空間(Workspace)
Agent 擁有自己的郵件信箱、行事曆、儲存空間,在授權範圍內操作 M365、CRM、ERP 等系統,與人類員工在同一套協作環境中共存。

稽核層(Audit Trail)
所有 Agent 動作、資料存取、跨域請求,全部留有日誌,記錄 Who、What、When、Where、Why 五要素,可供內部稽核與外部合規查核。這正是 SOC 2 Type II 稽核要求的基礎。


🤝 協作場景:人與 Agent 在同一個會議室

治理框架到位之後,真正有趣的事才開始:人與 Agent 的交互協作

以一場產品規劃會議為例,與會者除了人類的產品企劃、業務主管,「市調 Agent」和「業務 Agent」也是會議成員。這不是 chatbot 回答問題,而是 Agent 以一個有身份的協作者身份參與討論:提供市場數據、分析客戶反饋,在職掌外的議題靜默旁聽,被詢問時才發言。

這個場景能成立的治理前提:

  • 市調 Agent 只能讀取被授權的市調資料庫,無法存取財務或 HR 系統
  • Agent 的發言與操作紀錄完整保存,會後可供 Compliance 團隊查閱
  • 若 Agent 需要存取非授權資料,必須透過申請流程由人類主管審核
  • Agent 帳號可被停用、可被稽核,跟離職員工帳號回收的流程一致

🧠 更進一步:Agent 與 Agent 的協作,才是開創性想法的來源

人與 Agent 的協作只是第一步。更深遠的影響,來自 Agent 與 Agent 之間的互動

每個 Agent 都有自己的「腦」,也就是驅動它的 AI 模型。根據工作內容選配合適的模型,不只是成本考量,更會造就真正意義上的認知異質性:一個擅長分析推理的模型、一個擅長創意發散的模型、一個保守謹慎的風控模型,面對同一個問題會有截然不同的切入角度。

這裡有個關鍵洞察:如果所有 Agent 都跑同一個模型,它們的思考偏差方向是一致的,討論出來的結果只是同溫層。但當不同模型背景的 Agent 被迫針對同一個提案各自論證,讓保守的風控 Agent 和激進的產品 Agent「吵架」,最後由人類或 Orchestrator Agent 裁決,這個流程產出的結果,很可能比任何單一 Agent 或人類的獨立判斷都更完整。

人類歷史上很多突破性想法,都來自不同背景的人被迫一起解決同一個問題。Multi-Agent 的協作機制,本質上是在組織內複製這種認知摩擦(Cognitive Friction),而且可以在幾分鐘內完成原本需要跨部門會議幾週才能收斂的討論。

這種 Agent 對 Agent 的協作模式,目前在技術上已有 Multi-Agent Orchestration 的框架在推進,但真正的平等式討論協議(而非主從式的 Orchestrator 指揮 Sub-agent)仍是尚待成熟的領域。這個差距,才是下一個真正值得投入的技術問題。


🔍 治理成熟後的下一步:外部稽核

當 Agent 被納入完整的治理框架,所有行為都有日誌、所有存取都有紀錄,這份資料的價值或許不只停留在內部管控,有可能進一步成為外部稽核的佐證材料

這個演進路徑有點像 ERP 的歷史。企業當初導入 ERP 是為了營運效率,不是為了讓會計師查帳,但等資料夠完整、夠可信之後,ERP 日誌逐漸成了財報稽核的重要依據。Agent 治理日誌,或許也有機會走上類似的路。

如果這個方向成真,未來上市公司的會計師查核範圍,可能會延伸到 AI Agent 的行為,驗證這個虛擬員工有沒有越權存取、有沒有操作不該碰的財務資料、有沒有繞過 Internal Control。


📋 給各角色的行動建議

IT 主管
現在就開始清查組織內有哪些「影子 Agent」在運行。沒有身份、沒有日誌的 Agent 是最大的資安缺口。建立 Agent Registry 是第一步,接著把 Agent 納入既有的帳號生命週期管理(Joiner / Mover / Leaver)流程。

架構師 / 工程師
新建 Agent 時,把最小權限授權視為標配,而非事後的合規補貼。設計 Agent 的職掌範圍,就像設計 API 的存取控制一樣嚴謹。同時思考模型選配策略:每個 Agent 用最適合的模型,而非預設最貴的旗艦模型。

業務主管 / CISO
治理框架的建立不只是技術問題,更是組織問題。Agent 的「入職流程」:誰來提申請、誰來審核權限、誰來負責 Agent 的行為,需要在技術建置之前先定義清楚。


Agent 不只是工具的進化,而是企業組織圖的延伸。
當 AI 真的有了員工編號,當不同「腦袋」的 Agent 開始互相討論,
企業的集體智能才算真正被解放。


📢 歡迎轉載,請註明出處
📬 歡迎追蹤我的技術筆記與實戰經驗分享
FacebookHackMDGitHubNuGet


圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言