Zero data retention means your prompts and the model's outputs get processed for that single request and then discarded, not stored, logged, or used to train future models. For procurement and security teams, the practical effect is smaller: fewer copies of sensitive content sitting in a vendor's infrastructure, which shrinks your exposure if that vendor is breached, subpoenaed, or simply changes its policies later.
That single change reshapes how you should evaluate any AI vendor.
- No persistent record of your prompts or completions beyond the API call itself
- No use of your content to train or fine-tune future models
- A narrower attack surface for breach notification and subpoena exposure
Vendors including OpenAI and Google now publish zero data retention (ZDR) options for enterprise accounts, and Decagon's glossary frames the underlying mechanism as routing requests through a logging-exempt path where prompt-response pairs never touch a persistence layer.
Key Takeaways
Zero data retention works because it removes the storage step entirely, shrinking third-party exposure risk in ways that anonymisation and retention limits alone cannot match.
| Point | Details |
|---|---|
| ZDR is contractual and technical | Get both a signed clause and evidence of a logging-exempt route, not one without the other. |
| Feature exceptions are the trap | Grounding, file APIs, plugins, and session state often sit outside the core ZDR guarantee. |
| Metadata still persists | Token counts, timestamps, and billing records survive ZDR even when content doesn't. |
| Test before you trust | Run sandboxed test requests and inspect sanitised audit logs before relying on any vendor claim. |
| Legal carve-outs are normal | Short-term retention for abuse investigation or lawful requests doesn't invalidate a ZDR agreement. |
Table of Contents
- What zero data retention means in practice
- How zero data retention works at the infrastructure level
- What ZDR covers, and where it quietly stops
- Why enterprises are pushing ZDR into procurement requirements
- A procurement and security checklist for verifying ZDR
- The trade-offs nobody puts on the pricing page
- Inspirowrite's approach to confidential prompt processing
- Vendor documentation worth reading directly
- The procurement blind spot on zero data retention
- Sources
- FAQ
What zero data retention means in practice
Vendor marketing and technical enforcement are not the same thing, and procurement teams that treat them as interchangeable get caught out later. A contract clause promising "zero data retention" is a legal commitment; a logging-exempt API route is the engineering mechanism that makes it true. You want both, and you want the second one documented at the feature level, not the product level.
Common vendor phrases sound reassuring but mean specific, narrower things than they imply:
- "Deleted within seconds" usually refers to the inference pipeline, not every downstream system touching that request
- "Not used for model training" is a separate promise from "not retained" — a vendor can honour one without the other
- "Exceptions apply for law enforcement or abuse investigation" means a carve-out exists, and you need to know its scope and retention window
Decagon's own definition of ZDR draws exactly this contrast, noting that default retention policies often run 30 days unless a customer explicitly opts into zero retention. That gap between default and explicit is where most procurement mistakes happen. Read the feature-level documentation for the specific product you're buying, not the vendor's general privacy page, because ZDR commitments frequently apply to some endpoints and models while excluding others entirely.
How zero data retention works at the infrastructure level
Engineering teams enforce ZDR by routing eligible requests through a separate code path that skips the write-to-disk step most logging systems perform by default. Three implementation patterns show up repeatedly across vendors:
- Per-request flags. OpenRouter's documentation describes a
zdrparameter set on individual API calls, letting a single account run both retained and non-retained requests depending on workload sensitivity, as detailed in its ZDR guide. - Per-project or per-organisation toggles. Some platforms enforce ZDR at the account level, meaning every request from that project skips persistent logging by default rather than requiring a flag each time.
- Per-model-group enforcement. Not every model supports ZDR; OpenRouter notes that some model endpoints are classed as ZDR-eligible while others are not, so mixed workloads need explicit routing logic.
What still persists, even under strict ZDR, is metadata: token counts, timestamps, and billing records. That's the difference between content retention and operational telemetry, and it matters because auditors will ask about both. In-memory caching complicates this further. Google's Gemini documentation acknowledges that implicit caching may briefly persist data in RAM to reduce latency, which is generally treated as compatible with ZDR but is not the same guarantee as "nothing is ever held anywhere."
Pro Tip: Before trusting a ZDR claim, set the flag on a sandboxed test account, send a distinctive test prompt, then request your own audit logs. If that prompt shows up anywhere outside the immediate response, the enforcement isn't working the way the documentation says it should.
What ZDR covers, and where it quietly stops
This is where most zero data retention promises fall apart, and it's the section procurement teams skip at their own risk. ZDR typically applies to inference, the core prompt-in, output-out exchange. Everything adjacent to that exchange often runs on a separate retention clock.
Grounding and search-augmented features are the clearest example. Google's own documentation states that Grounding with Google Search and Maps stores prompts and contextual information for 30 days for debugging and grounding purposes, and this cannot be disabled while the feature is active. If your use case needs live web grounding, you cannot simultaneously claim a zero-data footprint for those requests, full stop.
Other exceptions worth checking line by line:
- File APIs often store uploaded files at rest until a customer explicitly deletes them, separate from the inference request itself
- Session and conversation-state APIs can retain multi-turn context to support resumption, unless you disable state storage explicitly
- Plugins and third-party connectors frequently operate under their own sub-processor's retention policy, not the core model vendor's ZDR terms
- Explicit context caching (as opposed to implicit in-memory caching) is a customer-controlled feature that persists content by design, and needs to be avoided or configured deliberately
Model availability adds a final wrinkle. Anthropic's Claude Code documentation confirms that some models require retention and are consequently disabled in ZDR-enabled accounts, so enabling ZDR can mean losing access to specific capabilities entirely, not just adjusting a setting.
Why enterprises are pushing ZDR into procurement requirements
Three drivers explain why ZDR has moved from a nice-to-have to a contractual line item in the last two years.
Regulatory exposure. GDPR, CCPA, and HIPAA all treat data minimisation as a core obligation, and persistent third-party logs of customer or patient content create liability that simply doesn't exist if that content is never stored. TechTarget's compliance coverage is blunt about this: ZDR reduces exposure but doesn't eliminate the enterprise's own due-diligence obligations around documenting lawful basis and managing sub-processors.
IP protection. Any organisation feeding proprietary code, financial models, or unreleased product plans into an AI tool wants assurance that content isn't quietly becoming training data for a future model version, potentially available to other customers in some generalised form.
Commercial trust. In regulated or privacy-sensitive markets, being able to tell your own customers "our AI vendor contractually and technically does not retain your data" is a sales asset, not just a compliance checkbox.
A procurement and security checklist for verifying ZDR
Don't take a vendor's landing page at face value. Verify the claim across three layers before signing anything.
Contract clauses to request:
- An explicit ZDR clause naming the specific products, models, and API endpoints it covers
- An updated Data Processing Agreement reflecting the ZDR scope, not a generic template
- Audit rights, including access to sub-processor lists and the specific models covered
- Documented retention carve-outs for legal requests or abuse investigation, with stated retention windows
Technical tests to run:
- Send test requests with the ZDR flag set and inspect whether sanitised audit logs show any content, not just metadata
- Check token telemetry to confirm what persists (counts, timestamps) versus what doesn't (prompt text)
- Test the specific features you plan to use, since grounding, file uploads, and plugins often sit outside the core ZDR guarantee
Operational controls to confirm: admin-level scoping of who can toggle ZDR settings, key rotation policies, seat-level access controls, and a documented incident response obligation if retention exceptions are triggered.
Pro Tip: Ask your vendor for their sub-processor list before signing, not after. A ZDR guarantee from the primary vendor is worthless if a third-party plugin they route through retains everything for 90 days.
The trade-offs nobody puts on the pricing page
Zero data retention is a genuine privacy control, not a free upgrade. Some models and features are simply unavailable under ZDR because they technically require retention to function, so you may lose access to grounding, certain caching features, or newer models that haven't yet been certified for non-retained processing.
There's also a quieter cost: if a vendor never sees your data, it can't use it to improve outputs for your specific use case the way ongoing feedback loops sometimes do elsewhere. And ZDR is not absolute. Legal requests and policy-violation investigations can trigger short-term retention even under a ZDR agreement, a carve-out that every vendor in this space documents somewhere in the fine print. Academic work on model memorisation adds a further caution: anonymisation isn't equivalent to non-retention, since models can retain recoverable traces of training data even after supposedly anonymised inputs. ZDR sidesteps that risk by never entering the training pipeline in the first place, but it's worth knowing the distinction exists.
Inspirowrite's approach to confidential prompt processing
Inspirowrite was built on the same principle underpinning enterprise ZDR requirements: your text gets processed for correction or translation and is never used to train models. For procurement teams evaluating AI writing tools under the same scrutiny they'd apply to any other vendor, that distinction matters as much for a proofreading tool as it does for a large language model.
- Confidentiality commitments are set out in full in the Datenschutzerklärung
- Further implementation detail on privacy-preserving translation workflows is covered in this guide to confidential translation tools
- Business customers can review contractual terms directly in the AGB before procurement sign-off
Vendor documentation worth reading directly
- Gemini's ZDR documentation details feature-level exceptions and caching behaviour
- OpenAI's ZDR page explains private safety processing trade-offs
- TechTarget's GDPR/AI guide covers enterprise compliance obligations beyond ZDR
The procurement blind spot on zero data retention
Most guidance on this topic treats zero data retention as a binary you either have or don't. That's the wrong frame. ZDR is a patchwork of feature-level commitments, and the vendors themselves document this openly if you read past the marketing page. The mistake enterprise buyers keep making is signing off on a vendor's general privacy claim without checking whether the specific feature they're about to deploy, grounding, file uploads, a plugin, actually falls inside that guarantee.
The conventional advice, "ask if the vendor offers ZDR", isn't wrong, it's just insufficient. The better question is narrower: does ZDR apply to this exact endpoint, this exact model, with this exact feature set enabled? Security teams that run a sandboxed test request and inspect the resulting logs catch gaps that a signed DPA alone never reveals.
If there's one priority above the rest, it's this: stop treating anonymisation and retention limits as substitutes for genuine zero retention. They solve different problems, and conflating them is how sensitive content ends up somewhere it was never meant to be. Read the feature documentation before you read the sales deck.
— Mike
Sources
- Zero data retention in the Gemini Developer API | Gemini API | Google AI for Developers
- OpenAI offering zero data retention for frontier models
FAQ
What does zero data retention mean?
It means prompts and outputs are processed for a single request and then discarded, without being stored, logged long-term, or used to train future models.
What is zero data retention in OpenAI's offering?
OpenAI has published zero data retention options for frontier models aimed at enterprise accounts, alongside private safety processing that aims to reconcile abuse monitoring with content confidentiality.
What does "0 retention" mean in practice?
It means no persistent copy of your prompt or the model's response exists after the request completes, though operational metadata like timestamps and token counts typically still gets recorded.
What does "zero data retention (ZDR)" cover, and what does it miss?
ZDR covers the core inference exchange but often excludes grounding features, file uploads, plugins, and session-state APIs, which frequently run on separate retention policies that need to be checked and controlled independently.