AIAI Toolbox
Submit a tool
AI PRIVACY

OpenAI API Zero Data Retention: An Implementation Checklist

A practical architecture and validation plan for teams that need OpenAI API prompts and responses excluded from provider retention.

By AI Toolbox Team··11 min read

To implement OpenAI API Zero Data Retention, obtain approval for the correct organization or project, route sensitive workloads only through ZDR-eligible endpoints and capabilities, keep conversation state and operational evidence in customer-controlled systems, and test every tool, file, image, cache, background job, and third-party handoff. ZDR changes provider-side retention; it does not automatically remove data from your application logs, vendors, user devices, or unsupported OpenAI features.

Key takeaways

  • ZDR is an approved API data control, not the default setting or a general ChatGPT privacy mode
  • Endpoint eligibility and application-state behavior matter as much as the organization-level setting
  • Customer systems must provide state, audit evidence, abuse controls, and deletion when OpenAI does not retain content
  • Third-party tools and services keep their own data-handling terms and can break the intended boundary
  • Legal and safety exceptions must be reflected in risk statements rather than hidden behind an absolute no-retention claim
  • Revalidate the architecture whenever OpenAI changes a model, endpoint, tool, cache, or safety-retention rule

Define the promise before choosing the architecture

Start by separating four questions that are often collapsed into one privacy claim: whether customer content is used for model training, whether it enters provider abuse-monitoring logs, whether an API feature stores application state, and whether people can review retained content. OpenAI says API business data is not used to train models by default unless the customer opts in, but default API abuse-monitoring logs may retain customer content for up to 30 days. ZDR is the approval-based control that excludes customer content from those logs and changes behavior for eligible endpoints.

Write the requirement in terms of a specific data flow. Name the project, endpoint, model, input types, tools, output destination, users, jurisdictions, and prohibited storage locations. Then identify what must still be retained by the customer: authorization decisions, operational metrics, safety signals, transaction records, or a sanitized audit trail. A vague requirement such as ‘the AI stores nothing’ is neither testable nor usually accurate.

Distinguish API ZDR from ChatGPT workspace retention. Enterprise workspace administrators can configure conversation retention, but that is a different product and control plane. Likewise, encryption, data residency, a DPA, and a BAA address related requirements without replacing an endpoint-level retention analysis. Use the executed agreement and current platform documentation as the authoritative scope, not a sales slide or an old architecture diagram.

Build an endpoint and feature allowlist

OpenAI's data-controls documentation separates abuse-monitoring retention from application state and publishes eligibility by endpoint. The Responses and Chat Completions APIs can be ZDR eligible, and ZDR forces their store parameter to false. By contrast, provider-managed conversations, vector stores, Assistants objects, files, batches, fine-tuning jobs, and other persistent resources have their own retention behavior or are ineligible. Eligibility also varies for image, audio, video, realtime, and tool capabilities.

Turn that table into a versioned allowlist enforced in code and infrastructure. Pin the organization and project used by the workload, allow approved endpoints and models, reject incompatible flags, and fail closed when a request tries to introduce an unreviewed tool. Do not allow a generic retry client to fall back to a non-ZDR project. Treat model aliases and vendor updates as change events because a familiar API path can acquire different feature or safety requirements over time.

Stateful conveniences require deliberate replacements. If store is false, your application must carry the needed conversation context or keep it in a customer-controlled store. Background mode relies on temporary provider state and is documented as incompatible with ZDR. Extended prompt caching and Code Interpreter also have limitations. A design that depends on these features cannot become compliant merely by toggling the project setting; the workflow, user experience, and failure handling may need to change.

Trace tools, files, images, and every secondary copy

The provider request is only one segment of the data path. Prompts can be copied into API gateway logs, application traces, exception reports, queues, data warehouses, replay systems, browser telemetry, employee support tools, and user-visible history. Responses can flow into email, documents, customer records, or downstream automation. Inventory these copies and apply minimum collection, access control, encryption, retention, deletion, and incident-response rules to each one.

Tool use expands the boundary again. OpenAI explicitly notes that remote MCP servers are third-party services and data sent to them follows their retention policies. Apply the same reasoning to any external search, database, SaaS connector, webhook, or customer-managed function. Define what fields the model may send, use scoped identities, log the authorization result without unnecessarily logging content, and obtain deletion and subprocessors information from the receiving service.

Files and images need route-specific review. Some file resources persist until deletion, while image and file inputs can be subject to safety scanning and documented CSAM retention exceptions. Test preprocessing, upload, retry, moderation, and deletion paths independently. If sensitive documents are converted into extracted text or embeddings before the API call, those derived copies remain sensitive even when the original upload is removed. ZDR is not a substitute for data minimization.

Design customer-controlled state and safety evidence

When OpenAI does not retain prompts and responses, the customer must operate the state it needs. Store only what the workflow genuinely requires, separate content from low-sensitivity operational metadata, encrypt both appropriately, and use short, purpose-based retention periods. Bind records to project, model snapshot, policy version, tool configuration, and authorization result so an investigator can understand system behavior without relying on provider-held transcripts.

