企业专属模型:让企业放心调用大模型的架构最佳实践

从共享 API 到私有化部署——五种架构模式解决'数据会不会被拿去训练'的终极顾虑

和企业客户聊 AI 落地,十次有九次会被问到同一个问题:“我们调用你们的大模型,数据会不会被拿去训练?”

这个问题背后的焦虑是真实的。企业的客户数据、商业机密、内部文档、代码仓库——这些是企业的核心资产。把它们发送给一个外部的大模型 API,本质上就是把家底给别人看了一遍。如果这些数据还被用来训练模型,那等于是在免费帮竞争对手提升 AI 能力。

好消息是,这个问题在 2026 年已经有了成熟的解决方案。坏消息是,大多数企业还不知道该怎么选。

企业的三层焦虑

企业对调用大模型的数据安全焦虑,可以分为三个层次:

第一层:数据会不会被用于训练?

这是最基本的焦虑。如果企业发送的 prompt 和回复被模型厂商用来训练下一代模型,那就意味着企业的私有数据"融化"进了一个公共模型中,理论上可能通过其他用户的查询被间接泄露。

第二层:数据会不会被人看到?

即使不用于训练,数据在传输和存储过程中是否可能被厂商的员工访问?是否有日志留存?如果被监管机构调取,数据在哪个管辖区?

第三层:数据会不会离开我的控制范围?

对金融、医疗、政府等强监管行业,数据不能离开特定的物理位置或网络边界。即使厂商承诺不训练、不查看,但数据一旦离开企业网络,就存在被截获的理论风险。

这三层焦虑对应着三种不同强度的安全需求,也对应着不同的架构解决方案。

五种架构模式:从轻到重

安全保障强度 ─────────────────────────────────────────→

模式 1        模式 2          模式 3        模式 4         模式 5
共享 API     零数据留存       专属实例      VPC 私有部署    本地私有化
(Shared)     (Zero Retention) (Dedicated)  (VPC Private)  (On-Premise)

成本: 最低    成本: 低         成本: 中      成本: 高        成本: 最高
延迟: 最低    延迟: 最低       延迟: 低      延迟: 低        延迟: 取决于硬件

模式一:共享 API + 不训练承诺

架构:企业调用厂商的公共 API 端点,与其他租户共享基础设施。厂商通过合同和政策承诺不使用 API 数据训练模型。

企业应用 → HTTPS → 厂商公共 API 端点 → 共享 GPU 集群
                                        (多租户共享)

安全保障

  • 数据不用于训练(合同保障)
  • 数据传输加密(TLS)
  • 数据静态加密(AES-256)
  • 通常有 30 天的日志留存(用于滥用监控,非训练)

现状:2026 年,所有主流模型厂商的 API 都已默认不使用客户数据训练模型。这已经是行业标准而非差异化竞争点:

厂商API 数据训练政策日志留存
Anthropic (Claude)API 数据不训练30 天滥用监控
OpenAIAPI 数据不训练(2023 年起)30 天滥用监控,可申请零留存
Google (Vertex AI)API 数据不训练可配置
阿里云百炼 (Qwen)API 数据不训练合规留存
百度千帆 (ERNIE)API 数据不训练合规留存
智谱 (GLM)API 数据不训练合规留存
DeepSeekAPI 数据不训练合规留存
火山方舟 (Doubao)API 数据不训练合规留存

注意区分:消费级产品(ChatGPT 免费版、通义千问 App 等)默认可能使用数据训练。企业必须使用 API 或企业版产品,不能让员工用消费级入口处理公司数据。

适用场景:数据敏感度中等的一般企业应用,如内部知识问答、文档摘要、代码辅助。

模式二:零数据留存(Zero Data Retention)

架构:在共享 API 的基础上,厂商承诺完全不存储请求和响应数据,连滥用监控日志都不保留。

企业应用 → HTTPS → 厂商 API → GPU 推理 → 返回结果
                               数据立即销毁,不写入任何存储

安全保障

  • 数据不训练 + 不存储 + 不留存
  • 没有任何日志可以被事后追溯
  • 即使厂商被入侵或被监管调取,也没有数据可泄露

