OpenAI给前沿模型加上零留存

OpenAI 在 8 月 19 日宣布，将继续为符合条件的 API 客户提供零数据留存，并把这一承诺明确延伸至前沿模型，同时预览一套名为 Private Safety Processing 的隐私安全处理机制。对开发者来说，这次更新的重点不是模型又多会做一道题，而是企业能否在调用能力最强的模型时，不必把敏感输入留在供应商的日志系统里。

零数据留存（Zero Data Retention，ZDR）是指 API 请求完成后，符合条件的输入和输出不会被写入用于滥用监控的内容日志。它解决的是“数据是否被保存”，而不是“数据是否被用于训练”；这两个概念经常被混为一谈，但在企业合规审查里属于完全不同的控制项。

Private Safety Processing 是 OpenAI 预览的一种隐私保护型安全处理方案，目标是在不保留客户内容的前提下，继续对前沿模型执行必要的安全检测。它针对的是 ZDR 长期存在的一组矛盾：模型供应商需要识别网络攻击、欺诈和高风险滥用，企业客户则不希望病历、源代码、合同或内部调查材料进入可长期访问的安全日志。

这不是“不拿数据训练”的重复声明

OpenAI 此次更新首先澄清了一个容易被市场宣传模糊的问题：API 数据默认不用于训练，并不等于 API 数据不会被保存。OpenAI 自 2023 年 3 月 1 日起默认不使用 API 输入和输出训练模型，除非客户明确选择共享数据；但在传统策略下，部分 API 内容仍可能被保留最多 30 天，用于识别滥用和调查安全事件。

ZDR 的价值在于把“最多保留 30 天”进一步压缩为符合条件内容不进入持久化日志。对于普通客服机器人，这可能只是采购表格上的一个勾选项；对于处理患者资料、未公开财报、并购文件和私有代码库的系统，它直接决定了应用能不能通过法务、信息安全和行业监管审查。

企业采用生成式 AI 时至少需要区分四种数据控制，它们不能相互替代。

| 控制项 | 解决的问题 | ZDR 是否覆盖 | 常见误解 | |---|---|---:|---| | 默认不训练 | 输入输出是否用于改进基础模型 | 间接相关 | 不训练就等于不保存 | | 零数据留存 | 请求内容是否进入持久化内容日志 | 是 | 所有元数据也会全部消失 | | 数据驻留 | 数据在哪个国家或地区处理、存储 | 否 | 选择欧洲区域就自动满足所有合规要求 | | 本地脱敏 | PII 是否在发送给云端前被删除或替换 | 否 | 云端启用 ZDR 后就不再需要数据最小化 |

零数据留存也不意味着 OpenAI 的系统完全看不到请求。模型要生成结果，就必须在推理期间处理输入；ZDR 所承诺的是处理后的内容不被写入特定持久化日志，而不是创造一种服务器无需接触明文语义就能完成通用大模型推理的机制。

零数据留存同样不应被理解为“系统不产生任何记录”。计费、请求时间、模型名称、Token 数量、错误码和组织标识等非内容元数据，通常仍是服务运营、容量管理和财务核算所必需的；企业真正需要核对的是哪些字段属于客户内容、哪些字段属于运营元数据，以及各自的保留周期。

前沿模型此前为什么更难做 ZDR

前沿模型是供应商当前能力最强、同时潜在风险最高的一组通用模型。它们通常拥有更强的代码生成、工具调用、长链路推理和网络安全能力，因此安全团队对它们的监控要求也比小型分类模型更严格。

前沿模型接入 ZDR 的难点不在删除数据库记录，而在删除之后如何继续发现系统性滥用。传统云端安全体系依赖请求日志进行规则匹配、聚类分析、人工复核和事后追踪；如果内容完全不落盘，安全团队就失去了最直接的调查材料，也更难判断一次异常请求究竟是误报、研究测试，还是连续攻击的一部分。

Private Safety Processing 试图把“检查内容”和“保存内容”拆成两个动作。按照 OpenAI 目前的预览描述，系统希望在请求处理期间完成高级安全判断，同时避免为了安全分析而牺牲客户的数据隐私；这意味着安全判断需要尽可能在受限、短暂且隔离的处理路径中完成，而不能默认依赖长期保存原始提示词和模型输出。

