治理决定 AI 允许做什么。网关仅负责执行。

每一次技术变革都遵循同样的模式。新平台出现，早期采用者争相试验，供应商竞相发布功能，不久后每场会议演讲都变成了基准图表。

企业 AI 也不例外，而目前企业基础设施中增长最快的类别之一就是 AI 网关。企业希望通过集中方式连接多个基础模型、管理凭证、监控使用情况并执行预算。随着 AI 从孤立的试点走向生产环境，网关不再是便利工具，而是必备组件。

但在与架构师、平台工程师和技术领导者一年多的交流后，我注意到一个反复出现的问题：真正的障碍几乎从来不是技术上的。

会议通常是这样的。安全团队询问客户数据是否可以发送到外部模型。财务团队想知道 AI 支出将如何在业务部门之间分配，以及当数十个应用每分钟都在消耗令牌时，预算归谁负责。法务团队询问 AI 决策如何审计。合规团队询问适用哪些法规。

然后有人提出了一个谁都没有准备好的问题。

“到底是谁决定我们可以这么做？”

房间里突然安静下来。不是因为答案很难，而是因为没人意识到需要一个答案。

这些都不是网关问题，而是治理问题。

什么是 AI 治理，为什么它应该优先？

AI 治理是一系列组织决策，决定公司被允许如何使用 AI：谁获准使用哪些模型、哪些数据可以离开组织、支出如何分配和封顶、必须记录和保留哪些内容、谁可以批准例外。这是一项领导职能，而非软件功能。

Bifrost 等平台很好地诠释了这一点。AI 网关是这些决策的执行层。

这正是顺序重要的原因。没有治理的网关无法解决不一致，而是将其工业化。

AI 网关是前门。治理决定谁拿到钥匙。

安装一扇前门很简单。决定谁拿到钥匙、钥匙能打开哪些房间、有效期多久，以及有人进出时记录什么，要困难得多。这些是组织决策。门只负责执行。

没有治理，每个应用团队都会独立决定供应商、凭证、预算、日志和数据处理。两个团队做几乎相同的工作，却因为两个不同的开发人员在两个不同的星期二做出了两个不同的判断，而形成了完全不同的策略。一致性消失，风险累积，运营复杂度随人数增加而增长。

网关的存在本身并不能解决这个问题。它只是提供了一个单一位置，让组织可以一致地解决问题。

如何将业务策略转化为技术策略？

这正是 Bifrost AI 网关比单纯管道更有趣的地方。成熟的网关不仅在应用和提供商之间路由请求，更将业务决策转化为运行时行为。

举个具体的例子。假设财务部门决定营销团队每月获得 2000 美元用于前沿模型实验，在达到上限 80% 时发出告警，达到 100% 时硬性停止；而工程团队获得 4 万美元，因为面向客户的生成式工作负载依赖 AI。这不是预算练习，而是关于相对风险和业务价值的治理决策。无法被系统执行的预算只是预测。

模型访问也是如此。客户支持、法务和工程团队各自面临不同的监管风险，有不同的理由访问特定模型，这些差异都需要技术机制，否则只能停留在建议层面。

每个链接都指向 Bifrost 如何实现该控制，不过无论选择哪个网关，映射关系都成立。

注意表格中没有发生的事情。网关没有决定治理。它在将治理操作化，而这个区别正是整个论点的核心。如果你想了解 Bifrost 如何实现这些功能，文档和开源组件可在 Bifost 仓库 中找到。

部署 AI 网关前需做的六项决策

