OpenAI Zero Data Retention Explained: Can Frontier AI Keep Business Data Private?

Companies want more capable AI, but the most useful prompts often contain the information they are least willing to expose: customer records, financial documents, medical notes, source code, legal strategy, product plans, and internal research. As AI systems move from answering one question to completing long, multi-step tasks, privacy becomes harder. A single response may be easy to process without storage. An agent that works across many interactions needs context, tool access, and safety monitoring.
OpenAI's answer for eligible API customers is Zero Data Retention, usually shortened to ZDR. In August 2026, the company reaffirmed that it intended to keep ZDR available for frontier models and previewed a new design called Private Safety Processing. The aim is to detect dangerous patterns across related interactions without giving OpenAI personnel access to the underlying customer content.
The headline sounds simple: prompts and responses are not retained after processing. The implementation is more complicated. ZDR is not the default for every account. It requires eligibility and approval. Some endpoints and features are compatible, while others store application state or are ineligible. Third-party tools have their own data rules. Certain legal and safety exceptions still apply.
This guide separates the promise from the fine print. It explains how OpenAI describes ZDR, how Private Safety Processing is expected to work, what `store: false` does, and what businesses must design around even after ZDR is enabled.

The Key Takeaways
OpenAI ZDR is an approved data control for eligible API organizations or projects; it is not automatically enabled for all API or ChatGPT users.
ZDR excludes eligible customer content from abuse-monitoring logs and forces supported Responses and Chat Completions requests to behave as if storage is disabled.
Turning `store` off creates a stateless request pattern but does not by itself enroll an organization in ZDR.
Endpoint behavior matters. Some stateful APIs and features remain ineligible or may store application state.
OpenAI is previewing Private Safety Processing to find risk patterns across interactions while keeping content inaccessible to OpenAI personnel.
Third-party MCP servers, connected services, and external tools can retain data under their own policies.
A ZDR contract is one layer of privacy; secure application architecture, access control, logging discipline, and data minimization are still required.

What Is Zero Data Retention?
OpenAI describes Zero Data Retention as a control for eligible API customers under which customer content is excluded from abuse-monitoring logs. For supported endpoints, prompts and model responses are not retained after the request is processed for normal service operation. OpenAI's August announcement also says customer content is not available to OpenAI personnel for review, subject to stated legal and safety exceptions.
The official API data-controls documentation adds operational detail. By default, OpenAI may generate abuse-monitoring logs containing prompts, responses, and derived metadata, and retain them for up to 30 days unless a longer period is legally required or reasonably necessary for protection. Approved customers can seek Zero Data Retention or Modified Abuse Monitoring controls. ZDR goes further by also changing how supported endpoints handle application state.
For the Responses API and Chat Completions, ZDR forces the `store` parameter to be treated as false even if a request tries to set it to true. This prevents an application from accidentally creating ordinary stored response state through those compatible endpoints. However, features that are not ZDR-eligible can still store application state.
ZDR should therefore be understood as a defined configuration across an organization or project, model, endpoint, and feature set. It is not a magic word that erases every copy of data throughout an application's wider supply chain.

ZDR Is Not the Same as "Your Data Is Not Used for Training"
Two promises are often mixed together. The first is whether API data is used to train or improve models. OpenAI's documentation says API data is not used for training by default unless the customer explicitly opts in. The second is how long content is retained for abuse monitoring or application functionality.
A provider can promise not to train on customer content and still retain logs temporarily for security, debugging, legal, or service reasons. Conversely, a stateless request can be processed without becoming training data. Businesses must read both policies separately.
ZDR is mainly about retention and access controls for eligible usage. It reduces the presence of customer content in provider-side logs and state. The no-training default is related but distinct.
This distinction also matters when comparing consumer ChatGPT, enterprise ChatGPT, ChatGPT Work, and the API. They are different products with different administrative controls. A company should not assume that a setting described for an API organization automatically applies to every employee's personal ChatGPT account.
Product-specific protections can also serve very different purposes. For example, our guide to ChatGPT for Teens and its safety controls covers age-appropriate behavior, parental tools, and learning features. Those controls should not be confused with an enterprise API retention policy.

Who Can Get ZDR?
OpenAI's documentation describes ZDR and Modified Abuse Monitoring as controls subject to prior approval and additional requirements. Approved customers can configure them at the organization or project level. The company directs interested organizations to its sales process to discuss eligibility.
That means a developer cannot create an ordinary API key, add `"zdr": true` to a request, and receive the full contractual and technical control. Enrollment is associated with the API organization or project. Administrators then need to configure the correct retention policy and ensure workloads use the approved project.
Organizations with regulated or highly sensitive data should confirm the exact scope in writing. Which endpoints are approved? Which models are eligible? Does a regional-processing requirement apply? Are image, file, web-search, code-execution, or third-party tools included? What happens during a severe-risk investigation? The answers can differ across configurations and can change as products evolve.

