和企业客户聊 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 天滥用监控 |
| 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 的基础上,厂商承诺完全不存储请求和响应数据,连滥用监控日志都不保留。
企业应用 → HTTPS → 厂商 API → GPU 推理 → 返回结果
↓
数据立即销毁,不写入任何存储
安全保障:
- 数据不训练 + 不存储 + 不留存
- 没有任何日志可以被事后追溯
- 即使厂商被入侵或被监管调取,也没有数据可泄露
谁提供:
- OpenAI 为合格客户提供 Zero Data Retention 选项
- Azure OpenAI 支持配置零日志留存
- Anthropic 在企业合同中可协商类似条款
适用场景:金融行业的风控模型输入、医疗行业的患者数据分析、法律行业的合同审查。
模式三:专属实例(Dedicated Instance)
架构:企业获得专属的 GPU 计算资源,不与其他租户共享硬件。模型运行在独立的计算实例上。
企业应用 → 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 访问模型服务。
企业 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 服务器。数据不离开企业的物理边界。
企业数据中心
┌─────────────────────────────────────────────┐
│ │
│ 企业应用 → 本地推理服务 → 企业 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 统一代理层解决了这个问题。
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 服务的备案登记
算法备案 → 算法推荐服务的备案
合同中必须明确的条款:
- 数据用途限制:明确声明 API 调用数据不用于模型训练
- 数据留存期限:明确日志留存的时间和用途
- 数据处理地点:数据在哪个地理区域处理和存储
- 人员访问控制:谁可以在什么情况下访问客户数据
- 安全事件通知:发生数据泄露时的通知时限和流程
- 数据返还/删除:合同终止后数据的处理方式
- 审计权:企业是否有权审计厂商的安全实践
一个容易被忽视的问题:微调数据的隔离
很多企业在使用大模型时会进行微调(Fine-tuning)——用自己的数据训练一个专属版本的模型。这里有一个容易被忽视的安全问题:微调数据本身的隔离。
微调数据流:
企业训练数据 → 上传到厂商平台 → 微调训练 → 生成专属模型权重
需要确认:
✓ 训练数据只用于本企业的微调,不会被其他租户使用
✓ 微调后的模型权重归企业所有
✓ 基础模型厂商无法逆向工程出微调数据
✓ 微调训练过程在隔离环境中进行
✓ 训练数据在微调完成后是否删除
主流平台的微调数据隔离保障:
- Azure OpenAI:微调数据存储在企业的 Azure 存储账号中,微调模型部署在企业的专属资源上
- AWS Bedrock:微调数据和模型权重保存在企业的 AWS 账号内,不跨账号共享
- 阿里云百炼:微调数据和模型在企业的百炼项目空间内隔离
- 开源模型自部署:微调数据完全在本地,天然隔离
结论
企业调用大模型的数据安全问题,本质上是一个架构设计问题,而不是一个信任问题。
不要把安全建立在"厂商承诺不训练"这一句话上。要通过架构设计让数据安全成为技术事实而非商业承诺:
- VPC 私有部署让数据在技术上不可能流向厂商
- 本地私有化部署让数据在物理上不可能离开企业
- 即使是使用共享 API,也要通过合同条款 + 合规认证 + 审计权形成约束闭环
五种架构模式不是非此即彼的选择,而是应该按数据分级混合使用。核心机密用本地模型,一般数据用云端 API——既保障安全,又控制成本。
在模型能力快速趋同的今天,谁能让企业更放心地使用大模型,谁就能赢得企业市场。而"放心"不是一句口号,是一套从合同到架构到认证的完整体系。