# 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 主管志明接到一通电话。 公司的会员活动页面崩了，客户付了钱却没收到确认邮件；志明打开 dashboard 想查 log，却找不到这个服务，问了一圈才知道，这是市场团队上周用 Cursor 写的，跑在某个人的个人云端账号上。 志明的工作从这一刻开始改变了。 这不是个案。shadow IT（员工绕过正式 IT 流程、自己采用工具或自建系统）一直都在，但当 AI 工具让市场、销售、HR 都能自己写一个 production 应用，它的尺度从「员工偷装个 SaaS」跃升到「员工偷跑一套后端」，传统 IT 治理的工具箱应付不了这个量级。这篇谈的就是这道新题：当 shadow IT 变成 shadow AI，企业的安全边界怎么跟着移动、夹在最前线的 IT 主管（在中小企业 / 传统行业也常称信息化主管、信息中心负责人，依公司规模也叫信息长 / 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-CN/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 服务。它们收客户数据、发邮件、串内部 ERP——而 IT 主管连名字都答不出来。这道[工具民主化与资安之间的拉扯](/zh-CN/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 看得到。没有可见性，后面两层都做不了。 落到实际画面是这样：志明打开公司的 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 / 等保 / 金融监管时，需要把 plan 内建工具对应到审计框架。这通常需要顾问或治理审查，不是 PaaS 该负责的事。 国内金融业已经有自己的对应框架。中国人民银行 2022 年正式发布[《金融领域科技伦理指引》（JR/T 0258—2022）](https://std.samr.gov.cn/hb/search/stdHBDetailed?id=EB8741137DC1D95CE05397BE0A0AEDB5)、国家金融监管总局也持续出台金融机构 AI 应用与数据治理的监管要求，把 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-CN/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) 是设计来做这件事的。