在第一篇文章《企业 AI 采用：安全、治理和规模化需求》中，我们确定了企业使用 AI 的四种方式和七种通用的要求。这些要求涵盖身份认证、非人类凭证、成本治理、安全和数据控制、模型灵活性、优化和可观测性。本文将把这些要求转化为参考架构，定义架构构建模块、它们的职责以及企业可用的实现选择。本系列第三篇文章将使用这些构建模块来为小型、中型和大型组织规定具体的架构。

一体双轨：两类控制路径

企业 AI 无法通过单一产品进行治理，因为并非所有 AI 流量都遵循相同的路径。

定制化应用、智能体（agents）、检索系统和兼容的编码工具可以通过企业控制的模型网关访问模型。网关可以认证工作负载、保护提供凭证、实施策略、路由请求、归属成本、应用通用安全护栏并记录遥测数据。

独立的托管应用程序如 ChatGPT、Claude、Gemini 以及专用的云工具通常直接与其提供者通信。它们的请求不经过企业模型网关，而是必须通过公司身份认证、配置、产品管理、合同、连接器控制、SaaS 安全和数据丢失防护及审计集成来进行治理。

这一区别至关重要。模型网关是一个重要的控制点，但它不是每种企业 AI 使用方式的通用控制平面。

图：企业 AI 需要为托管应用和企业控制的模型流量分别设置控制路径。

架构原则

参考架构遵循五大原则：

1. 集中策略而不集中所有决策

企业需要通用的边界来处理身份、凭证、approved 模型、数据、成本和可审计性。应用团队应有权在这些边界内选择模型和实施模式。中央平台应提供受治理的路径，而不是变成人工审批队列。

2. 分离人类、工作负载和代理身份

员工通过企业名称 identity provider 进行认证。应用程序和智能体使用工作负载身份。当智能体代表某人工作时，踪迹应同时保留智能体身份和发起用户身份。

3. 将提供凭证与应用隔离开

应用程序应向企业控制的网关进行身份验证。网关保护并轮换提供凭证、映射工作负载身份到策略，并在必要时发放虚拟凭证。

4. 使数据策略成为路由的一部分

并非每个模型或提供者都适合所有数据类别。在选择目的地时，必须优先考虑数据敏感性、合同条款、区域、保留策略和工作负载风险，之后才能考虑成本或性能优化。

5. 允许复杂性按需增长

逻辑架构可以保持一致，同时其实现可以从云原生服务扩展到管理网关、区域控制平面、专用安全工具和自托管推理。

技术全景

下表列出了一些代表性实现选择。它们是示例，并非对每个组织的推荐。

1. 企业身份与用户生命周期

企业名称 identity provider 是人类访问的起点。托管 AI 产品、编码应用、网关控制台、可观测性平台和内部应用程序应尽可能使用单点登录（SSO）。自动化配置应根据员工角色变化或离职来创建、更新、暂停和移除账户。

群组和角色应表示批准的群体，如普通 AI 用户、编码用户、敏感数据用户、平台管理员和模型审批人。身份认证建立责任主体和生命周期控制，但它不决定用户可以进入 AI 产品何种数据。数据策略和产品特定管理仍然必要。

2. 独立托管 AI 应用的治理

独立的托管应用位于模型网关路径之外。企业应维护批准的产品组合，并评估每个产品的 SSO、配置、管理控制、保留策略、培训条款、审计日志、区域处理、共享和连接器情况。

连接器需要特别注意。当托管应用连接到电子邮件、文件、源代码或协作系统时，它就获得了一个通往企业信息的新授权路径。管理员必须控制哪些连接可用、授予哪些 OAuth 权限以及如何撤销访问。

这是一个架构问题，但不是独立的部署产品。它通过身份认证、SaaS 管理、采购、CASB 或 DLP 控制、连接器治理和组织策略来实现。

3. 工作负载身份与密钥

每个生产工作负载都应有独立于创建它的开发人员的身份。生产和非生产环境不应共享身份或未受限的凭证。

如可能，请使用短期云工作负载凭证。必要时将密钥保存在企业密钥平台中，并通过既定流程轮换它们。应用程序应接收网关凭证或虚拟密钥，而非底层提供者的密钥。

这使得被攻陷的应用可以独立撤销、实现每个工作负载的预算和模型权限，并允许更改提供者凭证而无需重新部署应用。

4. 模型网关

模型网关是企业控制的工作负载与模型提供者之间的共享访问层。它应认证调用者并评估属性如应用程序、团队、环境、数据分类、用例、成本中心、区域和请求的功能。

