在业内有一个潜规则，就是即使厂商写了 ZDR，也不要完全相信。厂商没有说谎，只是这句话保证的范围比想象中小了很多。很多情况下，你以为你前面有一堵厚实的墙，但其实厂商只给你一扇门，在满足一定条件下门是可以打开的。
所谓 ZDR，也就是零数据保留。通俗地说，就是模型做完推理、把结果交给你之后，服务商不会把你给的 prompt 和它的回答写进长期硬盘。在 OpenAI 的 ZDR 服务公告 里，官方写明这项功能只对符合条件的 API 客户开放，请求处理完不保留提示词和回复，内容不供员工查阅，企业客户数据也不用于训练模型，除非客户明确选择加入。
2026 年夏天有个真事。Anthropic 提供企业 ZDR 安排。可当年 6 月，他们对最强前沿模型改政策，强制 30 天数据保留。在那项调整生效的几个月里，就算你之前签了 ZDR 协议，一旦调用这些模型，数据照样会在对方系统里暂存 30 天。在客户反弹后，CNBC 关于 Anthropic 数据保留争议的报道 指出，官方于 9 月推出了 Enterprise Frontier Safeguards，允许企业自行控制数据如何被审阅和存储，无需 Anthropic 人工审阅。
合同里的 ZDR 还在，但你默认的那层保护已经没了。厂商不用撕毁商业合同，只要改一下前沿模型的适用名单，原来的防护就直接落空了。
有人会问，这算不算厂商在耍花招？目前还没有厂商被公开发现故意欺骗 ZDR，或者声称支持 ZDR 却偷偷保存客户数据、因此被监管部门处罚的案例。数据泄露的风险不是来自厂商违背承诺。那些可能导致数据被保存、查看或提取的机制，往往早就写在 ZDR 协议的例外条款里。
所以厂商的 ZDR 承诺没有造假，但它其实只写了一句很短的话，就是请求处理完不写硬盘。除此之外，你的数据照样会进入缓存、被审查，或在法律程序里被调取。真正能自己验证的只有两件事：敏感数据没发出去，或者模型跑在你自己的机器上。看重安全，就去看架构，别只看承诺。
写代码的人写业务代码时，总把 API 当函数一样随手调用。要是以为开了安全开关，整个网络生命周期就会像铁桶一样密封，就可能对数据去向想岔了。
网络请求的真实路线：客户端发起请求，数据到达云厂商的接入层网关，网关将文本送入计算集群的显存，模型进行推理，生成回复文本后经由网络传回客户端。
ZDR 覆盖的范围，就是请求处理完成之后：服务商保证此后不静态保留这次请求的输入和输出。在这个范围之外，有几件事要交代清楚。
第一，先把最容易混的一件事分清：不训练不等于 ZDR。OpenAI 不拿企业客户数据训练，除非客户明确选择加入，Anthropic 的 API 数据保留说明文档也写明，未经明确授权，保留的数据不会用于训练。这条不训练的承诺更常见、也更容易做到；ZDR 比它更强，保证的是在覆盖范围内请求处理完不静态保留输入输出。数据没留下来，也就谈不上事后被拿去训练。数据被保留也不意味着可以用于训练，仍需客户明确授权。
第二是应用状态。构建智能体系统离不开会话历史和记忆。在 OpenAI 平台数据使用指南 中，官方列出了一批非 ZDR 端点，包括会话、助手、线程、向量数据库和批量处理接口。即使主账号开启了 ZDR，调用这些接口时，系统仍可能存储应用状态。对于助手接口创建的对象，你主动删除后，后台会在 30 天后清除；若没有主动删除，就会一直保存下去。
第三是安全监控与人工介入通道。开通 ZDR 并不是在控制台随手勾选就能生效。OpenAI 文档写得很清楚，这类安全权限必须经过厂商事先审批，只对符合条件的 API 客户开放。默认情况下，所有 API 功能调用都会生成反滥用监控日志。
第四是高级功能的例外保护。Anthropic 在文档里明确写了，当开发者启用未由 ZDR 涵盖的高级功能时，这表示你已选择让这些特定数据不受 ZDR 约束。
在理解了调用周期的断面以后，技术组往往会接着问：那为什么敏感代码或凭据仍然有可能留在远端？这是因为 ZDR 从来不是密不透风的铁板，它在安全防线、系统性能与法律管辖三个维度，给数据留出了完全合规的通道。
第一道缝隙来自反滥用监测。这是各家厂商为了防止黑客攻击和违规内容所设置的自动化排查系统。OpenAI 默认会为所有 API 功能调用生成监测日志。根据 OpenAI 的公开说明，这类日志默认会在服务器上保存最长 30 天，除非法律另有要求。
而一旦自动化的规则认定该调用有违规的可能，那么服务器上的保留时间可能变得长很多。Anthropic 对于数据存储的政策里也提到，如果某段对话触发了他们的安全规则，那么这段明文对话可被保留最多 2 年，相关的信任和安全分类分数则可被保留最多 7 年。
对于最前沿、能力最强的模型，某些情况下厂商甚至会取消常规 ZDR 的选项。Anthropic 的前沿核心模型保留政策 明确指出，Fable、Mythos 这些前沿模型强制要求 30 天数据保留，除非获得 Anthropic 专门授权，全平台都不支持 ZDR。在云分销渠道中，AWS Bedrock 数据保留配置指南 也写明，调用其中之一必须启用 aws_review 模式，数据在 AWS 边界内最多保留 30 天且可能接受 AWS 人工审阅；在 none/default 模式下该模型直接无法调用。
除了模型厂商本身以外，请求经过的云基础设施也可能保存记录。以 OpenAI 私有安全处理开发文档 为例，这套机制会把加密后的记录保存在客户自己区域的云存储上，并保留 30 天。企业事后撤销密钥授权可以阻止后续解密，但这一操作不会删除已经保存下来的文件，也不会撤销已经完成了的处理。
第二道缝来自性能优化。为了降低延迟和开销，大模型服务会使用提示词缓存。缓存，说白了就是把数据暂存在物理介质里。根据 OpenAI 的说明，提示词缓存的 KV 张量保存在图形处理器本地内存中，24 小时后消失；后台异步处理模式则会落盘约 10 分钟。在这些窗口内，缓存张量或后台处理数据仍停留在硬件介质中。
第三道缝是商业约定的硬边界。无论怎样的商业服务条款，在司法监管面前都必须退让一步。OpenAI 在执法政策说明 中明确，服务提供商在收到有效的法律请求之后，会对用户的数据进行最多 90 天的保全，并且在一定条件下会再延长 90 天；获取用户的通讯内容需要搜查令。ZDR 承诺不排除这类法律保全要求。
在购买大模型服务的过程中，许多团队往往将第三方的合规认证视为一种技术保障措施。把审计的印章当安全墙，常常忽视软件工程的基本验证原则。
VGS 在 VGS 数据安全分析文章 中提到一个更深刻的悖论：你不能审计不存在的东西。再负责任的审计师，进入机房或查看系统后，也只能确认眼前的运维日志、访问控制和加密流程符合标准。没有一种审计工具能向你证明，某次特定请求的代码片段或商业机密已在服务商成千上万台服务器内存中和所有备份介质中被彻底擦除。
行业资质也有明确的局限性。PremAI 对 SOC 2 认证界限的探讨 表明，服务组织控制报告，也就是业内常说的 SOC 2 第二类报告，只涵盖内部运维流程与传输加密机制；ISO 42001 则是一种管理体系标准。通过认证意味着服务商具备相关管理机制，但无法对物理数据的即时清除提供实时验证。
能自己验证、只能签合同的、只能靠信任的，是三个完全不同的层级。最底层的架构层，是你唯一能用技术手段验证的物理事实。只有两种情况是确定的：要么敏感信息在离开受控内网前已经脱敏，危险数据压根没发出去；要么模型镜像完整部署在你掌控的私有硬件上，即使拔掉网线，系统也能正常输出结果。中间层是商业合同，主要依赖数据处理协议，也就是常说的 DPA 等文书。合同的作用在于明确双方权责与违约责任，发生事故后为你提供追责和索赔依据。这种约束力完全在事后，数据在公网传输时，几张纸给不了一行代码的阻拦能力。最上面的认证背书层，无论是服务商官网的合规印章，还是第三方审计出具的年度流程报告，本质上都是主观信任，不能替代客观防护。
开源运行时的演进轨迹印证了这种层级划分。在 Ollama 隐私政策声明 中，官方承诺用户在本地运行 Ollama 时，平台不会看到任何提示词或数据；云端只会临时处理提示词和回复，不会用于模型训练，也不出售数据。这种本地安全性是由代码在本地受控运行这一物理事实保障的。该项目也提供云端接入能力，并在 Ollama 定价与服务说明 中向用户保证，提示词和回复数据不会被记录或用于训练，同时要求合作的 NVIDIA Cloud Providers 必须严格遵守不记录日志、不用于训练和 ZDR 政策。
对于几乎相同的安全措辞，另一个安全竞品在 ModelPiper 评论 Ollama 的云端隐私机制 中做出了冷静的评论：这种云端隐私机制是依靠承诺而不是通过架构来保护的。一旦计算请求被发送到云端，它就超出了开发者的控制范围，重新回到了依赖于外部信任的场景。
理解 ZDR 承诺的局限，不必因噎废食，也不该继续在生产环境裸奔。切实的工程实践，是在认清技术边界之后对架构做出分级应对。
将使用大模型的代码部署到生产环境之前，需要思考以下五个问题：第一，调用端点是否真的在 ZDR 的正式覆盖范围内？检查业务调用链，确保没有无意中使用了助手接口、向量数据库或不在 ZDR 清单上的前沿模型。第二，业务数据是否容易触发反滥用审查机制，提示词缓存的留存窗口又是多久？理解 OpenAI 提示词缓存的 KV 张量在图形处理器本地内存中暂存、24 小时后消失的状态，评估是否与合规底线冲突。第三，整条调用链路中是否存在未曾注意的子处理者，也就是替大模型厂商承接算力或存储的第三方云服务商？搞清楚数据是否会备份到其他区域，以及撤销解密密钥后物理数据究竟何时消亡。第四，系统网关层是否具备在数据离开内网前完成清洗的能力？把所有的内部用户标识、数据库连接串和通信私钥拦截在本地，用虚拟占位符替换真实信息。第五，一旦厂商突然改变数据保留规则，系统架构是否拥有随时切换的退路？业务编排层是否能够平滑转向另一家供应商，或者降级接入本地模型。
对于不同的应用场景，技术决策的分水岭在于何时仅需更换供应商，何时则必须坚决重构架构。如果系统主要处理普通公开讨论、低敏感度文案或缺乏攻击价值的半成品文本，那么选择信誉良好的主流云厂商并启用 ZDR 功能，已经在工程效率与商业保护之间找到了平衡。在低后果场景中，供应商安全政策的微小变动影响有限。然而，在处理核心系统源码、未公开专利方案、关键商业合同、员工真实身份以及医疗财务信息等高后果资产时，从一家云厂商转向另一家云厂商毫无意义，因为任何纸面协议都无法替代技术防火墙，唯一的解决方案是直接升级系统架构。正如 Fortune 关于企业转向开源模型与隔离访问的报道 所指出的那样，企业在经历前沿模型的数据保留波折后，转向开源模型，或者经 Amazon Bedrock 隔离访问。
业内常说的 ZDR 不过是一句朴素的工程常识。大模型的 ZDR 政策只是一个商业法务合同，它不能成为技术防火墙。真正决定数据能否被保留的是系统的架构设计。