AI 影子 IT:当产品团队构建自己的 LLM 代理时
你所在的平台团队计划在第三季度调查的影子 IT 事件,其实早在 1 月份就已经发生了。情况大致是这样的:某个产品团队的一名高级工程师本月要发布产品。而平台团队的“官方” LLM 网关还在“下季度”的路线图中。于是,这位工程师用公司信用卡开通了 OpenAI 账号,将 API 密钥丢进 .env 文件,发布了功能,并赶上了公开的截止日期。发布非常成功。六个月后,FinOps 团队发现了三个无人认领的供应商账号,安全团队发现包含客户数据的 Prompt 被路由到了不受数据处理协议(DPA)保护的地区,而平台团队发现他们花了两个季度构建的网关只有 14% 的采用率,因为每个需要 AI 的团队都在没有它的情况下完成了发布。
这不是安全方面的失败,也不是纪律方面的失败。这是平台与产品交付速度之间的不匹配,如果将其视为其他任何问题,那么你发布的下一个网关注定会遇到同样的采用率问题。
2026 年的数据表明,这已经不再是一种罕见的模式。对知识型工作者的调查一致显示,超过 75% 的人在工作中使用生成式 AI 工具,其中大约一半的人从事安全团队无法感知的未经授权的 AI 行为。《2026 年 FinOps 状态报告》显示,98% 的受访者将 AI 支出列为管理项目——而两年前这一比例仅为极小一部分。尽管每 Token 成本下降了几个数量级,但企业平均 AI 预算已从 2024 年的每年 120 万美元增加到 2026 年的约 700 万美元,因为使用量的增长速度超过了折扣力度。这些数字描述的不是一个边缘问题,而是一个未能跟上其理应支持的需求的运营模式。
为什么非正式渠道在建立之初就能胜出
在非正式渠道上线的当天,平台团队的网关和产品团队的 .env 文件并不是在技术优劣上竞争。它们在三个摩擦面上竞争,而平台团队通常在这三个方面全面溃败。
首个 Token 时间(Time to first token)。 一个今天需要调用 LLM 的产品工程师希望在接下来的一个小时内就能实现调用。供应商注册、一张信用卡、一段复制粘贴的 SDK 示例代码就能帮他们达成目标。而一个需要 JIRA 工单、安全审查、基于团队的密钥发放流程以及内部 SDK 迁移的平台网关,无法在同一个小时内满足需求。等到网关准备就绪时,非正式渠道已经在生产环境中通过了压力测试,团队也已经围绕其特性完成了构建。
功能覆盖面(Capability surface)。 供应商的原生 SDK 在发布当天就会开放所有功能:新模型、新的工具调用格式、新的 Prompt 缓存断点、新的 Embedding 端点。而平台网关只开放筛选后的子集,落后供应商数周之久。对于依赖网关尚未代理的功能的特性,网关不再是约束——而成了阻碍。产品团队会正确地观察到网关对他们的用例“尚未准备好”,而非正式渠道成了唯一的出路。
故障归因(Failure attribution)。 当通过网关的请求失败时,工程师现在有两个系统可以埋怨,有两个值班流程需要处理。而当通过供应商原生 SDK 的请求失败时,只有一段堆栈跟踪和一个状态页面。在事故中,网关是你必须首先证明其清白的一层。工程师通过将最核心的业务路径绕过网关来应对这种激励机制。
平台团队的直觉是将非正式渠道视为纪律问题并加以禁止。非正式渠道之所以存在,是因为在做决策的那一刻,平台的摩擦力高于替代方案。在不降低摩擦的情况下单纯禁止,只会让非正式渠道进一步转向地下。
当非正式渠道胜出时,到底会破坏什么
影子 LLM 代理带来的损害并非抽象。它在四个层面上复合叠加,而每一层都会在最初决定后的数周或数月内呈现在不同的团队面前。
成本归因变成考古。 FinOps 团队收到一张供应商发票,上面只有一行项目:每月 87,000 美元的 Token 支出,没有团队标签,没有按功能的明细,不知道哪 12 个服务占了账单的 90%。如果没有按请求的归因,就无法进行成本分摊(chargeback),无法标记某人编码助手中的失控循环,也无法评估哪些功能的单位经济效益是可行的。2026 年企业网关的标准是按请求进行成本归因,按团队、项目、客户和功能细分输入、输出和推理 Token——并将这些数据存档到可查询的存储中。影子账号在发布时没有任何这些功能。
审计追踪就是应用程序日志。 SOC 2、GDPR、ISO 27001 和《欧盟 AI 法案》等合规框架要求组织能够针对任何 AI 交互回答“哪个用户、针对哪个模型版本、在哪个日期、经谁授权,发送了什么 Prompt 以及输出了什么”。随着 2026 年 8 月《欧盟 AI 法案》对高风险系统的强制执行,罚金高达 3500 万欧元或全球收入的 7%,这个问题已不再是虚设。只有在应用程序显式记录的情况下,从应用程序代码直接进行的供应商调用才会存储 Prompt-Response 对,而且其格式需要合规团队反向工程才能查询,保留期限则受开发人员在发布之夜凌晨 2 点选择的默认值控制。而做得好的网关,会将这种记录作为调用的副产品。
数据驻留合同变成一种奢望。 与供应商签署的 DPA 规定了哪些地区可以处理哪些类别的数据。从应用程序代码发起的直接调用无法执行该合同——开发人员必须手动选择正确的端点,记住他们正在处理哪个数据集,并且在截止日期压力下不出现倒退。根据 GDPR 第 33 条,将个人数据发送到不受处理协议覆盖的 LLM 地区属于应报告的泄露行为,而发现这一情况的通常是法务团队,在监管机构的信件寄达三周后。网关可以根据数据分类自动进行路由;而 .env 文件做不到。
缺失限流和熔断。 当 Prompt 模板的回退在凌晨 4 点将编码助手变成无限重试循环时,在 Bug 和五位数的隔夜账单之间唯一的屏屏就是供应商的账号级限制,而这个限制通常被设置得足够高以吸收发布高峰。网关才是各团队预算、各租户限流和单次请求成本熔断器真正存在的层。 没有它,成本事故的范围仅取决于值班人员发现它需要多长时间。
Paved Road 运营模式
解决方法不是制定更严格的安全政策。而是建立一个在相同摩擦面上与“侧向通道”竞争的平台,并因提供侧向通道无法提供的东西而获胜。
以分钟计的自助式入驻。 一名产品工程师应该能够在 15 分钟内,在全新的笔记本电脑上配置团队密钥、访问工作端点并看到成功的响应。网关团队的首要指标应该是新应用的“首次生成 Token 的时间”(time-to-first-token),在达到这个 15 分钟的标准之前,相关的预算和优先级应高于任何其他路线图项目。Microsoft 的平台工程报告一再强调:Paved Road 必须是最简单的路径,而不仅仅是被批准的路径。Grab 的内部 AI 网关自 2023 年以来已支持 300 多个用例,它将此视为承重的基础设施,平台团队将其作为产品来运营,而不仅仅是一个合规检查项。
在协议层兼容 OpenAI。 网关应该是工程师已经熟悉的厂商 SDK 的无缝替代品。如果从 openai.chat.completions.create 切换到网关需要更改调用签名,那么你就在重新引入侧向通道所没有的迁移成本。2026 年的大多数生产级网关——Bifrost、Portkey、AWS 多供应商参考架构、Databricks Unity AI Gateway——都向 OpenAI API 的形态收敛,正是因为这种形态是 SDK 生态系统的通用语言,任何不兼容都是侧向通道可以利用的摩擦力。
能力对等,而非能力子集。 网关团队应承诺对新厂商能力的服务水平目标(SLO):在厂商正式发布(GA)后的 N 个 工作日内,代理每一个新模型、新端点、新工具调用格式。其中 N 必须足够小,以至于没有任何产品团队可以有理由声称网关阻碍了他们。如果团队错过了这一承诺,留下了长达一个季度的差距,那么每当厂商发布有趣的东西时,侧向通道都会获胜。网关是一个产品,其功能积压是所有厂商路线图的并集,人员配置必须以此为标准。
默认透明的成本分摊,而非作为附加功能。 通过网关的每个请求都会打上团队、项目、环境和功能的标签;每个响应都会记录 Token 数量、模型版本和计算出的成本;这些数据可由发出请求的工程师直接查询,无需提交工单。能看到自己 AI 账单的工程师会针对性地进行优化,而看不到的则不会。
应用无需自行构建的可观测性。 追踪 ID、提示词-响应捕获、工具调用追踪、延迟直方图、缓存命中率——所有这些都可从网关获取,无需更改应用。网关变成了组织中最有用的 AI 调试工具,这种转变将其从合规负担变成了工程师主动想要的功能。
在定性“错误”之前,先让侧向通道可见
即使有了 Paved Road,一些团队可能已经拥有了影子账户。发现问题本身就是一门学科。在网络边缘进行出站流量监控可以标记流向已知 LLM API 端点的流量,并识别哪些服务正在进行调用。在采购层的厂商账户审计可以发现未通过审批渠道的个人企业信用卡注册。一个“不究责”的特赦期——“告诉我们你的影子代 理,我们将帮助你在无后果的情况下进行迁移”——将发现问题转变为自我报告问题,这比在每个仓库中追踪每个 .env 文件要便宜得多。
顺序很重要。如果你在 Paved Road 存在之前就开始发现和强制执行,你只是将侧向通道从“工程师 A 的笔记本电脑”转移到了“增加了规避检测步骤的工程师 A 的笔记本电脑”。如果你先建立 Paved Road,并在摩擦力真正降低后让团队按自己的步调迁移,侧向通道会自行消失,因为 Paved Road 本就是更好的归宿。
组织失能才是真正的 Bug
发布影子 LLM 代理的团队不是 Bug。真正的 Bug 是组织让平台团队在“一个季度内”交付,而产品团队承诺在“本月”发布 AI 功能,却从未明确规定当截止日期冲突时哪个应该胜出。
平台团队需要比产品团队更快的节奏,否则他们就会变成一种“税收”。产品团队需要 Paved Road,否则他们就会变成安全事件。连接两者的桥梁是“平台即产品”的准则,它将采用率作为首要指标,根据厂商能力的更新速度来匹配人员配置,并将网关视为不仅是治理开销,而是组织中每个产品工程师停止自行重复构建可观测性、成本分摊和 DPA 执行的最廉价方式。
2026 年表现出色的团队不会是那些拥有最严格 AI 政策的团队。而是那些平台团队在“首次生成 Token 的时间”、能力对等和开发者体验方面战胜了侧向通道的团队——并且他们的网关因为确实更好用,而成为了阻力最小的路径。
- https://engineering.grab.com/grab-ai-gateway
- https://www.zenml.io/llmops-database/building-a-multi-provider-genai-gateway-for-enterprise-scale-llm-access
- https://www.cio.com/article/4162664/shadow-ai-morphs-into-shadow-operations.html
- https://www.cio.com/article/4083473/shadow-ai-the-hidden-agents-beyond-traditional-governance.html
- https://thehackernews.com/2025/09/shadow-ai-discovery-critical-part-of.html
- https://www.firetail.ai/blog/ai-security-risks-enterprise-management
- https://www.lasso.security/blog/what-is-shadow-ai
- https://www.lasso.security/blog/llm-data-privacy
- https://www.okta.com/identity-101/what-is-shadow-ai/
- https://www.paloaltonetworks.com/cyberpedia/what-is-shadow-ai
- https://data.finops.org/
- https://www.finops.org/wg/finops-for-ai-overview/
- https://www.finout.io/blog/finops-for-ai-agents-a-four-step-allocation-framework
- https://oplexa.com/ai-inference-cost-crisis-2026/
- https://www.ml6.eu/en/blog/why-you-need-a-genai-gateway
- https://www.truefoundry.com/blog/ai-gateway-a-core-part-of-the-control-plane-in-the-modern-generative-ai-stack
- https://aws.amazon.com/solutions/guidance/multi-provider-generative-ai-gateway-on-aws/
- https://devblogs.microsoft.com/engineering-at-microsoft/building-paved-paths-the-journey-to-platform-engineering/
- https://platformengineering.org/blog/what-is-platform-engineering
- https://devops.com/platform-engineering-creating-a-paved-path-to-reduce-developer-toil/
