大模型 API 数据保留 vs 零数据保留：上线前怎么核验

先给上线结论：“API 数据不用于训练”不能证明零数据保留(Zero Data Retention，ZDR)，store=false 也不能单独证明整条调用链零留存。 对源码、客户资料、未公开财务数据、个人信息或受监管数据，安全评审必须核验具体组织或项目、API 端点、模型、启用功能、网关、下游工具和本方日志。只看厂商品牌或一张 ZDR 宣传页，不足以上线。

可以按三条规则做第一轮决策：

• 公开资料、可替换的测试数据：在完成基础合同与安全评估后，标准 API 保留策略可能足够。
• 内部资料、低影响业务数据：先完成六个留存面的证据单；若默认日志期限、用途和删除机制符合内部政策，可以接受标准保留。
• 机密、个人、受监管或不可逆泄露的数据：必须取得覆盖当前路由的 ZDR 或等效合同与配置证据。任一关键层未知、功能不具备资格或网关不能给出完整上游证据时，停止发送敏感数据。

本文的验收结果不是“某厂商支持 ZDR”，而是形成一张能回答以下问题的上线证据单：哪类数据，经由哪条完整路由，在什么组织/项目配置下，调用哪个端点、模型和功能；每个可能留存的位置由谁负责；证据何时重新核验。

“不训练”“不记录”和“零留存”是三个不同承诺

企业采购中最常见的误判，是把一句“不会用你的 API 数据训练模型”直接翻译成“不会保存数据”。实际上，训练用途只是数据生命周期中的一个问题。

• 不用于训练：限制供应商将输入和输出用于改进或训练模型，但不排除风控日志、故障排查、应用状态、文件、缓存或法律义务下的保留。
• 关闭某个存储开关：通常只控制一个端点或一种应用状态，例如是否保存一个响应对象；它不自动关闭风控日志、文件、搜索、第三方工具或你自己的日志。
• 零数据保留(ZDR)：通常是需要资格、合同或组织级配置的产品承诺，而且只覆盖文档明确列出的端点、模型和功能。安全、法律或滥用调查例外仍要以合同和官方说明为准。

截至 2026 年 7 月 27 日，OpenAI API 数据控制文档说明，API 数据默认不用于训练，但默认滥用监控日志可能包含客户内容并最多保留 30 天；符合条件的客户可以申请 Modified Abuse Monitoring 或 ZDR。Anthropic 的 API 与数据保留文档和 Gemini Developer API ZDR 文档也都把训练用途、风控处理与具体功能存储分开说明。

因此，评审问题不应是“这个厂商是否训练我的数据”，而应是：“请求和响应在哪些系统中存在过、存在多久、由谁控制、什么配置能证明它已关闭？”

六个留存面：逐层找出数据可能还在哪里

下面的六层不是法律标准，也不是对任何厂商的认证；它是一套工程审计框架。每一层都对应当前官方文档中真实存在的一类例外。

六层之间是串联关系，不是任选项。比如某团队获得了模型厂商的 ZDR 批准，但 APM 自动采集了完整请求体，那么最终系统仍然保留了数据；又比如主生成端点符合 ZDR，但打开联网搜索后，请求进入了另一个有独立期限的服务，原审批也不再完整。

真正的通过标准是：六层都有明确 owner、期限、配置和证据。“未知”不是待上线后观察的低风险状态，而是对敏感流量的停止条件。

先按数据等级决定接受标准

不必让所有调用都承担最高等级的控制成本。更可执行的做法，是先给工作负载分级，再决定标准保留是否可接受。

这张表不是具体法律意见。数据出境、个人信息保护和行业监管的适用结论，需要结合主体、数据类型、地区和合同由专业人员确认。工程团队能先完成的是：减少不必要输入、用合成数据验证路由、把不确定边界显式挡在发布门禁外。

当前主要 API 路由的边界怎么读

下面不是供应商排名，也不表示某一品牌“天然更安全”。它只记录 2026 年 7 月 27 日官方文档中与路由评审直接相关的边界。产品名、资格、端点和保留期限都可能变化，上线前应重新打开对应官方页面。

OpenAI 当前把 Conversations、ChatKit threads、Assistants/Threads、vector stores、files、fine-tuning、evals、batches 和 Videos 等列为 ZDR 不合格或需要独立存储的范围，Responses 的 background mode、audio、hosted containers、第三方 MCP/网络服务和 prompt caching 也各有边界，详见其端点存储资格表。这正说明“OpenAI 支持 ZDR”不是一条可部署结论。

Anthropic 文档当前还列出部分模型和功能的特殊保留要求；Gemini 文档则明确区分风控 ZDR 与搜索 grounding、会话恢复、Files、Interactions、缓存，以及 AI Studio 项目日志和数据集的状态。供应商之间的定义并不完全相同，不能用一家厂商的 ZDR 解释另一家的产品。证据单还应记录项目级日志开关、请求实际 store、日志期限、是否创建/导出/分享数据集及删除验证。

对于云平台，同样要区分“模型提供商看不到数据”和“客户云账户不保存数据”。Amazon Bedrock 数据保护说明解决的是模型提供商访问边界；你自己开启的调用日志、对象存储、Agent、知识库和备份仍由本方控制。Microsoft Foundry 数据隐私说明也把模型训练、滥用监控与客户资源中的有状态数据分别说明。