OpenAI 尚未在本次预览中完整公开 Private Safety Processing 的技术架构、误报率、覆盖模型、上线日期和客户启用条件。现阶段更准确的判断是：它是一项方向明确但仍待验证的基础设施预告，不能直接等同于已经完成第三方审计、可以覆盖所有 API 工作负载的正式合规产品。

ZDR、隐私安全处理和本地过滤各管一段

OpenAI 在 2026 年 4 月发布的 Privacy Filter，补上了数据进入云端之前的另一层保护。OpenAI Privacy Filter 是一款用于检测和遮盖非结构化文本中个人身份信息（PII）的开放权重模型，可以部署在客户自己的设备或服务器上，让姓名、电话号码、地址等敏感字段在离开本地环境前被替换。

Privacy Filter 的技术路线与生成式大模型不同。它采用双向 Token 分类和片段解码，不是逐 Token 生成一份“改写后文本”，而是一次扫描输入并标记需要处理的连续片段，再通过受限 Viterbi 算法解码出连贯范围；这种设计更接近高性能序列标注器，速度、结果稳定性和可审计性通常优于让通用聊天模型凭提示词做脱敏。

Privacy Filter 已披露的模型规模为 15 亿总参数、约 5000 万活跃参数，并能预测 8 类文本片段。总参数与活跃参数相差 30 倍，说明它的设计目标不是充当另一款通用聊天模型，而是在高吞吐量流水线里承担专门的隐私过滤任务。

三种机制放在一起看，OpenAI 正在尝试建立一条从本地到云端的分层隐私链路。

| 机制 | 运行位置 | 核心目标 | 能否替代另外两项 | |---|---|---|---| | Privacy Filter | 客户本地或自有环境 | 在上传前识别、遮盖 PII | 不能，脱敏后数据仍可能包含商业机密 | | Zero Data Retention | OpenAI API 服务侧 | 请求完成后不保留符合条件的内容 | 不能，它不负责删除输入里的敏感字段 | | Private Safety Processing | OpenAI 安全处理路径 | 在保护隐私的同时执行高级安全检测 | 不能，它不是企业的数据分类和权限系统 |

分层部署比单独依赖 ZDR 更适合真正敏感的工作负载。医疗应用可以先在院内遮盖患者姓名和证件信息，再将必要的临床文本发送给启用 ZDR 的前沿模型；模型侧通过 Private Safety Processing 做风险判断，应用侧则继续保留自己的审计日志和访问控制记录。

真正的限制在端点，而不只在模型

企业评估 ZDR 时不能只问“某个模型是否支持”，还要问完整工作流涉及哪些端点和存储对象。一次看似无状态的模型调用，可能同时使用文件上传、异步批处理、对话状态、向量存储或评测数据集，而这些组件天然需要在多次请求之间保存数据。

有状态端点是为了后续操作而持续保存对象的 API 功能，例如文件、对话线程、向量库和批处理任务。它们与“请求结束即删除内容”的 ZDR 目标存在结构性冲突，因此即使核心推理请求符合零留存要求，外围组件也未必自动获得相同待遇。

开发团队需要按数据流而不是产品名称绘制合规边界。最实际的做法是列出每一步发送了什么、保存在哪里、由谁删除、保留多久，再根据 OpenAI 最新的数据控制矩阵和合同条款逐项确认；只拿一张“支持 ZDR”的销售材料，无法证明整个应用实现了零留存。

| 典型场景 | 主要敏感数据 | 更合适的控制组合 | 剩余风险 | |---|---|---|---| | 医疗病历摘要 | 姓名、病史、诊断结果 | 本地 PII 过滤 + ZDR + 内部审计 | 脱敏后文本仍可能重新识别患者 | | 私有代码审查 | 源代码、漏洞、密钥 | 密钥扫描 + ZDR + 最小权限 | 工具调用可能把数据发送到其他服务 | | 法务合同分析 | 当事人信息、交易条款 | 本地分类 + ZDR + 区域控制 | 输出可能复述原始敏感条款 | | 安全事件调查 | 攻击载荷、内部拓扑 | ZDR + Private Safety Processing | 安全检测误报可能影响可用性 |

OpenAI是在补企业市场最关键的一块短板

这次更新对普通个人开发者的直接影响有限，因为 ZDR 仍强调“符合条件的 API 客户”，并不是所有账户默认打开的通用开关。资格审核、组织级配置、端点兼容性和合同约束仍然重要，OpenAI 也没有宣布所有开发者可以自助启用，更没有给出单独的公开定价。

