Zero Retention AI: What It Means and How to Verify It

"Zero data retention" is now on almost every AI email tool's marketing page. It sounds like a full guarantee: the provider never keeps anything. In practice it means something narrower, it applies to one layer of the stack, and "no training on your mail" is a separate promise made at a different point. The two get conflated, and a vendor that honestly holds one may not hold the other.

This guide defines zero retention precisely, distinguishes it from the terms it gets confused with, walks through the abuse-monitoring exception that quietly reintroduces retention at the model provider, and ends with the two documents you can request that turn any zero-retention claim into something checkable.

The short answer#

Zero data retention means the AI model provider — OpenAI, Anthropic, Google, or whoever your vendor is calling — does not persist the API inputs your tool sends or the completions it returns after the request is served. Nothing is written to disk, nothing sits in a queue, nothing is available for a support engineer to pull up later. It is a claim about the model provider's storage layer, not about your vendor's own database, and not about the mail itself sitting in your mailbox.

Three terms get treated as if they mean the same thing. They do not.

• Zero data retention. The model provider does not store the API request or response after it is served. Usually a paid enterprise arrangement — not the default.
• No training on your data. The provider does not use your prompts or completions to train, fine-tune, or evaluate its models. A separate contractual clause, usually in the DPA.
• Encryption at rest. Anything that is stored — by your vendor's own database, by object storage, by the model provider under a standard retention window — is encrypted on disk. It says nothing about whether the data is stored in the first place.

Criteria that actually matter#

Once you get past the marketing sentence, a short list of dimensions separates a real zero-retention posture from a claim that will not survive an enterprise procurement review. These are what to check.

• Which layer the promise covers. Zero retention at the model provider says nothing about whether your vendor keeps a permanent copy of every message body in its own Postgres. A serious answer names both layers separately.
• Whether the abuse-monitoring exception applies to you. OpenAI's standard API retains inputs and outputs for up to 30 days for trust-and-safety review, then deletes them. Its Zero Data Retention program removes that window, but only for endpoints and customers that have been explicitly approved.
• No-training terms in writing. Zero retention does not automatically mean no training. Ask for both, in the DPA, not in a support-page paragraph.
• Sub-processor disclosure. Every model provider, embedding provider, and gateway is a sub-processor. If the list is missing or undated, you cannot audit the chain — and you cannot answer these questions for your own clients either.
• Where the vendor stores the mail itself. Message bodies, subjects, thread history, drafts. If those are held indefinitely with no stated maximum, the model-side promise is only half the story.
• Deletion on request. GDPR Article 17 applies to whatever is stored; a vendor that cannot actually delete on request within a stated window has no enforceable retention limit at all.

Scoring table: how to grade a zero-retention claim#

Six signals decide whether a zero-retention claim is enforceable or aspirational. Score each one against the vendor's actual documents — not a landing page, not a founder tweet.

Six green cells is a real posture. Four or five with a clear reason for the gap is workable. Three or fewer, or a vendor that will only answer in marketing prose, is a vendor that has not yet done the enterprise work — and you will find out the hard way during your own security review.

Worked example: an ops lead evaluating an AI email tool under HIPAA#

Take an operations lead at a small clinic evaluating an AI email tool to triage patient-scheduling mail. HIPAA is in play because the messages contain protected health information, and "we take privacy seriously" is not a defensible answer to a compliance officer.

How to verify it, in order#

1. 1

   Read the vendor's DPA end to end

   You are looking for three things: a no-training clause on Customer Data, a retention schedule per data category, and an Article 28 sub-processor clause. If any is missing, note it and ask.

2. 2

   Pull the sub-processor list

   It should be a public page with a last-updated date. Every model provider, embedding provider, gateway, and storage vendor should be named with region and purpose. An undated or missing list ends the review here.

3. 3

   Check the model provider's own enterprise terms

   OpenAI's enterprise privacy page and Anthropic's commercial terms both describe their default retention and their ZDR programs. If your vendor names OpenAI as a sub-processor, they must hold ZDR for the endpoints they use — otherwise the 30-day window applies to your data.

4. 4

   Ask for the ZDR letter or DPA clause naming it

   This is the single strongest piece of evidence. A vendor that holds ZDR can produce it. A vendor that cannot may still be honest, but is on the standard tier and needs to say so plainly.

5. 5

   Confirm your own deletion path

   Open a test account, put a distinctive string in a draft, request deletion in writing, and see whether it disappears from search within the stated window. This is the one signal that verifies itself.

Red flags#

These signals mean a zero-retention claim is not what it looks like. One on its own is a reason to ask questions. Two or three together is a reason to walk away.

• "Zero retention" claimed without naming which layer it applies to. The default assumption should be that it means the model provider only, and only if the vendor holds the enterprise agreement to enforce it.
• No sub-processor list, or one without a last-updated date. Enterprise buyers cannot chain-audit a claim they cannot see.
• The phrase "we may use aggregated or anonymised data to improve our services." That is a training carve-out, not a no-training promise.
• Retention stated as "as long as necessary" with no maximum. A window without a number is not a limit.
• Free cloud AI with enterprise data terms. Zero retention at the model layer usually costs the vendor money and a signed agreement. Perpetually free consumer-grade tools rarely have one.
• Password access or full IMAP scraping instead of least-privilege OAuth. A vendor that widens its access model rarely narrows its data model.

What we'd pick, and why (honest)#

Disclosure first: we build AI Emaily, so treat this section as an interested opinion and check the claims against our privacy model and security pages linked below. On a zero-retention question specifically, there are three shapes of answer worth weighing, and which one fits depends on where you draw the sensitivity line.

AI Emaily is the pick when you want cloud-AI triage across more than one mail provider under enforceable data terms. We route all model calls through a gateway that holds zero-retention agreements with the underlying providers, we do not train on your mail, and we publish a DPA. Message bodies live in encrypted object storage referenced by ID rather than inline in the database; OAuth tokens and any bring-your-own-key credentials are envelope-encrypted and never logged. The agent treats email content as untrusted input, so it will not execute instructions hidden inside a message, and nothing is sent until you approve it in Copilot mode. Packaging is a 7-day free trial on the paid plans — card required, $0 if you cancel before day seven — not a permanent free tier.

Where we'd send you elsewhere. If your bar is that the mail itself is unreadable by any vendor, not just unretained after model processing, an end-to-end encrypted provider like Proton Mail is a stronger position than any zero-retention API promise. Proton has built harder on the storage side than we have — with zero-access encryption the vendor genuinely cannot read the mail, ZDR or no ZDR — and its Scribe assistant is designed to run locally on the device or on no-logs servers. That is a real architectural advantage on the storage layer, and we do not match it.

And if your bar is that mail never leaves your device at all, a native local client with little or no cloud AI (Apple Mail, Mimestream) removes the model-provider question entirely. You give up cross-provider AI triage in exchange, which is a trade the highest-sensitivity readers should make.

In short: AI Emaily is the right pick if you want a working AI email assistant with enforceable zero-retention and no-training terms across Gmail, Outlook, iCloud and IMAP. Choose Proton if end-to-end encryption of stored mail is the priority. Choose a native local client if the answer to "can any vendor read this at all" must be no.