4 篇博文 含有标签「shadow-ai」

发现你上线了一个 AI 智能体的最糟糕时机是在事故复盘中。不是在设计文档里，不是在架构评审中，也不是在变更工单里 —— 而是在事故复盘现场，律师正询问为什么在未经授权的情况下给客户退了款，而一名工程师正翻找着一个上次进行实质性评审还是在 11 个月前的服务，然后在名为 enrichTicket 的函数第 40 行处，发现了一个模型调用，它读取客户记录、决定处理方案，并调用了计费 API。没有人画过它的架构图。没有人批准它作为一个智能体运行，因为对于编写它的人来说，它根本不是智能体。它“只是一个辅助工具”。

这就是影子 AI，它已经露出了獠牙。第一波浪潮是员工将公司数据粘贴到消费级聊天机器人中 —— 这是一个数据泄露问题，虽然严重但尚在可控范围内。第二波浪潮是智能体：嵌入内部工具的模型调用，它们读取真实数据并执行真实操作，潜伏在那些原本为完全不同的用途而获批的服务中。大约一半的员工承认使用了雇主从未批准过的 AI 工具，而且很大一部分比例的使用来自高层 —— 总监和高管是主要的“元凶”，而不是实习生。当这种本能延伸到你的代码库时，你得到的不再是一个泄露的电子表格。而是一个拥有生产环境凭据且未经任何人签字批准的自主代理人。

令人不安的是，影子智能体并非由鲁莽的人创建。它们是由优秀的工程师创建的，而他们只是在执行你的要求：快速交付价值、复用现有基础设施、不要为每一个微小的改动都提交工单。治理差距并不是纪律问题。它是一个定义问题 —— 你的评审流程中根本没有他们所构建内容的对应类别。

有一个数字应该可以结束关于你的公司是否存在影子 AI 问题的争论。在短短一个月内，监控企业浏览器流量的安全研究人员记录了超过 155,000 次复制操作和超过 313,000 次粘贴到生成式 AI 工具的操作。不是请求。不是页面浏览。而是复制和粘贴事件 —— 这正是工程师从生产日志中提取堆栈追踪（stack trace）并将其丢入聊天机器人以询问服务为何崩溃时所做的精确动作。

令人不安的事实是，这一切已经发生了。你的员工并没有等待 AI 政策委员会召开会议。几个月前，他们就已经把客户列表、合同草案、专有数据库架构以及半坏的函数粘贴到了消费级聊天机器人中，而且他们是通过你的 IT 部门无法看到的个人账号进行的。问题不再是如何防止影子 AI。而是如何治理一种已经普遍存在、大多不可见且不会停止的行为。

影子 IT 曾经意味着营销团队报销 SaaS 订阅，或者工程师私自创建 S3 存储桶。这很烦人，是采购方面的头疼问题，但大部分情况下是可以承受的。影子 AI 也是出于同样的本能——绕过缓慢的官方路径——只不过爆炸半径更大，且进入门槛几乎降至为零。

一名工程师可以在一个下午将 LLM API 调用接入生产工作流。一名支持主管可以在午饭前搭建一个无代码的分流智能体。一名数据分析师可以将一个季度的客户记录粘贴到聊天窗口中，以“快速总结一下”。这些都没有经过审查，没有出现在架构图中，而且你的治理计划无法保护一个它根本不知道存在的系统。

令人不安的是规模。2025 年 UpGuard 的一项调查发现，超过 80% 的员工——以及近 90% 的安全专业人员——在工作中使用未经批准的 AI 工具。你的安全团队在用，你的高管也在用。问题不在于你是否有影子 AI，而在于你是否能看到它。

你支持团队的一位高级 CSM 花了一个周末搭建了一个内部 Slack 机器人。他们自己编写了系统提示词（system prompt），并将其指向了公开文档、Zendesk 已解决工单的导出数据以及变更日志（changelog）。六周后，它能回答团队以前需要手动输入的约 40% 的一级（tier-1）问题。你的工程团队架构中没人知道它的存在。当平台团队第一次发现它时，安全部门的人会问，为什么一个服务账号会在凌晨 3 点访问 Zendesk 的 API。

默认的反应是恐慌。封锁 API 令牌。发送一封关于未经授权 AI 的全公司邮件。在下一次治理审查中增加一张幻灯片。然后承诺平台团队将在下个季度，按照正式的路线图（roadmap）构建“官方版本”。

这种反应忽略了实际发生的情况。CS 团队并没有擅自行动 —— 他们构建了一个工程团队尚未交付的产品的可用原型。他们拥有真实的反馈数据、真实的提示词迭代周期和真实的用户反馈。而你的平台路线图里这些都没有。将这个机器人视为合规违规行为，会丢掉你的 AI 计划今年能获得的最准确的优先级信号。