用 route evidence card 代替截图式审批

供应商页面的一张截图很快会过期，而且通常无法说明你实际调用的路由。每个生产工作负载都应有一张 route evidence card，并和变更流程绑定。

可以直接使用下面的字段：

text
工作负载 / owner：
数据等级与禁止输入：
API base URL：
网关 / 云平台 / 上游供应商 / 下游工具：
组织、项目、workspace、云账号和区域：
端点与模型 ID：
启用功能：search / files / batch / cache / agents / MCP / code / memory / ...

训练用途：
风控日志与期限：
供应商应用状态：
功能专用存储：
子处理者与第三方：
本方日志、数据库、备份与删除规则：

官方资格页和合同版本：
后台配置或导出证据：
安全/法务批准人：
未知项与阻断规则：
最后核验日期 / 下次核验日期：

证据单必须记录值，不能只打“已检查”。例如，应写“生产项目 proj-prod-01、/v1/responses、store=false、未启用 Files/搜索/MCP、ZDR 批准编号由安全团队保管”，而不是写“OpenAI：通过”。这样模型切换、网关 fallback 或新功能上线时，系统才能检测审批范围是否被改变。

一个可执行的评审例子

假设代码审查助手要把私有仓库 diff 发给模型。团队拿到了上游模型端点的 ZDR 证明，但调用先经过内部 API gateway，再由第三方聚合路由选择上游，同时错误追踪工具会采集 HTTP body。

评审结果应是“不通过”，原因不是上游 ZDR 无效，而是完整链路仍有三个未关闭的留存面：

1. 聚合路由的实际 endpoint 和 fallback 未固定，无法证明每次都进入合格端点。
2. 聚合服务自己的请求日志和子处理者缺少当前合同证据。
3. 本方错误追踪保存了包含源码的请求体。

修复顺序也应与证据对应：固定并校验上游 endpoint；取得或替换网关层的合同与日志控制；在发送前最小化 diff；关闭 body capture 并做一轮删除验证；最后用不含机密的合成请求复测。只有六层都通过，才允许 L2 源码流量。

网关场景必须 fail closed

网关能统一密钥、计费、fallback 和模型访问，但也会增加一个数据处理者以及更多日志、路由和子处理者。对要求 ZDR 的工作负载，应同时满足：

1. 网关自己的保留、训练、日志和子处理者条款符合要求。
2. 实际上游 endpoint 的 ZDR/等效资格有当前证据。
3. fallback 不会悄悄切到不合格模型、区域或供应商。
4. 请求使用的搜索、文件、缓存、MCP、代码执行等功能都在批准范围内。
5. 本方 API 日志、APM、错误追踪、队列、数据库和备份不重新保存内容。

任一项不满足时，让路由拒绝请求，而不是“尽量走 ZDR”。理想的发布门禁会把已批准的 provider、endpoint、model、feature 和 region 做成 allowlist；检测到未知组合就返回可观察错误，并要求重新评审。

对于 laozhang.ai，本轮没有核验到可覆盖 ZDR 必需工作负载的公开合同与完整处理链证据，因此本文不推荐将其用于必须零留存的数据。同样的停止规则适用于任何不能提供网关自身、实际上游和下游工具证据的服务。

哪些变化必须触发重新评审

ZDR 不是一次采购后永久有效的标签。以下变化应让当前证据卡自动过期：

• 更换 API base URL、网关、云平台、上游供应商或区域；
• 新增或替换模型、端点、组织、项目或 workspace；
• 开启 search、Files、batch、cache、agents、memory、MCP、代码执行或会话恢复；
• 更改 AI Studio 项目日志、请求级 store、日志期限，或创建、导出、分享数据集；
• 添加 APM、错误追踪、日志、队列、数据仓库、备份或新的子处理者；
• 合同续签、供应商政策或官方资格表更新；
• fallback、重试或灾备路径改变；
• 数据从 L0/L1 升级到 L2/L3，或出现新的个人信息字段。

变更检查最好进入 CI/CD 或架构发布单，而不是依赖某位工程师记得重看文档。最小门禁可以比较本次部署的 base_url + account/project + endpoint + model + features + subprocessors 与已批准证据；任何差异都进入人工审批。

上线前的最终检查

发送第一条敏感请求前，按以下顺序收口：

1. 用数据分类决定标准保留还是 ZDR，而不是先选品牌。
2. 画出从业务系统到模型、工具和日志的完整数据流。
3. 给六个留存面分别写 owner、期限、配置和证据。
4. 对照当天官方文档核验具体端点、模型与功能资格。
5. 在非敏感测试项目中验证配置、fallback、日志脱敏和删除。
6. 固化 route evidence card、阻断规则、批准人和复核日期。
7. 只放行证据覆盖的数据等级；未知项继续 fail closed。

隐私边界通过后，才值得比较成本。可以继续使用大模型 API 价格与供应商选择指南完成费用评估；如果任务其实是删除 Google/Gemini 已有历史或账号数据，应转到Google AI 数据删除指南，不要把消费者数据清理与 API ZDR 混为一谈。涉及 Claude MCP 时，还要结合Claude MCP 内部工具接入边界重新审计下游工具。

最终判断只有一句：标准保留是否可接受，取决于数据等级与明确期限；ZDR 是否成立，取决于当前合同和完整路由证据。六个留存面中任何一层未知，就不要让敏感数据进入这条 API。