返回
原文
OpenRouter：Announcements（RSS）
精选
62AI 编辑部评分，满分 100

AI 治理清单：LLM 架构先行

2026-06-23 03:00· 46天前· OpenRouter
AI 导读

Deloitte 报告显示企业 AI 抱负与治理成熟度之间差 53 个百分点，74% 计划两年内部署智能体 AI，仅 21% 拥有成熟治理模型。路由架构是首个治理层。三种姿态——托管网关（如 OpenRouter、Portkey）、自托管网关（如 LiteLLM）和直接 API——默认治理能力不同，直接 API 缺乏统一控制面，造成治理盲区。治理清单可映射为资产盘点、问责制、访问控制、证据记录与合规性五大支柱。路由层能提供跨团队可见性与审计证据，而电子表格不能。

推荐理由

这不是另一篇泛泛的治理框架文章，它把合规差距直接映射到路由架构上，三张对比表格比政策文档更有用，做 LLM 平台或 infra 的团队值得对照检查自己的堆栈。

正文 · AI 翻译
AI Governance Checklist: Your LLM Architecture Comes First
  • 治理差距具体体现在哪里
  • 你的路由架构是第一层治理
  • 一份与你的技术栈相对应的治理检查清单
  • 托管网关能给你什么，又不能给你什么
  • 自托管治理与托管治理
  • 后续步骤

德勤报告指出，在人工智能的雄心与治理成熟度之间存在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 以及架构无法满足的要求

欧盟《人工智能法案》增加了任何路由层本身都无法满足的要求。对于高风险人工智能系统，该法规涵盖了 (EU) 2024/1689 号法规下关于技术文档、透明度、人工监督、合规性评估、上市后监控以及严重事件报告的义务。这些要求需要在请求路径之外，具备相应的流程、责任归属和审查机制。

智能体式人工智能使得这一边界变得更加重要，因为自主系统可以调用工具、执行操作并在工作流中推进，而无需人工审批每一步。你的路由层可以显示系统调用了什么以及请求发往何处，但你的治理框架仍然必须定义何时需要人工介入以及如何处理事件。

托管网关能提供什么，以及不能提供什么

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

OpenRouter 默认提供的内容

其价值在于集中化。你无需在各个服务中分散使用不同的提供商密钥，而是通过一个路由层来实现模型访问、提供商选择、使用情况可见性以及数据策略控制（例如零数据保留路由）。这为技术负责人提供了一个实际的起点，用以回答谁调用了哪个模型、由哪个提供商处理以及成本是多少。

这些控制措施之所以重要，是因为它们紧邻请求路径。它们减少了后续的清理工作。同时，它们也使下一个治理决策更加明确：是将控制保留在路由层，还是添加到应用程序代码中，亦或是通过采购和合规审查来处理。

Portkey 的框架基本正确

在其 2026 年 1 月的指南中，Portkey 认为“可观测性成为治理、审计、优化以及对生产结果信心的基础”。这个顺序是正确的。在声称治理系统之前，先要观察系统。

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

自托管与托管治理

自托管和托管网关通过不同的所有权模式解决相同的可见性问题。

何时选择 LiteLLM

对于希望完全掌控的团队，自托管 LiteLLM 是一个常见建议，而且这个建议有充分的依据。LiteLLM 在 GitHub 上拥有超过 4 万颗星，其功能集专为希望直接控制其网关的平台团队而构建。

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

何时选择托管网关

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

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

自托管的运营成本

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

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

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

后续步骤

  • 审计你当前的大语言模型 API 访问模式：统计你的服务中使用了多少个提供商的 API 密钥，并确认谁有权访问每个密钥。
  • 将你团队的路由架构映射到三种模式之一：托管网关、自托管网关或直接 API。
  • 用你当前的配置回答四个基础治理问题：谁在花费多少、用于哪些模型、流向哪些供应商，以及这些活动是否产生审计日志？
  • 如果你无法回答这些问题，请在本迭代周期内将一项服务通过托管网关进行路由。
  • 设置一个审查触发条件：当你的团队遇到合规审计、采购审查或 B 轮尽职调查时，重新审视自托管与托管平台之间的决策。
