Enable zero-retention mode for AI content

To enable zero-retention mode for AI content responsibly, start by defining what “zero retention” actually covers. OpenAI describes Zero Data Retention (ZDR) as a promise that eligible API customers’ prompts and model responses are not retained after a request is processed. It also says that customer content under ZDR is not available to OpenAI personnel for review, while enterprise customer data is not used to train models unless the customer explicitly opts in.

That definition is important, but enabling ZDR is not a single-switch privacy strategy. Eligibility, organization and project configuration, endpoint compatibility, application-state behavior, observability, internal logging, and compliance evidence all affect the result. A trustworthy implementation therefore combines OpenAI’s documented controls with disciplined application architecture, data minimization, testing, and ongoing governance.

Understand what Zero Data Retention does,and does not mean

OpenAI’s standard API retention and Zero Data Retention are different policies. Under the default API policy described by OpenAI, API inputs and outputs are removed after 30 days unless the company is legally required to retain them. ZDR is an additional option available to eligible customers and supported endpoints; it is not simply another name for the default 30-day policy.

For approved use cases, ZDR changes how customer content is handled after processing. OpenAI says prompts and model responses are not retained after a request is completed, and the content is not available to its personnel for review. This can materially reduce the amount of customer content held by the model provider.

Operational rule: Treat ZDR as a narrowly defined provider-side retention control, not as proof that the entire AI workflow retains no data anywhere.

Your application may still create copies before or after an API request. Web servers, API gateways, tracing systems, browser storage, content management systems, analytics platforms, support tools, error trackers, backups, and employee devices can all retain AI content independently of the model provider.

For example, an editorial application might send a confidential draft to a ZDR-compatible endpoint but also write the full request to an internal debugging log. The provider-side request could satisfy ZDR while the overall system continues to retain the draft. That would be a failure of architecture and governance, even if the API setting itself were correct.

Separate four concepts that are often confused

• Request processing: The model must process the prompt and generate a response. Zero retention does not mean zero processing.
• Provider retention: ZDR addresses whether OpenAI retains prompts and responses after processing for eligible configurations and compatible features.
• Model training: OpenAI states that enterprise customer data is not used to train models unless the customer explicitly opts in. This is related to privacy, but it is distinct from request-retention duration.
• Application retention: Your own systems and vendors may store source documents, prompts, responses, metadata, or derived content according to separate policies.

This distinction creates a more accurate answer when legal, security, or procurement teams ask whether AI content is retained. Instead of saying “nothing is stored,” document which party processes each data category, where copies can be created, what retention rule applies, and which technical control enforces it.

Confirm that the organization and use case are eligible

OpenAI does not present ZDR as a universal option for every account. Its business privacy information says qualifying organizations can configure retention policies, including a zero data retention policy, through the API platform. Availability is limited to eligible API customers and qualifying use cases.

The first implementation task is therefore an eligibility review, not a production configuration change. Contact the appropriate OpenAI account or support channel and describe the intended workflow accurately. Avoid describing only the lowest-risk example if production traffic will contain more sensitive material or use additional capabilities.

Prepare a clear use-case description

A useful review package should explain the service without sending unnecessary customer content. It can include:

• The purpose of the AI feature and the expected users.
• The categories of content that may appear in prompts, attachments, and responses.
• Whether regulated, confidential, personal, health-related, or proprietary information is in scope.
• The models, API endpoints, tools, and response modes the application expects to use.
• Whether the workflow is synchronous, multi-turn, agentic, or dependent on background processing.
• The projects, environments, and organizational units that require ZDR.
• The internal retention and deletion rules that apply outside OpenAI.

OpenAI’s Healthcare Addendum offers an especially explicit definition of a “Zero Retention API”: customer content is processed without being saved, retained, or logged for human review. That wording can help a healthcare organization understand the intended provider behavior, but it should not be generalized into a claim that every endpoint, account, or healthcare workflow is automatically covered. Contract terms, approval status, and current endpoint documentation remain decisive.

Do not assume account approval makes every feature compatible