What `store: false` Really Does
OpenAI's Responses API can preserve response state to support later calls. Setting `store: false` tells the service not to create that normal stored response object. This is useful for stateless workflows, and OpenAI documentation provides techniques such as encrypted reasoning items to continue certain reasoning tasks without ordinary server-side state.
But `store: false` is not the same as ZDR. Without an approved ZDR policy, abuse-monitoring logs may still be generated and retained under the default period. Some features can also create temporary application state for their own operation.
Think of `store: false` as an application instruction and ZDR as an approved organizational data-control regime. A strong privacy design may need both: the organization is enrolled in ZDR, and the application uses only compatible endpoints and avoids stateful features that conflict with the requirement.
The distinction is easy to miss because both produce a stateless-looking API call. Compliance teams should verify the account configuration rather than relying only on code review.

Why Frontier AI Makes Retention Harder
Older AI workflows were often independent: send one prompt, receive one response, finish. A frontier agent may plan for an hour, call tools, create files, inspect results, revise its strategy, and continue across many interactions. The user's intent may not be visible in any one message.
That creates a safety challenge. A sequence of individually harmless-looking requests might form a dangerous operation when combined. An attacker might gradually probe restrictions, distribute actions across accounts, or disguise a harmful objective as routine research. An agent might also continue beyond the user's authority after a stop instruction.
Traditional ZDR-compatible monitoring that evaluates each interaction separately can miss this pattern. Retaining every conversation for human investigation would improve context but conflict with privacy promises. Private Safety Processing is OpenAI's proposed way to reduce that tension.
The issue connects directly to the rise of autonomous systems described in our guide to what AI agents can actually do in 2026. The more authority an agent receives, the more important both cross-step safety and strict data governance become.

How Private Safety Processing Is Designed to Work
OpenAI says Private Safety Processing extends automated protection across related interactions without providing OpenAI personnel access to the content. The design is currently a preview being tested with early customers, not a reason to assume every feature is already generally available.
The company describes two possible storage arrangements. In a ZDR deployment, customer content can remain on infrastructure controlled by the customer. OpenAI is also developing an option in which content is stored on OpenAI infrastructure but encrypted with keys controlled by the customer. OpenAI personnel would not hold those keys and therefore could not read the underlying prompts or responses.
Automated systems can process the content to identify patterns of misuse or agent misalignment. If a risk is detected, OpenAI receives a narrowly defined signal describing the type of activity rather than the raw content. That signal can inform an enforcement decision.
The customer retains information in its own systems and can investigate an alert. If the customer believes an action was legitimate or wants to appeal, it can choose to share relevant evidence with OpenAI. The architecture attempts to keep the content under customer control while preserving a mechanism for platform safety.

Privacy Without Blindness
Private Safety Processing reflects a broader security principle: a system can reveal a limited fact without exposing the underlying record. A fraud engine might report that a payment pattern is suspicious without sharing every purchase. A confidential-computing system can process encrypted or isolated data and release only an approved result.
The quality of the design depends on technical details that OpenAI says it will explain further. What can the automated processor access? How are customer-held keys managed? What metadata exists outside the encrypted content? How are false positives handled? Can signals be linked across accounts? How can an auditor verify that personnel cannot access the data?
Until the technical white paper and rollout details are available, businesses should treat Private Safety Processing as a promising architecture under evaluation. The August announcement establishes the intended privacy model, not every implementation guarantee.

Where Data Can Still Be Stored
Stateful Endpoints
OpenAI's data-control table lists endpoints such as Conversations, ChatKit threads, Assistants, Threads, vector stores, files, batches, fine-tuning jobs, and evals with application state that can persist until deletion or under service-specific rules. Many are not marked as ZDR eligible.
If an application requires strict ZDR, the architecture may need to avoid those features and store necessary state inside the customer's own environment. A team cannot select a stateful feature and assume the organization-level ZDR flag removes data that the feature needs in order to function.

Background Processing
The Responses API documentation says background mode stores response data to disk for roughly ten minutes so the application can poll for completion. That temporary state may conflict with a customer's strict interpretation of zero retention, even though it is short-lived. Confirm whether the feature is allowed in the approved configuration.

Audio
Certain audio outputs can retain application state for about one hour to support multi-turn conversation. Voice features therefore require their own review.