教程/实践部署/工程

来源：OpenRouter：Announcements（RSS） · openrouter.ai

导出 Markdown
返回
精选62打开原文
导出 Markdown

AI 治理清单：LLM 架构先行

OpenRouter：Announcements（RSS）·2026-06-23 03:00·46天前·OpenRouter
AI 导读

Deloitte 报告显示企业 AI 抱负与治理成熟度之间差 53 个百分点，74% 计划两年内部署智能体 AI，仅 21% 拥有成熟治理模型。路由架构是首个治理层。三种姿态——托管网关（如 OpenRouter、Portkey）、自托管网关（如 LiteLLM）和直接 API——默认治理能力不同，直接 API 缺乏统一控制面，造成治理盲区。治理清单可映射为资产盘点、问责制、访问控制、证据记录与合规性五大支柱。路由层能提供跨团队可见性与审计证据，而电子表格不能。

正文 · AI 翻译
AI Governance Checklist: Your LLM Architecture Comes First
  • 治理差距具体体现在哪里
  • 你的路由架构是第一层治理
  • 一份与你的技术栈相对应的治理检查清单
  • 托管网关能给你什么，又不能给你什么
  • 自托管治理与托管治理
  • 后续步骤

德勤报告指出，在人工智能的雄心与治理成熟度之间存在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 以及架构无法满足的要求

欧盟《人工智能法案》增加了任何路由层本身都无法满足的要求。对于高风险人工智能系统，该法规涵盖了 (EU) 2024/1689 号法规下关于技术文档、透明度、人工监督、合规性评估、上市后监控以及严重事件报告的义务。这些要求需要在请求路径之外，具备相应的流程、责任归属和审查机制。

智能体式人工智能使得这一边界变得更加重要，因为自主系统可以调用工具、执行操作并在工作流中推进，而无需人工审批每一步。你的路由层可以显示系统调用了什么以及请求发往何处，但你的治理框架仍然必须定义何时需要人工介入以及如何处理事件。

托管网关能提供什么，以及不能提供什么

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

OpenRouter 默认提供的内容

其价值在于集中化。你无需在各个服务中分散使用不同的提供商密钥，而是通过一个路由层来实现模型访问、提供商选择、使用情况可见性以及数据策略控制（例如零数据保留路由）。这为技术负责人提供了一个实际的起点，用以回答谁调用了哪个模型、由哪个提供商处理以及成本是多少。

这些控制措施之所以重要，是因为它们紧邻请求路径。它们减少了后续的清理工作。同时，它们也使下一个治理决策更加明确：是将控制保留在路由层，还是添加到应用程序代码中，亦或是通过采购和合规审查来处理。

Portkey 的框架基本正确

在其 2026 年 1 月的指南中，Portkey 认为“可观测性成为治理、审计、优化以及对生产结果信心的基础”。这个顺序是正确的。在声称治理系统之前，先要观察系统。

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

自托管与托管治理

自托管和托管网关通过不同的所有权模式解决相同的可见性问题。

何时选择 LiteLLM

对于希望完全掌控的团队，自托管 LiteLLM 是一个常见建议，而且这个建议有充分的依据。LiteLLM 在 GitHub 上拥有超过 4 万颗星，其功能集专为希望直接控制其网关的平台团队而构建。

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

何时选择托管网关

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

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

自托管的运营成本

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

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

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

后续步骤

  • 审计你当前的大语言模型 API 访问模式：统计你的服务中使用了多少个提供商的 API 密钥，并确认谁有权访问每个密钥。
  • 将你团队的路由架构映射到三种模式之一：托管网关、自托管网关或直接 API。
  • 用你当前的配置回答四个基础治理问题：谁在花费多少、用于哪些模型、流向哪些供应商，以及这些活动是否产生审计日志？
  • 如果你无法回答这些问题，请在本迭代周期内将一项服务通过托管网关进行路由。
  • 设置一个审查触发条件：当你的团队遇到合规审计、采购审查或 B 轮尽职调查时，重新审视自托管与托管平台之间的决策。

来源：OpenRouter：Announcements（RSS）· openrouter.ai