OpenAI warns that not every endpoint or capability is compatible with ZDR. Some features can store application state even when an organization has enabled a zero-retention policy. Background mode is a documented example: it is incompatible with ZDR because response data is stored briefly so the application can poll for the result.

This means eligibility must be evaluated at more than one level. An organization may be approved for ZDR while a particular workflow remains unsuitable because it uses an incompatible endpoint or a stateful capability. The safest approach is to maintain an explicit allowlist of approved models, endpoints, modes, and tools rather than assuming the organization setting covers every API operation.

Configure ZDR at the organization and project levels

OpenAI’s platform documentation says approved organizations can choose Zero Data Retention or Modified Abuse Monitoring at the organization level and then configure behavior per project. This hierarchy matters because production applications are often split across projects, environments, business units, or data classifications.

Exact interface labels and available options can change as the platform evolves, so current OpenAI platform documentation should be the source of truth during implementation. The following process focuses on durable control objectives rather than assuming a specific screen layout.

1. Obtain and record approval. Confirm that the correct API organization is eligible for ZDR and that the intended use case is within scope. Store the approval or contractual evidence in the organization’s compliance repository.
2. Inventory organizations and projects. Identify every OpenAI organization and project used by development, testing, staging, production, data science, and support teams. A setting applied to one project should not be presumed to cover another.
3. Choose the organization-level policy. For an approved organization, select the documented Zero Data Retention policy where it is appropriate. Understand the distinction between ZDR and Modified Abuse Monitoring before making the choice.
4. Review each project. Set or verify project-level behavior according to the data handled by that project. High-sensitivity workloads should not share an ambiguously configured project with experiments that have different retention requirements.
5. Map all API operations. List the endpoint, model, tools, modes, file handling, state behavior, and any agentic features used by each application path. Check each item against the current ZDR compatibility documentation.
6. Remove incompatible behavior. Redesign calls that depend on unsupported stateful features. In particular, do not use background mode in a workflow represented as ZDR-compatible while the documentation identifies that mode as incompatible.
7. Restrict credentials and access. Give services access only to the projects and capabilities they need. This reduces the chance that a ZDR workload is silently redirected through an unapproved project.
8. Test configuration in a controlled environment. Verify project identifiers, request paths, error handling, retries, and fallbacks without placing sensitive production content in test logs.
9. Approve the production release. Require privacy, security, engineering, and the relevant data owner to confirm that the documented configuration matches the deployed architecture.
10. Monitor for drift. Recheck the policy when adding a model, endpoint, tool, project, integration, or new class of content.

Project-level design is particularly valuable for enforcing boundaries. A company might isolate a sensitive document-processing service in one approved project while keeping low-risk prototyping in another. Separation makes access review, cost attribution, deployment control, and compliance evidence easier, although it does not replace endpoint-level compatibility checks.

Define a safe failure policy

Configuration errors should fail closed when content requires ZDR. If the approved project is unavailable, an application should not automatically route sensitive prompts to a project with standard retention merely to preserve uptime. Any fallback that changes the retention policy should be treated as a material change and explicitly approved.

The same principle applies to feature fallbacks. If a synchronous request fails, silently switching to background mode would conflict with a ZDR requirement because OpenAI identifies background mode as incompatible. Availability goals should be balanced against the stated privacy commitment rather than overriding it invisibly.

Design the whole AI content path for minimal retention

Provider configuration is only one layer of a zero-retention architecture. To enable zero-retention mode for AI content in a meaningful way, trace content from collection through preprocessing, transmission, response handling, display, and disposal. Every component on that path should have a defined purpose and retention rule.

Minimize content before the API call

Send only the information required to perform the task. If a model needs to classify a paragraph, it may not need the author’s name, full document history, account number, or unrelated attachments. Removing unnecessary fields reduces exposure regardless of the provider’s retention setting.

Where appropriate, applications can replace direct identifiers with internal references before transmission. The mapping should remain in a separately controlled system and should not be included in the prompt. Redaction must be tested against the actual content format because sensitive details can appear in free text, filenames, ers, images, metadata, or quoted conversation history.