这次更新对金融、医疗、法律和政府客户的意义更大，因为这些行业并不缺模型演示，而是缺少能够写进风险评估和数据处理协议的明确边界。前沿模型能力越强，企业越希望把核心数据交给它；但模型能力越强，供应商又越需要做严格安全监控，Private Safety Processing 正面处理了这组矛盾。

OpenAI 的优势是可以把 ZDR、安全分类器、前沿模型和企业合同整合在同一套服务中。竞争对手也提供不训练承诺、数据驻留、私有网络和保留期控制，但真正决定企业选择的不会是一句“保护隐私”，而是模型覆盖范围、端点例外、审计报告、区域可用性和事故响应流程能否拼成一条完整证据链。

OpenAI 当前方案的短板是透明度仍然不足。Private Safety Processing 如果不公开处理位置、短暂数据的生命周期、自动化决策范围、人工访问条件和第三方验证结果，就很难让高监管行业仅凭产品名称接受它；对于这类客户，可验证的架构和合同责任比概念预览更有价值。

开发者现在应该检查什么

开发者现在最该做的不是等待一个新按钮，而是重新检查应用的数据路径。ZDR 只能控制 OpenAI 服务侧的一部分留存行为，应用自己的日志平台、错误追踪工具、代理服务器、云函数和可观测性系统，仍可能完整记录提示词与模型输出。

一份可执行的检查清单至少应包含以下项目：

• 确认组织是否具备 ZDR 资格，以及配置作用于组织、项目还是具体端点。
• 核对当前使用的模型、响应端点、文件、批处理和向量存储是否分别支持 ZDR。
• 关闭应用日志、异常追踪和分析工具中的请求正文采集，或设置独立脱敏规则。
• 在发送请求前移除访问令牌、私钥、身份证件、患者标识和不必要的内部编号。
• 将业务审计日志与模型内容日志分离，只记录操作者、时间、用途和结果状态等必要字段。
• 要求供应商在合同中明确内容数据、元数据、临时缓存和安全信号的定义与保留周期。
• 等待 Private Safety Processing 正式可用后，再核对其覆盖模型、区域、误报处理和人工访问政策。

企业还应避免把 ZDR 当作绕过内部治理的理由。零留存降低了云服务商持有内容的风险，却不会自动解决员工越权访问、错误授权、提示注入、工具调用泄露、输出复述以及本地数据库长期保存等问题。

判断：方向正确，成色要看正式技术说明

OpenAI 把 ZDR 明确带到前沿模型，是一次比跑分升级更实际的产品更新。它降低了高价值模型进入敏感业务的制度成本，也说明前沿 AI 的竞争已经从“谁的模型更聪明”推进到“谁能在安全、隐私和可审计性之间给出可部署方案”。

Private Safety Processing 是这次公告里更值得关注、也更需要谨慎看待的部分。它如果能够在不持久化原始内容的情况下保持高级滥用检测能力，就会成为前沿模型基础设施的重要组件；但在架构、评测和审计材料公开之前，它仍是一项预览，而不是已经被充分证明的隐私技术。

最终决定这项更新是否有用的，不是“零数据留存”六个字，而是支持范围和例外条款。开发者需要等 OpenAI 给出逐模型、逐端点和逐区域的正式兼容矩阵；企业则应把这些范围写进数据处理协议，而不是依赖会随产品更新变化的网页说明。

参考来源

• OpenAI：《Offering Zero Data Retention for frontier models》，2026 年 8 月 19 日官方公告；用于确认 ZDR 对符合条件前沿模型 API 客户的承诺，以及 Private Safety Processing 预览。根据链接域名限制，本文不附站外链接。
• OpenAI：《Introducing OpenAI Privacy Filter》，2026 年 4 月 22 日官方技术说明；用于核对模型定位、双向 Token 分类、片段解码、参数规模和本地部署能力。根据链接域名限制，本文不附站外链接。
• OpenAI GitHub 官方组织：OpenAI 对外发布开源代码、模型工具与相关技术项目的官方账号，可用于后续核查公开实现和技术材料。
• OpenAI：商业数据隐私、安全与合规说明；用于核对 API 数据默认不参与训练、静态与传输加密以及符合条件组织的数据保留控制。根据链接域名限制，本文不附站外链接。