网关不应包含所有业务逻辑。最终用户授权、提示构建、工具选择和领域规则通常属于应用或智能体运行时。

在网关后面，企业可以使用直接模型提供者 API、公有云 AI 平台、专用推理平台或自托管开源模型。

5. 模型提供者与推理平台

云原生平台对于已经标准化使用某一云的公司来说是实际的选择起点，因为它们集成到云的 identity、网络、账单和区域控制中。直接提供者可能更早暴露能力，但会创建额外的合同、凭证、账单路径和数据边界。自托管推理提供部署控制，但将扩展、安全、可用性、升级和责任转移到企业自身。

参考架构允许这些选项在受控访问路径下共存。

6. 策略、数据控制与安全护栏

策略连接企业的要求到运行时决策。它可以在允许或路由请求之前考虑工作负载、用户、环境、数据类别、模型、提供者、区域和预算等因素。

安全护栏动作可能包括阻止、脱敏、警告、记录、重试或重路由。没有任何一个安全护栏产品可以确定特定领域的正确性或消除最小权限应用设计的需要。

7. 路由、弹性和可移植性

路由是一个逻辑架构模块，即使它被实现在网关内部。

回退方案必须满足与原始目的地相同的数据和合规策略。技术上一个可用的模型并不自动成为一个批准的回退选项。

8. 智能体框架、运行时与工具治理

智能体框定义智能体、工具、交接、状态和执行流程。运行时操作这些工作流，包括长时间运行执行、重试、队列、隔离和可恢复性。网关控制模型访问但并不治理智能体能采取的每一个动作。

对于高影响的操作，模型应提出操作建议而确定性代码验证授权并执行业务操作。

9. 成本治理与 FinOps

网关应记录应用程序、团队、环境、提供者、模型、使用量和估计成本。这可以实现实时预算、告警、配额和速率限制。

企业 FinOps 有更广泛的责任。它必须核对提供者发票，包括支持的检索开销如数据库、队列、智能体计算和自托管推理。随着成熟度提高，演进路径是：

计量 → 预算与告警 → 归属 → 预测 → 优化 → 展示或分摊。

优化可以包括小模型路由、缓存、提示精简、智能体循环限制、批处理或自托管推理。质量和成本必须一起衡量。

10. 企业知识与检索

员工知识访问和应用 RAG（检索增强生成）是不同的架构需求。

公司知识在 ChatGPT 中可以搜索员工已连接的批准应用并返回引用的答案，同时尊重源权限。它是 ChatGPT Business 和 Enterprise 内部的一个功能，而非独立产品或可复用的后端用于定制化应用。

产品应用需要有包含 ingestion、变更检测、分类、权限同步、授权检索、引用和评估的检索架构。验证检查应在未经授权的內容提供给模型或写入踪迹之前发生。

组织可以使用企业搜索产品、管理云服务或自定义共享平台，具体取决于规模和需求。

11. 监控、追踪、审计与评估

架构产生四种类型的运行证据：

遥测需要其 own 数据策略。提示、响应、检索文档和工具输出可能包含敏感信息。企业必须定义脱敏、保留、加密、区域存储和操作员访问权限。

云原生平台还是专用网关？

云服务原生模型平台在以下情况下可能就足够了：大部分工作负载使用单一云、模型组合有限、云身份和账单提供足够的控制、不需要跨提供者路由。

专用网关在以下情况下非常宝贵：应用使用多个提供者、凭证需要集中隔离、预算和政策必须跨团队应用、或需要通用的路由、安全护栏和审计记录。

这两种方法是互补的：专用网关可以将云原生模型平台作为后端。

托管、自托管还是内部自建？

托管产品减少运维工作。自托管产品增加部署和数据控制，但需要升级、安全维护、扩展和高可用性所有权。内部开发应保留用于现有产品无法满足的需求。

模型代理或 RAG 演示可能很简单。具有身份、策略、流媒体、重试、会计、权限、删除追踪和高可用性的生产平台则不然。

从参考架构到具体方案

架构有意设计得比任何单个组织应立即部署的范围更广泛。一个小公司可能只需要批准的员工助手、一个云模型平台和基本预算。中型组织可能需要管理网关、共享追踪和应用级 RAG。大型企业集团可能需要区域网关、多提供者路由、专用安全护栏、分摊成本、共享智能体运行时和自托管组件。

下一篇文章《为小型、中型和大型企业规定企业 AI 架构》将为每个画像选择连贯的实现方案并列出代表性厂商。

--- 翻译自：A Reference Architecture for Governed Enterprise AI | Sreenivas Makam's Blog - https://sreeni.blog/2026/07/11/a-reference-architecture-for-governed-enterprise-ai/