谁提供

  • OpenAI 为合格客户提供 Zero Data Retention 选项
  • Azure OpenAI 支持配置零日志留存
  • Anthropic 在企业合同中可协商类似条款

适用场景:金融行业的风控模型输入、医疗行业的患者数据分析、法律行业的合同审查。

模式三:专属实例(Dedicated Instance)

架构:企业获得专属的 GPU 计算资源,不与其他租户共享硬件。模型运行在独立的计算实例上。

企业应用 → HTTPS → 厂商 API 网关 → 企业专属 GPU 集群
                                    (硬件级隔离,不共享)

安全保障

  • 硬件级隔离,其他租户的请求不会经过相同的 GPU
  • 消除"旁路攻击"的理论风险(共享 GPU 的内存泄露)
  • 保证吞吐量(不受其他租户影响)
  • 数据不训练 + 可配置是否留存

谁提供

厂商/平台产品名称隔离级别
Azure OpenAIProvisioned Throughput Units (PTU)专属计算容量
AWS BedrockProvisioned Throughput专属推理容量
Google Vertex AIProvisioned Throughput专属容量
阿里云百炼专属实例独立计算资源
火山方舟专属实例独立计算资源

成本模式:按预留容量计费(类似云服务器的包年包月),而非按 token 计费。需要预估用量,闲置时也在付费。

适用场景:对吞吐量有保障需求的高频调用场景,如客服系统、实时翻译、批量文档处理。同时满足安全审计要求。

模式四:VPC 私有部署

架构:模型运行在企业自己的云账号 VPC(虚拟私有云)内。数据不经过公共互联网,通过 PrivateLink 或 VPC Endpoint 访问模型服务。

企业 VPC
┌─────────────────────────────────────────────┐
│                                             │
│  企业应用 → VPC Endpoint / PrivateLink      │
│                    │                        │
│                    ▼                        │
│         模型推理服务(在 VPC 内)              │
│                                             │
│  数据全程在 VPC 内流转,不经过公网             │
└─────────────────────────────────────────────┘

安全保障

  • 网络级隔离:数据不经过公共互联网
  • 可结合 VPC 的安全组、网络 ACL 进一步限制访问
  • 支持客户管理的加密密钥(CMEK)
  • 完整的审计日志(CloudTrail / ActionTrail)
  • 与企业现有的云安全体系无缝集成

谁提供

平台VPC 隔离方案关键特性
Azure OpenAIAzure Private LinkGPT-4o/Claude 在企业 Azure 订阅内
AWS BedrockVPC Endpoints + PrivateLinkClaude/Llama 在企业 AWS 账号内
Google Vertex AIVPC Service ControlsGemini/Claude 在企业 GCP 项目内
阿里云 PAI-EASVPC 内模型部署Qwen 在企业阿里云 VPC 内
火山引擎专有网络部署Doubao 在企业火山云 VPC 内

关键细节:通过 AWS Bedrock 或 Azure OpenAI 的 VPC 部署,实际上是在企业的云账号内运行模型推理。数据不会流向模型厂商(Anthropic/OpenAI),而是在企业控制的基础设施内处理。这从架构上根本性地解决了"数据会不会到厂商那里"的问题。

适用场景:已有云基础设施的企业,特别是金融、医疗、政府行业。能同时满足数据不出境和网络隔离的合规要求。

模式五:本地私有化部署(On-Premise)

架构:模型完全运行在企业自己的数据中心,使用企业自有的 GPU 服务器。数据不离开企业的物理边界。

企业数据中心
┌─────────────────────────────────────────────┐
│                                             │
│  企业应用 → 本地推理服务 → 企业 GPU 集群     │
│                                             │
│  模型权重存储在本地                           │
│  数据全程在数据中心内                         │
│  完全不依赖外部网络                           │
│                                             │
└─────────────────────────────────────────────┘

安全保障:最高级别——数据从未离开企业的物理控制范围。不存在网络传输风险、不存在第三方访问的可能性。

可选的模型

这是一个关键限制——不是所有模型都支持私有化部署。只有开源/开放权重的模型可以真正本地部署:

模型系列可私有部署的版本最大规模许可证
Qwen (阿里)Qwen2.5-72B, Qwen3 系列72B+Apache 2.0
DeepSeekDeepSeek-V3, R1671B (MoE)MIT
ChatGLM (智谱)GLM-4-9B 系列9B+开源许可
Llama (Meta)Llama 3.1-405B405BLlama License
MistralMistral Large, Mixtral8x22BApache 2.0
Gemma (Google)Gemma 2-27B27BGemma License

不支持私有化部署的:GPT-4o(OpenAI)、Claude Opus(Anthropic)、Gemini Ultra(Google)——这些闭源旗舰模型只能通过云 API 使用。

但这个局面正在变化。国内厂商在私有化部署上更加积极:

  • 阿里云:提供 Qwen 企业私有化部署包,含模型权重 + 推理框架 + 技术支持
  • 百度:ERNIE 系列为金融和政府客户提供私有化部署
  • 智谱:GLM 系列企业私有化部署服务
  • 火山引擎:Doubao 混合云部署方案

硬件成本现实:私有化部署的门槛主要在 GPU。部署一个 70B 参数的模型,至少需要 2-4 张 A100/H100 GPU。以当前市场价,一台配备 8 张 H100 的服务器成本在 200-300 万人民币。对中小企业来说,这个门槛不低。

适用场景:强监管行业(军工、国防、特定政府部门)、数据绝对不能出境的场景、对延迟极其敏感的边缘部署。

OpenClaw 的架构实践:LiteLLM 统一代理层

在实际的企业级 Agent Runtime 中,模型层的架构设计需要考虑灵活性——企业可能同时使用多个模型厂商、多种部署模式。OpenClaw 通过 LiteLLM 统一代理层解决了这个问题。

Agent 层
OpenClaw Gateway
LiteLLM Proxy (统一代理)
  ├── 路由 1 → Azure OpenAI (VPC 私有部署的 GPT-4o)
  ├── 路由 2 → AWS Bedrock (VPC 私有部署的 Claude Opus)
  ├── 路由 3 → 本地 vLLM (私有部署的 Qwen3-72B)
  └── 路由 4 → 阿里云百炼 API (共享 API 的 Qwen-Plus)

配置示例:

{
  "models": {
    "providers": {
      "azure": {
        "baseUrl": "https://my-company.openai.azure.com",
        "apiKey": "${AZURE_API_KEY}",
        "models": [
          {
            "id": "gpt-4o",
            "api": "openai-completions",
            "deployment": "my-gpt4o-ptu"
          }
        ]
      },
      "local": {
        "baseUrl": "http://192.168.1.100:8000",
        "models": [
          {
            "id": "qwen3-72b",
            "api": "openai-completions",
            "contextWindow": 128000
          }
        ]
      }
    }
  },
  "agents": {
    "list": [
      {
        "id": "internal",
        "model": {
          "primary": "local/qwen3-72b",
          "fallbacks": ["azure/gpt-4o"]
        }
      },
      {
        "id": "external",
        "model": {
          "primary": "azure/gpt-4o"
        }
      }
    ]
  }
}

这个架构的几个关键设计:

1. 模型路由与 Agent 绑定:不同 Agent 使用不同的模型路由。内部 Agent 优先使用本地部署的 Qwen(数据不出企业网络),外部 Agent 使用 Azure OpenAI(通过 VPC 专线)。

2. Fallback 机制:主模型不可用时自动切换到备用模型。本地 GPU 故障时回退到云端 API,保证服务连续性。

3. 统一接口:所有模型通过 OpenAI 兼容的 /v1/chat/completions 接口访问。Agent 不需要知道背后是哪个厂商的模型,路由逻辑对上层透明。

4. 按场景选择安全级别

  • 涉及企业核心数据 → 路由到本地模型(模式五)
  • 涉及客户数据 → 路由到 VPC 私有部署(模式四)
  • 一般性对话 → 路由到共享 API(模式一,成本最优)

企业选型决策树

面对五种架构模式,企业应该如何选择?以下是一个实用的决策树:

Q1: 数据是否涉及国家安全或军工?
  → 是 → 模式五(本地私有化),且只能用国产模型
  → 否 → 继续

Q2: 数据是否受到严格的数据出境限制?
  → 是 → 模式四(VPC 私有部署,使用国内云厂商)
        或 模式五(本地私有化)
  → 否 → 继续

