Zero data retention: what legal signed vs. what engineering shipped
The most common AI data problem we see is a contract that's perfectly accurate about a system your engineers never built.
This page is general information for operators, current as of the date shown. It is not legal advice, and reading it does not create an attorney-client relationship. Specific facts change the answer.
Two different promises
"We don't train on your data" and "we don't retain your data" sound like the same sentence. They are two different promises, with two different machines behind them. Training is about whether your customer's inputs get folded into somebody's model weights. Retention is about whether those inputs still exist on somebody's disk after the API call returns. A vendor can hold to one and not the other, and most of them gate and price the two separately. Enterprise buyers ask for both in the same breath, which is how a sales call turns into a contractual commitment to architecture your company doesn't actually run.
What the major vendors actually do
As of August 9, 2026
| Area | Status | Date | Note |
|---|---|---|---|
| Anthropic | Zero data retention is an organization-level arrangement you negotiate through sales, not a setting anyone can switch on in a console. It also doesn't cover every feature: the Batch API carries its own retention window, and file, code-execution, and connector features sit outside a ZDR arrangement. Content flagged by safety systems can be retained substantially longer. | Not dated | |
| OpenAI | By default, API inputs and outputs may be retained for up to 30 days so the service can run and abuse monitoring can work. Zero retention is available to eligible enterprise customers, on specific endpoints, and only when your agreement actually says so. | Not dated | |
| Azure OpenAI | Unless you change it, prompts and completions are logged for up to 30 days for abuse monitoring. Turning human review off means applying for Modified Abuse Monitoring, which is gated to managed enterprise customers who can document a justification. | Not dated |
These details move, which is exactly why the table carries a date. Your contracts should carry one too, along with a scheduled re-read.
The failure mode
Here is the sequence, and it plays out the same way almost every time. Legal negotiates a ZDR commitment with the model vendor and gets it right. Sales then tells the customer "we have zero retention," which is close enough to be believed and loose enough to be wrong. Months later an engineer wires a new feature to the standard API tier, or to a batch endpoint, or to a second vendor entirely, with no idea that any of it had been promised away. Nothing in the API response says "your retention promise no longer matches your architecture." So the gap sits there quietly until a customer's security review, a subpoena, or an incident asks the precise question, and by then you're answering it on someone else's clock.
The flow-down problem
Your customer's DPA binds you. Your vendor's terms bind your vendor. Nothing in either document connects the two automatically, and nobody is going to reconcile them on your behalf. So if your customer contract promises 30-day deletion including backups while your vendor holds flagged content far longer, you have promised something you cannot actually deliver. Saying "our vendor wouldn't delete it" doesn't get you out of it; it confirms the breach in writing, in your own words. The same logic runs all the way down through every subprocessor sitting underneath your vendor.
The self-check
You can run this yourself, this week, without hiring anyone:
If your list came back clean, put a date on it and re-run it the next time the architecture changes. If it didn't, the fixes are usually contractual before they're technical, which makes them faster and cheaper than they look from where you're standing. That's a fifteen-minute conversation.