TL;DR: Zero data retention ensures that AI providers like OpenAI delete your inputs and outputs in real time after processing, eliminating the default 30-day storage window that would otherwise persist even when data is no longer visible in the user interface. But ZDR only addresses what happens after data arrives at the provider. To fully secure AI workflows, organizations need an additional layer: a browser extension or MCP gateway that prevents sensitive data from reaching the provider in the first place.
Every time an employee pastes customer data into an AI prompt, a question follows: Where does that data go, and how long does it stay there? Zero data retention, the principle that AI providers process your inputs without storing them, has become a baseline expectation for organizations feeding sensitive information into large language models.
Here's what most security leaders discover the hard way: OpenAI zero data retention is a necessary control, but it's neither easy to obtain nor fully within your control. ZDR isn't a setting you switch on, it's approval-gated and limited to eligible endpoints, so most organizations never get it and stay on OpenAI's default retention. And even when you have it, a retention policy only governs what happens after data reaches the model; it does nothing to stop sensitive information from being sent there in the first place. This article breaks down how zero data retention OpenAI policies actually work, what they cover and miss, how hard they are to secure in practice, and how to close the gap between a vendor's retention promise and your organization's real data exposure risk.
{{banner-large="/banners"}}
What Is Zero Data Retention and Why Does It Matter?
Before getting into OpenAI's specific implementation, it's worth understanding what zero data retention actually means at a technical level and why it's become a priority for security teams evaluating AI providers.
How Zero Data Retention Works Technically
Zero data retention is a commitment from an AI provider that your inputs (prompts, files, conversation context) are not stored after the model generates a response. The data enters the system, gets processed in memory, and is discarded once the output is returned. No logs, no copies, no training data extraction.
Zero data retention means the provider processes your request in memory and discards all input and output data immediately after inference, with no persistent storage at any layer.
In practice, the implementation varies between providers. Some treat in-memory prompt caching (used to reduce latency on repeated inputs) as separate from “retention." OpenRouter's ZDR documentation, for instance, explicitly states that implicit in-memory caching is not considered data retention under their policy. Others draw the line differently. This distinction matters because it determines whether your sensitive data could theoretically be reconstructed from cache, even if the provider claims zero retention.
There's also the question of scope. A zero data retention policy might cover inference inputs but not metadata like timestamps, token counts, or user identifiers. It might apply to one API endpoint but not another. These nuances are exactly where compliance risks hide, and they're worth scrutinizing before you sign off on any provider. Organizations that need to understand how sensitive data flows across their AI tools can benefit from platforms focused on AI security and governance to close those gaps.
Why Security Leaders Are Paying Attention to ZDR
When employees paste customer records, source code, or internal financials into AI tools, that data leaves your perimeter. If the provider retains it, even temporarily, you've created an exposure surface you can't control, audit, or remediate.
Regulatory pressure is accelerating this concern. Article 5 of the GDPR requires that personal data be “kept in a form which permits identification of data subjects for no longer than is necessary." Sending PII to an AI provider that stores prompts for 30 days directly conflicts with that storage limitation principle. The requirements are even stricter for organizations handling PHI or PCI data. Having strong data privacy and compliance monitoring in place becomes essential when AI tools are part of your workflows.
Then there's the training risk, and it's worth being precise about how it works. On OpenAI, excluding your data from model training is a setting available on all enterprise accounts, independent of whether you have ZDR. Training exclusion and data retention are two separate controls: one governs whether your data trains the model, the other governs whether it's stored. Security leaders who conflate “we don't train on your data" with “we don't store your data" are leaving a real gap in their risk assessment. Make sure you're reading the fine print on both fronts.
OpenAI Zero Data Retention: How the API Policy Works
Now that we've covered what zero data retention means conceptually, let's get specific about OpenAI's implementation. When most security teams say “we use OpenAI ZDR," they're often referring to a policy they haven't fully read. And the gaps matter more than you'd think.
What OpenAI ZDR Covers (and What It Doesn't)
OpenAI's zero data retention policy applies to eligible API endpoints. When ZDR is enabled, OpenAI commits to not storing your API inputs or outputs after processing. The details underneath that are where things get interesting for security teams.
First, OpenAI ZDR applies specifically to the API, not to ChatGPT consumer or Team plans. If your employees are using ChatGPT through a browser, the ZDR API policy doesn't protect those conversations. Second, even with zero data retention enabled, OpenAI may still retain certain metadata and abuse-monitoring data for a limited window to comply with legal obligations and safety requirements. This is a legal necessity, but it does mean that “zero retention" isn't absolutely zero in every sense of the word.
A comparative study published on arXiv examining zero data retention across enterprise AI assistants found that both consuming applications (like Salesforce AgentForce and Microsoft Copilot) and LLM providers (OpenAI, Anthropic, Meta) implement ZDR with distinct architectural and compliance trade-offs. The takeaway is that ZDR isn't a universal standard. It's a vendor-specific implementation with real variation in scope and enforcement.
Here's a breakdown of what falls under OpenAI's ZDR umbrella and what doesn't, so your compliance and security teams can plan accordingly:
- Covered: API prompt and completion data and model training exclusion.
- Not covered: ChatGPT browser sessions (separate policy), abuse monitoring metadata (may be retained temporarily for safety/compliance), and data sent before ZDR was enabled.
{{cs-1="/banners"}}
How to Enable Zero Data Retention on OpenAI
Enabling OpenAI ZDR is tied to your API agreement and organization settings. Here's how the process typically works:
- Qualify for an eligible API plan. Zero data retention is available on OpenAI's enterprise API tier. You'll need to be on an API usage agreement that explicitly includes ZDR terms. This isn't available on free-tier or standard pay-as-you-go accounts by default.
- Configure your organization settings. Once eligible, you request ZDR through your OpenAI account settings or sales contact. OpenAI applies the policy at the organization level, so all API calls from that org inherit the retention configuration.
- Verify endpoint coverage. Confirm which endpoints are covered. Not every API surface falls under ZDR. Image generation, fine-tuning, and file upload endpoints can have different retention rules than chat completions.
- Document the policy for your compliance team. OpenAI provides data processing agreements and documentation you can use for audit trails. Keep these alongside your vendor risk assessments.
Enabling OpenAI ZDR is a necessary step, but it only governs what happens after your data reaches OpenAI's infrastructure. It cannot prevent sensitive data from being sent in the first place. The harder truth is that most organizations never clear the approval bar at all, leaving them on the default retention window.
That distinction is critical. OpenAI zero data retention protects you from storage risk at the provider layer, but if an engineer pastes a production database dump into an API call, the damage isn't about retention, it's about exposure. This is exactly why organizations need data security posture management that catches sensitive data before it ever reaches a third-party API. The retention policy at the destination is your second line of defense, and one you may not even be able to secure. Your first line should be making sure that data never leaves in the first place.
Why Compliance Teams Require Zero Data Retention for AI
Security leaders might understand the technical merits of zero data retention, but it's your compliance team that will ultimately decide whether a given AI vendor is acceptable. Their concerns are tied to specific regulations, audit requirements, and the very real financial consequences of getting it wrong.
The Regulatory Frameworks Driving ZDR Adoption
Several regulatory frameworks either explicitly or implicitly demand controls over how long third parties retain your data. GDPR's storage limitation principle (which we covered earlier) is the most cited, but it's far from the only one. HIPAA requires covered entities to ensure that business associates, including AI providers processing PHI, have appropriate safeguards around data retention and disposal. PCI DSS mandates that cardholder data not be stored beyond business necessity. And newer state-level privacy laws like the CPRA give consumers the right to limit how their personal information is used, which creates downstream obligations for any vendor in your data supply chain.
The common thread across all of these frameworks is the expectation that you demonstrate control over where sensitive data lives and how long it persists. When your organization sends data to an AI provider that retains prompts for 30 days, you've effectively extended your data footprint into an environment you don't own. That's a finding waiting to happen in your next SOC 2 audit or regulatory examination. Understanding how to discover and classify all of your data across these environments becomes a critical first step in maintaining that control.
Evaluating AI Vendors Through a Data Retention Lens
Not every vendor that claims “we don't store your data" means the same thing. Compliance teams need a structured way to evaluate these claims and separate genuine zero data retention commitments from marketing language. Here's a practical framework for assessing any AI vendor's data retention practices before onboarding them:
- Request the vendor's data processing agreement (DPA): Look for explicit language on retention periods, deletion timelines, and whether the commitment applies to all data types. That means not just inference inputs but also metadata, logs, and cached content.
- Distinguish between retention and training exclusions: A vendor may promise not to train on your data while still retaining it for abuse monitoring or quality assurance. These are separate commitments, and your DPA should address both independently.
- Map endpoint-level coverage: As we saw with OpenAI ZDR, retention policies can vary by API endpoint. Document which services are covered and flag any that fall outside the zero data retention commitment.
- Verify audit and certification evidence: Ask for SOC 2 Type II reports, ISO 27001 certifications, or third-party attestations that validate the vendor's retention claims. Self-reported policies without independent verification carry limited weight during regulatory audits.
- Establish an ongoing review cadence: Vendor policies change. Build a quarterly or semi-annual review into your data access governance program so retention commitments stay current.
ZDR Alone Isn't Enough: Protecting Sensitive Data Before It Reaches AI
OpenAI zero data retention addresses one side of the equation: what happens to your data after it arrives at the provider but says nothing about what gets sent there in the first place. That distinction is where most organizations still carry unaddressed risk.
The Gap Between Retention Policies and Data Exposure
An engineer who copies a production table into a GPT-4 API call has created an exposure event regardless of whether OpenAI retains that prompt for zero seconds or zero days. Understanding the broader ChatGPT security risks makes this pattern even clearer.
This gap is especially pronounced with unstructured data. Support tickets in Zendesk, shared documents in Google Drive, Slack threads with customer PII: These are the inputs employees pull from when they interact with AI tools. None of that content goes through a checkpoint by default. And most organizations have no automated mechanism to intercept sensitive data before it enters an external API call. The concept of personal data licensing highlights just how far the industry still needs to go in giving organizations granular, enforceable control over where sensitive information travels.
A retention policy governs what happens after data arrives at the provider. Real-time deletion narrows the breach window to near zero, but the data does travel to OpenAI. Preventing that transmission entirely requires a different layer of control.
How Teleskope Prevents Sensitive Data from Entering AI Systems
Teleskope works at a different layer, and it's important to be precise about the risk it addresses. For organizations using ChatGPT, Teleskope's compliance integration removes sensitive data from the employee-facing ChatGPT interface in real time, so that if an employee's account is compromised, the sensitive content isn't sitting in their conversation history waiting to be read. That is a different threat from the one zero data retention is built for. ZDR governs whether the provider holds onto data it shouldn't; Teleskope's integration governs what an attacker would actually find if they got into a user's account. The two protect against different failure modes, which is why mature AI security programs treat them as complementary rather than interchangeable.
The following table breaks down how provider-side zero data retention compares to Teleskope's pre-exposure approach, and why the differences matter for teams serious about keeping sensitive data out of third-party models.
Teleskope's Redact API can be embedded directly into codebases to scrub PII before it reaches inference or training pipelines. For teams that need to block sensitive data from reaching OpenAI entirely, Teleskope's browser extension intercepts inputs at the source, and its MCP gateway partner integrations enforce controls across agentic workflows where API calls are triggered programmatically. Its classification engine, processing at 40,000 items per second with 99.3% accuracy, identifies over 150 sensitive data types across structured and unstructured environments. Real-world results back this up: Ramp uses Teleskope for real-time data redaction across internal systems, preventing PII exposure in production before it can propagate into downstream tools.
If your team is adopting AI and wants to pair OpenAI ZDR with upstream data controls that actually stop sensitive information from reaching third-party models, book a demo to see how Teleskope closes that gap.
{{cs-2="/banners"}}
Key Takeaways for Security Leaders Adopting AI Safely
Zero data retention is a meaningful control, but treating it as your entire AI data security strategy is like wearing a seatbelt and removing the brakes. OpenAI ZDR handles the storage question at the provider layer. It doesn't answer the harder questions:
- What sensitive data is leaving your environment?
- Which workflows are where it is happening?
- Who authorized it?
The organizations that adopt AI without regret are the ones building controls at both ends, enforcing retention policies downstream and catching sensitive data upstream before it ever reaches a third-party model. If your current approach relies entirely on vendor promises, you're trusting a lock on someone else's door while leaving your own wide open. Start by mapping where sensitive data actually flows into AI tools, then decide whether your existing controls match the risk you're carrying.
