数据回流与训练

上游模型供应商是否保留 prompt 与 output 用于训练——三大供应商的默认条款、关闭回流的方法、向客户证明的途径。

问题概述

每次 agent 调用上游模型 API（Anthropic、OpenAI 等），客户的 prompt 内容与 agent 的 output 都会经过供应商的服务器。供应商默认情况下可能保留这些数据用于训练后续模型——这一行为对客户合规是直接威胁，对产品方是合同与销售的硬话题。

不同合规场景的关切点：

  • GDPR：个人数据被用于其他目的需明确同意；训练用途未经客户授权属违规
  • HIPAA：医疗数据不允许用于任何二次目的，包括模型训练
  • 企业商业秘密：客户的 prompt 可能包含未公开战略、合同条款、客户信息——被供应商保留意味着潜在外泄
  • 行业特定：金融、法律、政府客户都有类似但更严格的限制

三大供应商的默认条款现状

下表为本文写作时（2026 年初）的主要供应商默认条款。条款经常变动，签合同前务必核对最新版本。

供应商通用 API 默认企业 / Enterprise 计划关闭训练用途的方法
Anthropic默认不用于训练（已修订）同上 + DPA + BAA默认即满足；额外需求走 Enterprise 合同
OpenAIAPI 默认不用于训练（2023 起）ZDR（Zero Data Retention）选项 + DPA + BAA申请 ZDR；30 天默认保留可缩短到 0
Google (Vertex AI)默认不用于训练（企业账户）数据驻留区域选项 + 详细 DPA默认即满足
自有部署模型完全可控自定义不涉及外部回流

关键变化趋势：

  • 2022-2023 年默认条款是”可能用于训练”，企业市场反弹后供应商陆续改成”默认不训练”
  • 但条款随时可能变——签合同时取得书面承诺比依赖默认设置更安全
  • ChatGPT 等消费者产品的条款与 API 条款不同——用户对话默认用于训练，企业 ChatGPT 才有 ZDR 选项

关闭回流的三层

第一层：合同条款

与上游模型方签订企业合同（非默认 API 接入），合同中明确：

  • “Provider shall not use Customer Data to train, fine-tune, or otherwise improve any AI models.”
  • “Provider shall not retain Customer Data beyond [X] hours for operational purposes.”
  • 加入 DPA（Data Processing Agreement）——GDPR 要求
  • 涉医疗加 BAA（Business Associate Agreement）——HIPAA 要求

第二层：技术开关

供应商提供的 API 选项：

  • OpenAI：API 调用时设置 data_retention: "zero" 或在账户设置启用 ZDR
  • Anthropic：默认零保留；企业账户额外签 DPA 时确认条款
  • Vertex AI：账户级数据控制设置

技术开关与合同条款应同时使用——合同是法律保障，技术开关是技术执行。

第三层：审计验证

合同与技术开关如何向客户证明？

  • 上游供应商通常不直接给”我们的客户”出证明（你的客户不是他们的直接客户）
  • 实操做法：你（产品方）持有上游供应商的合同 / 证书，作为 sub-processor 关系向客户证明
  • 客户合同里说明 sub-processor 列表 + 每个 sub-processor 的数据使用条款
  • 供应商方的合规认证（SOC2、HIPAA-eligible 等）可作为间接背书

向客户的标准答复

企业客户的尽调清单里几乎必然有此问题。准备一份标准答复，避免每个销售对话从零回答：

问：我们的数据会被用于训练 AI 模型吗？

答：不会。具体如下：

1. 我们的上游模型供应商（[列表，例如 Anthropic / OpenAI / ...]）默认条款
   即承诺不使用 API 输入用于模型训练。我们与供应商签订企业级合同
   ([合同名称]) 进一步明确这一条款。

2. 我们在 API 调用层启用了零数据保留（Zero Data Retention）配置
   （供应商支持此选项的情况下）。

3. 在我们自己的基础设施层，prompt 与 output 仅保留于审计日志（用于
   合规与故障排查），保留期 [X] 天，仅授权人员可访问。

4. 我们持有以下文件可应客户尽调要求提供：
   - 上游供应商的 DPA / BAA
   - 我们的 SOC2 Type II 报告（如适用）
   - sub-processor 完整列表

如需更详细信息，请联系 compliance@[domain]。

自有部署 / 私有模型的取舍

部分客户（金融、政府、医疗）会要求完全私有部署——模型权重在客户基础设施内，prompt 永不出客户边界。

权衡：

维度公有 API（上游模型方）私有部署（自有模型 / 客户基础设施）
合规边界跨组织（多 sub-processor）单一边界（客户自己）
成本单价低（共享基础设施）单价高（专属基础设施 + 模型许可）
模型能力始终最新（供应商持续升级）落后（自有模型更新慢）
部署复杂度低（API 调用）高（需 GPU 集群、模型管理）
适用客户大多数企业客户顶级合规客户、政府、敏感行业

实操策略：

  • 默认产品方案：公有 API + 严格合规配置（适合 80% 客户）
  • Enterprise 加售：私有部署选项（适合剩余 20%，单价 5-10× 标准合同）
  • 不要主动推私有部署给所有客户——成本与运维负担巨大，仅当客户硬性要求时才提供

与其他章节的衔接

这页有帮助吗？
在 GitHub 编辑