公司裡到底有多少 AI Agent 在跑？企業怎麼盤點未授權 AI、資料權限與責任歸屬

很多企業以為 AI Agent 都是資訊部門正式導入的：有專案、有權限、有負責人，也知道它連到哪些系統。

但實際情況可能完全不同。

行銷團隊自己用 AI 服務做內容流程，客服同仁串了一個自動分類工具，業務把 AI 接到 CRM 查資料，開發人員又用 API 做了另一個自動化任務。每一個工具單獨看都可能有價值，但當它們開始取得正式帳號、讀取企業資料，甚至自動更新系統時，管理問題就不再只是「員工用了哪個 AI」。

真正的問題是：公司裡到底有哪些 AI Agent 正在工作？它們能看什麼、能做什麼、出了問題要找誰？

這類企業不知道、沒有被集中盤點，卻已經接觸公司資料或流程的 AI 應用，市場上常被稱為 Shadow AI 或 Shadow Agent。名詞可以不記，但管理問題不能忽略。

Shadow AI Agent 跟員工自己用 ChatGPT，有什麼不同？

如果員工只是把一段公開文字丟進生成式 AI，風險通常集中在資訊使用規範。

但 AI Agent 往前跨了一步。

它可能具備：

公司帳號或 API Token。
CRM、ERP、文件庫或客服系統的讀取權限。
自動建立任務、寄通知或更新資料的能力。
定時執行、Webhook 觸發或無人值守的流程。
呼叫其他 Agent、外部 API 或自動化工具的能力。

所以 Shadow Agent 最麻煩的地方不是「有人偷偷用 AI」，而是某個沒被完整納管的 AI 已經擁有執行工作的手腳。

IBM 在 2026 年 8 月 26 日談企業 Agent fleet 時，把 shadow agents 列為最先浮現的風險之一：這些 Agent 可能使用真實憑證、操作真實系統，但企業卻缺乏完整可見性與稽核軌跡。

Microsoft 8 月底的安全更新也把重點放在提高 Agent 活動的可見性、治理身分與權限，以及在自主動作擴大前先建立控制。

這反映一個很明顯的市場變化：企業 AI 已經開始從「員工使用工具」進入「AI 代表人執行工作」。

為什麼企業很容易在不知不覺中長出一堆 AI？

通常不是因為員工故意繞過 IT，而是因為導入門檻已經變得太低。

今天一個部門可能在幾小時內完成：

選一個 AI 模型或 Agent 平台。
貼入 API Key 或 OAuth 授權。
連上 Google Drive、CRM、Email 或內部 API。
設定一條自動化流程。
開始替部門執行工作。

這在創新階段很有效率，卻也讓企業容易出現「每個部門各做一套」的情況。

最後不是只有工具變多，而是下列東西一起分散：

哪些資料可以被 AI 使用。
哪些帳號或 Token 已經授權。
哪些流程會由 AI 自動執行。
哪些操作需要人工確認。
哪個部門或人要對結果負責。
Agent 不再使用後，誰負責撤銷權限。

如果這些答案散落在不同人的瀏覽器、腳本、帳號與聊天紀錄裡，企業其實沒有真正管理 AI。

第一個要盤點的，不是模型，而是「權限」

很多企業盤點 AI 時會先問：「現在用了 ChatGPT、Gemini 還是 Claude？」

這不是最重要的問題。

更應該問的是：

這個 AI 用誰的身分登入？
它拿到哪些系統權限？
可以看到哪些資料表、文件或欄位？
它只有讀取權限，還是可以新增、修改與刪除？
權限是個人帳號、共用帳號，還是獨立服務帳號？
權限到期、負責人離職或專案結束時，誰會收回？

同一個 AI 模型，只有讀 FAQ 文件，和可以修改客戶、訂單或付款資料，風險完全不是同一個等級。

所以企業不應該只做「AI 工具清單」，而要進一步建立「AI 身分 × 資料 × 動作」的權限盤點。

建立 AI Agent 名冊，至少要記住六件事

企業不一定一開始就需要昂貴的大型治理平台，但至少要先知道自己正在管理什麼。

每一個正式或試用中的 Agent，建議至少建立以下資料：

Agent 用途：它解決什麼工作，不要只記產品名稱。
負責人：業務 Owner 與技術 Owner 是誰。
身分與憑證：使用哪個帳號、API Key、Token 或服務身分。
資料與系統範圍：連到 CRM、ERP、文件、Email 還是其他 API。
可執行動作：只能查詢，還是能更新資料、建立任務、寄信或送審。
生命週期狀態：測試、正式、暫停、待檢討或已停用。

除此之外，如果 Agent 具有比較高的自主程度，還要再補上：

是否需要人工確認。
哪些例外一定要升級人工。
最後一次權限檢查時間。
最近是否修改 Prompt、模型、工具或資料來源。
停用時需要撤銷哪些憑證與連線。

這個名冊的目的不是增加行政工作，而是讓企業終於能回答一個最基本的問題：

