企业把数字员工接入合同、病历、财务或研发资料时，经常同时提出两个看似冲突的要求：模型服务商不能保留业务内容，但系统又必须识别跨多轮、跨任务累积的危险行为。单轮内容审核可以少存数据，却难以发现长期试探权限、绕过护栏或被要求停止后仍继续执行的 Agent。
OpenAI 在 2026 年 8 月 19 日宣布继续为符合资格的 API 客户提供 Zero Data Retention（ZDR），并预告 Private Safety Processing。它尝试让自动安全系统在不向 OpenAI 人员暴露底层提示词和响应的前提下，从相关交互中识别风险模式。对企业而言，重点不是“零保留”四个字，而是重新划清模型推理、业务状态、安全检测与人工调查之间的数据边界。
官方事实：ZDR 保证了什么
OpenAI 的公告称，获批 ZDR 的 API 客户在请求处理完成后，提示词和模型响应不会被 OpenAI 保留，OpenAI 人员无法审阅客户内容；企业客户数据默认也不用于训练模型，除非客户明确选择加入。
但 ZDR 不是所有功能自动“无状态”。官方 API 数据控制文档说明，资格需要事先审批并接受附加要求，可在组织或项目级配置。ZDR 会把 Responses 与 Chat Completions 的 store 强制视为 false，即使请求试图设为 true。与此同时，Conversations、ChatKit threads、Assistants、Vector Stores、Files、Batch 与视频等端点或能力可能不符合 ZDR，仍可能保存应用状态。
Responses 也存在明确的运行例外：后台模式为了轮询会把响应数据写盘约十分钟；音频输出为多轮对话保存约一小时；提示缓存可能在 GPU 本地保留加密张量，最长窗口另有规则；Hosted Shell、Code Interpreter、托管 Skills 和远程 MCP 还各有自己的生命周期。尤其是第三方 MCP 或外部网络服务，数据进入对方系统后适用的是对方的保留政策，而不是 OpenAI ZDR。
因此，采购合同里的“启用 ZDR”必须下沉为一张端点与工具矩阵，不能只在供应商一栏打勾。
Private Safety Processing 的设计边界
官方预告提出两种内容位置。其一是客户控制的基础设施，适用于 ZDR 部署；其二是仍在开发的 OpenAI 托管存储，但内容使用客户控制的密钥加密，OpenAI 人员不持有密钥。自动系统可跨相关交互识别模式，只向 OpenAI 返回范围受限的风险类型信号，不返回底层提示词或响应。
客户仍在自己的系统中调查告警或处置决定；若要申诉、解释合法用途或配合已验证的滥用调查，可以选择共享相关资料。这意味着安全提供商拿到的是“需要处置的信号”，企业保留的是“能够解释业务上下文的证据”。这是一种值得关注的控制面分离，但目前仍是设计预告，不是已经公开白皮书和独立审计结果的成熟标准。
OpenAI 称 Private Safety Processing 正与早期客户测试，计划在 9 月开始推出并发布技术白皮书。现阶段没有公开误报率、漏报率、跨交互关联键、密钥托管细节、延迟与成本数据，也不能据此断言它满足某项行业法规。
企业架构：把状态留在自己的控制面
如果数字员工需要长时记忆、审批恢复和审计回放，最稳妥的做法仍是由企业维护任务状态，而不是依赖模型供应商的会话对象。建议把一次运行拆成四层：
- 推理层只接收完成当前步骤所需的最小上下文，默认
store:false； - 业务状态层在企业数据库保存任务、审批、幂等键、工具结果与补偿状态，并设置字段级生命周期；
- 安全层保留策略版本、风险信号、决策和必要的脱敏证据，不复制完整对话作为“方便排障”的默认做法；
- 调查层只在事件触发后按授权临时调取原始资料，记录谁查看、为何查看、何时删除。
这种分层与 企业 Agent Runtime 选型清单 的核心一致：恢复能力、可观测性和业务审计不能由模型对话历史代替。使用 OpenAI Agents SDK 时，也应单独检查 trace、会话、工具参数与回放状态是否包含敏感数据；SDK 0.22.0 对被护栏拒绝的终态工具输出做了脱敏加固，但它不等于应用所有日志都自动符合 ZDR。
远程 MCP、搜索、支付、邮件和浏览器工具尤其需要逐跳梳理。模型请求不保留，不代表工具供应商、代理层、日志平台和业务 SaaS 不保留。可参考 MCP 企业治理清单，为每个工具记录数据字段、目的、传输区域、保留期、删除接口与人工访问权限。
采购与上线验收清单
企业在签署“零保留”承诺前，至少应完成以下验证：
- 书面确认组织与具体项目已经获批 ZDR，而不是仅有“不用于训练”承诺；
- 建立模型、端点、工具、区域和保留方式的允许清单，阻止不兼容能力被动态启用；
- 用自动测试证明
store、后台模式、缓存、文件、会话与托管容器符合设计； - 远程 MCP、搜索和其他第三方服务分别完成数据处理与删除条款审查；
- 明确安全信号如何关联租户、用户和任务，以及企业能否解释、申诉和导出证据；
- 对法定保留、安全事件和模型资格变化设置告警、通知期限与回退供应商；
- 让安全、法务、采购和业务负责人共同审批高敏场景，不能由开发团队单独把 ZDR 当作合规结论；
- 在真实但脱敏的任务上测量延迟、误报、人工调查量和每次成功交付成本。
官方资料还列出重要例外：疑似 CSAM 的图像即使在 ZDR 部署中也可能为人工审阅和法定报告而保留；严重风险调查也有单独的 Safety Retention 条件和书面通知机制。企业合同、隐私告知与事件响应必须覆盖这些例外，不能对员工或客户承诺绝对意义上的“任何数据永不保留”。
研究限制与编辑判断
本文的功能事实来自 OpenAI 8 月 19 日公告与持续更新的 API 数据控制文档，两者均为 P0 官方一手来源。官方页面中的客户引语属于厂商客户自述，本文没有将其作为独立成效证据。当前也没有第三方审计、生产误报数据或 Private Safety Processing 技术白皮书，法规适用仍需企业法务结合地区、数据类型与合同判断。
我们的编辑判断是：Private Safety Processing 的价值不在于替企业“自动合规”，而在于提出一条可采购的架构方向——让供应商处理有限安全信号，让原始业务内容、长期状态和调查证据尽量留在客户控制域。企业现在最值得做的不是等待一句更强的隐私口号，而是把每个端点和工具的数据生命周期变成可测试、可审计、可退出的工程契约。