行銷部門偷接了三個 AI 代理，而 IT 完全不知情：影子 AI 正在變成資安黑洞

某家台灣中型電商的資安人員跟我描述過一個場景。他在例行檢查 API 存取紀錄時，發現一組憑證在凌晨三點持續讀取訂單資料庫，每次幾百筆，持續了兩個多月。

不是入侵。是行銷部門三個月前接的一個 AI 代理，用來自動產出每日銷售摘要。憑證是當時某位工程師「先給他測試看看」給的，權限開的是唯讀全表。

沒有人是壞人。沒有人違反公司規定——因為公司根本沒有這條規定。

事件背景

影子 IT 這個詞存在很久了：員工繞過 IT 部門自行採用工具，用個人 Dropbox 傳檔案、用免費線上工具轉 PDF。風險真實存在，但邊界相對清楚——那些工具是被動的，你放什麼進去它就處理什麼。

AI 代理不一樣，而這個差異是關鍵。代理會主動執行動作：讀取系統、呼叫 API、寫入資料、發送訊息。它不是一個你偶爾上傳檔案的網站，是一個持續運作、持有憑證、在你的系統裡動手做事的東西。

而導入它的門檻低到不可思議。現在的低程式碼平台讓一位行銷專員在一個下午就能接好一個會讀 CRM、寫報表、發 Slack 訊息的代理。他不需要 IT 核准，不需要採購流程，甚至可能不覺得自己在「導入系統」——他覺得自己只是設了個自動化。

這個問題大到有新創專門在做。Y Combinator 2026 年夏季梯次的 Decawork 就自稱是「IT 團隊的代理控制平面」，主打讓 IT 部門在單一介面上部署、治理並維護整個組織的 AI 代理：上線前要簽核、憑證權限要縮限到最小範圍、所有動作都被監控留痕。公司由 Aman Raj 與 Sarthak Aggarwal 於 2026 年在舊金山創立，目前團隊只有兩人——規模很小，但方向說明了問題的真實性。

本次重點

• 影子 AI 與影子 IT 的關鍵差異：代理會主動執行動作，而非被動處理你給它的東西。
• 導入門檻極低，一位非技術人員一個下午就能接好一個持有憑證的代理。
• 最大的風險不是資料外洩，是權限過大且無人監督的持續存取。
• 稽核困難：代理的行為是動態的，傳統靜態權限模型不容易涵蓋。
• 這個問題正在被監管注意到，歐盟 AI 法對可稽核性的要求會加速企業處理。

市場影響分析

對台灣使用者

先講一件公道話：會自己接 AI 代理的員工，通常是團隊裡最積極的那群人。他們不是在破壞規矩，是在解決自己的問題，而且往往解得不錯。

所以處理影子 AI 的第一原則是：不要用禁止的方式處理。你一禁止，這件事只會轉入地下——原本還在公司帳號下的代理，會被搬到個人帳號上，變得更難追蹤。

務實的做法是提供一條合法的路。明確告訴同仁：你可以用代理，但要登記、要走一個簡化的審核、要用 IT 配發的憑證而不是跟工程師要。把摩擦降到最低，讓合規比違規更方便，這比任何政策文件有效。

對企業應用

從企業風險管理的角度，影子 AI 的危險性被系統性低估了，原因有三個。

第一是權限失控。憑證通常是臨時給的，給的時候想著「先測試」，測試完就沒人回來收。而 AI 代理為了能處理各種情況，被給的權限往往比實際需要的大——唯讀全表比逐張授權省事，所以就給了唯讀全表。

第二是資料流向不明。代理背後接的是哪家的模型？資料有沒有離開台灣？有沒有被用於訓練？導入的人多半沒問過這些問題，因為介面上不會顯示。

第三，也是最麻煩的：沒有稽核軌跡。當有一天需要回答「我們的客戶資料有沒有被不當存取」，如果代理是部門自己接的，你連從哪查起都不知道。