这些是在基础设施开始执行前就必须存在的决策。

  1. 指定负责人。 单一问责人或常设委员会。安全、法务和工程之间共享所有权往往导致无人负责。
  2. 对数据进行分类。 哪些类别可以发送到外部模型，哪些永远不能，哪些需要自托管部署。大多数组织已有此类分类，只是尚未将其映射到 AI。
  3. 按功能而非偏好定义获批模型层级。 面向客户的生产环境、内部生产力和实验研究是三种不同的风险画像，不应共用同一允许列表。
  4. 在首个生产工作负载上线前设定预算所有权和上限。 在采用后才回补成本控制是政治问题而非技术问题，而且会更糟。
  5. 决定记录哪些内容以及保留多久。 NIST 的 AI 风险管理框架、ISO/IEC 42001、欧盟 AI 法案以及现有的 SOC 2 控制都需要证据。在需要出示证据之前就决定证据的形式。
  6. 制定例外路径。 没有记录例外路径的策略不会阻止例外发生，只会让例外在无记录的情况下发生。

这是一周的会议，而不是一个季度的会议。

这些决策在配置中的表现形式

决策三和四最容易看到，因为同一个对象同时承载两者。在 Bifrost 中，该对象是虚拟密钥，包含提供商和模型的允许列表、所属团队以及自身预算。之前财务会议中做出的营销决策，最终会呈现如下形式。

{
  "name": "Marketing Experimentation",
  "team_id": "team-marketing",
  "provider_configs": [
    { "provider": "openai", "allowed_models": ["gpt-4o-mini"] }
  ],
  "budget": {
    "max_limit": 2000.00, "reset_duration": "1M"
  },
  "expires_at": "2026-12-31T00:00:00Z",
  "is_active": true
}

Enter fullscreen mode Exit fullscreen mode

此前存在于幻灯片中的策略。允许列表对应决策三，预算对应决策四，expires_at 对应决策六，因为对例外设置时间限制是防止其默认永久化的方式。现在审阅策略只需阅读文件，而非采访二十个团队，当“上季度哪些模型获批给谁”的答案变成一次 diff 时，审计就不再是考古项目。

这才是更深层的意义。在请求发生的瞬间创建的记录才是证据。事后从发票和回忆中重建的记录只是证词。我曾在其他文章中将其称为 写端托管，即溯源必须在写入发生时捕获，而非事后组装。网关是组织发起的每一次 AI 请求的写端，这使其成为托管成本最低的地方。

“治理优先”是否只是意味着等待？

这是一个合理的反对意见，而且失败模式真实存在。许多组织已讨论 AI 治理十八个月却一无所获，而工程师们悄然报销个人 API 密钥并继续工作。治理每讨论一个月，组织就在没有治理的情况下决策一个月。

因此，诚实的论点不是“完成治理后再购买基础设施”，而是这六项决策成本低廉，生产流量不应早于其中三项：数据分类、预算所有权和日志记录。网关可以并发部署，但不要让首个面向客户的工作负载成为发现敏感数据定义缺失的触发器。

当治理发生变化时会怎样？

六个月后，同一家公司收购了一家竞争对手。营销团队一夜之间翻倍。财务希望收购团队使用单独预算。法务坚持欧洲客户数据不得离开欧盟。工程团队已有二十个生产应用，且无意重写任何应用。

这时组织才会发现网关的真正用途。不是路由请求，而是吸收策略变化而无需强制应用变更。

如何超越功能列表评估 AI 网关

通过统计提供商数量、测量延迟或对比定价来比较网关很容易。这些因素很重要。但每个网关在每秒十次请求时的演示看起来都一样。它们在预算上限、审计请求和重组时产生分歧。如果你正在进行正式评估，LLM 网关采购指南 是一个合理的参考框架。

治理先于基础设施

技术从来不能替代策略。组织可以购买市场上最强大的网关，但如果尚未决定如何治理 AI，仍然会遇到困难。反之也成立，而且更有趣：先确定治理的组织往往能更快地采用新模型，而不是更慢，因为难题只需解答一次，而非在每次集成时重复辩论。

这又回到了安静的会议室。

目标不是永远没有人问“是谁决定我们可以这么做”。目标是当有人提出这个问题时，房间里有人能说出名字，并指向执行该决策的系统。

就像每扇前门一样，网关的价值不在于它打开得多好，而在于你能多有信心地知道谁正在穿过它。

本文与 Bifrost 团队合作撰写。文中的架构观点和结论均由本人独立提出。