摘要： OpenAI 宣布把 Zero Data Retention（ZDR）扩展到前沿模型，并预览 Private Safety Processing（PSP）。这两个概念解决不同问题：ZDR 约束客户提示词与模型响应在请求处理后的保留；PSP 则尝试在不让 OpenAI 人员访问底层客户内容的情况下，跨相关交互识别安全风险模式。本文依据 OpenAI 官方文档，拆解 ZDR、Modified Abuse Monitoring、Eyes Off、Safety Retention 与 PSP 的边界，说明哪些 API 端点仍可能保存应用状态、store:false 为什么不等于 ZDR，以及企业如何设计无状态 Responses API、客户侧存储、工具调用和审计架构。
核心结论
OpenAI Zero Data Retention 与 Private Safety Processing 并不冲突：ZDR 保证符合条件的 API 客户在请求处理后，OpenAI 不保留提示词或模型响应；PSP 则在客户控制或客户密钥保护的内容上运行自动化安全分析，跨多次相关交互发现风险，并只向 OpenAI 返回窄化的安全信号，而不是底层内容。PSP 的目标正是让更强的前沿模型继续兼容 ZDR，而不是取消 ZDR。
- ZDR 不是默认开关。 它面向符合条件的 API 客户，需要 OpenAI 事先批准并接受额外要求，可在 Organization 或 Project 层配置。
store:false不等于 ZDR。 它关闭部分应用状态保存，但不会自动让组织获得 ZDR，也不能改变不符合 ZDR 条件的端点、工具或第三方服务的保留行为。- ZDR 不等于零处理。 模型仍需在内存中处理请求，自动安全系统仍可分析交互；关键承诺是请求处理后不保留客户提示词和响应，并限制人员访问。
- PSP 目前是预览与早期客户测试。 OpenAI 表示计划从 9 月开始推出并分享技术白皮书；当前不能把它写成所有客户已经可配置的 GA 功能。
- 企业必须逐端点核验。 Responses、Chat Completions 等可符合 ZDR，但 Conversations、Threads、Vector Stores 等持久化资源不符合；Background mode、文件、图像、工具和外部 MCP 还存在额外边界。
为什么 OpenAI 要同时推进 ZDR 与 PSP
前沿模型和 Agent 的任务越来越长，严重风险不一定出现在单次请求里。一个请求可能完全正常，但多次相关交互组合后可能表现为持续绕过防护、跨账号协调、分阶段滥用，或者 Agent 在被要求停止后仍继续行动。
传统 ZDR 兼容安全系统主要逐次评估交互。它保护隐私，但对跨会话模式的识别能力有限。另一种做法是让供应商长期保存内容用于安全监控，但金融、医疗、法律、研发和政府客户往往无法接受这种数据暴露。
Private Safety Processing 的定位，就是在“保留原始内容以做跨交互安全分析”与“完全看不到跨交互风险”之间建立新的技术路径：
Customer-controlled content
→ automated safety processing across related interactions
→ narrow safety signal
→ enforcement decision
OpenAI personnel do not receive underlying prompts or responses.OpenAI 官方表示，在 ZDR 部署中，客户内容保留在客户控制的基础设施；另一种正在开发的方案是在 OpenAI 基础设施中保存内容，但由客户控制密钥加密，OpenAI 人员没有这些密钥。无论哪种方式，PSP 自动系统可识别潜在滥用并返回有限信号。
ZDR、MAM、PSP 与普通 API 保留的区别
| 模式 | 客户内容进入滥用监控日志 | 应用状态 | 跨交互安全识别 | 当前状态 |
|---|---|---|---|---|
| 默认 API | 可能，通常最长 30 天 | 取决于端点和 store | 使用现有安全系统 | 默认 |
| Modified Abuse Monitoring | 通常排除客户内容，图像/文件有少数例外 | 可继续使用平台完整能力并按端点保存 | 现有自动安全机制 | 需批准 |
| Zero Data Retention | 与 MAM 一样排除客户内容 | ZDR 合格端点不保留客户内容；store 被强制为 false | 现有 ZDR 兼容安全机制 | 需批准 |
| Private Safety Processing | 不以人员可读原文形式返回 | 内容在客户控制基础设施或客户密钥加密存储 | 跨相关交互识别模式并返回窄信号 | 早期客户测试/预览 |
这里最容易误解的是 MAM 与 ZDR。OpenAI 文档说明，二者都会让客户内容排除在滥用监控日志之外；差异在于 ZDR 还改变部分端点行为，并要求 ZDR 合格能力不保存客户内容作为应用状态。MAM 更适合需要使用持久化平台能力、Background mode 或其他非 ZDR 工作流，但又希望减少滥用监控内容保留的客户。
ZDR 到底承诺什么
OpenAI 对前沿模型 ZDR 的官方表述是：对符合条件的 API 客户，请求处理后不保留其提示词或模型响应；客户内容不提供给 OpenAI 人员审查，企业客户数据默认不用于训练，除非客户明确选择加入。
不进入常规滥用监控内容日志
默认情况下，滥用监控日志可能包含提示词、响应以及从内容派生的分类器输出，通常最长保留 30 天，但法律要求或保护服务与第三方安全的必要情况可能改变期限。获批 ZDR 后，客户内容被排除在这些日志之外，受到官方列明例外和限制约束。
强制无状态保存
对 /v1/responses 与 /v1/chat/completions，ZDR 会把 store 视为 false，即使请求尝试设置为 true。这意味着应用不能依赖 OpenAI 端持久响应对象保存长会话状态，应把必要上下文留在客户系统中，并在后续请求重新提交。
不用于训练不是 ZDR 独有
API Platform 的业务数据默认不用于训练，除非客户主动选择分享。因而“是否训练”和“是否保留”是两个不同控制：一个标准 API 项目可以默认不用于训练，但仍可能有最长 30 天的滥用监控保留或端点应用状态；ZDR 进一步解决保留问题。
仍有法律、安全与特定内容例外
OpenAI 文档说明，图像和文件输入会进行 CSAM 扫描；如果分类器检测到潜在 CSAM，内容可能被保留供人工审查，即使启用了 ZDR、MAM 或 Eyes Off。企业不能把 ZDR 写成无条件、无例外的数据销毁承诺，合同、文档和具体项目配置才是最终依据。
store:false 为什么不等于 Zero Data Retention
这是开发团队最常犯的错误。store:false 是请求级应用状态设置；ZDR 是经批准的组织或项目级数据保留控制。
from openai import OpenAI
client = OpenAI()
response = client.responses.create(
model="YOUR_APPROVED_MODEL",
store=False,
input="Summarize this redacted internal policy."
)
print(response.output_text)这段代码能要求 Responses API 不持久保存响应对象，但它不会：
- 自动批准组织使用 ZDR；
- 自动排除默认滥用监控保留；
- 让非 ZDR 合格端点变得合格；
- 改变文件、图像、Background mode 或外部工具的保留规则；
- 约束你自己的日志、APM、代理、数据库和第三方处理方。
OpenAI 官方 Programmatic Tool Calling 文档也明确指出，设置 store:false 可以启用无状态延续，但不会自行启用 ZDR；ZDR 必须在 Organization 或 Project 上获批并启用，完整请求的模型、工具与第三方服务都会影响资格和保留。
哪些 API 能力需要特别核验
官方数据控制页面提供逐端点表格，企业上线前必须以当前表格为准。根据 2026 年 8 月 26 日文档，可做如下架构判断：
| 端点或能力 | ZDR 判断 | 关键注意事项 |
|---|---|---|
/v1/responses | 可符合，有限制 | ZDR 下 store 强制为 false；工具可能另有状态 |
/v1/chat/completions | 可符合，有限制 | 同样强制无状态；检查图像/文件输入例外 |
/v1/embeddings | 可符合 | 客户端仍需保护输入与向量存储 |
| Audio transcription/translation | 可符合 | 当前表格显示无滥用监控与应用状态保留 |
| Image generation/edit | 可符合但有限制 | Eyes Off/Safety Retention 合格性与文本端点不同 |
/v1/conversations | 不符合 | 状态保存至删除，不适合严格 ZDR 架构 |
| Assistants/Threads/Runs | 不符合 | 应用状态保存至删除，优先迁移无状态 Responses |
| Vector Stores | 不符合 | 文件与向量属于持久状态，应放在客户控制层 |
| Background mode | 与严格 ZDR 不兼容 | 为轮询可靠性约保存约 10 分钟；MAM 可用 |
OpenAI Deep Research 文档特别提醒，Background mode 会把响应数据写入磁盘约 10 分钟以支持轮询，因此与 ZDR 要求不兼容；ZDR 凭证出于兼容原因可能仍接受 background=true，但严格需要 ZDR 时不应使用。
Private Safety Processing 如何工作
PSP 的核心不是“完全不看内容就判断风险”，而是让自动化安全处理可以使用相关交互内容，同时不给 OpenAI 人员访问底层明文。
客户控制内容的位置或密钥
OpenAI 描述了两种方向：
- ZDR 部署中，内容保持在客户控制的基础设施；
- OpenAI 提供存储时，内容使用客户控制密钥加密，OpenAI 人员没有密钥副本。
官方公告尚未公开完整密码学架构、威胁模型、密钥生命周期、隔离实现与性能指标，并表示计划分享技术白皮书。因此不能擅自将其描述为特定的可信执行环境、同态加密或某种已认证标准。
自动系统跨相关交互分析
现有 ZDR 兼容系统主要单次评估，PSP 扩展到相关交互，尝试识别逐步形成的风险。例如，同一 Agent 在多步任务中逐渐偏离用户意图，或多次请求组合后形成严重滥用模式。
只返回窄化安全信号
当识别到风险时，OpenAI 接收指示活动类型的窄化信号，用于判断是否需要执行措施。官方明确称，即使内容被标记，OpenAI 人员也不会因此获得客户内容访问权。
客户掌握调查证据
客户可以使用自己系统中的信息调查警报和执行决定。需要申诉、说明合法用途或协助调查已验证滥用时，客户可选择向 OpenAI 分享相关信息。这把“底层证据默认暴露”转变为“客户选择性披露”。
Eyes Off 与 Safety Retention 不能忽略
OpenAI 数据控制文档还列出 Eyes Off 与 Safety Retention，这两者是理解例外的重要部分。
Eyes Off
对于已获批 ZDR 或 MAM 的客户，OpenAI 保留在提前书面通知受影响客户后，使特定模型不再符合 ZDR/MAM 的权利。在 Eyes Off 情况下，内容可能进入滥用监控保留，但排除人工审查，法律要求除外。
Safety Retention
如果为调查或防止严重风险活动而合理必要，OpenAI 可在提前书面通知后，让特定模型对特定客户不再符合 ZDR/MAM。在 Safety Retention 下，分类器发现可能违反 Usage Policies 或协议的内容可能被保留并进行人工审查；其他内容的保留不受影响。
这说明 ZDR 是具有资格、端点、模型、客户和安全条件的合同与技术控制，不是任何 API Key 都天然拥有的永久属性。采购、安全与开发团队必须保存获批范围、书面通知流程和例外处置计划。
企业如何申请与配置 ZDR
官方文档要求事先批准。建议流程如下：
- 定义 Qualifying Use Case。 说明数据类型、法规、模型、端点、地区、吞吐量和为什么需要 ZDR。
- 联系 OpenAI Sales。 询问资格、附加要求、合同、端点与模型范围。
- 建立数据流图。 列出客户端、API Gateway、OpenAI、工具、MCP Server、日志、数据库、队列和备份。
- 逐端点核对资格。 不要只检查模型名称；端点、参数、工具和后台模式都会改变状态保留。
- 获批后配置 Organization。 在 Settings → Organization → Data controls 选择 ZDR 或 MAM。
- 按 Project 覆盖。 项目可继承默认、显式选择 ZDR/MAM，或设置 None 禁用这些控制。
- 做负面测试。 验证
store:true是否被强制关闭、持久化端点是否被架构阻止、日志是否泄露 Prompt。 - 建立持续验证。 每次新增模型、Tool、Endpoint、Region 或 SDK 功能都重新检查资格。
示例项目策略不是 OpenAI 官方格式，但可用于内部 IaC 与审计：
openai_data_policy:
organization_control: "ZDR_APPROVED"
allowed_endpoints:
- "/v1/responses"
- "/v1/embeddings"
denied_capabilities:
- "conversations"
- "vector_stores"
- "background_mode"
request_defaults:
store: false
customer_side_state:
encrypted: true
retention_days: 7
redact_before_send: true
logging:
prompt_body: false
response_body: false
request_id: true
model: true
latency: true
change_control:
require_review_for_new_model: true
require_review_for_new_tool: trueZDR 下如何构建多轮 Responses API
ZDR 项目不能依赖 OpenAI 端有状态会话。应用应保存自己允许保留的对话，并在每轮请求传回最少必要上下文。
对于需要推理连续性的模型，OpenAI 文档提供 encrypted reasoning items：设置 store:false，保存并回传响应中的加密推理内容。OpenAI 在内存中解密用于下一次生成，随后丢弃，并把新的推理内容立即加密后返回。
概念流程：
Customer App stores:
redacted user messages
encrypted reasoning items
tool results required for next turn
Each request:
minimum context + encrypted items + store:false
→ in-memory processing
→ output + newly encrypted items
→ customer-controlled storage客户侧存储不是“免费获得合规”。企业成为数据保留责任主体，必须实施加密、最小权限、删除策略、审计、备份过期和数据主体请求流程。
Agent 与工具调用的 ZDR 设计
Agent 使用 Web Search、File Search、Code Interpreter、Computer Use、MCP 或自定义函数时，完整数据路径超出单一模型请求。
优先使用无持久容器的编排
OpenAI Programmatic Tool Calling 可以在隔离的临时 V8 Runtime 中编排工具，不需要持久代码容器，并支持 ZDR 工作流。但 ZDR 仍需项目获批，且每个 Tool 和第三方服务需要独立核验。
外部工具是新的数据处理方
即使 OpenAI 请求符合 ZDR，远程 MCP Server、搜索供应商、CRM、数据库、监控平台或自定义 API 可能记录参数与结果。必须对工具做数据分类、字段裁剪、DPA、保留期限和权限审查。
写操作保留人工审批
ZDR 只解决数据保留，不解决 Agent 行为风险。付款、删除、发布、发信、修改权限和生产数据库操作仍需人工审批、幂等、限额与全链路审计。
日志不要重新制造副本
很多“ZDR 架构”最终在 API Gateway、异常跟踪、APM 和 Debug 日志中保存了完整 Prompt。日志仅保留 Request ID、Project、Model、Latency、Token 数、策略结果与脱敏错误，不记录正文。
选 ZDR 还是 Modified Abuse Monitoring
| 需求 | 更适合 ZDR | 更适合 MAM |
|---|---|---|
| 不允许供应商保存提示词/响应 | 是 | 不一定 |
| 需要 Conversations/Threads/Vector Stores | 否 | 是，仍按端点保存状态 |
| 需要 Background mode | 否 | 是 |
| 客户自行管理会话状态 | 是 | 可选 |
| 希望保留完整平台体验 | 有限制 | 更合适 |
| 法规要求严格数据最小化 | 优先评估 | 需结合合同判断 |
正确选型不是“隐私越强越好”，而是把业务功能与保留义务匹配。如果产品依赖持久会话、文件检索或长时间后台任务，强行宣称 ZDR 会造成技术与合规不一致。可以把敏感路径拆成 ZDR Project，把需要状态的低敏感路径放入 MAM Project，并通过 Gateway 阻止串用 Key。
想进一步了解 API 无状态 Agent，可查看 AI Stack Nav 的 OpenAI Responses API 教程；企业数据治理可继续阅读 AI 数据隐私与安全专题。
常见误区与排查
Dashboard 设置了 ZDR，但请求仍产生状态
检查项目是否继承正确 Organization 设置、Key 是否属于目标 Project、Endpoint 是否 ZDR 合格、是否使用 Conversations、Vector Stores、Background mode 或持久化工具。组织获批不代表所有项目都启用。
设置 store:false 后认为合规完成
确认是否有正式 ZDR 批准。再检查 abuse monitoring、代理日志、工具提供商、文件上传、缓存、队列、错误追踪和客户侧数据库。store:false 只是一个字段。
Responses 多轮质量下降
无状态应用必须自行回传必要历史和工具结果。对于推理连续性，按官方 Responses 迁移文档使用 encrypted reasoning items；不要用 previous_response_id 依赖服务端状态来模拟严格 ZDR。
长任务需要 Background mode
严格 ZDR 下不要使用，因为它约保存响应数据 10 分钟用于轮询。可把任务编排、队列和状态放在客户基础设施中，采用前台请求分段执行，或评估 MAM 是否更符合业务需求。
Private Safety Processing 被误认为已经 GA
截至本文核验日，OpenAI 将 PSP 描述为 Preview，正在与早期客户测试，并计划从 9 月开始推出与分享白皮书。采购与架构文档应标记为“计划中/待合同确认”。
风险、限制与合规边界
- ZDR 仅适用于获批 API Organization/Project 和合格端点，不是 ChatGPT 消费者产品的通用设置。
- ChatGPT Work、Enterprise、Business、Edu 等产品有各自保留控制；API ZDR 不能直接推导其规则。
- PSP 的技术白皮书尚未公开，密钥管理、隔离、审计与部署细节仍需等待官方说明和客户合同。
- ZDR 不阻止客户自己的系统、第三方工具、MCP Server 或网络代理保存数据。
- 数据不用于训练与数据不保留是不同承诺，安全评审必须分别核验。
- 图像与文件存在特定安全扫描例外；法律义务和严重风险机制也可能影响保留。
- 合规结论需要法律、隐私、安全与采购团队共同确认，本文不构成法律意见。
事实依据与来源
- OpenAI 官方已确认： 默认 API 滥用监控日志可能包含客户内容并最长保留 30 天，受到法律与安全例外约束。
- OpenAI 官方已确认： ZDR 与 MAM 需要事先批准；ZDR 会强制 Responses 与 Chat Completions 的
store为 false。 - OpenAI 官方已确认： 端点资格不同，Conversations、Threads、Vector Stores 等持久化能力不符合 ZDR。
- OpenAI 官方已确认： PSP 跨相关交互运行自动化安全处理，仅向 OpenAI 返回窄化信号，不向人员开放底层内容。
- OpenAI 官方已确认： PSP 正在早期客户中测试，计划从 9 月开始推出并发布技术白皮书。
- 实施建议： 项目分层、YAML 策略、客户侧状态与持续验证清单是本文架构建议，不是 OpenAI 官方配置格式。
- 未确认事项： PSP 的完整密码学实现、支持模型、定价、资格和 GA 日期尚未在已公开官方资料中完整说明。
FAQ
OpenAI API 默认是 Zero Data Retention 吗？
不是。API 业务数据默认不用于训练，除非客户主动选择分享，但默认滥用监控日志可能保留内容最长 30 天，部分端点还保存应用状态。ZDR 需要符合条件并获得批准。
store:false 是否等于 ZDR？
不等于。它关闭 Responses 或 Chat Completions 的部分应用状态保存，但不会自动排除滥用监控日志，也不能改变非 ZDR 端点与第三方工具的保留。
ZDR 与 Modified Abuse Monitoring 最大区别是什么？
二者都将客户内容从常规滥用监控日志中排除，受例外约束；ZDR 还对合格端点的应用状态施加不保留要求，并强制 store:false。MAM 更适合仍需持久平台能力的项目。
Private Safety Processing 会读取客户内容吗？
自动化系统需要利用相关交互内容识别跨交互风险，但 OpenAI 的设计目标是不让 OpenAI 人员访问底层内容。它只返回窄化风险信号，内容保持客户控制或由客户密钥加密。
PSP 是否已经面向所有 API 客户开放？
没有。官方当前称其正在与早期客户测试，属于 Preview，并计划从 9 月开始推出和分享技术白皮书。具体资格需向 OpenAI 确认。
ZDR 可以使用 Responses API 吗？
可以使用合格的 Responses API 路径，但 store 会被强制为 false，不能依赖持久响应状态。多轮推理可使用客户侧历史与 encrypted reasoning items。
ZDR 可以使用 Background mode 吗？
严格要求 ZDR 时不应使用。Background mode 为可靠轮询会将响应数据写盘约 10 分钟，官方明确说明这与 ZDR 不兼容；MAM 项目可以使用。
ZDR 是否覆盖远程 MCP Server 和第三方工具？
不会自动覆盖。每个外部工具都是独立数据处理环节，可能记录请求和结果。企业必须单独核验权限、保留、地区、合同和日志策略。
启用 ZDR 后还需要 Moderation 与安全治理吗？
需要。获批 ZDR/MAM 的客户仍负责确保用户遵守 OpenAI 政策以及适用法律下的审核与报告要求。ZDR 不替代输入校验、权限隔离、人工审批和审计。
参考来源
- OpenAI Docs：Data controls in the OpenAI platform
- OpenAI：Offering Zero Data Retention for frontier models
- OpenAI Enterprise Privacy
- OpenAI Docs：Migrate to the Responses API
- OpenAI Docs：Programmatic Tool Calling
- OpenAI Docs：Deep Research and Background mode
会员充值与订阅排查资料
适合阅读会员充值、订阅购买、权益对比和支付问题类文章后继续转化。