實務上的第一步不是買工具，是盤點。用最土法煉鋼的方式：查 API 金鑰的核發紀錄、查資料庫的異常存取模式、查各部門的 SaaS 訂閱帳單、直接問各部門主管「你們有沒有在用什麼會自動做事的工具」。這份清單通常會讓人嚇一跳。

盤點完之後才是分級：哪些代理碰得到個資、哪些能寫入而不只是讀取、哪些能對外發送訊息。碰個資又能寫入又能對外發訊的，就是最高風險，優先處理。

對開發者

對工程團隊來說，這件事最實際的教訓是：憑證核發要有生命週期。

「先給你測試」是所有問題的起點。合理的做法是任何臨時憑證都必須有到期日，時間到自動失效，需要延長就重新申請。這件事技術上不難，難在習慣。

另一個要建立的是最小權限的預設值。代理要讀訂單資料，就給它訂單資料的唯讀權限，不是整個資料庫。這聽起來是資安基本功，但在「快點讓它跑起來」的壓力下最常被跳過。

我也建議把代理的行為日誌當成第一等公民來設計。代理做了什麼、存取了什麼、輸出了什麼，這些如果沒有在設計時就留下來，事後絕對補不回來。歐盟 AI 法對可稽核性的要求正在把這件事從最佳實務推向必要條件。

未來發展趨勢

第一，代理治理會成為 IAM（身分與存取管理）的延伸領域。現有的權限管理工具是為人與應用程式設計的，代理的行為模式介於兩者之間——它像應用程式一樣持續運作，卻像人一樣做出不可預期的判斷。這個空隙會被填補，可能由既有的資安大廠併購新創來完成。

第二，「代理身分」會變成一個明確的概念。就像服務帳號（service account）當年從人類帳號中分化出來，代理需要自己的身分類型、自己的權限模型與自己的生命週期管理。

第三，監管會加速這件事。當企業必須向主管機關證明自己的 AI 系統做了什麼，那些沒人知道存在的代理就會變成不可承受的風險。合規壓力往往比資安警告更能推動預算。

TheAI學院 總結與評語

我想先說一句可能不太受歡迎的話：這件事的責任不在那些自己接代理的員工身上。

當公司沒有提供合法途徑、沒有說明規則、也沒有人告訴你「拿一組唯讀全表的憑證給外部服務」有什麼問題時，員工用自己的方式解決問題，是完全合理的行為。責任在於組織沒有跟上工具的變化速度。

我對這個問題的判斷是：它現在還沒爆，但正在累積。多數企業裡的影子 AI 都還在「幫忙產報表」這種相對無害的階段，但代理的能力每個月都在變強，同一組憑證明年可能就不只是讀資料了。

處理的時機是現在，趁清單還盤點得完的時候。

評語：影子 AI 不是員工的紀律問題，是組織的治理缺口。禁止沒有用，唯一有效的做法是把合規的路鋪得比違規更好走。

給台灣讀者的具體建議：如果你負責公司的 IT 或資安，這個月做三件事。第一，盤點——查 API 金鑰核發紀錄、資料庫異常存取模式與各部門 SaaS 帳單，做出一份代理清單。第二，收斂憑證——所有臨時憑證設到期日，所有代理權限縮到最小必要範圍。第三，開一條合法通道——設計一個五分鐘能填完的登記表，讓同仁願意主動報備。至於治理工具，Decawork 這類產品方向正確但團隊僅兩人、今年才成立，現階段建議先理解問題、小範圍觀察，別急著把公司的鑰匙交出去。想了解更多相關工具，可以看站上的 AI 開發框架與基建 分類，或參考 AI 任務指南。

資料來源

• Decawork（Y Combinator 公司頁）
• 歐盟執委會：AI 法執法框架

（本文依公開資訊整理，案例情境為綜合多方訪談後改寫，不指涉特定公司。）