# Vibe Coding 時代的 AI 治理：當 Shadow IT 變成 Shadow AI > 當 AI 讓行銷、HR、業務都能自己跑後端，Shadow IT 變成了 Shadow AI。從現象、成因到一套可用的治理框架，看 AI 治理在 vibe coding 時代的新難題。 2026 年 5 月，以色列資安公司 RedAccess 掃出 38 萬個 vibe coding 做的、公開掛在網路上的應用，其中約 5,000 個裝著真實的公司機密：巴西一間銀行的金流資料、英國一項臨床試驗的病患記錄、一間醫院的醫病對話與員工班表、一所學校的上課錄影與學生個資。這些 app 跑在 Lovable、Replit、Base44、Netlify 這類平台上。[根據 Axios 報導](https://www.axios.com/2026/05/07/loveable-replit-vibe-coding-privacy)，大多不是被駭，是平台預設公開、沒人手動關成私有，於是被搜尋引擎直接收錄。 做這些 app 的人，多半不知道自己漏了東西——這就是 AI 時代的 Shadow IT。這個詞先記著，等一下回來講清楚。 --- 把鏡頭拉近，看一個更日常的版本。 週一早上十點，IT 主管志明接到一通電話。 公司的會員活動頁面當機，顧客付了錢但沒收到確認 email；志明打開 dashboard 想查 log，卻找不到這個服務，問了一圈才知道，這是行銷團隊上週用 Cursor 寫的，跑在某個人的個人雲端帳號上。 志明的工作從這一刻開始改變了。 這不是個案。shadow IT（員工繞過正式 IT 流程、自己採用工具或自建系統）一直都在，但當 AI 工具讓行銷、業務、HR 都能自己寫一個 production 應用，它的尺度從「員工偷裝個 SaaS」躍升到「員工偷跑一套後端」，傳統 IT 治理的工具箱應付不了這個量級。這篇談的就是這道新題：當 shadow IT 變成 shadow AI，企業的安全邊界怎麼跟著移動、夾在最前線的 IT 主管（在中小企業 / 傳產也常稱 MIS、資訊主管，依公司規模也叫資訊長 / CIO）又該怎麼接。 先把範圍標清楚：AI 治理很大，模型風險、AI 使用政策、human-in-the-loop、責任歸屬都在裡面。這篇聚焦其中一塊、也是最近最快浮上檯面的一塊：vibe coding 把 shadow IT 變成 shadow AI 之後，企業安全邊界怎麼移。會從現象、成因，一路講到一套可以照著做的治理框架。其他幾塊，另文處理。 > **TL;DR** > - **框架**：AI 治理三層，可見性 → 邊界 → 稽核；順序很重要，跳級會掉下去。 > - **論點**：沙盒成為新的企業安全邊界，不要禁 vibe coding，把它收進 IT 看得見的地方。 > - **三步走**：盤點現在跑了什麼 → 開一個被允許的 workspace → 建立稽核節奏。 ## Vibe coding 時代的 Shadow AI：為什麼比過去的 Shadow IT 嚴重十倍 Shadow IT 不是新詞，Gartner 在 2010 年代就把它變成專有名詞。對 IT 來說它是治理盲點，對員工來說它常是「為了把工作做完」的合理選擇，兩邊立場各有道理；長期累積下來，公司資料、流程、權限會散在 IT 看不到的地方。 十年前的 shadow IT 是員工偷用 Notion、自己付費裝 Slack。IT 主管的工作是審 SaaS 採購單、寫 acceptable use policy、定期跑盤點。痛點是「資料散在不對的地方」，但這些地方至少是知名 SaaS，背後有 SOC 2 報告、有 SLA、有客服窗口。 Shadow AI 是 shadow IT 在 AI 時代的版本，底層問題一模一樣：員工把機敏資料放到第三方、未經 IT 審核的服務上。真正變的是那個「第三方」的性質：過去是現成 SaaS，現在是 vibe coding 平台、或員工自己搭的後端與資料庫。容器從「審計過的知名服務」換成「沒人管的自建系統」，風險自然不是同一個量級，攤開比較： | 維度 | Shadow IT（過去）| Shadow AI（現在）| |---|---|---| | 機敏資料放在哪 | 現成 SaaS（Notion、Slack）| vibe coding 平台、或員工自建的後端 + 資料庫 | | 那個服務背後有什麼 | SOC 2、SLA、客服窗口 | 沒治理紀錄、沒人接手 | | 出事的規模 | 一個帳號、一份資料 | 後端 + 資料庫 + API 整套散出去 | | IT 的舊對策 | 審採購單、寫使用政策、定期盤點 | 舊工具箱應付不了這量級 | | 痛點 | 資料散在不對的地方 | 資料、後端、權限全散，出事叫不出名字 | 最關鍵的差別是「可控性」。以前資料不小心放上 Notion、權限忘了關、外部人士點進了頁面，關掉權限、刪掉頁面，風險大致就止血了。但 Shadow AI 是把機敏資料「接進」一個活著的系統：一個對外端點露了餡，攻擊者就能順藤摸瓜，把後面串的資料庫、API、其他內部資料全拉出來，刪一個頁面救不回來。開頭那 5,000 個外洩 app，就是預設公開、被搜尋引擎一路收走的。 這個現象比你想像的還普遍，幾個數字疊起來看： - 40%+ 企業會在 2030 年前撞上 shadow AI 的資安／合規事故（[Gartner 預測](https://www.itpro.com/technology/artificial-intelligence/gartner-says-40-percent-of-enterprises-will-experience-shadow-ai-breaches-by-2030-educating-staff-is-the-key-to-avoiding-disaster)）。 - 71% 員工用過未經授權的 AI 工具，51% 每週都在用（[Microsoft UK 2025 年 10 月調查](https://ukstories.microsoft.com/features/rise-in-shadow-ai-tools-raising-security-concerns-for-uk/)）。 - 真的規律在用 AI 的前線員工只有一半。拿得到 GenAI 是一回事（成熟產業七成員工有、未成熟產業不到一半），拿到了真的在用又是另一回事。[BCG 2025 年 9 月《*The Widening AI Value Gap*》](https://media-publications.bcg.com/The-Widening-AI-Value-Gap-Sept-2025.pdf)（1,250 位受訪者）把「能拿到 vs 真的在用」的這道缺口稱為「silicon ceiling」（矽天花板）。 就算規律在用 AI 的只有一半，這一半就已經在累積 IT 看不見的 shadow AI。 [vibe coding](/zh-TW/blogs/vibe-coding-explained) 把這個遊戲改了：員工做的事升級了一格，從「裝個 SaaS」變成「自己跑一套後端 + 資料庫 + API」。AI 工具（[Claude Code](https://docs.claude.com/en/docs/claude-code/overview)、Cursor、GitHub Copilot）讓「寫 code 的能力」從工程師擴散到所有人，但「跑 production 的責任」沒有跟著擴散。寫得出來，並不代表知道： - secret 不該寫進 repo。 - backup 不會自動跑。 - 流量衝 10 倍進來時要先做點什麼。 結果是公司不知不覺累積了十到三十個沒有任何治理紀錄的 production 服務。它們收客戶資料、發 email、串內部 ERP——而 IT 主管連名字都答不出來。這道[工具民主化與資安之間的拉扯](/zh-TW/blogs/on-the-edge-of-innovation-vibe-coding-between-tool-democratization-and-cybersecurity)，是 vibe coding 治理繞不開的底層張力。 ## 舊安全邊界為什麼守不住 vibe coding 產出 shadow AI 撐這麼大，背後是三股同時發生的力量，每一股都讓傳統 IT 防線（firewall、IDP）守不住員工的產出。 ### 部署門檻歸零，可見性全失 Lovable、Bolt、v0、Replit Agent、Claude Code 都把「寫完直接跑在平台沙盒」變成預設動作：不寫 Dockerfile、不設伺服器、不申請帳號。對員工是天大好事，對 IT 主管是可見性全失：他不知道公司有多少個沒走流程的 production app 在跑、跑在誰的個人帳號上、付費信用卡是誰的。 ### AI 要做出能用的東西，就得拿到真實公司資料 vibe coding 產出要從雛形變成真的能用，AI 就需要餵真實脈絡，客戶名單、訂單紀錄、過去問題的解法、內部 wiki。給越多脈絡、AI 寫出來的越貼場景。但給資料就要面對脫敏 / 隱私 / 合規責任；不給，員工就是巧婦難為無米之炊，產出停在「看起來會動但對不上場景」的玩具版本。 ### Agent + 員工自跑系統，繞過舊的識別邊界 Anthropic 的 Computer Use（2024-10）、OpenAI Operator、Devin 等讓 agent 自己動鍵盤滑鼠寫 code 並部署；員工的 AI 應用也常常自己跑出一個沒走 IDP（identity provider）的系統。SaaS 時代靠 IDP 管「誰能登入哪個系統」，現在被新的 actor（agent）跟新的 surface（員工自己開出來的 production app）一起繞過。 [Deloitte 2026 年《State of AI in the Enterprise》報告](https://www.deloitte.com/global/en/issues/generative-ai/state-of-ai-in-enterprise.html) 指出只有 1 in 5（20%）公司對自主 AI agent 有成熟治理模型，並直接點出方向：「Effective governance integrates with existing risk and oversight structures, not parallel 'shadow' functions」。意思是治理要整合進既有風險結構、而不是另開平行的 shadow 機能。 這三股力量把「企業安全邊界」的定義改了。新的邊界該落在哪、為什麼答案會指向「沙盒」，後面會專門展開（這個詞同樣先擱著）。 ## Shadow AI 失控的三個訊號：可見性、邊界、稽核危機 當 IT 主管開始講這三句話的時候，shadow IT 的問題已經到了該動的時間點： ### 訊號一：可見性危機 > 「我不知道公司現在有幾個應用在跑」 員工的 AI 應用散在不同帳號、不同付費卡、不同 PaaS；IT 沒有清單，每次出事第一個被叫的是他，但他連這個東西叫什麼都不知道。 ### 訊號二：邊界危機 > 「他下週離職，但我不知道他做的東西用了哪些公司資料」 員工把客戶資料庫的連線字串給 AI 看、寫進 code 裡，跑在他的個人帳號上。當這個人離開，公司沒有接手這套東西的機制，也沒有收回他存取權的方式。 ### 訊號三：稽核危機 > 「年底要過稽核，但這些東西不在我控制範圍內」 客戶要求 SOC 2、政府標案要 ISO、產業要過資安檢查。稽核員會問「存取紀錄？備份？變更紀錄？誰能改誰能看？」IT 主管沒有答案。 ## 企業 AI 治理的兩難：IT 主管夾在導入與風控之間 先看一個基準數字：[McKinsey 2025 年《The State of AI》全球調查](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai)（橫跨 105 國、1,993 位受訪者）發現，88% 的組織已經在至少一個業務職能規律使用 AI，但只有 18% 建立了企業層級的 AI 治理委員會。也就是說，八成以上的公司，員工已經在用 AI，治理結構卻還沒長出來。IT 主管的兩難，就長在這道落差上。 要理解 IT 主管的困境，先看上面兩層的壓力。 ### 老闆視角：AI 導入的焦慮 2025-2026 這兩年幾乎每個公司老闆都在 AI 焦慮：同業在做、競爭對手在做、媒體在追、員工會問。本能反應是自上而下要求：「明年我們 AI-first」「每個部門交一個 AI 應用」「不會用 AI 的部門要重新評估」。這些要求的目的，是讓公司看起來在動、不被洗掉。但自上而下推動跟真正導入之間有一道鴻溝。 Duolingo 是這個鴻溝公開化的代表案例：2025 年 4 月 28 日 CEO Luis von Ahn 在 LinkedIn 公告 "AI-first" 策略：逐步停用 AI 能取代的約聘人員、把「會用 AI」列入招募條件與績效考核；[TechCrunch 報導](https://techcrunch.com/2025/04/30/duolingo-launches-148-courses-created-with-ai-after-sharing-plans-to-replace-contractors-with-ai/) 公告兩天後公司就推出 148 個 AI 生成課程，把 12 年的課程開發量壓縮到不到一年。社群反彈迅速爆發：學員取消訂閱、刪 app、TikTok 負評洪水，Duolingo 把所有 TikTok / Instagram 貼文刪光、整體沉寂了一段時間。約四週後 von Ahn 在 LinkedIn 公開撤回先前發言，[Fortune](https://fortune.com/2025/05/24/duolingo-ai-first-employees-ceo-luis-von-ahn/) 引述他的原話：「I do not see AI as replacing what our employees do」、並聲明招募仍維持原本步調；Q2 2025 法說會上他也承認，AI 言論讓 DAU 增長落到預期低點（40% YoY，去年同期 60%）。 這個套路在很多公司自上而下推 AI 時都重複出現。[Fortune](https://fortune.com/2025/05/09/klarna-ai-humans-return-on-investment/) 報導 Klarna 用 AI 取代 700 名客服、半年後又重新招回人，是同樣劇本。 我自己最常用的描述是： > 用上不等於導入、導得入也不代表用得上。—— [Ling Wu](https://thelingwu.com) 員工每天打開 Cursor（甚至拿它問午餐吃什麼）不代表公司真的把 AI 導入了工作流；就算真的拿它開發出幾個小系統，多數公司也還沒有一把尺，去衡量「到底有沒有靠 AI 提升生產力」。中間兩道落差（treatment vs deployment、deployment vs utilization）都會卡。 ### IT 主管視角：風控與彈性的兩難 在這個夾心餅乾結構裡，IT 主管要同時回應老闆「我們要 AI-first」的要求（推導入）、又要管 vibe coding 蔓延的治理風險（守穩定）。這是放行與管控同時做的工作，任何一邊太多就翻車。 對應的兩個極端反應，都是夾不住兩邊的版本： #### 反應一：封殺 「以後不准員工自己用 AI 寫應用，全部走 IT 申請流程。」結果是強迫大家用會卡自己手的工具：IT 准的那組往往跟外面 builder 在用的能力差一截，做不到員工真正想做的事；員工不會因為 IT 反對就停下來（老闆才剛說「大家用 AI 提升效率」），於是繼續做、放到更隱蔽的地方。封殺把可見性危機放大成地下化危機，且讓 IT 主管在老闆眼裡變成「AI 推不動的瓶頸」。 #### 反應二：放任 「反正稽核還沒到，先不管。」姑且放著，但放著放著問題會自己長大：不熟前端框架跟資料庫選擇的同事各自挑工具，三個人可能就用了三種不同框架、四種不同資料庫；十個系統同時長出來，公司手上是一堆排列組合的技術堆疊等著有人收。等稽核員真的上門，IT 主管要扛的不只是稽核噩夢，還有當初放任沒處理的技術堆疊排列組合一起爆。 夾心餅乾的痛說穿了是：老闆只看導入有沒有動、員工只在意自己寫的能不能跑，風險（資料外流、合規破口、稽核失敗）跟維運的債（誰修、誰備份、誰換工具）卻全壓在 IT 主管一個人身上——沒人關心你扛的是什麼。 對的方向是第三條路：把 AI 產出物收進 IT 看得見的環境，但不阻止員工繼續寫。換個說法：**沙盒成為新的企業安全邊界**（英文圈一句話叫「sandbox is the new perimeter」）。 在這個切角下，IT 主管同時放行（員工繼續用 AI）+ 管控（IT 看得到 / 管得到），既回應老闆自上而下、又解治理風險，員工日常工作流也不被打斷。沙盒到底是什麼、為什麼這一兩年才變成企業安全邊界的預設答案，後面有一節專門講。 ## Vibe coding 治理框架：可見性、邊界、稽核三層 要把 vibe coding 治理當成嚴肅的企業層級議題來處理，業界已經有幾個既有標準在處理這個議題： - [NIST Cybersecurity Framework 2.0](https://www.nist.gov/cyberframework)（2024）— 6 大功能：Govern、Identify、Protect、Detect、Respond、Recover。涵蓋從風險辨識到事件回應的完整 cyber governance lifecycle。 - [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)（NIST AI 100-1, 2023）— 4 大功能：Govern、Map、Measure、Manage。把 AI 風險當成企業風險來治理的基準。 - [ISO/IEC 42001:2023](https://www.iso.org/standard/81230.html) — 第一個國際 AI 管理系統標準，對齊 ISO 9001 / ISO 27001 等既有 ISMS 框架。 這些標準之間怎麼對齊、SMB 該從哪裡開始落地、實作上有哪些取捨（quality gate、operational debt、technical debt、paved path 這幾個 AI 治理術語怎麼套進自家流程），會在另一篇文章完整拆解。 本篇把上面這些標準摘錄成三層、可以快速辨識 vibe coding 場景問題的框架：visibility、boundaries、audit。順序很重要，每一層解的問題不同： | 層 | 解的問題 | 具體 artifact | 跳過會怎樣 | |---|---|---|---| | **1. 可見性** | 現在在跑什麼？ | 一個 workspace、一個 dashboard、一個帳單入口 | 出事時 IT 主管說不出服務的名字 | | **2. 邊界** | 每個東西能碰到什麼？ | 環境隔離、共用 secret manager、座位撤銷自動化 | 員工離職時資料跟著走 | | **3. 稽核** | 誰、何時、做了什麼？ | 稽核日誌、資源歸屬、部署歷史 | 稽核員的結論寫「我們不知道」 | ### 第一層：可見性（visibility） 最基本的工作是把所有 AI 應用收進同一個地方看。一個帳單入口、一個 dashboard 看全部 deployment、一份稽核日誌知道誰改了什麼。 具體要做的事是：給員工一個被允許使用的環境（公司付錢的 workspace、公司管理的帳號），鼓勵他們的 AI 應用部署到這裡。員工繼續 vibe coding，IT 看得到。沒有可見性，後面兩層都做不了。 台灣本地的對照組是 91APP。[根據關鍵評論網報導](https://www.thenewslens.com/article/196661)，他們在做 AI 推薦之前先成立「資料治理定義小組」、把 Looker 當作集中的資料治理平台，再讓 jooii 之類的零售 AI 模型長在上面。順序很清楚：先把資料看得見、定義收齊，AI 應用才接得上去。vibe coding 治理的第一層是同一條邏輯：先有看得見的環境，後面的放行才有意義。 落到實際畫面是這樣：志明打開公司的 IT workspace，第一眼看到十二個服務並排：`marketing-membership-page`（行銷做的、上週小陳改過 env var）、`hr-interview-scheduler`（HR 做的、跑在亞洲區、本月用了 2.3 GB）、`sales-customer-cleanup`（業務做的、已經兩週沒部署）⋯⋯每一個都有負責人、最後部署時間、地區、成本。志明不需要問任何人，dashboard 直接回答「現在跑了什麼」。 ### 第二層：邊界（boundaries） 可見性解決「不知道在跑什麼」，邊界解決「不知道用了什麼」。 具體要做的事，是三件： - 環境隔離：dev / staging / production 各環境權限獨立，實驗不會誤打到 production 資料。 - 共用 secret manager：憑證放在一個管理過的地方，AI 看得到 reference 但碰不到明文。 - 席位撤銷自動化：員工離開時所有存取路徑一鍵收回，不用在五個 PaaS dashboard 上玩打地鼠。 員工的 AI 應用可以串內部資料，但憑證不會被 AI 讀進 prompt、員工離開時存取權自動斷。 落到實際畫面：上週離職的小陳曾經做過 `customer-feedback-collector`、跑在他自己的 GitHub OAuth account 上。志明在 workspace 按一下「移除協作者」：這個服務的正式環境自動切到「待認領」、存取路徑全收回、付費歸到公司主帳號，HR 不用追小陳要任何東西。 ### 第三層：稽核（audit） 稽核日誌知道誰部署了什麼、誰改了 env var、誰看了 log；資源歸屬讓「這個服務是誰的」有答案；部署歷史讓變更紀錄不需要員工自己存。 這層只解決治理面，不解決合規認證本身。客戶要過 ISO / SOC 2 / ICP / 金管會時，需要把 plan 內建工具對應到稽核框架。這通常需要顧問或治理審查，不是 PaaS 該負責的事。 台灣金融業已有對應框架：金管會 2024 年 6 月的[「金融業運用人工智慧（AI）指引」](https://www.ithome.com.tw/news/163575)把 AI 生命週期拆成四階段、各對應核心原則。對銀行 / 保險業的 IT 主管這是直接寫給你的，對其他產業也是早期參考。但稽核要的「誰在哪個階段做了什麼決策」，PaaS 的稽核日誌只解一半，另一半得靠流程落地。 舉一個具體場景：某位員工用自己搭的工作流（Claude Code 寫的小工具 + n8n 串內部 wiki API）想自動產出客戶面的回應內容；為了讓 AI 回答得更準，他把公司內部 wiki 資料塞進 prompt 裡，但內部 wiki 裡的資料沒有完全脫敏：人員名單、合作金額、過去客訴紀錄都在裡面。AI 不會主動分辨哪些可公開、哪些不能，於是部分隱私資料夾在「給客戶看的回應」裡公開出去。 這個場景的當責 / 官司問題姑且不論。audit 層真正的核心是流程設計：有沒有在 AI 接觸敏感資料的節點放檢核點。稽核員來時拿得出 log 是基本款，流程設計才是真正在守的東西。AI 時代誰也不知道下一個「龍蝦」級別的公開治理事件何時出現，逐步把三層治理落實，才能把這類風險從「災難」變成「可被早期攔下的小事故」。 具體做法之一是把第一道把關推到員工那邊：deploy 前先跑 secret 掃描、敏感資料漏出檢查、依賴告警，員工自己補、IT 接手的是過了第一關的成品。市面上已有不少服務把這關自動化。至於檢核點怎麼設、human-in-the-loop 怎麼建立，是另一篇的主題。 把 visibility → boundaries → audit 三層擺在一起、解的是不同層次的問題；但這三件事都有一個共同前提：要有一個 IT 看得見、能管的容器讓它們落腳。前面《企業 AI 治理的兩難》提過這個答案：沙盒成為新的企業安全邊界。下一節展開為什麼這個答案是這一兩年才浮現的、什麼東西改變了。 ## Shadow IT 的新企業安全邊界：沙盒 前面一直把「沙盒」當答案丟，這裡正式講清楚它是什麼。 沙盒就是一塊「被圈起來的場地」：員工在裡面照樣自由寫 code、部署、串公司資料，想做什麼都行；但這塊場地是 IT 圈出來的：看得到裡面在跑什麼、管得到誰能進、東西也跑不出這條界線。 這個概念其實不新：瀏覽器有沙盒（網頁不能亂存取你的本機檔案）、iOS 有沙盒（每個 app 只能碰自己的資料）、程式語言的 runtime 也都有隔離設計，至少十年起跳。新的是：這一兩年它被推上 IT 治理討論的中心、變成企業安全邊界的預設答案。原因是前面那三股力量（部署門檻歸零、AI 要真資料、agent 繞過 IDP）把舊的防線打穿了。 沙盒是這三股力量的共同解：員工照樣零門檻部署，但跑在 IT 看得到的沙盒裡；AI 只看得到沙盒裡準備好的資料切片、敏感欄位在離開沙盒前就處理完，IT 不用逐一審每個 prompt；沙盒同時收 agent 動作 + 員工系統，作為統一的執行邊界。E2B、Daytona、CodeSandbox SDK、Modal、Beam 等專做 agent 沙盒的公司在過去 12 個月快速冒出，就是看到這個落差。 ### 沙盒本身要跑在哪？ 沙盒落地有三個選項：用平台內建沙盒、完全 self-host、或代管沙盒（PaaS 模型）。承認沙盒是答案只是第一步：沙盒本身要跑在哪、誰管它、出事誰修，是 2026 年所有 IT 主管都在評估的選擇題，三條路各有取捨： - 用平台內建沙盒（Lovable / Bolt / v0 等的預設）：簡單，但資料跟產出物綁在供應商、IT 拿不到清單、付費常常還是員工個人卡。 - 完全 self-host：技術上可控，但要養一組 infra 人專門維護。員工 vibe coding 為了避開 IT 流程，IT 卻為了把 vibe coding 圈在沙盒裡多管一套系統，成本未必比較便宜。 - 代管沙盒（PaaS 模型）：選自己要的雲、地區、資料主權範圍，但維運交給平台處理。 這個選擇沒辦法延後，員工 vibe coding 不會等你。 把前面三股力量拉在一起看，企業安全邊界的定義其實一路在變：2000 年代以前是 firewall 的時代，守的是「誰能進公司網路」；2010 到 2024 年換成 IDP / SaaS，守「誰能登入哪個系統」；2024 年之後進到 vibe coding 時代，要守的變成「員工和 agent 的產出物跑在哪個沙盒裡」。 這個沙盒給員工的自由劃一個 IT 看得見的範圍。員工（和員工開出來的 agent）在裡面繼續 vibe coding；IT 不用審 code、不用禁工具、不用重做員工的東西，只需要維持這個沙盒本身：它在哪、誰能進、跑了什麼、用了多少。 這個切角對 IT 主管來說是解放：他的角色從「禁員工做 X」翻到「給員工一個能做 X 的地方」。前者讓他變成絆腳石，後者讓他變成推手；同樣一個 IT 主管，差別只在他選擇守哪一條線。 ## IT 主管落地 vibe coding 治理的三個步驟 如果你是 IT 主管、公司剛開始進入 vibe coding 階段： 第一步：跑一次盤點。問每個部門「你們最近有沒有用 AI 寫什麼東西在跑？」結果通常會嚇到人。寫下來，這是你的可見性基準。 第二步：開一個被允許的 workspace，集中部署、共用帳單、稽核日誌、席位管理一次到位。這個生態系約莫分三層、常見選項： - 身份與權限層：Okta、Entra ID（前 Azure AD）、Auth0、JumpCloud、GitHub Enterprise SSO，管「誰能登入哪個系統」 - 部署 + 帳單 + 稽核整合層：Fly.io organizations、Heroku Teams、Render Teams、Vercel Teams、Zeabur Team Plan，管「東西跑在哪、誰看得到、誰付錢」 - 風控與合規自動化層：Vanta、Drata、Secureframe、Datadog Cloud Security，管「稽核準備跟異常告警」 完整的工具堆疊通常混搭兩三層。挑選不是重點，讓員工現有的 AI 應用搬進來、新的預設跑在這裡才是。 第三步：設稽核走道。即使不用過正式 ISO 或 SOC 2，每季跑一次稽核日誌檢查、確認所有 production 服務都有負責人。這個習慣會在真正稽核到來時救你一命。 不同產業的公司應對 AI 治理問題，各自有自己的理解。[喜劇娛樂業的兩人引擎](/zh-TW/blogs/str-network) 是一個近期案例：Sunny 主導管理、小馮工程實作，把上面三層治理寫進日常工作流。 ## 把 vibe coding 系統納入 IT 治理框架 回到志明的故事，三個月過去了。 當初接到「會員活動頁當機」電話時，志明連那個服務叫什麼都不知道。現在打開公司的 IT workspace，他看到的是一個統一 dashboard：行銷做的會員活動頁面在這、業務做的客戶資料整理工具在那、HR 弄的面試排程也在。每一個服務的部署狀態、最近誰改了什麼 env var、資源用了多少、跑在哪個地區，全在同一個畫面裡。 員工繼續用 Cursor 寫東西，新做出來的 AI 應用預設部署到這個 workspace。志明不需要追問每個部門「你們最近做了什麼」，dashboard 就回答了這個問題；出事時他知道找誰、知道對應服務跑在哪、知道資料邊界在哪。 他沒有禁止任何人用 AI，做的事是把沙盒設好，讓員工的 vibe coding 自然發生在這個被允許的空間裡。 這就是 vibe coding 時代的 IT 治理：把員工能跑在哪裡設計清楚，誰能寫就不再是問題。 想直接動手把沙盒開起來、把員工的 vibe coding 收進 IT 看得到的環境，[Zeabur Team Plan](https://zeabur.com/pricing) 是設計來做這件事的。