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

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

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

企业的三层焦虑

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

第一层：数据会不会被用于训练？

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

第二层：数据会不会被人看到？

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

第三层：数据会不会离开我的控制范围？

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

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

五种架构模式：从轻到重

1
2
3
4
5
6
7
8
安全保障强度 ─────────────────────────────────────────→

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

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

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

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

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

安全保障：

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

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

厂商

API 数据训练政策

日志留存

Anthropic (Claude)

API 数据不训练

30 天滥用监控

OpenAI

API 数据不训练（2023 年起）

30 天滥用监控，可申请零留存

Google (Vertex AI)

API 数据不训练

可配置

阿里云百炼 (Qwen)

API 数据不训练

合规留存

百度千帆 (ERNIE)

API 数据不训练

合规留存

智谱 (GLM)

API 数据不训练

合规留存

DeepSeek

API 数据不训练

合规留存

火山方舟 (Doubao)

API 数据不训练

合规留存

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

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

模式二：零数据留存（Zero Data Retention）

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

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

安全保障：

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

谁提供：

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

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

模式三：专属实例（Dedicated Instance）

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

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

安全保障：

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

谁提供：

厂商/平台

产品名称

隔离级别

Azure OpenAI

Provisioned Throughput Units (PTU)

专属计算容量

AWS Bedrock

Provisioned Throughput

专属推理容量

Google Vertex AI

Provisioned Throughput

专属容量

阿里云百炼

专属实例

独立计算资源

火山方舟

专属实例

独立计算资源

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

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

模式四：VPC 私有部署

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

1
2
3
4
5
6
7
8
9
10
企业 VPC
┌─────────────────────────────────────────────┐
│                                             │
│  企业应用 → VPC Endpoint / PrivateLink      │
│                    │                        │
│                    ▼                        │
│         模型推理服务（在 VPC 内）              │
│                                             │
│  数据全程在 VPC 内流转，不经过公网             │
└─────────────────────────────────────────────┘

安全保障：

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

谁提供：

平台

VPC 隔离方案

关键特性

Azure OpenAI

Azure Private Link

GPT-4o/Claude 在企业 Azure 订阅内

AWS Bedrock

VPC Endpoints + PrivateLink

Claude/Llama 在企业 AWS 账号内

Google Vertex AI

VPC Service Controls

Gemini/Claude 在企业 GCP 项目内

阿里云 PAI-EAS

VPC 内模型部署

Qwen 在企业阿里云 VPC 内

火山引擎

专有网络部署

Doubao 在企业火山云 VPC 内

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

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

模式五：本地私有化部署（On-Premise）

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

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

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

可选的模型：

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

模型系列

可私有部署的版本

最大规模

许可证

Qwen (阿里)

Qwen2.5-72B, Qwen3 系列

72B+

Apache 2.0

DeepSeek

DeepSeek-V3, R1

671B (MoE)

MIT

ChatGLM (智谱)

GLM-4-9B 系列

9B+

开源许可

Llama (Meta)

Llama 3.1-405B

405B

Llama License

Mistral

Mistral Large, Mixtral

8x22B

Apache 2.0

Gemma (Google)

Gemma 2-27B

27B

Gemma 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 统一代理层解决了这个问题。

1
2
3
4
5
6
7
8
9
10
11
12
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)

配置示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
{
  "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（模式一，成本最优）

企业选型决策树

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Q1: 数据是否涉及国家安全或军工？
  → 是 → 模式五（本地私有化），且只能用国产模型
  → 否 → 继续

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

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

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

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

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

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

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

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

关键认证速查：

1
2
3
4
5
6
7
8
9
10
11
12
13
国际认证:
  SOC 2 Type II    → 证明安全控制经过第三方审计
  ISO 27001        → 信息安全管理体系认证
  HIPAA BAA        → 医疗数据处理合规（美国）
  GDPR DPA         → 数据处理协议（欧盟）
  FedRAMP          → 美国联邦政府云安全认证

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

合同中必须明确的条款：

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

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

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

1
2
3
4
5
6
7
8
9
微调数据流:
  企业训练数据 → 上传到厂商平台 → 微调训练 → 生成专属模型权重

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

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

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

结论

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

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

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

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

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

AI  LLM  enterprise  architecture  security  deployment  best-practices 

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