AI 治理清单：LLM 架构先行

德勤报告称，AI 雄心与 AI 治理成熟度之间存在 53 分的差距。74% 的企业计划在两年内部署智能体 AI，而只有 21% 拥有成熟的自主智能体治理模型。

对于工程团队而言，AI 治理清单只有映射到架构上才会变得有用，因为政策语言无法显示谁调用了哪个模型、哪个提供商处理了请求，或者审计追踪存放在哪里。

三种路由姿态——托管网关、自托管网关和直接 API——与你 LLM 技术栈实际能够满足的治理要求之间的映射各不相同。

治理差距在哪里变得具体可感

当智能体 AI 离开试点项目、进入生产工作流时，治理差距就会显现。对于工程负责人来说，当模型调用触及客户上下文、经由外部提供商路由，并产生技术栈无法回答的审计问题时，这一差距就变得具体可感。

德勤还发现，数据隐私与安全位列领导者对 AI 的首要担忧之中。这让工程负责人陷入尴尬境地。你的团队可能已经把模型调用接入生产工作流，而治理却仍停留在电子表格、政策文档或会议议程里。

为什么 53 分的差距值得关注

这一差距之所以重要，是因为智能体 AI 不会停留在演示里。它会调用工具、接触客户上下文、触发下游工作流，并产生最终必须有人来解释的支出。

你的技术栈必须回答：谁调用了哪个模型、哪个提供商处理了该请求、花费了多少，以及审计追踪存放在哪里。

为什么治理清单产生不了审计日志

OWASP 为合规负责人提供了一个有用的起点。OWASP Top 10 for LLM Applications Cybersecurity and Governance Checklist是为“高管、技术、网络安全、隐私、合规和法律领域的领导者，以及 DevSecOps、MLSecOps 和网络安全团队与防御者”编写的。当任务是风险评估、供应商管理、指导委员会和政策归属时，这样的范围是合理的。

逐项检查治理领域产出的是一个 PDF，而不是支出可见性、提供商归属或单一可审计端点。那份 PDF 可以指导项目，但它无法显示某个内部工具是否在高风险用例中使用了已批准的模型，也无法产出你的团队周一就需要的那份审计追踪。

你的清单可能是对的，而你的技术栈仍然无法证明发生了什么。

你的路由架构就是你的第一层治理

LLM 治理的第一步，是让模型流量经过一个能够记录用量、提供商、成本和访问决策的架构。正是在这一点上，API 治理不再只是一句政策口号，而成为一个工程界面。如果请求路径无法捕获证据，治理项目从一开始就存在盲区。

三种架构姿态

托管网关将模型调用通过第三方路由层发送，以实现提供商接入、用量记录和路由控制。

自托管网关将该层置于你自己的基础设施之内，以更多的控制权换取更多的运维责任。

直接 API 访问让每个服务直接连到模型提供商，把治理原语留给各个团队自行处理。

每种姿态默认能为你提供什么

以下是每种路由姿态在你的团队添加自定义控制之前所能证明的实用基线。

该表格展示了哪些治理证据默认存在，哪些仍需你的团队自行构建。

为什么直接 API 访问会留下缺口

直接 API 访问不会给你任何治理原语。六个提供商密钥散落在十二个微服务中，你无法在一个地方查看支出、提供商归属、访问控制或审计历史。一旦使用范围超出一个团队，你的路由架构就成了决定你得到一份报告还是一个清理项目的关键。

下一步是把这一架构基线转化为一份你的技术栈真正能够回答的治理清单。

一份映射到你技术栈的治理清单

一份有用的治理清单会把你的路由层能够证明的控制项，与你的组织仍需自行承担的控制项区分开来。把这份清单视为五大支柱：

• 清单：正在使用哪些 AI 系统、模型和提供商
• 问责：每个系统、工具和审批路径由谁负责
• 访问：哪些团队可以将已批准的工具用于高风险用例
• 证据：哪些日志能够支撑审计追踪、数据驻留和支出相关的问题
• 合规：哪些控制措施需要政策审查、偏见评估、事件响应计划或 EU AI Act 文档

工程层面的问题是，其中哪些是你的现有技术栈能够从容证明的。

AI 清单与模型追踪

你的 AI 清单始于请求路径。如果每一次模型调用都经由同一个端点路由，你就能看到哪些应用使用了哪些模型，以及这种使用情况随时间如何变化。如果每个团队都直接调用各家提供商，那么你的清单只存在于有人记得记录的地方。

一张电子表格可以列出已获批的系统。一个路由层则能显示生产流量是否与这份清单相符。

支出可见性与预算控制

支出可见性往往是你最早获得的预警系统。OpenRouter 通过 活动仪表盘公开每个密钥的使用情况，这为工程负责人提供了一个在财务或安全部门把它变成紧急事件之前查看用量的地方。自托管网关只要你的团队配置好追踪、仪表盘和告警，也能提供同样的视图。

直接使用 API 访问，你面对的只有各提供商的账单页面以及各家服务记录的内容。当一个团队负责一个功能时，这还能行得通。但当多个团队针对不同提供商上线 AI 功能，而没人能说清是哪个项目造成了用量激增时，这套做法就崩溃了。

提供商归属与数据驻留