「如果今天發生資料外洩、錯誤更新或異常自動化，我們能不能在幾分鐘內找到是哪一個 Agent、用了哪個身分、碰了哪些系統？」

如果不能，責任與處理時間都會被放大。

未授權 AI 最容易造成的五種企業成本

1. 資料外洩與過度授權

員工可能只是想讓 AI 幫忙查詢資料，卻直接授予整個資料夾、CRM 範圍或共用帳號權限。

Agent 能做的事情，往往比原本的工作需求更大。

2. 自動化錯誤被放大

人做錯一筆，通常是一筆。

Agent 如果排程每小時執行一次，可能在被發現前已經做錯幾十次。

3. 重複整合與維護成本

兩個部門不知道彼此都在做 AI，便可能各自重接同一個 CRM、文件庫與 API，之後又各自維護。

這也是 Shadow AI 的隱性成本：不是只有安全，而是重工。

4. 出事後找不到責任人

誰建立的？誰批准的？誰知道 Prompt？誰有 API Key？

如果建立者已經離職或專案結束，問題會更難處理。

5. 正式 AI 治理永遠追不上現場

企業花時間制定 AI 政策，但現場已經有新的工具、新的 Agent、新的自動化流程在跑。

如果治理只靠禁止，員工可能轉往更難被看見的工具；真正需要的是把創新導回可管理的環境。

不要一發現 Shadow AI 就全部封鎖

Shadow Agent 的存在，往往也代表員工真的有工作痛點。

所以比較務實的做法不是「抓到就關掉」，而是先分類。

可以先分成三層：

低風險：只讀公開或低敏感資料，不會更新系統。
中風險：會讀取內部資料、產生判斷或建立工作，但關鍵動作仍需人工確認。
高風險：可以直接更新正式資料、對外溝通、執行付款或跨系統自動化。

治理強度應跟 Agent 能造成的影響成比例。

低風險工具如果被過度限制，員工會覺得 IT 只是在阻礙效率；但高風險 Agent 如果只靠「大家小心使用」，又明顯不夠。

一套可落地的治理循環：看見、登記、分類、控管、持續檢查

企業可以先從一個簡單循環開始：

看見：盤點部門正在使用的 AI、API、自動化服務與 Agent。
登記：建立 Owner、帳號、連線系統、資料範圍與用途。
分類：依敏感資料、可執行動作與自主程度分級。
控管：設定最小權限、人工確認、例外流程與紀錄。
持續檢查：定期檢視 Agent 是否仍需要、權限是否過大、負責人是否改變。
退役：不用的 Agent 必須連同 Token、帳號、Webhook 與排程一起收掉。

這裡的核心觀念是：

企業不只是要管理「AI 是什麼」，而是管理「AI 被誰建立、代表誰、能碰什麼、正在做什麼」。

niio 在這個問題裡能做什麼？

niio 不應被理解成一套會自動掃描整個公司網路、找出所有 Shadow AI 的資安偵測工具。

真正適合 niio 的位置，是把已經決定納管的企業 AI 應用，放回可管理的資料、權限與流程裡。

例如企業可以用 niio 建立自己的 AI 應用／Agent 管理資料結構，記錄：

Agent 用途與負責人。
使用模型與執行範圍。
關聯系統與資料來源。
權限與人工確認需求。
狀態、檢查日期與停用紀錄。

而在 niio 本身的 AI 應用中，平台既有權限可以限制 AI 查詢及操作資料的範圍；AI Agent 涉及新增、更新等資料異動時，也能設定執行前確認。

如果外部 AI Agent 需要透過 MCP 或 API 操作 niio 資料，仍應在企業授權與既有權限範圍內執行。

這樣的價值不是「把所有 AI 都搬進一個工具」，而是讓重要的企業 AI 工作逐步從看不見的個人自動化，變成：

有 Owner、有權限、有流程、有紀錄，也有停用機制的正式企業能力。

管理者今天就可以先問六個問題

不需要等到發生事故才開始。

資訊主管、數位轉型負責人或部門主管可以直接問：

公司目前有哪些部門正在使用 AI Agent 或自動化 AI？
哪些 Agent 已經連到正式公司資料或系統？
它們使用誰的帳號與權限？
哪些 Agent 可以直接修改資料或執行動作？
每一個 Agent 是否都有清楚的 Owner？
如果明天要停掉其中一個 Agent，我們知道要關閉哪些 Token、排程與連線嗎？

如果這六題有一半答不出來，企業現在最需要的可能不是再做下一個 Agent，而是先把已經存在的 AI 看清楚。

AI 創新越快，「看得見」反而越重要

AI Agent 的價值，本來就是讓工作更快、更主動。

但企業不能用「看不見」來換速度。

當 Agent 開始取得真實身分、真實資料與真實系統權限後，它就應該被當成正式的企業數位資產來管理。

不是禁止部門創新，而是讓每一次創新都有清楚的責任邊界。

真正成熟的企業 AI，不是 Agent 越多越好，而是企業知道每一個 Agent 為什麼存在、能做什麼，以及什麼時候該停下來。