本文要点
- 从单次交互安全检查，转向跨相关交互的模式识别。
- 从人工可见内容审查，转为自动系统返回有限安全信号。
- 从单一ZDR部署，预告客户自管或客户控钥两种路径。
阅读辅助
先看数字、证据和来源，再读正文。
OpenAI称会继续为frontier models提供Zero Data Retention。
背景 · OpenAI公开说明API和企业数据默认不用于训练，除非客户明确选择分享。
OpenAI在8月19日发布《Offering Zero Data Retention for frontier models》，把Zero Data Retention和Private Safety Processing放进同一套企业安全与隐私架构预告。官方新闻RSS给出的发布时间是2026-08-19 19:00 UTC，落入本期北京时间早报窗口；页面正文预览了Private Safety Processing，目标是在Zero Data Retention部署中识别相关交互之间的潜在滥用模式，同时不让OpenAI人员接触底层提示词或模型响应。
现在能确认的事实很集中。OpenAI表示会继续为符合条件的API客户提供Zero Data Retention；这句话的状态动词是continue，不是increase，也不是expand。新的Private Safety Processing还没有被写成全面可用功能，OpenAI的表述是previewing，并称计划在2026年9月开始rollout，同时发布技术白皮书。对ZDR部署，官方摘录写明客户内容保留在客户控制的基础设施上；另一个正在开发的选项，是内容存放在OpenAI基础设施上，但用客户控制的密钥加密。
信源边界同样关键。主事实来自OpenAI官方页面、RSS和官方X；普通HTTP抓取会遇到OpenAI 403，因此本文额外使用指向同一官方文章的HN Algolia条目作为可机读日期锚点。OpenAI只说自动系统可以识别潜在滥用并返回limited safety signals，没有披露信号字段、保存周期、谁可访问、客户如何审计，以及这些信号是否会跨模型、跨项目或跨组织聚合。官方还保留了一个敏感例外：疑似CSAM图片即使在ZDR部署中也会继续为人工复核和报告目的保留。这个边界应按合规例外理解，不能被泛化成“ZDR下所有内容都可被人工查看”。
这条新闻最直接影响企业API客户、安全团队和采购方。过去ZDR常被当作隐私采购底线，但强隐私部署会削弱平台跨请求识别滥用的能力。OpenAI现在试图把二者重新组合：客户继续要求内容边界，平台则争取保留有限、自动化、可用于风控的信号层。真正的可买性要等9月白皮书给出审计和控制细节。
发生了什么
Zero Data Retention的含义，是符合条件的API客户请求在处理后不保留提示词和模型响应。OpenAI在本次文章中把它放到frontier models的企业使用场景里重申：企业客户内容仍由客户控制，API和企业数据也不会在没有明确选择分享的情况下用于训练。这个背景解释了为什么这篇文章更像一次具体产品约束的重新设计，而不只是政策声明。
Private Safety Processing要解决的是另一个方向的问题。随着AI承担更长、更自主的工作，风险并不总出现在单次请求里。一个请求本身可能看起来正常，多个相关交互连起来才暴露出滥用、规避或高风险操作。传统安全系统如果只能看单次交互，容易漏掉模式；如果扩大人工可见内容，又会破坏ZDR客户最看重的数据边界。
OpenAI给出的答案，是把安全处理做成更私有的自动化层。官方正文摘录称，Private Safety Processing设计用于识别相关交互之间的模式，而不让OpenAI人员访问底层内容。对于ZDR部署，客户内容保留在客户控制的基础设施上；OpenAI还在开发另一种选项，即内容存储在OpenAI基础设施上，但用客户控制的密钥加密。在这两种情形下，自动系统可以识别潜在滥用，并返回有限安全信号。
这里要把“人员不可见”和“系统完全不处理”分开。OpenAI的表述强调自动化系统在不向OpenAI personnel暴露underlying prompts or responses的情况下返回有限安全信号；它没有承诺没有任何自动化系统接触输入输出。对企业合规评审来说，这个差别很重要：前者是访问控制与处理边界，后者才是完全不处理内容。OpenAI目前只公开了前者。
状态语义先校准
这篇公告的语言容易被误写，因为OpenAI同时说了“继续提供ZDR”“预览私有安全处理”“9月开始rollout”。三者状态不同，不能合并成“ZDR能力再次升级且已经上线”。
- “will continue to offer Zero Data Retention”应理解为继续提供ZDR，语义是维持承诺。
- “previewing Private Safety Processing”说明功能处在预览阶段，尚未全面上线。
- “plan to begin rolling out in September”指9月计划开始rollout，8月仍是预告期。
- “customer content remains on infrastructure the customer controls”强调客户内容留在客户控制的基础设施。
- “limited safety signals”是有限安全信号，不能扩写为完整内容摘要或可人工阅读日志。
RSS摘要也支持同一口径：OpenAI reaffirms Zero Data Retention for eligible API customers，并预览Private Safety Processing。这里的eligible API customers同样不能省略。ZDR不是面向所有ChatGPT使用者的通用承诺，也不是所有API调用天然获得的默认配置；它是符合条件客户在特定部署和合同条件下采购的数据保留模式。
OpenAI官方X公告补充了同一组动词。它写的是“We will continue to offer Zero Data Retention for frontier models”，随后说明随着AI承担更长、更自主的工作并为企业带来更大价值，安全系统也需要识别相关交互中的风险。这个社交公告适合作为措辞核对来源，但事实主体仍应落在官网文章和RSS上。
为什么企业会在这里纠结
企业采用frontier models时，ZDR经常是隐私、安全和法务共同关注的采购项。一个医疗、金融、制造或代码托管客户，可能愿意把任务交给模型处理，却不愿把提示词、响应、内部代码、客户数据或调查材料留在模型供应商环境中。这个要求来自合规义务、客户合同和内部访问控制，并不只关乎对模型能力的信任。
问题在于，越严格的数据不留存，平台越难发现跨交互风险。很多高风险行为不是单次请求暴露出来的。用户可能把目标拆成多步，先请求无害信息，再逐步组合成违规用途；也可能让Agent在长任务中调用多个工具，风险只在任务链后半段出现。随着企业把AI从问答工具推进到工作流代理，安全系统如果只看一次输入输出，盲区会变大。
OpenAI这次预览的Private Safety Processing，本质是在“内容最小可见”和“风险模式可识别”之间寻找中间层。它不把ZDR简单解释为平台完全退出安全责任，也不把安全治理简化为保留全部内容。更准确的理解是：OpenAI想让自动化安全组件提取足够少、但对滥用检测足够有用的信号，同时把原始prompt和response挡在人员访问之外。
这也是它对企业市场有意义的地方。对于采购方来说，ZDR以前常是一条单独的隐私承诺；如果Private Safety Processing成立，ZDR会变成一个可以和滥用检测、事故响应、合规审计同时讨论的架构包。对安全负责人来说，评估问题会从“供应商是否保存内容”扩展成“安全信号如何生成、谁控制密钥、系统能否被第三方审计、例外处理如何触发”。
两种部署方向的实际含义
OpenAI官方摘录给出的部署描述只有两句，但已经能看出产品方向。一种是ZDR客户内容保留在客户控制的基础设施上。另一种是OpenAI开发中的选项：内容存储在OpenAI基础设施上，但用客户控制的密钥加密。两种方案都试图让自动系统识别潜在滥用并返回有限安全信号。
| 方案 | 官方已说的部分 | 企业要追问的部分 |
|---|---|---|
| 客户控制基础设施 | ZDR部署中客户内容保留在客户控制的基础设施上 | 安全处理组件运行在哪里，日志由谁保存 |
| OpenAI基础设施加客户控钥 | OpenAI在开发该选项，内容用客户控制的密钥加密 | 密钥轮换、撤销、托管地域和故障恢复 |
| limited safety signals | 自动系统返回有限安全信号，不暴露底层内容给人员 | 信号字段、留存周期和误报申诉流程 |
| CSAM例外 | 疑似CSAM图片会继续为人工复核和报告目的保留 | 触发条件、报告路径和地域法规差异 |
客户控制基础设施听起来更贴近高合规行业的直觉，因为内容边界更清楚。但它也带来运维和安全责任问题：模型供应商的安全组件如何部署，更新如何推送，检测逻辑是否可验证，客户能否看到足够多的误报和漏报信息。客户自管会把一部分责任从供应商侧移回企业侧，实际复杂度未必更低。
客户控制密钥的OpenAI托管方案则更像云安全领域常见的折中。客户希望借用供应商基础设施的可用性和更新速度，同时把解密控制权放在自己手里。这个模式是否足够强，取决于白皮书会不会说明密钥管理、运行时访问、内存中明文处理、备份、崩溃转储、跨区域复制和合规审计。仅有“客户控制密钥”这几个字，还不足以让高敏行业放心。
CSAM例外也不能被忽略。它说明ZDR存在特定法律与安全义务下的人工复核和报告路径，并非绝对无条件的不保留承诺。对企业读者来说，合理的评估方式是要求例外可预期、可审计、范围清楚，并且不会被扩展到与该义务无关的普通企业内容。
这条公告的价值来自一个具体承认：企业AI安全已经进入长期代理场景，风险需要跨步骤识别；客户同时要求更强隐私边界，供应商也不能继续依赖传统日志审查来解决问题。
早报判断是，Private Safety Processing如果做成，会把企业AI采购问题从“是否允许供应商留存内容”推进到“安全信号是否足够、可解释、可审计”。这对OpenAI有利，因为它可以保住ZDR这个企业承诺，同时不完全放弃平台级风控；对客户也有利，因为安全团队终于可以把隐私、滥用检测和事故响应放在同一张架构图里评审。
风险在于，limited safety signals这个短语现在承载了太多承诺。信号太少，跨交互滥用检测可能只是形式；信号太多，客户会担心它变成另一种内容留存。9月白皮书要拿工程和合规细节说话：哪些数据被处理，哪些数据被丢弃，谁能证明这件事确实发生了。
接下来怎么验证
第一个观察点是9月白皮书。它至少要说明安全信号的数据结构、生成位置、留存时间、访问权限、删除机制和客户审计方式。若白皮书只停留在概念图和原则声明，这个方案对高合规企业的采购价值会明显打折。
第二个观察点是早期客户。OpenAI称该方案正在与早期客户测试。有说服力的案例需要披露部署形态、审计流程、事故响应路径，以及ZDR和安全检测同时运行时的实际延迟、误报和漏报成本，不能只停留在“重视隐私”的表态。
第三个观察点是模型范围和资格条件。官方用了frontier models和eligible API customers两个限定词。企业需要确认哪些模型、哪些端点、哪些区域、哪些用量等级可以使用ZDR和Private Safety Processing。若范围过窄，它更像高端合规选项；若覆盖主力API流量，它会成为OpenAI企业平台的关键差异化。
第四个观察点是例外处理。疑似CSAM图片保留是明确、合理但敏感的边界。OpenAI需要把触发规则、人工复核权限、报告对象、保留期限和客户通知方式讲清楚。否则，ZDR客户会把例外当作不确定风险，而不是可管理的合规条款。
最后要看竞争者如何回应。Anthropic、Google、Microsoft和开源推理服务商都面临同一个问题：越往企业核心工作流走，越不能只用“我们不训练你的数据”回答隐私问题。下一轮企业AI平台竞争，可能会落到可验证的数据控制、可审计的安全信号，以及客户能否把供应商承诺写进自己的合规证据链。