Control logs and traces

Many AI frameworks capture prompts and completions to help developers troubleshoot quality. That behavior is useful in a laboratory environment but can undermine a production zero-retention objective. Review HTTP logging, distributed tracing, application performance monitoring, error reporting, analytics, and evaluation pipelines for full request or response capture.

• Log request identifiers, timing, model names, status codes, and token-related operational metadata only when needed.
• Disable capture for sensitive routes.
• Sanitize exception messages and stack-context fields.
• Avoid placing prompt excerpts in alert titles or collaboration tools.
• Apply access controls and deletion rules to the metadata that remains.
• Test whether failed calls, retries, and timeouts produce more verbose logs than successful calls.

Do not claim that all logging disappears. OpenAI states that security and compliance logging can exist outside customer-content retention. Its compliance APIs retain logs for 30 days, and deletion requests are retained internally for no more than 30 days for audit and security purposes. These facts reinforce the need to define precisely whether a statement refers to customer prompts and responses, operational metadata, compliance records, or deletion audit records.

Handle generated content deliberately

ZDR does not prevent your application from saving the model’s response. A content management platform may intentionally store a generated draft, while a transient summarization tool may display a result and discard it. Both designs can use ZDR at the provider, but they have different application-level retention outcomes.

Document whether generated content is temporary, user-controlled, or a formal business record. If it is saved, define its storage location, owner, access policy, retention period, deletion process, and backup treatment. Calling an application “zero retention” would be misleading if the application intentionally stores every response indefinitely.

Account for endpoint state and agentic workflows

Modern AI applications may involve more than a single prompt followed by a single response. Multi-turn interactions, tool calls, reasoning continuity, and agentic processes can depend on state. That state must be evaluated separately rather than assumed to fall under a simple request-response interpretation.

OpenAI has continued ZDR-related product work in 2026. A recent OpenAI post about frontier models says ZDR can support new agentic workflows, including responses that persist reasoning items across turns through encrypted state. OpenAI’s August 19, 2026 announcement also frames new safety systems as “private safety processing” and says they are being previewed while remaining compatible with ZDR.

These developments show that sophisticated workflows and ZDR are not necessarily mutually exclusive. They do not, however, establish universal compatibility for every agent, endpoint, tool, or state mechanism. Teams should verify the specific combination they intend to deploy against current documentation and their approved account configuration.

Ask state-specific questions

• What state is created during the workflow?
• Does the provider, the customer application, or another vendor hold it?
• Is the state customer content, encrypted workflow state, operational metadata, or an application record?
• How long does each component need the state?
• Is the endpoint and mode explicitly documented as ZDR-compatible?
• Does polling require temporary response storage?
• Can the workflow continue without storing full prompts and responses in customer-controlled logs?

Background mode deserves a separate control because its polling design stores response data briefly and is therefore not compatible with ZDR according to OpenAI. A code review should look for explicit background settings as well as wrappers or software development kits that might enable background behavior indirectly.

For agentic workflows that use encrypted state, keep the claim narrow: the cited OpenAI product work says this mechanism can maintain reasoning items across turns when building with ZDR. It does not justify describing every stateful agent as zero retention. Record the supported model, endpoint, state mechanism, project policy, and documentation version reviewed for the release.

Manage the governance and data-sharing trade-offs

OpenAI’s Help Center states that organizations with Zero Data Retention enabled cannot opt in to data sharing. They cannot participate in feedback, evaluation, or fine-tuning data-sharing programs while ZDR is enabled. This is a meaningful governance consequence, not a minor account preference.

Teams accustomed to sending production examples back to a provider for evaluation or improvement need a different quality process. They can still assess their own application, but the dataset, tooling, permissions, and retention rules must be managed within their authorized environment and must comply with applicable contracts and policies.

Build a privacy-aware evaluation process