Q3: 所在行业是否有明确的数据留存禁止要求?
  → 是 → 模式二(零数据留存)或更高
  → 否 → 继续

Q4: 是否需要硬件级隔离来满足审计要求?
  → 是 → 模式三(专属实例)或更高
  → 否 → 继续

Q5: 是否已有"不训练"的合同保障?
  → 是 → 模式一(共享 API)已经足够
  → 否 → 至少要模式一 + 签署 DPA(数据处理协议)

现实中的最佳实践是混合模式——不同的数据敏感级别使用不同的架构:

数据分级                   推荐架构                   典型模型选择
──────────                ─────────                  ────────────
最高密级(核心商业机密)    模式五: 本地私有化          Qwen3-72B / DeepSeek-V3
高密级(客户数据)         模式四: VPC 私有部署         Claude Opus (Bedrock)
中密级(内部文档)         模式三: 专属实例             GPT-4o (Azure PTU)
低密级(公开信息处理)      模式一: 共享 API            Qwen-Plus / GPT-4o-mini

合规认证:不能只看厂商的承诺

“我们不会用你的数据训练”——这句话说起来容易,但企业不能只靠一句承诺。需要看到可验证的合规认证可执行的合同条款

关键认证速查:

国际认证:
  SOC 2 Type II    → 证明安全控制经过第三方审计
  ISO 27001        → 信息安全管理体系认证
  HIPAA BAA        → 医疗数据处理合规(美国)
  GDPR DPA         → 数据处理协议(欧盟)
  FedRAMP          → 美国联邦政府云安全认证

中国认证:
  等保三级          → 信息系统安全等级保护(必需)
  数据安全法合规     → 数据分级分类、出境评估
  个人信息保护法     → 个人数据处理的合法性基础
  大模型备案        → 生成式 AI 服务的备案登记
  算法备案          → 算法推荐服务的备案

合同中必须明确的条款

  1. 数据用途限制:明确声明 API 调用数据不用于模型训练
  2. 数据留存期限:明确日志留存的时间和用途
  3. 数据处理地点:数据在哪个地理区域处理和存储
  4. 人员访问控制:谁可以在什么情况下访问客户数据
  5. 安全事件通知:发生数据泄露时的通知时限和流程
  6. 数据返还/删除:合同终止后数据的处理方式
  7. 审计权:企业是否有权审计厂商的安全实践

一个容易被忽视的问题:微调数据的隔离

很多企业在使用大模型时会进行微调(Fine-tuning)——用自己的数据训练一个专属版本的模型。这里有一个容易被忽视的安全问题:微调数据本身的隔离

微调数据流:
  企业训练数据 → 上传到厂商平台 → 微调训练 → 生成专属模型权重

需要确认:
  ✓ 训练数据只用于本企业的微调,不会被其他租户使用
  ✓ 微调后的模型权重归企业所有
  ✓ 基础模型厂商无法逆向工程出微调数据
  ✓ 微调训练过程在隔离环境中进行
  ✓ 训练数据在微调完成后是否删除

主流平台的微调数据隔离保障:

  • Azure OpenAI:微调数据存储在企业的 Azure 存储账号中,微调模型部署在企业的专属资源上
  • AWS Bedrock:微调数据和模型权重保存在企业的 AWS 账号内,不跨账号共享
  • 阿里云百炼:微调数据和模型在企业的百炼项目空间内隔离
  • 开源模型自部署:微调数据完全在本地,天然隔离

结论

企业调用大模型的数据安全问题,本质上是一个架构设计问题,而不是一个信任问题。

不要把安全建立在"厂商承诺不训练"这一句话上。要通过架构设计让数据安全成为技术事实而非商业承诺

  • VPC 私有部署让数据在技术上不可能流向厂商
  • 本地私有化部署让数据在物理上不可能离开企业
  • 即使是使用共享 API,也要通过合同条款 + 合规认证 + 审计权形成约束闭环

五种架构模式不是非此即彼的选择,而是应该按数据分级混合使用。核心机密用本地模型,一般数据用云端 API——既保障安全,又控制成本。

在模型能力快速趋同的今天,谁能让企业更放心地使用大模型,谁就能赢得企业市场。而"放心"不是一句口号,是一套从合同到架构到认证的完整体系。


See also