Files and Images
File objects may remain until deleted or until an expiration policy removes them. Image and file inputs can also be scanned for child sexual abuse material. OpenAI states that images flagged as potential CSAM may be retained for human review and legally required reporting even when ZDR or other controls are enabled.

Video
OpenAI's current documentation describes the Videos API as storing data during processing and retaining outputs for a limited download period plus abuse monitoring. It is listed as blocked for ZDR or Modified Abuse Monitoring requests unless a project is configured without those controls. Product eligibility can change, so verify the current table.

Third-Party Tools Are a Separate Boundary
An OpenAI request can call an MCP server or other external service. The data sent to that service is subject to the third party's retention and residency policy. OpenAI ZDR does not force an independent provider to delete its logs.
This is one of the most important practical limitations. A company may carefully configure the OpenAI API and then send the entire prompt to a search provider, CRM, payment system, observability vendor, or custom MCP service that keeps data indefinitely. The privacy chain is only as strong as every participant.
Our guide to Google's A2A protocol and MCP explains why agent interoperability is growing quickly. Each tool connection should be treated as a data transfer with its own purpose, minimum necessary fields, authentication, audit log, and deletion rule.
For sensitive workflows, send the smallest possible subset. A scheduling tool may need a date and duration, not the confidential document that produced the request. A retrieval system may return a relevant passage without exposing an entire archive to the model.

What ZDR Does Not Protect
ZDR cannot protect data that the customer's own application logs. Development teams often print full prompts and responses to debugging systems. Observability platforms, error trackers, analytics tools, reverse proxies, and support tickets can create copies outside the model provider.
It cannot protect an API key stored in public code or a misconfigured database. It cannot prevent an authorized employee from exporting data they are allowed to access. It cannot fix an application that sends unnecessary personal information to a model.
It also does not make AI output correct. A model can hallucinate, misclassify, or make an unsafe recommendation even when the prompt is processed privately. Privacy, security, reliability, and fairness are separate quality dimensions.
Finally, ZDR does not automatically satisfy every law or industry rule. Compliance depends on purpose, contracts, location, access, security controls, retention across all vendors, and the nature of the data. Organizations should obtain qualified legal and security advice for regulated deployments.

A Practical ZDR Architecture
Keep State in Customer-Controlled Systems
Store conversation history, workflow status, and documents inside the organization's approved database. Send only the context required for the current model call. If later steps need the history, retrieve and minimize it inside the customer environment.

Use Approved Projects and Keys
Separate production from experiments. Restrict ZDR-enabled project keys to approved services. Do not let developers silently route sensitive workloads through a personal or non-approved account.

Minimize Before Sending
Remove fields the model does not need. Replace names with internal identifiers when possible. Summarize long records. Redact secrets, payment data, and unrelated personal information.

Restrict Tools
Allow only the tools required for the task. Give each tool narrow permissions and short-lived credentials. Review every third party's retention policy. Keep irreversible actions behind deterministic checks and human approval.

Control Logs
Disable raw prompt logging in application and infrastructure layers unless there is a documented, approved reason. Redact sensitive values from errors. Set deletion periods for operational metadata.

Test the Exact Configuration
Confirm that the selected model, endpoint, tool, processing region, and feature are eligible. Product names alone are not sufficient. A ZDR-compatible model can become part of a non-compliant workflow when combined with an ineligible feature.

How ZDR Changes Enterprise AI Adoption
For many organizations, the barrier to frontier AI is not model quality; it is the inability to explain where sensitive data goes. A useful legal assistant needs documents. A healthcare workflow needs patient context. A finance agent needs records. If the provider retains that content in ordinary logs, the risk may outweigh the benefit.
ZDR gives security teams a more credible architecture for approved workloads. Private Safety Processing could preserve access to increasingly capable models without requiring customers to surrender readable content for cross-interaction safety monitoring.
The business value is significant. Companies can use better models for complex work while keeping the source material under tighter control. The deployment may still require more engineering because state, monitoring, and evidence must be managed inside customer systems.
Enterprise examples such as how NVIDIA uses ChatGPT Work to save 16 hours per week show why organizations want AI connected to real workflows. The more valuable the context, the more important it is to distinguish product convenience from verified data governance.

ZDR and Frontier Models
OpenAI's announcement is notable because some advanced-model deployments in the industry have required content retention for stronger safety monitoring. OpenAI is arguing that privacy and safety can advance together through automated processing and customer control.
Frontier capability makes the problem urgent. A strong model may recognize sensitive patterns, infer trade secrets from partial information, or use tools across a long task. Organizations need the best available reasoning but cannot accept undefined human access to the input.
OpenAI is also pushing the same model family toward lower cost and higher throughput. Our article on GPT-5.6 Sol, Luna access, and the tradeoffs users can miss explains the capability side of that change. ZDR addresses a different part of enterprise adoption: whether valuable context can be processed under acceptable data controls.
The same model family can also be used in very different environments. Our GPT-5.6 vs Gemini 3.7 Flash vs Claude Opus 5 comparison focuses on capability and product fit. Enterprise selection must add data retention, residency, tool boundaries, auditability, and contract terms to the comparison.

