对于处理敏感代码、内部文档或客户数据的企业来说，是否保留 API 请求数据往往和模型能力同样重要。OpenAI 重申：符合条件的 API 客户可以使用 Zero Data Retention（ZDR，零数据保留），同时预览 Private Safety Processing，让更先进的 AI 安全能力能够在不牺牲数据隐私的前提下参与处理。
这项变化的重点，不只是“删除日志”四个字，而是把模型调用、安全检测、数据治理和客户资格放到同一个工程决策中考虑。
ZDR 解决的是什么问题
在传统的模型 API 集成中，企业通常需要确认几类数据会发生什么变化：
- 请求正文是否会被保留。
- 响应内容是否会进入调试或安全日志。
- 数据是否可能用于后续模型改进。
- 违规检测、滥用监控和人工审查是否需要访问请求内容。
- 不同模型、端点和功能是否拥有相同的数据处理政策。
ZDR 的核心价值，是为符合条件的 API 客户提供一种不保留 API 数据的处理模式。它特别适合源代码、个人信息、商业合同、医疗记录和内部知识库等数据类型。
不过，ZDR 不等于“所有数据永远不会离开企业网络”，也不等于可以跳过企业自身的数据治理。请求仍然需要发送到模型服务，网络传输、身份凭证、访问控制、客户端日志和输入脱敏依然需要由调用方负责。具体资格、适用范围、例外情况和可用端点应以合同及当前产品政策为准。
Private Safety Processing 的意义
隐私和安全经常被当成二选一：如果平台不接触请求内容，就很难执行高质量的安全检测；如果平台需要完整访问内容，企业又可能无法接受数据保留或扩散风险。
Private Safety Processing 试图解决的正是这个张力。根据目前的预览信息，它面向更先进的 AI 安全处理，同时保持与隐私要求相匹配的数据处理方式。对企业而言，这意味着安全能力不必简单地建立在长期保存客户内容之上。
工程上需要区分几个概念：
- 数据保留：数据在服务端保存多久，以及是否保存用于后续处理。
- 数据处理：请求是否会被安全系统、滥用检测或策略系统即时分析。
- 数据使用目的：数据是否被用于提供请求、改进模型、调查滥用或满足合规要求。
- 数据访问边界：哪些系统、人员和供应商可以接触数据。
因此，采用 ZDR 的团队仍然需要向安全、法务和合规团队说明：零保留并不意味着零处理，而是需要把“即时处理”和“持久化保留”分别审查。
可以这样设计一次调用
下面是一个可改造的 Python 示例。它展示了客户端侧的基本做法：通过环境变量管理凭证，不把提示词和响应写入应用日志，并用一个示意性的隐私配置字段表达“该配置需要在账户层面获得支持”。实际字段名、端点能力和 ZDR 开通方式需要以所使用的 API 文档及客户协议为准。
运行前设置 OPENAI_API_KEY，并将示例中的模型名替换为你的账户可用模型。
import os
from openai import OpenAI
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
request = {
"model": os.getenv("OPENAI_MODEL", "your-eligible-frontier-model"),
"input": "请将这段内部技术说明整理成三条风险摘要。",
# 这是配置意图示例；请根据账户支持的产品接口进行调整。
"privacy_mode": "zero_data_retention",
}
response = client.responses.create(**request)
# 只记录请求标识和耗时，不记录原始输入、输出或敏感元数据。
print({
"response_id": response.id,
"status": getattr(response, "status", "completed"),
})
如果当前 SDK 或端点不接受 privacy_mode 这类字段，不要把它硬编码到生产请求中。ZDR 通常是账户、组织或合同层面的数据处理配置，应用代码应通过供应商控制台、客户支持或合同确认开通状态。代码层面更重要的是避免日志泄露，并建立能够证明数据流向的审计记录。
也可以先从反向代理或服务封装层开始治理：
# 示例配置，字段名仅用于表达团队内部的治理约定
model_gateway:
provider: openai
zero_data_retention_required: true
private_safety_processing_required: true
log_request_body: false
log_response_body: false
redact_headers:
- authorization
- x-api-key
audit_fields:
- request_id
- model
- timestamp
- policy_decision
这类配置不能替代供应商的正式 ZDR 配置，但可以让部署检查、代码审查和运行时监控共享同一套要求。
落地时要检查的边界
1. 逐项确认资格
不要因为组织已经签署了隐私协议，就假设所有模型、端点和功能都自动具备 ZDR。把模型版本、批处理、文件、工具调用、评估功能和安全处理能力逐项列出，并确认每一项的适用条件。
2. 关闭本地敏感日志
ZDR 只覆盖供应商侧的特定数据处理范围。应用服务器、API 网关、追踪系统、异常平台和开发者终端仍可能保存完整请求。生产环境应默认只记录请求 ID、模型、延迟、状态和策略结果。
3. 保留可审计但不可逆的证据
企业仍然需要知道谁在什么时候调用了什么模型、调用是否成功、策略是否阻断。审计日志可以保留请求 ID、租户 ID 的哈希、策略版本和时间戳，避免保存原始提示词与响应内容。
4. 为安全处理设计数据最小化
即使 Private Safety Processing 能在更严格的隐私模式下工作，也不意味着输入可以无限扩大。调用前仍应删除不必要的姓名、账号、令牌、客户标识和原始附件，只发送完成任务所需的最小上下文。
5. 验证故障行为
测试模型不可用、安全处理不可用、策略判定超时和配置失效时的行为。对于高敏感数据，系统应能够拒绝降级到未获批准的模型或日志路径，而不是悄悄改变数据处理方式。
采用建议
ZDR 适合被当成一项数据处理控制，而不是一个简单的请求参数。推荐按以下顺序推进：
- 盘点请求中可能出现的敏感数据和所有日志副本。
- 与供应商确认目标模型、端点和 Private Safety Processing 的资格与限制。
- 在网关层禁止请求体和响应体日志，加入脱敏和审计字段。
- 用合成数据测试安全策略、失败模式和告警流程。
- 在合同、架构文档和运行手册中记录 ZDR 的适用边界。
对于需要前沿模型能力、又不能接受长期保存业务数据的场景，ZDR 与 Private Safety Processing 提供了一条更务实的路径：让模型安全和数据隐私共同进入系统设计，而不是在上线后再补救。真正的落地标准，是团队能够清楚回答每一份数据在哪里被处理、是否被保存、谁可以访问，以及配置失效时系统会如何停止或降级。