目錄
This article reflects information available as of August 2026. Private Safety Processing is still in the early customer testing and gradual rollout stage.
OpenAI has announced a change with fairly direct implications for enterprise and API developers: the company will continue offering Zero Data Retention (ZDR) to eligible API customers while previewing a new safety mechanism called Private Safety Processing. The fact that these two topics appeared in the same announcement is not accidental, because they address the same emerging tension. As AI moves from answering a single question to running Agent tasks that can continue for tens of minutes or even hours, some risks become visible only when multiple interactions are viewed together. But cross-interaction safety analysis usually requires some form of state or logging, which can directly conflict with enterprise restrictions on data retention.
For ordinary ChatGPT web users, this is not a new privacy toggle that suddenly appeared in the interface. The announcement mainly affects eligible API and enterprise workloads, especially workflows involving financial records, health data, customer contracts, unreleased product information, or internal research. The first thing to understand is not simply whether “OpenAI keeps no data,” but which content is excluded from safety-monitoring logs, which features inherently require Application State to be stored, and whether an entirely different retention policy applies once the data is sent to an external MCP service or SaaS platform.
What Is Zero Data Retention? First Separate “Not Used for Training” from “Not Stored”
OpenAI API Data Is Not Used for Training by Default; ZDR Addresses a Different Layer of Retention
Data sent through the OpenAI API is not used to train or improve models by default unless the customer explicitly opts in to sharing it, but “not used for training” and “not stored at all” have always been two different things. Under ordinary API usage, OpenAI may still create Abuse Monitoring Logs to enforce usage policies and detect misuse. These logs may include Prompts, Responses, and safety classifications derived from the content, and they can be retained for up to 30 days by default.
Zero Data Retention goes one step further at this layer. Eligible organizations approved by OpenAI can prevent Customer Content from entering these Abuse Monitoring Logs, while ZDR-compatible endpoints such as the Responses API and Chat Completions also force store to be treated as false. A more accurate way to understand this is that the standard API already excludes customer data from model training by default, while ZDR further limits OpenAI’s retention of Customer Content for abuse monitoring and certain forms of application state.
But ZDR should not be interpreted as meaning that “not a single Byte remains anywhere in OpenAI’s systems.” Account Data, Billing, Usage Statistics, Support Requests, and other forms of System Data are handled separately from Customer Content and do not disappear simply because ZDR is enabled. Enterprises therefore still need to distinguish between Customer Content, Application State, and System Data when conducting data-processing assessments.
Not Every OpenAI API Feature Is Eligible for ZDR
ZDR is also not a master switch for the entire API Platform. Chat Completions, Responses, Embeddings, and certain Image, Audio, and Moderation functions can support ZDR, while capabilities such as Conversations, Assistants, Threads, Vector Stores, Files, Fine-tuning, and Batches inherently require Application State to be retained and therefore cannot be understood using the same zero-retention logic.
The reason is fairly straightforward. If you are using a Vector Store, the data must remain available for later Retrieval. If a Conversation is expected to continue next week, some persistent state must exist. So the real enterprise question is not simply “Does OpenAI support ZDR?” but whether every Endpoint and Tool used in the actual workflow is ZDR Eligible.
Some features that appear to support ZDR also have their own limitations. Background Mode, for example, needs to temporarily retain Response Data so it can be polled later, while Code Interpreter currently cannot be used directly with full ZDR. Certain Prompt Caching or Hosted Container features may also involve short-term functional storage. These temporary states are not the same as placing complete Prompts into 30-day logs for abuse investigation, but they still show that ZDR does not mean data never touches storage at any point.
Once You Use Remote MCP, Third-Party Retention Policies Must Be Evaluated Separately
This point is especially easy to miss in Agent Workflows. Even if OpenAI uses ZDR on its side, once the Responses API sends content to a Remote MCP Server, the downstream handling of that data is governed by the third party’s own Retention Policy. OpenAI’s ZDR does not automatically extend to Notion, a CRM, a search provider, or a self-hosted MCP Server.
That means an Agent system needs to map the entire Data Flow: where the data enters, which models process it, which Tools are called, which third parties receive the original content, and how long each stop retains it. Checking only the model provider covers only one segment of the flow and can easily miss the place where the data is actually being stored.
Why Do Agents Create a New Safety Problem for Zero Data Retention?
A Single Prompt May Look Harmless, While Risk Becomes Visible Only Across Many Sequential Actions
OpenAI specifically notes in this announcement that existing safety systems compatible with ZDR primarily evaluate each Interaction individually. But as Agents become capable of handling long-running, multi-step tasks, the risky pattern may not appear in any single Prompt. Separate actions can each look completely normal—for example, checking one configuration, asking about a set of permissions, and then requesting access to a certain Credential. Only when many interactions are connected may it become apparent that they form a high-risk sequence.
Agents stretch this problem even further. An Agent may search for data, re-plan, call tools, observe the results, and then decide what to do next, without requiring the user to issue a new instruction at every step. The scenarios OpenAI mentions even include an Agent continuing to take actions after the user has asked it to stop. This type of deviation from the original intent is also easier to detect when the full activity context is available.
The tension therefore becomes very direct: safety systems want a longer Context in order to detect cross-step risk, while enterprises may require sensitive Customer Content not to be retained long-term by the model provider. Private Safety Processing is intended to separate those two requirements.
How Does Private Safety Processing Work? Automated Systems See the Pattern While Personnel Do Not Directly Read the Content
In ZDR Mode, Cross-Interaction Data Can Remain in Customer-Controlled Infrastructure
According to OpenAI’s current public design, Private Safety Processing can operate under different data-storage models. In a ZDR Deployment, Customer Content needed for cross-interaction analysis can remain within customer-controlled Infrastructure, while automated safety systems evaluate related interactions for suspicious patterns rather than first creating a complete conversation record that OpenAI personnel can directly read.
OpenAI is also developing another model in which data is stored in OpenAI-provided Storage but encrypted using Customer-controlled Keys. OpenAI Personnel would not hold those Keys and therefore could not directly access the underlying Customer Content. This direction resembles customer-managed encryption-key designs already common in enterprise infrastructure, but the full technical white paper has not yet been published, so it would be premature to fill in implementation details such as Confidential Computing, TEE architecture, or Key Lifecycle on our own.
The Safety Team Receives a Limited Signal, Not a Summary of the Prompt
When Private Safety Processing detects potentially problematic activity, OpenAI currently describes the output as a narrowly defined safety signal that mainly indicates the category of activity involved, rather than exposing the original Prompt, Response, or a complete summary of the content directly to personnel.
In other words, automated systems can analyze multiple related interactions, while OpenAI Personnel receive only a limited risk signal. The underlying content remains in a customer-controlled environment or protected by encryption keys controlled by the customer. If an Appeal, clarification of legitimate use, or abuse investigation later requires confirmation, the customer can then decide whether to provide the relevant information.
This is the most important aspect of Private Safety Processing. It does not remove safety monitoring; it tries to separate “analyzing the content” from “allowing personnel to directly read the original content.”
Is Private Safety Processing Available Now? It Is Still in Early Testing
Private Safety Processing should not yet be treated as a fully available feature that every OpenAI API customer can simply enable. OpenAI says it is currently testing the system with Early Customers, expects to begin a gradual Rollout in September 2026, and plans to publish a Technical White Paper at the same time.
What can currently be confirmed are several design goals: Private Safety Processing is intended to support safety judgments across multiple interactions, avoid giving OpenAI Personnel direct access to the underlying Customer Content, support Customer-controlled Infrastructure, and eventually support OpenAI Storage protected by Customer-controlled Keys. The final output is designed to be limited Safety Signals.
The critical lower-level questions—including Encryption Architecture, Execution Environment, Key Revocation, Signal Schema, Retention Lifecycle, False Positive handling, and whether third parties can independently verify these boundaries—will need to wait for the technical white paper before they can be assessed properly. Teams conducting procurement or compliance evaluations can therefore treat Private Safety Processing as an Upcoming Capability, but should not use the current announcement as if it were already a formal Security Specification.
What Types of Data Are Best Suited to Zero Data Retention?
Sensitive Data Is a Strong Candidate for ZDR, but “Confidential” Does Not Automatically Mean Every Workflow Needs the Strictest Setting
OpenAI’s announcement lists examples such as Financial Records, Health Data, Confidential Business Plans, and Proprietary Research. The reason these categories care so much about retention is usually not simply that they are “private,” but that they may also be subject to regulation, customer contracts, NDAs, or internal Security Policies.
For example, if a workflow sends unreleased financial statements, health records, customer contracts, or R&D data into an API, the enterprise needs to verify more than whether transmission is encrypted. It also needs to know whether the model provider retains the raw content, how long it is stored, which personnel might be able to access it, whether it is used for training, which features create Application State, and which third-party services receive the data after it leaves the model.
ZDR addresses an important part of that problem, but it is not an automatic compliance button. Different industries, jurisdictions, and contractual obligations impose different requirements on third-party data processing. A more reasonable approach is to classify the data first and then decide which Workflows genuinely require ZDR rather than applying the strictest condition to every project.
ZDR Also Trades Away Some Functional Flexibility
Full ZDR restricts some features that depend on persistent state, so low-sensitivity work such as organizing public information, general Brainstorming, or summarizing already published content does not necessarily need the strictest data controls. A more common enterprise architecture is to place highly sensitive Workflows inside a ZDR Project while using a separate Project and data policy for ordinary content, rather than forcing every workload into zero retention and losing functionality that is genuinely needed.
Zero Data Retention Still Has Exceptions, and Legal Obligations Remain
Even with ZDR, it would be incorrect to assume that content can never be retained under any circumstances. OpenAI specifically notes in this announcement that images suspected of containing Child Sexual Abuse Material may still need to be preserved, sent for human review, and reported as legally required. These obligations do not disappear because a customer uses ZDR.
OpenAI’s API Data Controls also retain mechanisms related to Safety Retention. If the company determines that temporarily changing the normal ZDR eligibility for a particular Customer and Model is reasonably necessary to investigate or prevent Severe Risk Activity, it may do so, but affected customers must be notified in writing in advance.
This is also an important point in enterprise Compliance Review. What matters is not whether the product name contains the word Zero, but the Scope, Exceptions, Notification Process, and the actual endpoints, models, and tools covered by the condition.
The Difference Between OpenAI and Anthropic Is Not Simply Which Company Cares More About Privacy
OpenAI’s announcement is easy to frame as a direct comparison with Anthropic because Anthropic takes a different safety trade-off for high-capability models such as Fable 5 and Mythos 5. Relevant Traffic must be retained for 30 days so the company can detect cross-Request Jailbreaks, Cyber Misuse, and other complex attack patterns, and Anthropic explicitly states that this data is not used to train new Claude Models.
The two companies are actually addressing the same problem but choosing to place the data needed for safety observation in different locations. Anthropic takes the more direct approach of retaining raw Traffic for a period of time so its safety teams can conduct cross-interaction investigations. OpenAI’s Private Safety Processing instead aims to keep Customer Content within customer-controlled environments, or eventually protect it using Customer-controlled Keys, while automated systems return only limited safety signals.
This is not simply “OpenAI prioritizes privacy while Anthropic prioritizes safety.” Both want to detect risks across interactions; they differ in who should hold the raw evidence. There is still not enough public information to conclude which approach will ultimately prove more reliable, especially because OpenAI’s Private Safety Processing has not yet been fully rolled out and the complete White Paper is not expected until September.
After ZDR, the Enterprise’s Own Audit Trail Becomes Even More Important
If the model provider genuinely does not retain complete Customer Content that personnel can directly inspect, the amount of detail that can be reconstructed from the provider side after an incident will naturally differ from an architecture that stores complete Prompt／Response logs. But that does not mean zero retention makes investigation impossible; it means more responsibility shifts back to the enterprise itself.
If an Agent is already interacting with internal data, external Tools, or production workflows, the enterprise should already maintain its own Activity Log—for example, what task the Agent received, which internal data it read, which Tools it called, what information it sent externally, which Records it modified, and which actions received human approval.
ZDR can reduce the amount of sensitive Customer Content held by the provider, but it should not replace the enterprise’s own Observability. In fact, the relationship can be understood in reverse: the less the model provider retains, the more important it becomes for the enterprise to know exactly what its Agent did.
AWS AgentCore Web Search Addresses Another Kind of Agent Boundary
Another relevant example is Amazon Bedrock AgentCore Web Search. AWS now allows Web Search to enforce server-side restrictions on specific Domains. Administrators can decide whether an Agent is allowed to receive results from certain websites, and that restriction is enforced by Infrastructure rather than written into a Prompt as a reminder to the model.
This is a different problem from Private Safety Processing, but the design direction is similar. Rather than telling the model “do not search this website,” the system can simply refuse to return that Domain. Rather than telling safety personnel “do not read the customer’s sensitive Prompt,” the architecture can be designed so Personnel do not possess the Key and cannot access the underlying plaintext.
For Agent systems, controls outside the model are generally easier to verify than a rule written into a Prompt. One important caveat is that AWS documentation currently supports capabilities such as Domain Filtering, but there is not enough evidence to state that a specific publication-date Filter was first introduced on August 19 itself, so that detail should not be forced into the same-day news narrative.
API ZDR Does Not Automatically Apply to the Regular ChatGPT Web App
This is another easy source of confusion in real-world use. The Zero Data Retention discussed by OpenAI here is a Data Retention Control available on the API Platform to eligible organizations. It is not a new setting that ordinary ChatGPT Plus users suddenly received.
The regular ChatGPT product has its own policies for chat history, deletion, model improvement, and data retention. So if someone simply opens the ChatGPT website, uploads a customer contract, and starts chatting, they cannot infer that the conversation is covered by Zero Data Retention just because OpenAI offers ZDR elsewhere.
When sensitive data is involved, the first step is always to identify which product and which Endpoint is actually transmitting the data, and then check the Data Controls that apply to that specific system.
When Enterprises Evaluate AI Data Retention, Start by Checking These Four Things
First: Confirm Whether the Actual Endpoint Is ZDR Eligible
Do not only ask whether the account has ZDR enabled. List every component used in the real Workflow, including Responses, Chat Completions, Files, Vector Stores, Code Interpreter, Background Mode, and Remote MCP. If any stage inherently requires persistent state, the entire flow cannot simply be described as “completely zero retention.”
Second: Identify What Data Remains Besides Prompts and Responses
Account Data, Billing, Usage Statistics, Application State, temporary storage, and legal exceptions all need to be evaluated separately. The useful question is not whether the vendor uses the word Zero, but exactly which categories of data that Zero applies to.
Third: Draw Third-Party Tools into the Same Data Flow
If the Agent calls Google Drive, Notion, a CRM, Web Search, or an external MCP service, each stop may have its own Retention Policy. Enabling ZDR only on the OpenAI side does not mean the entire workflow is zero retention.
Fourth: Wait for the Private Safety Processing White Paper Before Evaluating the Underlying Architecture
Once the September Technical White Paper is available, the details worth checking include how Customer-controlled Keys are managed, which Execution Environment processes the content, what fields a Safety Signal actually contains, how long Signals are retained, how Key Revocation works, and how Forensics are handled after a Critical Incident.
Those details will determine whether enterprises can actually place this mechanism into production far more than a headline promise to “balance Privacy and Safety.”
The Real Innovation in Private Safety Processing Is Separating Safety Signals from Raw Content
What is genuinely new in OpenAI’s announcement is not another statement that API data is not used for training; that principle has existed for some time. The new problem comes from Agents. When a model can execute many steps on its own, checking each Prompt independently may not reveal the full risk. But if the solution is simply to retain every piece of work content at the model provider, it directly conflicts with enterprise requirements for data control.
Private Safety Processing attempts to solve this by allowing Automated Systems to retain cross-Interaction detection capabilities while limiting what OpenAI Personnel can directly access to narrowly defined Safety Signals. The underlying Customer Content remains under customer control or is protected using encryption keys controlled by the customer.
Whether this architecture can preserve both Privacy and sufficient Forensics during real Abuse Investigations is still unanswered. The September White Paper, the actual Rollout, and any future third-party Security Review will be more useful for evaluating that question than the current announcement alone.
But one point is already clear: enterprise evaluation of AI services will no longer be limited to model capability and Token pricing. How long data is retained, who can see it, who controls the encryption keys, which features require persistent state, how much information safety systems can access, and where external Tools send the content will all become formal procurement criteria.
FAQ
No. ZDR primarily prevents eligible Customer Content from entering Abuse Monitoring Logs and limits related Application State on supported ZDR Endpoints. Account, Billing, Usage Statistics, and other System Data may still exist, and different Endpoints and features have their own retention requirements.
Data sent through the OpenAI API is not used to train or improve models by default unless the customer explicitly opts in to sharing it. This policy is separate from Zero Data Retention. Even when data is not used for training, ordinary API usage may still involve Abuse Monitoring Retention.
Not yet. OpenAI says it is currently testing the system with Early Customers and expects to begin a gradual rollout in September 2026 while publishing a Technical White Paper. It is therefore better understood as a publicly announced design direction and upcoming enterprise safety capability rather than a feature that is already universally available.
According to the architecture currently described, OpenAI Personnel do not gain direct access to the underlying Customer Content simply because the safety system is triggered. Automated Systems analyze relevant interactions and produce a limited Safety Signal. If an appeal or investigation later requires more information, the customer can decide whether to provide the relevant content.
Not necessarily. A Remote MCP Server is a third-party service, and once data is sent there, that service’s own Retention Policy applies. OpenAI-side ZDR does not automatically extend to every external SaaS provider, MCP Provider, or other Tool.
Not necessarily. ZDR is especially relevant for high-sensitivity Workflows governed by contractual or data-management requirements, but it can also limit features that require persistent state. A more practical approach is usually to separate Projects and Data Policies based on data sensitivity rather than applying the same setting to every workload.