评测
OpenAI 把前沿模型带进 Zero Data Retention：Private Safety Processing 如何兼顾隐私与跨会话安全？
OpenAI 在 2026 年 8 月 19 日宣布，符合条件的 API 客户可以继续在前沿模型上使用 Zero Data Retention（ZDR），并预览一套名为 Private Safety Processing 的新机制。ZDR 的核心承诺是：请求处理完成后，不保留客户的 Prompt 和模型响应；这些内容不会开放给 OpenAI 人员审阅，企业数据也不会用于训练，除非客户主动选择加入。问题在于，Agent 正在从“一问一答”变成持续十几分钟甚至数小时的多轮任务，一些真正严重的安全风险只有把多个交互放在一起才能识别。Private Safety Processing 试图解决这个冲突：安全系统可以跨相关交互识别风险模式，但 OpenAI 人员仍然不能看到底层客户内容；在 OpenAI 托管存储场景中，内容可由客户控制密钥加密。本文从数据路径、企业架构、日志留存、密钥管理、Agent 安全和采购评估六个角度拆解这项变化。
# OpenAI 把前沿模型带进 Zero Data Retention：Private Safety Processing 如何兼顾隐私与跨会话安全？
## 文章摘要
OpenAI 在 2026 年 8 月 19 日宣布，符合条件的 API 客户可以继续在前沿模型上使用 Zero Data Retention（ZDR），并预览一套名为 Private Safety Processing 的新机制。ZDR 的核心承诺是：请求处理完成后，不保留客户的 Prompt 和模型响应；这些内容不会开放给 OpenAI 人员审阅，企业数据也不会用于训练，除非客户主动选择加入。问题在于，Agent 正在从“一问一答”变成持续十几分钟甚至数小时的多轮任务，一些真正严重的安全风险只有把多个交互放在一起才能识别。Private Safety Processing 试图解决这个冲突：安全系统可以跨相关交互识别风险模式，但 OpenAI 人员仍然不能看到底层客户内容；在 OpenAI 托管存储场景中，内容可由客户控制密钥加密。本文从数据路径、企业架构、日志留存、密钥管理、Agent 安全和采购评估六个角度拆解这项变化。
---
## 一、为什么“Zero Data Retention”在 Agent 时代变得更难？
传统 LLM API 的交互很简单：
```text
Prompt
↓
Model
↓
Response
↓
结束
```
安全系统只要判断这一次请求是否存在问题即可。
Agent 完全不同。
一个企业 Agent 可能连续执行：
```text
读取需求
↓
搜索文档
↓
读取代码
↓
调用 MCP
↓
访问 CRM
↓
执行数据库查询
↓
调用第二个工具
↓
等待用户确认
↓
继续执行
```
真正的风险可能并不存在于任何一个单独步骤。
例如，单独看以下请求都可能合理：
```text
“帮我列出所有可访问资源。”
“再告诉我哪些资源允许导出。”
“把符合条件的结果打包。”
“把压缩包传到这个外部地址。”
```
只有把多轮操作串起来，才会发现最终行为可能构成数据外泄。
因此，Agent 安全天然需要：
> **跨步骤、跨工具、跨交互理解意图。**
这正是传统 ZDR 模式最难处理的地方。
---
## 二、OpenAI 这次没有取消 ZDR，而是把安全机制重新设计了一层
根据 OpenAI 8月19日的说明，符合条件的 API 客户仍然可以获得明确的 ZDR 承诺：
- 请求处理完成后，不保留 Prompt 和响应；
- 客户内容不提供给 OpenAI 人员人工审阅；
- 企业数据不会用于训练，除非明确 Opt-in。
同时，OpenAI 正在测试 Private Safety Processing。
核心目标不是：
> “为了安全重新把所有内容留起来。”
而是：
> **允许自动化安全系统跨相关交互识别风险，同时不把底层原文开放给 OpenAI 人员。**
这是本次变化最值得企业关注的点。
---
## 三、Private Safety Processing 的基本工作方式
可以把它理解成三层。
### 第一层：客户内容
内容可能存在于：
```text
客户控制的基础设施
```
或者：
```text
OpenAI 提供的存储
```
对于 OpenAI 托管存储，OpenAI 表示正在开发由客户控制密钥进行加密的选项。
关键点是：
> OpenAI 人员没有这些客户密钥的副本，因此不能直接访问底层内容。
---
### 第二层：自动化安全处理
安全系统可以分析相关交互之间的模式。
例如：
```text
多轮提示
工具调用
Agent 行为
重复试探
跨账户模式
```
目的是识别单轮检测看不到的风险。
---
### 第三层：有限安全信号
当系统识别风险后，OpenAI 接收到的是一个：
> narrowly defined safety signal
也就是经过限制的安全信号，而不是完整客户原文。
这个信号可以用于判断是否需要执行安全措施。
即使内容被标记，OpenAI 人员仍然不会因此自动获得底层内容访问权限。
---
## 四、为什么跨会话风险检测越来越重要？
OpenAI 在公告中提到了几类情况。
### 1. 重复试探安全边界
单次请求看起来无害。
但一个账户连续几十次：
```text
改变表达
绕开限制
测试分类器
寻找最薄弱边界
```
整体行为就很不一样。
---
### 2. 多账户协同行为
攻击者可能不是一个账户完成所有操作，而是拆成多个身份。
单账户看：
> 正常。
跨账户聚合后：
> 可能是系统性滥用。
---
### 3. Agent 偏离用户意图
这是企业尤其应该关注的部分。
例如用户说：
> “停止执行。”
Agent 却因为内部状态、延迟工具或任务队列继续执行。
单独查看每一个工具调用，可能都属于原任务允许范围。
但把时间线串起来：
```text
用户撤销指令
↓
Agent 仍然继续
↓
产生外部副作用
```
问题就非常明确。
这说明 Agent Safety 不只是内容审核。
它还包括：
> **Authority Alignment——Agent 是否始终服从当前授权。**
---
## 五、这对企业采购 OpenAI API 有什么实际变化？
过去企业安全评估经常只问：
```text
数据是否训练？
数据保留多久？
日志在哪里？
有没有 SOC 2？
```
现在不够了。
至少要增加下面这些问题。
### 1. Agent 运行时数据在哪里？
区分：
- Prompt；
- Response；
- Tool Call；
- Tool Result；
- Conversation State；
- Trace；
- Safety Signal；
- Application Log。
不能把它们都笼统叫“对话数据”。
---
### 2. 谁控制加密密钥？
如果使用客户控制密钥，需要确认：
```text
Key Owner
Rotation
Revocation
HSM / KMS
Break-glass
Audit
```
特别是：
> 密钥撤销后，历史数据是否立即不可访问？
---
### 3. 安全信号里到底包含什么？
企业需要区分：
```text
Raw Content
Derived Metadata
Risk Classification
Enforcement Signal
```
ZDR 不意味着系统没有任何安全元数据。
采购和法务真正要问的是：
> **什么被处理、什么被持久化、谁能访问、保存多久、用于什么。**
---
## 六、ZDR 也不等于“企业什么都不用记录”
很多团队会走向另一个极端：
> 供应商不留，我自己也不留。
这对生产 Agent 非常危险。
如果 Agent 可以：
- 修改数据；
- 发邮件；
- 创建订单；
- 发布代码；
- 访问客户资料；
企业自身至少应该有：
```text
request_id
user_id
tenant_id
agent_id
prompt_version
model
tool_name
tool_arguments_hash
tool_result_status
approval_id
start_time
end_time
business_outcome
```
注意：
> 不一定要永久保存完整 Prompt。
可以通过分层日志降低敏感性。
---
## 七、推荐企业采用“三层日志”
### L1：默认运行日志
不保留完整内容。
记录：
```text
用户
模型
Agent
工具
耗时
Token
状态
风险等级
```
适合大多数生产请求。
---
### L2：受控诊断日志
用于：
- Bug；
- 质量问题；
- 安全事件。
可以保留部分脱敏内容。
需要：
```text
审批
有限时间
有限人员
```
---
### L3：事件取证日志
只在明确安全事件中启用。
需要：
- Legal Hold；
- 事件编号；
- 最小必要范围；
- 审计访问。
这样才能同时满足：
> 隐私最小化 + 可运营 + 可调查。
---
## 八、Private Safety Processing 和企业自己的 DLP 是替代关系吗？
不是。
企业自己的 DLP 应该发生在：
```text
用户输入
↓
AI Gateway
↓
DLP / Classification
↓
模型
```
而模型输出也需要：
```text
模型
↓
Output Filter
↓
Tool Policy
↓
用户 / 系统
```
Private Safety Processing 更像：
> 模型供应商层面的跨交互安全能力。
企业仍然必须负责：
- 数据分类；
- 权限；
- 脱敏；
- Tool Scope；
- 审批；
- 数据驻留；
- 行业监管。
---
## 九、最值得关注的 Agent 安全场景：撤销授权
Agent 时代有一个特别容易被忽略的设计：
> 用户说“停”，到底发生什么？
正确架构应该是：
```text
User Cancel
↓
Session State = CANCELLED
↓
Revoke Tool Authorization
↓
Cancel Pending Tasks
↓
Invalidate Approval Tokens
↓
Prevent New Writes
↓
Audit
```
而不是只：
> 停止前端显示。
如果后台 Queue 仍然继续：
```text
发送邮件
创建工单
修改数据库
```
那就不是一个安全的 Agent。
OpenAI 此次特别把“Agent 被要求停止后仍继续行动”作为跨交互风险示例，说明这个问题已经进入前沿 Agent 安全的核心范围。
---
## 十、企业应该如何设计 Stop / Cancel？
建议每个长任务有：
```text
run_id
authority_version
cancel_token
approval_scope
expires_at
```
每次工具执行前检查：
```python
if run.cancelled:
deny()
if approval.expired:
deny()
if authority_version != current_authority:
deny()
```
这比只依赖模型记住：
> “用户刚才叫我停。”
可靠得多。
---
## 十一、客户控制密钥会带来什么架构变化？
如果未来使用 OpenAI 提到的客户控制密钥模式，企业需要把 KMS 当成 AI 架构的一部分。
建议：
```text
Cloud KMS / HSM
↓
Customer Controlled Key
↓
OpenAI Storage Encryption
```
并定义：
### Rotation
多久轮换？
### Revocation
事件发生时是否可立即撤销？
### Regionality
Key 与数据是否在同一合规区域？
### Separation of Duties
AI Platform Admin 是否有权同时修改 Key？
最好不要。
---
## 十二、金融、医疗和研发团队为什么会最关注？
OpenAI 特别提到其企业客户会处理：
- 金融记录；
- 健康数据；
- 机密商业计划；
- 专有研究。
这些场景最大的问题不是：
> “模型好不好用。”
而是：
> **数据一旦进入高能力 Agent 工作流，能否保持原来的合规边界。**
如果一个模型只能在“供应商长期保留内容”的条件下提供高级安全能力，很多受监管行业就无法部署。
因此 Private Safety Processing 的商业意义其实很明确：
> 高能力模型要进入敏感行业，安全与隐私不能成为二选一。
---
## 十三、ZDR 项目上线前建议做什么 PoC？
不要只验证：
> API 能不能返回答案。
建议至少跑五类测试。
### 1. 正常多轮 Agent
验证业务成功率。
### 2. 用户中途撤销
检查是否真的停止所有后台动作。
### 3. Prompt Injection
检查 Agent 是否越权。
### 4. 敏感数据
检查 DLP、日志和 Trace 是否泄露。
### 5. 安全事件
模拟被安全系统阻断后，企业自己能否调查原因。
---
## 十四、企业架构建议
推荐：
```text
Employee / Application
↓
Enterprise AI Gateway
├── SSO / Identity
├── DLP
├── Data Classification
├── Model Policy
├── Budget
└── Audit
↓
OpenAI ZDR Endpoint
↓
Private Safety Processing
↓
Model
↓
Tool Gateway
├── Authorization
├── Approval
├── Idempotency
└── Cancellation
↓
Enterprise Systems
```
这里最重要的是：
> ZDR 只是其中一层。
它不能替代企业自己的身份、权限、工具治理和审计。
---
## 十五、采购评估清单
### 数据
- Prompt 是否保留？
- Response 是否保留？
- Tool Result 呢？
- Trace 呢？
- Derived Signal 呢？
### 人员访问
- 谁能访问？
- Break-glass 如何触发？
- 是否有审计？
### 密钥
- 谁控制？
- 如何轮换？
- 如何撤销？
### 安全
- 是否跨交互识别？
- 用户撤销后如何阻止继续执行？
- 安全信号是什么粒度？
### 运维
- 企业自己能否调查？
- 能否导出必要的事件证据？
---
## 十六、一个容易被误解的地方：ZDR 不是“零数据处理”
ZDR 是：
> Zero Data Retention。
不是：
> Zero Data Processing。
模型当然仍然必须处理内容才能生成结果。
安全系统也可能在处理过程中分析风险。
真正的区别是：
> 请求结束后哪些数据继续存在，以及谁能访问。
企业在合同、架构和合规评估中必须把这两个概念分开。
---
## 十七、OpenAI 接下来还会公布什么？
OpenAI 表示 Private Safety Processing 目前正在与早期客户测试，并计划在 **2026 年 9 月**开始逐步推出，同时发布技术白皮书。
因此今天更适合把它看成：
> 一个明确方向 + 早期架构预览。
还不适合假设所有技术细节已经固定。
企业应该重点关注后续白皮书中的：
- Cryptographic Boundary；
- Key Architecture；
- Signal Design；
- Storage Semantics；
- Incident Handling；
- Regional Deployment。
---
## 总结
OpenAI 这次更新真正解决的是一个 Agent 时代非常棘手的矛盾：
> **安全系统需要看“更长的行为链”，企业却希望供应商看到“更少的原始内容”。**
Private Safety Processing 试图同时保留：
- 前沿模型；
- Zero Data Retention；
- 跨交互风险识别；
- OpenAI 人员无法直接查看底层客户内容；
- 未来客户控制密钥加密的托管存储选项。
对企业来说，这不是“用了 ZDR 就结束了”。
真正成熟的 AI 架构还要补齐：
- AI Gateway；
- DLP；
- 身份与权限；
- Tool Policy；
- Stop / Cancel；
- 幂等；
- 分层日志；
- KMS；
- 事件调查。
如果高能力 Agent 要真正进入金融、医疗、研发和企业核心系统，未来最重要的竞争力之一很可能不是单纯模型能力，而是：
> **谁能在不牺牲客户数据控制权的前提下，把更强的安全能力一起交付。**
想继续了解 OpenAI API、企业隐私、Agent 安全和生产级 AI 架构，可以访问 **智元选**：https://www.zyentorpicks.com/。我们会持续把最新平台变化拆解成可以直接用于技术决策的内容。