如果你的提示词包含客户数据，那么处理它的提供商就成了一个与合规相关的事实。你需要知道请求流向何处，而不仅仅是由哪个模型做出了响应。

OpenRouter 会按请求暴露提供商归属信息，并支持零数据保留路由。而直接使用 API 访问则会让每一段提供商关系彼此孤立。

访问控制、已批准的工具与高风险用例

高风险用例，例如招聘、贷款、医疗分诊或财务决策，需要比内部摘要更严格的规则。

OpenRouter 在 API key 和工作区层面限定访问权限，因此你可以按团队或应用区分 key，并设置每个 key 的预算。需要在单一平台内实现集中式 RBAC 和路由级强制执行的团队，可以叠加使用 Portkey 或 LiteLLM Enterprise。

审计追踪与持续监控

这些控制措施对任何治理项目都很重要，因为它们证明的是部署之后实际发生了什么，而不仅仅是政策原本意图如何。

托管网关可以快速提供其中一部分证据。自托管网关则能提供更深入的证据，前提是你在其周围构建日志记录与监控。直接 API 访问不会留下共享的追踪记录，除非你的团队在每一个提供商集成上自行创建一条。

欧盟 AI 法案、智能体 AI，以及架构无法满足的部分

欧盟 AI 法案增加了任何路由层本身都无法满足的要求。对于高风险 AI 系统，该法规涵盖了技术文档、透明度、人类监督、合规性评估、上市后监控以及严重事件报告等方面的义务，依据是 Regulation (EU) 2024/1689。这些要求需要在请求路径之外有流程、责任归属和审查。

智能体 AI 让这一边界变得更加重要，因为自主系统可以调用工具、采取行动并在工作流中推进，而无需人类批准每一步。你的路由层可以展示系统调用了什么以及请求去了哪里，但你的治理框架仍然必须界定人类何时介入以及事件如何处理。

托管网关能给你什么，以及不能给你什么

托管网关为你提供的是一个快速的治理基线，而不是一套完整的治理方案。它帮助你集中管理模型访问、查看使用情况并控制路由，但它并不能免除对策略、采购审查或针对特定工作负载的合规决策的需求。

OpenRouter 默认提供什么

价值在于集中化。你不再需要把各服务商密钥分散到各个服务中，而是获得一个统一的路由层，用于模型访问、服务商选择、用量可见性，以及诸如零数据保留路由这类数据策略控制。这让工程负责人有了一个切实的起点，来回答谁调用了哪个模型、由哪个服务商处理、花费了多少。

这些控制之所以重要，是因为它们紧贴请求路径。它们减少了后续的清理工作。它们也让下一个治理决策更加明确：把控制留在路由层、在应用代码中添加，还是通过采购与合规审查来处理。

Portkey 的框架大体上是正确的

在其 2026 年 1 月的指南中，Portkey 主张“可观测性成为基础”，用于治理、审计、优化以及对生产结果的信心。这个顺序是对的。先观测系统，再声称你在治理它。

当你的首要问题是 LLM 访问碎片化和可见性薄弱时，使用托管网关。当你的需求扩展到正式的脱敏工作流、自定义授权，或超出路由日志范围的审计证据时，把这些视为独立的设计决策。

自托管与托管式治理

自托管网关和托管网关以不同的归属模式解决相同的可见性问题。

LiteLLM 何时胜出

自托管 LiteLLM 是希望获得完全控制权的团队常见的推荐做法，这一建议有切实依据。LiteLLM 拥有 40K+ GitHub stars，其功能集专为希望对网关拥有直接控制权的平台团队而打造。

当控制权比速度更重要时，选择自托管。它适合需要完全数据主权、自定义身份验证、内部日志标准、模型访问控制以及与现有平台系统紧密集成的团队。它也适合已经具备运行另一个生产服务能力的团队。

托管网关何时胜出

当你无法回答谁在哪些模型上花了多少钱、流向了哪些提供商时，就使用托管网关。

这能让你立即获得关于支出、提供商选择和使用模式的证据，而无需将网关运维变成一个新的平台项目。

自托管的运营成本

自托管只是把治理成本转移到了你团队的待办事项列表中，而不是将其消除。你需要负责部署、日志基础设施、正常运行时间、升级和事件响应，包括那些决定网关是成为可靠基础设施还是又一个脆弱服务的问题：

• 谁来打补丁？
• 谁来处理提供商故障？
• 谁来维护仪表盘和告警？
• 审计时谁来解释日志缺失？

如果你有这样的团队，自托管可能是正确的决定。如果你没有，托管路由会给你一个更清晰的第一步。无论哪种方式，架构选择本身就已经是一个治理选择。

后续步骤

• 审计你当前的 LLM API 访问模式：统计你的各项服务中一共存在多少个提供商 API key，并确认谁有权访问每一个。
• 将你团队的路由架构对应到三种姿态之一：托管网关、自托管网关或直接 API。
• 用你当前的设置回答四个基线治理问题：谁在花什么钱、用在哪些模型上、流向哪些提供商，以及其中是否有任何环节产生审计日志？
• 如果你无法回答这些问题，就在这个 sprint 里把一个服务通过托管网关来路由。
• 设置一个复审触发条件：当你的团队遇到合规审计、采购审查或 B 轮尽职调查时，重新审视自托管与托管平台之间的决策。