AI Coding:业务部门的狂欢,信息管理的噩梦

上一篇文章里，我写了我们在公司内部推进 AI Coding 的一些实践。

那段时间，我们从高层到普通员工做了系统培训，带着大家去上手 Cursor、Trae 这类工具。我们的出发点其实很明确：不是让大家停留在“知道 AI 很强”，而是希望大家真的能把 AI 用进工作里，去解决重复性的事务，去回应那些长期存在、但又很难进入正式 IT 建设序列的小问题。

后来，我们又办了 AI 竞赛，鼓励员工用 AI 做小工具、小程序，提升效率，优化流程，也尝试把一些过去一直希望系统化承接的业务问题，先用更轻的方式跑起来。

开始，我们只是想把AI真正用起来

这件事带来的变化，比我原来预想得更快。

很多过去需要提需求、等排期、反复沟通的事情，业务部门现在可以自己先做出来了。有人做数据处理工具，有人做报告生成小程序，有人做知识查询助手，也有人开始尝试设备预约、项目管理这类更接近业务系统的应用。

再往后，有的部门甚至开始主动来找 IT，希望提供服务器，把这些工具部署起来，作为部门内部长期使用的系统。

从推动 AI 普及的角度看，这当然是一件好事。

因为这说明，AI 不再只是一个展示层面的新技术，而是真的进入业务现场了。员工开始主动用 AI 改造自己的工作，开始把那些以前只能停留在“想法”的事情，真正做成工具。

这其实是企业内部创新被激活的一个信号。

但很快，这件事就不只是“创新”了

当企业真正把 AI Coding 普及开之后，接下来一定会面对一个问题，那就是影子 IT 的治理。

这并不是因为业务“越界”了，也不是因为创新“失控”了。

恰恰相反，影子 IT 的出现，往往说明企业内部的一线创新真的被激活了。那些最懂业务、最接近问题现场的人，第一次有能力直接把需求变成应用。

这本身是值得肯定的。

但问题在于，当这种创新开始成规模发生时，它就不再只是“会不会用 AI”的问题，而会迅速变成“企业怎么承接这些应用”的问题。

业务部门看到的是效率释放，企业管理者必须看到的是治理挑战。

影子IT为什么一定会出现

如果站在业务部门的角度，这件事其实很好理解。

过去很多需求，不是不重要，而是不够“大”，进不了正式 IT 项目的优先级；还有一些需求变化太快，等正式开发跟上时，业务场景早就变了。

所以当 AI Coding 出现之后，它本质上是把一种原来被压着的能力释放了出来。

最懂业务的人，第一次有机会直接把自己的问题做成应用。

这种速度感、掌控感和即时反馈，对业务来说是非常有吸引力的。

也正因为如此，我们内部很快就积累了 160+ 个 AI 小程序。

AI Coding 解决了“做不出来”的问题，但也把“做出来之后怎么办”的问题提前摆到了台面上。

真正的问题，不是做出来，而是接不接得住

我们后来对内部 AI 小程序做了一轮梳理。

从结果看，活跃度很高，说明大家确实在用 AI 解决问题；但从运营角度看，一些典型问题也已经出现了。

1. 很多工具做出来了，但没有真正沉淀下来

从历史存量看，整体下线率已经超过 68%。

这意味着，大量工具停留在尝试阶段，做出来的时候很热闹，但后续没有迭代、没有运营，也没有真正转化为长期生产力。

2. 重复建设开始出现

因为缺少统一可见性，同类场景往往在不同部门被重复开发。

我们盘点下来，仅管理系统类就有 9 个，监控爬虫类就有 8 个。表面上看是创新活跃，实际上是同类问题被重复投入、重复维护。

3. 应用形态已经在变化

很多工具最初只是个人提效工具，但只要它足够好用，很快就会从“个人使用”变成“团队共用”，再变成“部门协同”。

一旦进入多人协同，它就不再是简单的本地脚本，而开始承载共享状态、共享数据，甚至承载部门日常运转中的一部分流程。

4. 安全和交接风险开始累积

我们当时看到，很多应用分散在 100+ 位制作人的个人电脑上，没有统一源码托管，没有统一备份，也没有清晰的数据边界。

只要人员发生变动，或者本地环境出现问题，应用就可能中断，数据也可能失控。

很多企业不是没有创新，而是创新长出来之后，没有机制把它接住。

所以，AI运营不能只做培训和竞赛

这也是为什么我后来越来越觉得，AI 运营如果只做到培训、竞赛和案例推广，其实是不完整的。

培训和竞赛，解决的是“如何把创新释放出来”；

但当创新真正发生之后，企业还必须回答另一个更关键的问题；

这些从一线快速长出来的应用，组织有没有能力把它们接住。

在我看来，这就是影子 IT 治理的核心意义。

这里有一个判断我一直比较明确：

治理不是为了限制创新，而是为了让创新能够持续。

如果一开始就把所有 AI 小程序都按正式系统去管理，业务创新很快就会被压制；但如果完全放任不管，局面最终一定会越来越混乱。

企业真正需要的，不是一刀切的管控，而是一套与风险等级相匹配的治理机制。

我们后来是怎么分的

所以我们后来在设计这套机制时，抓住了三个最关键的问题：

第一，数据是否长期驻留在工具中。

第二，工具是否已经进入多人协同。

第三，工具一旦丢失，是否会影响业务连续性。

基于这三个判断，我们把 AI 小程序分成了三个层级。

L1：个人提效工具

这类工具通常只服务个人，数据不长期留存，工具丢失后可以重做。

对这类工具，我们的策略不是重管控，而是明确使用边界，补上最基本的离职交接和风险提示。

L2：部门协同工具

这类工具已经开始承载多人共享的数据、记录和流程。

对于这类工具，重点不是马上由 IT 全面接管，而是要求登记、明确责任人、落实备份，形成部门自治和最基本的运维能力。

L3：关键业务工具

只要一个工具开始长期保存数据，而且数据丢失会影响业务连续性，那么它就不应该继续以“个人小程序”的方式存在，而应该转入正式 IT 建设轨道，由 IT 负责部署、备份、安全和运维。

真正落地，第一步不是审批，而是先看见

在企业里，很多问题不是不能管，而是根本看不见。

有多少应用，谁在维护，解决什么场景，是否还在使用，是否存在重复建设，是否涉及共享数据，这些如果没有统一掌握，后面的分级、查重、接管和交接都无从谈起。

所以我们先把 AI 应用台账建立起来，把资产先看见。

台账的意义，不是多一张表，而是让组织第一次对这批快速长出来的应用形成整体认知：哪些值得继续孵化，哪些应该合并复用，哪些必须纳入正式治理。

在此基础上，治理动作才真正变得可执行：新增应用要登记，存量应用要回溯盘点，相似场景要查重，关键应用要逐步迁移，协同工具要落实备份，个人工具要纳入离职交接。

很多治理做不起来，不是因为没有制度，而是因为连资产都没看见。

最后想说的

回过头看，我现在越来越觉得，AI 时代的企业运营，前半段是把创新放出来，后半段是把创新接住。

前半段靠培训、工具和激励机制，解决的是“大家愿不愿意做”；

后半段靠分级、台账、备份和接管机制，解决的是“做出来的东西能不能留下来”。

如果说 AI Coding 让更多业务人员第一次具备了“自己做程序”的能力，那么影子 IT 治理，就是企业把这种能力真正沉淀为组织资产所必须补上的那块底盘。

影子 IT 治理不是 AI 创新的对立面，反而是 AI 创新走向规模化、组织化之后的一道必答题。