Modified Abuse Monitoring vs ZDR
OpenAI also offers Modified Abuse Monitoring for approved customers. Both controls can exclude customer content from ordinary abuse-monitoring logs, subject to limitations. ZDR additionally changes supported endpoint behavior so normal application state is not retained for eligible calls.
Modified Abuse Monitoring may be appropriate when a customer needs more platform features that create state, while ZDR is stricter and can limit compatibility. The right choice depends on the workload and risk model.
Do not infer the difference from the names alone. Review the current endpoint table, the account approval, and the product contract. Ask which capabilities will be disabled or changed under each setting.

Safety and Legal Exceptions
No serious privacy analysis should hide exceptions. OpenAI says it may make particular models ineligible for ZDR or Modified Abuse Monitoring for specific customers when necessary to investigate or prevent severe-risk activity, with notice under the relevant terms. In those cases, flagged content may be retained and reviewed.
The company also notes legally required handling of apparent child sexual abuse material. Potentially matching images can be retained for manual review and reporting even under ZDR.
These exceptions do not make ZDR meaningless. They define the boundary of the promise. Organizations should document them, assess whether they are acceptable, and avoid telling employees or customers that no data can ever be retained under any circumstance.

Questions Buyers Should Ask OpenAI and Their Own Team
Ask OpenAI which models and endpoints are approved for the organization today. Ask whether the requested region supports storage and processing requirements. Ask how Private Safety Processing changes the existing ZDR contract when it becomes available.
Ask the internal engineering team where prompts are constructed, logged, cached, and observed. Ask which tools receive content. Ask how state is stored and deleted. Ask who can use the production key and what prevents an experiment from accessing sensitive data.
Ask the business owner why each category of data is necessary. A model should not receive an entire customer record simply because it is convenient. Data minimization reduces legal and security risk while often improving model focus.
Ask the incident-response team how credentials can be revoked, how an agent can be stopped, and how an investigation can proceed without raw provider logs. Privacy controls change the evidence available after a failure, so customer-side audit design becomes more important.

Final Thoughts
OpenAI Zero Data Retention is a meaningful option for eligible API customers, but it is not a universal privacy switch. It changes how supported endpoints handle customer content and can keep prompts and responses out of ordinary provider-side logs and state. The exact protection depends on enrollment, project configuration, endpoint eligibility, features, and exceptions.
Private Safety Processing is an ambitious attempt to solve a real tension. Advanced agents need cross-interaction safety signals, while sensitive organizations cannot allow provider personnel to read their data. Processing content under customer control or customer-held encryption keys and returning only limited safety signals could offer a better balance.
The responsible approach is to combine ZDR with strong application design. Keep state under customer control, minimize context, restrict tools, control logs, review every third party, and verify the current official endpoint table. Privacy is not achieved by one vendor setting. It is achieved by the complete path the data takes.

Frequently Asked Questions

Is OpenAI ZDR enabled for everyone?
No. OpenAI describes Zero Data Retention as an approved control for eligible API customers subject to additional requirements. It must be configured for the relevant organization or project.

Does `store: false` enable ZDR?
No. It prevents ordinary stored response state for that request pattern, but full ZDR depends on the organization's approved data-control configuration. Default abuse-monitoring retention may still apply without ZDR.

Does OpenAI train models on API data?
OpenAI documentation says API data is not used for training by default unless the customer explicitly opts in. This is separate from retention for monitoring or application state.

Are MCP tools covered by OpenAI ZDR?
Data sent from OpenAI to a third-party MCP server is subject to that server's policies. The OpenAI-side request may be ZDR-compatible while the external service retains its copy.

Can files be used in a ZDR workflow?
Compatibility depends on how files are supplied and which endpoint or file object is used. Persistent file objects may be ineligible, and image or file inputs have stated safety exceptions. Verify the current data-control table for the exact workflow.

What is Private Safety Processing?
It is an OpenAI preview designed to detect risk patterns across related interactions without providing OpenAI personnel access to the underlying content. The company describes customer-controlled storage or encryption keys and limited safety signals.

Does ZDR guarantee legal compliance?
No. Compliance depends on the whole system, contracts, jurisdictions, purpose, access, security, third parties, and the type of data. ZDR can support a compliance program but does not replace it.