A practical internal process can use approved test cases that are synthetic, de-identified, or specifically authorized. Human reviewers should see only the content necessary for their role, and evaluation results should have a documented retention period. If real customer examples are required, obtain the appropriate legal basis and internal approval rather than treating ZDR as blanket permission.

The inability to join OpenAI’s feedback, eval, or fine-tuning data-sharing programs should be reflected in technical and product plans. A team should not enable ZDR and simultaneously design an automated export of prompts to a provider data-sharing channel. That would conflict with the documented account restriction and with the privacy objective behind the configuration.

Governance principle: Improving model quality should not silently change the approved destination, purpose, or retention of sensitive content.

Assign ownership for this trade-off. Engineering may operate the API configuration, but privacy should define acceptable data use, security should review controls, legal or compliance should interpret obligations, and product owners should decide whether the feature can meet quality requirements without provider-side data sharing.

Use accurate user-facing language

A privacy notice, sales document, or interface message should avoid absolute claims such as “your data is never stored anywhere.” A more defensible description identifies the boundary: eligible requests are processed through an OpenAI API configuration under which OpenAI does not retain prompts or model responses after processing, while the application’s own storage practices are described separately.

Any public claim must match the actual production route. If some projects use standard API retention, some endpoints are incompatible, or generated drafts are saved in the customer’s account, explain those distinctions. Trust comes from precise boundaries, not from compressing multiple policies into a broad marketing promise.

Validate the deployment and preserve evidence

Privacy controls require evidence. A configuration screenshot alone is not enough because it does not prove that production traffic uses the intended organization, project, and compatible endpoint. Conversely, application tests alone do not prove that the provider approved and configured the account for ZDR.

Build an evidence package that combines administrative, architectural, and operational records. Keep it free of unnecessary prompt content.

1. Approval evidence: Retain the applicable OpenAI confirmation, account documentation, contract material, or other authoritative record showing ZDR eligibility.
2. Configuration evidence: Record the organization policy and relevant per-project behavior. Include the date of review and responsible owner.
3. Compatibility evidence: Identify the documentation used to confirm that each model, endpoint, mode, and capability supports ZDR.
4. Architecture evidence: Maintain a data-flow diagram covering user input, preprocessing, API transmission, response handling, internal storage, observability, and deletion.
5. Code evidence: Review how the application chooses project credentials, endpoints, request modes, tools, retries, and fallbacks.
6. Logging evidence: Demonstrate that sensitive request and response bodies are not copied into unapproved logs, traces, alerts, or evaluation systems.
7. Test evidence: Use non-sensitive markers to check application-controlled storage locations and verify expected routing without claiming access to provider systems you cannot inspect.
8. Release evidence: Record sign-off by the designated engineering, security, privacy, and data owners.

Test negative paths, not only successful requests

Privacy failures often appear during exceptions. Simulate authorization failures, rate limits, endpoint errors, network timeouts, parsing failures, and unavailable dependencies with non-sensitive inputs. Check whether debugging middleware captures bodies or whether the system routes requests to a non-ZDR fallback.

Also test project separation. A service intended for a ZDR project should reject credentials or configuration belonging to an unapproved environment. Deployment templates can validate project identifiers, while change-management controls can require review when those identifiers are modified.

Be honest about what can be verified

Customers generally cannot inspect a provider’s internal storage directly. Assurance therefore depends on documented provider commitments, applicable agreements, account configuration, compatibility documentation, and the customer’s own technical controls. Do not present a client-side test as proof of every internal provider process.

OpenAI links ZDR with broader enterprise privacy and compliance controls, including encryption, retention controls, and data residency options for qualifying organizations. These controls can contribute to a compliance program, but none should be treated as automatic certification that a particular application meets every legal requirement.

Integrate ZDR into compliance and ongoing operations

ZDR can reduce provider-side content retention and support data-minimization objectives. Compliance still depends on context: the type of data, applicable law, contractual commitments, user expectations, organizational role, location, security measures, and the behavior of every processor or subprocessor in the workflow.

