Data Retention Questions to Ask an AI Email Vendor

The data retention policy questions you ask an AI email vendor decide more about your risk than any feature list on their pricing page. Every vendor says your mail is private. Fewer say, without being asked twice, how many days it sits in their database after you hit delete, whether a backup outlives that deletion, or what the AI model behind the product is allowed to keep once it reads a message.

This post is the interrogation script, not the reassurance. Ask the questions below, in order, and a real policy separates itself from a good sentence in about five minutes. We build AI Emaily, an AI-native email client, and we run the same script against ourselves near the end — including where we don't have a published number yet.

The short answer#

Ask five things, in this order: how long mail is kept after deletion, whether backups follow the same clock, which AI model provider actually processes the content and what that provider retains, whether your mail is used to train any model, and how fast a deletion request clears the live database, the backups, and the logs — not just the inbox view.

• Live retention — how long a message sits in the working database after you delete it in the app
• Backup retention — whether a nightly or monthly backup outlives that number, and by how much
• Model-provider retention — what the AI model itself keeps, separate from the vendor's own database
• Training use — whether your mail, or anything derived from it, is used to train a model, ever
• Deletion mechanics — a stated process and timeframe for full removal, not "contact support"

Criteria that actually matter#

Most vendor privacy pages answer the easy question — encryption in transit — and skip the ones that actually determine your exposure. Five criteria separate a real retention policy from a reassuring paragraph.

• Live storage duration. How long a message sits in the vendor's working database after you delete it in the app. A day and a year are both defensible answers; "as long as needed" is not an answer.
• Backup retention. Backups usually outlive live deletion by design, so the vendor should state that separately — a 30-day live retention with a 90-day backup tail is normal and honest; an unstated backup policy is not.
• Model-provider retention. The vendor likely routes AI calls through a third-party model or a gateway sitting in front of several. That provider has its own retention terms, and they are not automatically the vendor's terms.
• Training use. Whether your mail, or any output derived from it, is used to train a model — the vendor's or the provider's. This should be a plain no or a plain yes, not a hedge.
• Deletion mechanics. What happens the day you close the account: a stated timeline for the live copy, the backups, and any logs, not "we'll take care of it."

Two rules that already exist, independent of any vendor's policy#

If the vendor connects to Gmail, its handling of that data is also bound by Google's API Services User Data Policy, which restricts what a Gmail-scoped app may do with message content — separately from whatever the vendor's own retention page says.

And under GDPR Article 28, a vendor acting as a data processor for an EU-based customer is contractually required to delete or return personal data at the end of the engagement, on request. If you're in the EU, ask to see that clause in the data processing agreement rather than taking a policy page's word for it.

In the US, several state privacy laws — California's CCPA and CPRA among them — give residents a right to request deletion of personal information a business holds. That's another lever if a vendor is dragging its feet on a specific request rather than answering it.

Score every answer against this table#

Bring this table to the sales call or the security questionnaire. A vendor that answers with specifics on most of these rows has a real policy; one that answers all of them in vague marketing language does not, whatever the pricing page claims.

None of these rows require a vendor to reveal anything competitively sensitive. A retention number, a named model provider, and a deletion timeline are operational facts, not trade secrets — a vendor that treats one of them like a secret is telling you something too.

Worked example: scoring one vendor's answers#

Here's how the scoring plays out against a real exchange — details changed, structure kept, because the pattern repeats across this category more than any single vendor's wording does.

A reader emailed a mid-size AI email vendor's support address with four of the questions above. The reply came back inside a day, which is itself a decent sign — a fast reply to a security question usually means someone owns the answer instead of drafting one from scratch.

Four questions, one half-credit answer. That's not evidence the vendor is doing anything wrong with the mail — it's evidence nobody has been asked in a way that required a specific answer back. The fix, from the reader's side, is to ask again and ask for the number in writing rather than on a call.

If the second reply is still vague, that's the answer. A vendor that can't produce a retention number on the second ask isn't going to produce one after you've paid. The same rubric applies whichever vendor you're evaluating — score the reply, not the tone of the reply.

Red flags in a vendor's answer#

Some phrases are almost always doing the same job: making a vague policy sound like a specific one. Watch for these in a security questionnaire response or a sales call.

• "As long as necessary" or "as long as required by law" with no number — this covers everything from one day to indefinitely and commits the vendor to nothing.
• "Industry-standard" applied to encryption, security, or retention, without naming the standard.
• "We take your privacy seriously" as the entire answer to a specific retention question.
• A named AI feature with no named model provider behind it — you can't check a provider's retention terms if you don't know who the provider is.
• A privacy policy that spends several paragraphs on collection and one sentence on retention.

What we'd pick and why (honest)#

We build AI Emaily, so treat what follows as an interested party answering its own checklist — and check the pages we point to rather than taking our word for the number.

Against the criteria above, here's what's actually documented today. AI Emaily does not train any model on user mail. AI calls route through a single AI gateway (OpenRouter) rather than directly to a model provider we don't control, and that routing is built around a zero-retention arrangement with the model providers on the other end of it. Message bodies live in our own object storage, referenced by an id, rather than scattered across a marketing tool or a support ticket system. OAuth tokens and BYOK API keys are envelope-encrypted and never logged in plain text; a BYOK key is decrypted only inside an isolated worker, never on the client and never in a log line.

What we won't do here is invent a number we haven't published. This post doesn't give a specific day-count for how long a deleted message survives in a backup, and it doesn't cite a SOC 2 or ISO 27001 report — so if either of those is the deciding row on your table, ask us directly and check /security and /docs/account-data for the current answer rather than trusting this paragraph for it. A vendor that already publishes a numbered backup-retention SLA and a report you can download today is the stronger fit on that specific row, until we do.

If you need a signed compliance report in hand this week — a healthcare practice under a BAA, or a finance team against a vendor-risk deadline — this checklist tells you what to ask, but it doesn't replace asking us, or anyone, directly and in writing before you sign.

For a team choosing which AI email tool to trust with a live inbox, that's the actual decision: not who uses the fewest words about safety, but who answers this six-question script with numbers instead of adjectives — whether that's us or one of the other AI inboxes launching this year.