结论先行
企业讨论 AI Gateway 时，最容易出现的误解，是把“请求先经过网关”理解成“数据没有离开企业”。实际上，网关只是调用链上的控制点， 不是天然的数据隔离层。
只要最终是外部 Provider 在执行推理，原始 prompt、system instruction、RAG 检索片段、工具参数、上传文件或模型输出， 都有可能在链路中的某一层被处理、缓存或记录。
真正要审查的不是“有没有 Gateway”，而是“哪一层能看到什么、是否留存、是否用于训练、是否跨境，以及合同和审计是否可追溯”。
判断风险时，不要只看“用了哪个模型”，而要看“谁在链路中有机会看到你的数据，以及能保留多久”。
先判断：这次调用是不是本地推理
第一步先区分，这次调用是不是在企业自控环境里完成推理。如果模型和推理服务都运行在企业控制域内，数据边界与外部 API 完全不同。
调用方式对比
| 调用方式 | 数据路径 | 隐私边界 | 适用场景 |
|---|---|---|---|
| 本地推理 / 本地模型服务 | 数据停留在企业控制域内，由企业自控算力完成推理。 | 默认不离开企业网络，外部 Provider 不直接接触原始数据。 | 极高敏感数据、源代码、核心财务、强监管业务。 |
| 企业自建 AI Gateway + 私有部署模型 | 数据先到企业网关，再进入专属模型实例或私有端点。 | 可通过专有网络、专属资源池和私有端点控制暴露面。 | 高敏场景、需要审计和策略控制的生产流量。 |
| 企业 AI Gateway + 外部 Provider API | 数据先到网关，再出网到上游 Provider 执行推理。 | 需要同时审查网关与上游 Provider 的日志、训练和跨境政策。 | 通用生产场景、中等敏感数据。 |
| 聚合平台 / 路由平台 + 外部 Provider | 数据至少经过一个额外第三方，再进入最终模型 Provider。 | 多一层平台，就多一层需要审查的保留和子处理者政策。 | PoC、A/B 测试、低敏流量和快速试错。 |
如果是本地推理，原始业务数据可以主要停留在企业控制域；如果是任何形式的外部 API，请默认数据至少会经过一家以上第三方，直到你把每一层都审清楚。
再拆开：一次 LLM API 请求经过哪几层
一次典型的 LLM API 请求，至少会穿过四层。真正的治理工作，是把每一层分别审清楚，而不是把所有风险都笼统归因到“模型厂商”。
一次请求经过的关键层级
| 层级 | 角色 | 可能接触的数据 | 企业需要确认什么 |
|---|---|---|---|
| 业务应用层 | 组装用户输入、system prompt、RAG 上下文和工具参数。 | 原始业务数据、用户标识、上传文件、检索片段。 | 这一层是否已经做脱敏、字段最小化和数据分级？ |
| AI Gateway / Policy 层 | 做鉴权、路由、配额、重试、审计和策略控制。 | 请求全文、响应全文、token 用量、调用元数据。 | 日志默认是否开启？能否禁记正文、按字段脱敏和按租户审计？ |
| 聚合 / 适配层 | 做统一协议、供应商切换、fallback 和成本路由。 | 可能接触请求全文、模型选择信息和异常日志。 | 是否还有额外第三方？是否列明上游 Provider 和子处理者？ |
| Model Provider 层 | 执行推理并返回结果。 | prompt、上下文、附件、模型输出。 | 是否用于训练？是否短期留存？是否支持区域、DPA 和专有部署？ |
不同数据分级应走什么链路
决定数据是否可以走外部 Provider，不应只看业务时效，更应该先做数据分级。数据等级不同，推荐的调用链路也不同。
数据分级与调用方式
| 数据等级 | 典型数据 | 推荐链路 | 原因 |
|---|---|---|---|
| P0 核心机密 / 高监管数据 | 源代码、未披露财务、个人敏感信息、合同原文。 | 本地推理或专有部署，不经公共 API。 | 不能把“平台承诺不训练”当作充分控制。 |
| P1 内部敏感数据 | 客户工单、内部报表、含少量个人信息的知识库。 | 自建 AI Gateway + 已审查 Provider，要求 no-train、受控日志和合同约束。 | 需要在网关层做脱敏、审批和审计。 |
| P2 一般内部数据 | SOP、产品文档、非敏感研发知识。 | 可走 AI Gateway + 外部 Provider API。 | 仍需设置日志保留、区域和调用策略。 |
| P3 公开或低敏数据 | 官网文案、公开 FAQ、营销素材。 | 可用聚合平台或多 Provider 路由。 | 重点在成本、可用性和模型质量，不在强合规。 |
对 P0 与高监管流量，不要把“平台承诺不训练”视为充分控制；对 P1 与 P2，可以在完成脱敏、合同约束和审计策略后通过 AI Gateway 受控出网。
Provider 审查表
即使你已经部署 AI Gateway，上游 Provider 仍然需要单独审查。网关是策略执行层，不是对上游合规责任的免责层。
企业至少要核查的 Provider Policy 项
| 审查项 | 企业至少要确认什么 | 最低可接受标准 |
|---|---|---|
| 是否用于训练 | 默认是否会用 API 数据训练模型？哪些 SKU 或套餐例外？ | 生产流量默认 no-train，并在条款或 DPA 中写明。 |
| 留存周期 | prompt、response、file、logs 各留多久？能否关闭正文日志？ | 能禁记正文，或最短化留存并明确 TTL。 |
| 数据驻留与跨境 | 数据处理和存储发生在哪些区域？是否存在跨境子处理者？ | 能指定区域，跨境路径清晰且可归档。 |
| 人工访问 | 支持、调试或安全团队能否人工查看样本？ | 最小权限、审批控制和访问审计可追溯。 |
| 子处理者 | 是否还有代理商、云厂商或路由平台参与处理？ | 子处理者清单可查，责任边界清晰。 |
| 合同与 DPA | 是否能签 DPA、SCC、企业附加条款？ | 高敏场景必须有正式合同约束。 |
| 私有化能力 | 是否支持 dedicated capacity、private endpoint、VPC/VNet？ | 高敏业务应提供更强的隔离能力。 |
| 审计与删除 | 能否提供审计记录、删除请求和事件通知？ | 满足内部审计和事件响应要求。 |
OpenRouter 类平台的价值和边界
OpenRouter 这类平台的价值，是帮助团队更快接入多模型、做 A/B test、fallback 和成本路由；但它不能替企业完成数据分级和 Provider 审查。
OpenRouter 类平台能解决什么，不能解决什么
| 平台能力 | 带来的价值 | 边界 |
|---|---|---|
| 统一接入多家模型 | 降低试错成本，加快切换不同模型与厂商。 | 不能替企业完成数据分级和上游 Provider 审查。 |
| 做成本 / 质量路由 | 便于 A/B test、fallback 和预算控制。 | 不代表所有 Provider 都满足相同的隐私标准。 |
| 加快新模型试用 | 让产品团队更快验证场景和体验。 | 不适合作为高敏数据的默认出口。 |
| 统一 API 形态 | 降低工程接入和切换成本。 | 统一协议不等于统一合同责任和日志策略。 |
AI Gateway 对企业的实际作用
AI Gateway 的核心价值，不是“证明数据不出企业”，而是让企业能决定哪些数据可以出、经谁出、以什么策略出，以及出了以后如何追踪、审计和止损。
AI Gateway 对企业的实际作用
| 能力 | 对治理的直接价值 |
|---|---|
| 路由与策略编排 | 让不同数据等级走不同 Provider、不同区域或不同模型。 |
| 脱敏与最小化 | 在请求出网前裁剪 PII、密钥、内部标识和无关上下文。 |
| 统一鉴权和配额 | 减少散落 API Key，便于权限治理和滥用防控。 |
| 审计与可观测 | 记录谁在什么时候调用了什么模型、消耗了多少 token。 |
| 供应商切换与 fallback | 降低单一 Provider 故障或政策变化带来的业务中断。 |
| 成本治理 | 统一看预算、限额、缓存命中与模型选择。 |
企业评估清单
企业评估 AI Gateway 时，至少要先核查下面这 8 个参数。只有把这些问题逐项确认，才能判断这条调用链是否适合进入生产。
至少先核查这 8 个参数
| 参数 | 企业需要确认什么 |
|---|---|
| 原始请求是否离开企业网络 | 哪些流量必须本地处理，哪些允许出网？是否已经和业务 owner 对齐？ |
| 哪一层能看到 prompt / context / file | 网关、聚合平台、Provider、日志系统分别能看到什么？ |
| 是否记录正文日志 | 是否支持只记元数据，不记 prompt / response 正文？ |
| 日志保留多久 | 默认 TTL、多环境差异和删除机制是否明确？ |
| 是否用于训练或模型改进 | 默认策略、企业套餐例外和合同约束是否一致？ |
| 数据驻留在哪个区域 | 是否可指定 region？是否存在跨境子处理者？ |
| 是否具备合同和审计闭环 | DPA、SCC、审计日志和事件通知是否可提供？ |
| 是否能做脱敏与分级路由 | 在出网前能否基于字段、租户或业务线执行策略？ |
上线前检查清单
| 检查项 | 通过标准 |
|---|---|
| 数据分级矩阵已确定 | P0 / P1 / P2 / P3 分类已与安全、法务和业务 owner 对齐。 |
| Provider 审查完成 | 条款、留存、训练、区域和 DPA 已归档到同一审查记录。 |
| 网关策略已配置 | 脱敏、allowlist、限额、fallback 和日志策略都已启用。 |
| 高敏流量完成隔离 | P0 / P1 不走未审查的公共聚合路径。 |
| 访问控制到位 | 只有批准的应用和团队可以调用对应模型与路由。 |
| 监控与告警上线 | 异常调用、成本异常和策略拒绝有实时告警。 |
| 删除与事件响应流程可执行 | 能处理数据删除、误发和泄露排查，并有责任人。 |
| 参考来源与条款版本留档 | 对外 policy、内部审查结论和责任人可追溯。 |
FAQ
企业通过 AI Gateway 调用大模型时，数据一定会被 Provider 看到吗？
如果最终是外部 Provider 在执行推理，Provider 至少会处理生成所必需的输入数据。网关可以减少暴露面、做脱敏和控制日志，但不能把外部推理变成“完全不出企业”。只有本地推理或专有部署，才能把原始数据主要留在企业控制域。
OpenRouter 类平台适合正式生产吗？
适合低敏流量、多模型试验、fallback 和成本路由，但不应直接成为高敏数据的默认出口。正式生产是否可用，取决于平台自身 policy、上游 Provider 组合、合同条款以及你是否已经完成分级、脱敏和审计设计。
Provider 承诺“不用 API 数据训练”，是不是就足够了？
不够。训练政策只是其中一项。企业还要确认日志留存、人工访问、区域与跨境、子处理者、DPA、删除流程和事件通知。只看 no-train，通常会漏掉真正的合规风险。
AI Gateway 能完全替代数据脱敏和权限治理吗？
不能。AI Gateway 是治理执行点，不是治理策略本身。先有数据分级、字段分类、访问审批和业务规则，网关才能把这些规则落成路由、脱敏、日志和限额策略。
如何判断某类数据该走本地推理还是外部 API？
先看监管义务和泄露代价，再看业务时效。如果数据属于 P0 核心机密或强监管类别，应优先本地推理或专有部署；如果是 P1 或 P2，可在完成脱敏、Provider 审查和合同约束后走 AI Gateway + 外部 API；公开数据则可以用聚合平台提高效率。
最终建议
从架构视角看，AI Gateway 的价值不是替企业“证明数据绝不出境”，而是把原本分散在应用代码、供应商文档和人工流程里的治理逻辑， 统一收拢为一套可执行、可审计、可回滚的策略体系。
如果你的流量包含 P0 或强监管数据，应优先考虑本地推理或专有部署；如果是 P1 或 P2 数据，就把重点放在脱敏、Provider 审查、日志留存最小化和合同闭环； 只有公开或低敏数据，才适合默认走聚合平台和多 Provider 路由。
最稳妥的方式，不是先挑“哪家模型最好”，而是先把“哪些数据能出、谁能看、能留多久、出了以后如何追责”定下来，然后再让 AI Gateway 去执行这套策略。
参考来源
页面底部保留来源区，方便团队做政策比对、内部归档，也方便搜索引擎与 AI 搜索系统识别内容依据。