A defensible control statement should be specific. It might say that an approved OpenAI API organization uses ZDR for listed projects and compatible endpoints, while internal content storage follows a separate schedule. It should also disclose relevant exclusions, such as background mode, application records, or operational audit information.

Maintain a living control record

• Name the business and technical owners.
• List approved organizations, projects, models, endpoints, and capabilities.
• Record prohibited modes, including background mode where ZDR is required.
• Describe internal logging and response-storage rules.
• Document the restriction on OpenAI feedback, evaluation, and fine-tuning data sharing.
• Reference the provider documentation and agreements reviewed.
• Set review triggers for product changes, not just a calendar review.

Useful review triggers include adopting a new frontier model, adding tools, enabling multi-turn state, changing an SDK, creating a project, modifying observability, introducing a fallback, or expanding into a new data category. OpenAI’s 2026 work on encrypted state and private safety processing illustrates why controls must evolve as supported workflows change.

Incident response should also distinguish provider retention from customer-side leakage. If prompts appear in an internal trace, disabling that trace and deleting unauthorized copies may be the immediate priority even when OpenAI ZDR remains correctly configured. If traffic was routed through an incompatible mode or wrong project, pause the affected path, preserve non-content evidence where possible, assess scope, and follow the organization’s incident and notification procedures.

Use precise audit language

Auditors and customers may ask whether “logs” exist. OpenAI’s statements require a nuanced response: ZDR concerns prompts and model responses after processing and their availability for human review, while certain security, compliance, deletion, or audit records can have separate treatment. OpenAI says its compliance API logs are retained for 30 days, and deletion requests are kept internally for no more than 30 days for security and audit purposes.

Precision strengthens rather than weakens the control narrative. It shows that the organization has examined different data categories instead of relying on an undefined promise. The same discipline should be applied to encryption and data residency: describe the controls actually enabled, their scope, and any eligibility or product limitations.

Create a practical production checklist

Before releasing an AI content workflow under a zero-retention claim, conduct a final review that connects policy to deployed behavior. The checklist should be owned, repeatable, and tied to release management.

• OpenAI has confirmed that the organization and use case are eligible for ZDR.
• The correct organization-level retention policy is configured.
• Every production project has been reviewed independently.
• Each model, endpoint, tool, mode, and state mechanism is documented as compatible.
• Background mode is not used where ZDR is required.
• Credentials cannot silently redirect traffic to a standard-retention project.
• Fallbacks fail closed instead of weakening the retention policy.
• Prompts and responses are excluded from unnecessary application logs and traces.
• Generated content stored by the application has an explicit business purpose and retention rule.
• OpenAI data-sharing options for feedback, evals, and fine-tuning are not treated as available to the ZDR organization.
• User-facing and contractual language accurately states the provider and application boundaries.
• Evidence is preserved without retaining sensitive content merely to prove that retention was minimized.
• A change in models, endpoints, SDK behavior, tools, projects, or workflow state triggers a new review.

No checklist can replace current documentation. Platform capabilities evolve, as shown by OpenAI’s 2026 ZDR-compatible work involving agentic workflows, encrypted state, and private safety processing. Revalidate compatibility before adoption rather than assuming that a new feature inherits the policy behavior of an older endpoint.

It is equally important not to overstate what the checklist delivers. It can support implementation assurance and identify common gaps, but legal compliance and contractual suitability require review by qualified professionals who understand the organization’s data, jurisdiction, industry, and obligations.

To enable zero-retention mode for AI content successfully, combine OpenAI approval, organization and project configuration, endpoint compatibility checks, minimal data collection, controlled logging, safe fallbacks, and documented verification. ZDR can provide a strong provider-side privacy control for eligible API customers, but its scope should remain clear: it addresses retention of prompts and model responses under supported conditions, not every copy created across an application ecosystem.

The most trustworthy implementation is one that can explain its boundaries without relying on absolutes. Confirm current OpenAI documentation, isolate approved workloads, avoid incompatible features such as background mode, account for separate security and compliance records, and reassess the design whenever the workflow changes. That approach turns a retention setting into an auditable privacy practice rather than a marketing label.