AI 治理清单：LLM 架构先行
这不是另一篇泛泛的治理框架文章，它把合规差距直接映射到路由架构上，三张对比表格比政策文档更有用，做 LLM 平台或 infra 的团队值得对照检查自己的堆栈。
Deloitte 报告显示企业 AI 抱负与治理成熟度之间差 53 个百分点，74% 计划两年内部署智能体 AI，仅 21% 拥有成熟治理模型。路由架构是首个治理层。三种姿态——托管网关（如 OpenRouter、Portkey）、自托管网关（如 LiteLLM）和直接 API——默认治理能力不同，直接 API 缺乏统一控制面，造成治理盲区。治理清单可映射为资产盘点、问责制、访问控制、证据记录与合规性五大支柱。路由层能提供跨团队可见性与审计证据，而电子表格不能。
AI治理清单：你的大语言模型架构是首要考虑
OpenRouter · 2026年6月22日
- 治理差距变得具体之处
- 你的路由架构是第一个治理层
- 一份映射到你技术栈的治理清单
- 托管网关能给你什么，以及不能给什么
- 自托管与托管治理的对比
- 后续步骤
德勤报告称，AI雄心与AI治理成熟度之间存在53个百分点的差距。74%的企业计划在两年内部署AI智能体，而只有21%的企业拥有成熟的模型来治理自主智能体。
对于工程团队而言，AI治理清单只有映射到架构时才变得有用，因为政策语言无法显示谁调用了哪个模型、哪个提供商处理了请求，或者审计跟踪存在于何处。
三种路由模式——托管网关、自托管网关和直接API——在映射到你的大语言模型技术栈实际能够满足的治理要求时表现不同。
治理差距变得具体之处
治理差距在AI智能体离开试点项目进入生产工作流时显现。对于工程主管而言，当模型调用触及客户上下文、通过外部提供商路由、并产生技术栈无法回答的审计问题时，这一差距变得具体。
德勤还发现，数据隐私和安全位列领导者对AI最关心的问题之中。这使得工程主管处于尴尬境地。你的团队可能已经在将模型调用路由到生产工作流，而治理仍然存在于电子表格、政策文件或会议议程中。
为什么53个百分点的差距很重要
这一差距之所以重要，是因为AI智能体不会停留在演示阶段。它会调用工具、触及客户上下文、触发下游工作流，并产生最终必须有人解释的开支。
你的技术栈必须能够回答：谁调用了哪个模型，哪个提供商处理了请求，花费了多少，以及审计跟踪存在于何处。
为什么治理清单不会产生审计日志
OWASP 为合规负责人提供了一个有用的起点。OWASP 大语言模型应用十大网络安全与治理清单的受众是“高管层、技术、网络安全、隐私、合规及法务领域负责人，以及 DevSecOps、MLSecOps 和网络安全团队与防御者”。当涉及风险评估、供应商管理、指导委员会以及政策归属时，这个范围是合理的。
检查治理领域会生成一份 PDF，而不是开支可见性、供应商归属或一个可审计的端点。这份 PDF 可以指导治理项目，但它无法显示内部工具是否在高风险用例中使用了经批准的模型，也无法生成你的团队在周一所需的审计追踪。
你的清单可能是正确的，但你的技术栈仍然无法证明发生了什么。
你的路由架构是第一层治理。
大语言模型治理的第一步，是通过一个能够记录使用情况、供应商、成本和访问决策的架构来路由模型流量。这正是 API 治理从政策口号变成工程实体的关键点。如果请求路径无法捕获证据，治理项目从一开始就存在盲区。
三种架构姿态
托管网关通过第三方路由层发送模型调用，以获取供应商访问、使用记录和路由控制。
自托管网关将该层置于你的基础设施内部，以更多的控制换取更多的运维责任。
直接 API 访问让每个服务直接连接模型供应商，将治理原语留给各个团队。
每种姿态默认提供的能力
以下是在你的团队添加自定义控制之前，每种路由姿态能够证明的实际基线。
| 姿态 | 开支可见性 | 供应商归属 | 数据主权 | RBAC | 审计追踪 |
|---|---|---|---|---|---|
| 托管网关（OpenRouter、Portkey） | 是。OpenRouter 活动仪表盘，按 API 密钥区分 | 是。每次请求的供应商归属 | 是。零数据保留路由控制 | 按密钥和工作区控制；Portkey 提供完整 RBAC | 使用记录和供应商记录；Portkey 提供完整审计日志 |
| 自托管网关（LiteLLM） | 是。通过虚拟密钥跟踪开支 | 是。记录每条路由的供应商 | 是。基础设施和日志仍由你掌控。 | 是。LiteLLM 企业版。 | 是。LiteLLM 企业版审计日志加 Prometheus。 |
| 直接 API。 | 否。 | 否。 | 无共享控制平面。 | 否。 | 否。 |
该表展示了哪些治理证据默认存在，以及你的团队仍需构建哪些。
为什么直接 API 访问会留下缺口
直接 API 访问不会提供任何治理原语。六个供应商密钥分散在十二个微服务中，你无法在一个地方检查支出、供应商归属、访问控制或审计历史。一旦使用范围超出单个团队，你的路由架构就成了报表与清理项目之间的分水岭。
下一步是把该架构基线转换为一份你的技术栈能够实际响应的治理清单。
一份映射到你的技术栈的治理清单
一份有用的治理清单区分了路由层能够证明的控制措施与组织仍需自行负责的控制措施。请将清单视为五大支柱：
- 资产清单：正在使用的 AI 系统、模型和供应商
- 问责制：每个系统、工具和审批路径的负责人
- 访问权限：哪些团队可以为高风险用例使用已批准的工具
- 证据：哪些日志支持审计追踪、数据驻留和支出查询
- 合规性：哪些控制措施需要政策审查、偏见评估、事件响应计划或欧盟 AI 法案文档
工程问题在于：你当前的技术栈中哪些部分无需仓促准备就能证明其有效性。
AI 资产清单与模型追踪
你的 AI 资产清单始于请求路径。如果每次模型调用都经过同一个端点，你就能看到哪些应用在使用哪些模型，以及这种使用情况随时间如何变化。如果每个团队直接调用供应商，你的资产清单就只能存在于有人记得记录它的地方。
电子表格可以列出已批准的系统。路由层可以显示生产流量是否与列表匹配。
支出可见性与预算控制
支出可见性往往是你所能获得的最早期预警系统。OpenRouter 通过活动仪表盘公开每个密钥使用情况，让工程负责人能够在财务或安全部门将问题演变为紧急事务之前，审查具体用量。自托管网关在你的团队配置好追踪、仪表盘和告警之后，也能提供同样的视图。
直接 API 访问只留给你各家提供商的计费页面以及每项服务记录的内容。当一个团队独立负责某一功能时，这或许还能正常运作。但当多个团队针对不同提供商部署 AI 功能，且无人能回答是哪个项目导致了峰值时，这种做法就难以为继了。
提供商归因与数据驻留
如果你的提示词包含客户数据，处理该提示词的提供商就会成为一个合规相关的事实。你需要了解请求流向何处，而不只是哪个模型做出了响应。
OpenRouter 公开每个请求的提供商归因，并支持零数据保留路由。直接 API 访问则会让各个提供商关系彼此孤立。
访问控制、经批准的工具以及高风险使用场景
高风险使用场景，例如招聘、贷款、医疗分诊或金融决策，需要比内部摘要更严格的规则。
OpenRouter 在 API 密钥和工作区级别限定访问范围，因此你可以按团队或应用分离密钥，并设置每个密钥的预算。需要在一个平台内实现集中化 RBAC 和路由级策略强制的团队，可以在上面叠加 Portkey 或 LiteLLM Enterprise。
审计追踪与持续监控
这些控制措施对任何治理项目都至关重要，因为它们证明了部署之后实际发生了什么，而不仅仅是策略的意图是什么。
托管网关可以快速提供部分证据。如果你围绕自托管网关构建日志记录和监控系统，它能为你提供更深度的证据。直接 API 访问则没有任何统一的追踪记录，除非你的团队在每个提供商集成中自行创建。
欧盟 AI 法案、智能体 AI 以及架构无法满足的部分
欧盟《人工智能法案》增加了一些任何路由层本身都无法满足的要求。对于高风险人工智能系统，该法规（欧盟第 2024/1689 号法规）涵盖了关于技术文档、透明度、人工监督、合格评定、上市后监控及严重事故报告等方面的义务。这些要求需要在请求路径之外，具备相应的流程、责任归属和审查机制。
智能体 AI 使得这一边界变得更加重要，因为自主系统无需人工逐一步骤审批，即可调用工具、执行操作并完成工作流程。你的路由层可以展示系统调用了什么以及请求的去向，但你的治理框架仍需定义何时进行人工干预以及如何处理事故。
管理型网关能给你带来什么，又无法取代什么
管理型网关能为你提供一个快速的治理基线，而非一套完整的治理方案。它有助于你集中管理模型访问、使用情况可见性和路由控制，但并不能取代政策制定、采购审查或针对特定工作负载的合规决策。
OpenRouter 默认提供的功能
其价值在于集中化。你不再需要跨服务管理分散的供应商密钥，而是拥有一个统一的模型访问、供应商选择、使用情况可见性以及数据策略控制（如零数据留存路由）的路由层。这使得技术负责人能够从一个实际起点入手，了解是谁调用了哪个模型、由哪家供应商处理以及成本是多少。
这些控制措施之所以重要，是因为它们贴近请求路径。它们能减少后续的清理工作，也使下一个治理决策变得更加明确：是将控制保留在路由层，添加到应用代码中，还是通过采购和合规审查来处理。
Portkey 的框架基本正确
在其 2026 年 1 月的指南中，Portkey 认为“可观测性成为治理、审计、优化和对生产结果信心的基础”。这一顺序是正确的。先观测你的系统，再宣称你对其进行了治理。
当你的首要问题是碎片化的大语言模型访问和薄弱的可见性时，使用托管网关。当你的需求扩展到正式编辑工作流、自定义授权或超出路由日志的审计证据时，将这些作为独立的设计决策来处理。
自托管与托管治理
自托管网关和托管网关以不同的所有权模式解决相同的可见性问题。
LiteLLM 适合的情况
对于希望完全控制的团队，自托管 LiteLLM 是一个常见建议，而且这个建议有实际依据。LiteLLM 在 GitHub 上有 4 万多个星标，其功能集专为希望直接控制网关的平台团队构建。
当控制比速度更重要时，使用自托管。它适合需要完全数据主权、自定义身份验证、内部日志记录标准、模型访问控制以及与现有平台系统紧密集成的团队。它也适合那些已经有能力运行另一个生产服务的团队。
托管网关适合的情况
当你无法回答谁花了多少钱、花在哪些模型上、流向了哪些供应商时，使用托管网关。
这能让你立即获得支出、供应商选择和使用模式的证据，而无需将网关运维变成一个全新的平台项目。
自托管的运营成本
自托管将治理成本转移到了团队的积压工作中，而不是消除它。你需要负责部署、日志基础设施、正常运行时间、升级和事件响应，包括那些决定网关是成为可靠基础设施还是另一个脆弱服务的问题：
- 谁来打补丁？
- 谁来处理供应商故障？
- 谁来维护仪表盘和告警？
- 谁在审计期间解释丢失的日志？
如果你有那个团队，自托管可能是正确的决定。如果没有，托管路由能为你提供一个更清晰的第一步。无论如何，架构选择本身就已经是一种治理选择。
后续步骤
- 审计你当前的大语言模型 API 访问模式：统计你的服务中存有多少个供应商 API 密钥，并确认谁有权访问每个密钥。
- 将你的团队的路由架构映射到三种模式之一：托管网关、自托管网关或直接 API。
- 用你当前的设置回答四个基线治理问题：谁在什么模型上花了多少钱、流向哪些提供者，以及这些操作是否产生了审计日志？
- 如果你无法回答这些问题，请在本迭代周期内将一项服务通过托管网关进行路由。
- 设置一个审查触发器：当你的团队遇到合规审计、采购审查或B轮尽职调查时，重新审视自托管与托管平台的决策。