OpenAI assigns approved ZDR and Modified Abuse Monitoring customers responsibility for user compliance with usage policies and applicable moderation or reporting requirements. Build abuse detection, rate and spend controls, identity signals, investigation procedures, user appeals, escalation, and legally required reporting into the customer environment. Ensure reviewers have enough evidence to distinguish legitimate work from misuse while limiting access to raw content.

OpenAI's August 2026 Private Safety Processing announcement describes a preview for detecting patterns across related interactions without personnel access to underlying customer content. It says customer-controlled storage is one deployment approach and previews a customer-key option for OpenAI-hosted storage. Treat those statements as a product preview, not a generally available control or completed technical specification. Reassess when the promised white paper and rollout details arrive rather than designing against future behavior as if it already exists.

Test the claim and maintain defensible evidence

Validate configuration in a dedicated non-production project with synthetic content. Exercise ordinary responses, multi-turn state, tool calls, images, files, audio, retries, timeouts, refusals, malformed input, quota failure, failover, and support escalation. Confirm that the application does not request storage, use an ineligible feature, cross into a different project, or expose content in logs. Test deletion and access revocation in every customer-controlled store and vendor that receives data.

Preserve an evidence package containing the approval and contractual scope, project settings, architecture and data-flow diagrams, endpoint allowlist, automated configuration checks, vendor reviews, test results, retention schedules, access reviews, incident exercises, exceptions, and documentation review date. Avoid proving ZDR by searching only one log: absence from an application console does not demonstrate the provider's contractual or internal retention behavior.

Describe exceptions honestly. OpenAI documents legal and safety circumstances that can affect retention, including flagged potential CSAM images and notified Eyes Off or Safety Retention modes for particular customers or models. Wording should match the executed terms and current documentation rather than promise impossibility. This checklist is documentation-based analysis, not hands-on verification of OpenAI systems, legal advice, a privacy impact assessment, or a compliance certification.

Practical checklist

  • Classify each workload's prompts, responses, files, images, metadata, and regulatory constraints
  • Obtain written ZDR approval and record the organization and project configuration in scope
  • Create an allowlist from OpenAI's current endpoint and capability eligibility table
  • Set store to false explicitly and verify that application code does not depend on provider-side response state
  • Replace incompatible conversation, vector-store, file, background, interpreter, or cache features where necessary
  • Map every remote MCP server, web request, connector, logging sink, trace, queue, and support workflow
  • Keep required state encrypted in customer-controlled storage with access, retention, and deletion controls
  • Implement customer-side misuse monitoring, incident handling, appeals evidence, and legally required reporting
  • Test text, audio, image, file, tool, retry, failure, and fallback paths with non-sensitive fixtures
  • Prove project isolation so a ZDR workload cannot silently use a project configured with no retention control
  • Document exceptions, residual metadata, subprocessors, regional behavior, and the exact contractual commitment
  • Schedule recurring review of OpenAI documentation and rerun tests after every architecture change

Warning signs

  • A diagram labels the whole product ZDR even though only one API project has the control enabled
  • The application uses conversations, vector stores, stored files, background mode, or Code Interpreter without an eligibility decision
  • Prompts disappear from OpenAI but remain indefinitely in application logs, traces, support tickets, or analytics
  • A remote tool receives sensitive content but its retention policy and deletion path are unknown
  • Developers can route requests through an unrestricted fallback project when the ZDR path fails
  • Compliance language promises that no data is ever retained without describing documented legal or safety exceptions
  • The team cannot reproduce which endpoint, model, project, tools, and data-control settings handled a request

Frequently asked questions

Does OpenAI API Zero Data Retention apply automatically?

No. OpenAI describes ZDR as an approval-based control for eligible customers. Approved organizations configure it at organization or project level, and projects can inherit, explicitly select, or disable the control.

Does ZDR mean OpenAI never processes the prompt?

No. Processing is necessary to return a response and automated safety systems may evaluate content. ZDR concerns retention of customer content after processing, subject to documented feature limitations and legal or safety exceptions.

Can a ZDR application use the Responses API?

Yes for eligible usage, but ZDR forces store to false. Provider-managed conversations, background mode, Code Interpreter, extended prompt caching, and other stateful capabilities have separate limitations that must be checked in the current data-controls table.

Are remote MCP servers covered by OpenAI ZDR?

No. OpenAI's documentation says remote MCP servers are third-party services. Data sent to them is governed by their own retention and privacy practices, so they need a separate review.

Is ZDR alone enough for HIPAA compliance?

No. OpenAI's Healthcare Addendum limits PHI to eligible services, approved organization IDs, and eligible endpoints and imposes customer responsibilities. A signed BAA, correct implementation, access controls, testing, training, and the customer's broader compliance program are still required.

Primary sources and further reading

Research before you rely.

AI products, prices, policies, and capabilities change. Verify consequential details with primary sources and test tools using representative work.