Anthropic announced zero data retention for enterprises. The data is still retained, in your cloud account, on your bill.

Anthropic announced Enterprise Frontier Safeguards on 1 September, describing it as "a solution that combines the privacy of zero data retention (ZDR) with state-of-the-art safeguards for detecting misuse".

Read the mechanism in the same paragraph and the shape of it becomes clear: "EFS works by storing data in cloud infrastructure controlled by the customer, not Anthropic."

The data is still stored. It still sits there for a period. Anthropic's automated systems still read it. What changed is whose account it sits in, whose keys encrypt it, whose staff may look at it, and whose bill the storage lands on.

That is a real improvement for a regulated buyer and it is worth having. It is also not what most people understand by zero data retention, and the gap matters if you are writing it into a control document.

What moved, and what did not

Anthropic's own account of why retention existed

The most useful part of this announcement is that it explains the thing vendors usually leave out. Retention was not an accident or a data-harvesting play, and Anthropic says so directly:

"Effective detection requires storing data for a meaningful period of time so that it can be correlated across time and accounts. For this reason, we introduced 30-day data retention starting with Fable 5."

And then, pre-empting the obvious accusation: "This policy was not motivated by a desire to train on enterprise data: Anthropic has never trained on enterprise data without explicit permission, and never will."

The reasoning is sound and it is worth internalising, because it applies to your own logging as much as to theirs. Sophisticated misuse is spread across many sessions and many accounts. You cannot correlate across time if you discard at the end of each interaction. Anyone who has run a SIEM knows this: retention is not the opposite of security, it is a precondition for a whole class of detection.

Which leaves a genuine tension rather than a villain. Anthropic then states plainly what happened next: enterprises "generally understood the safety and security value of data retention, but many, especially in regulated industries, found it difficult to use models with data retention".

So the customers refused, and this is the architecture that resolves it.

What actually changed

Two things moved, and both are meaningful.

The store moved. Data now sits in the customer's own cloud account on AWS, Google Cloud or Azure, in an environment they already trust, under Customer-Managed Encryption Keys if they enable them.

Human review moved. Anthropic states that "EFS has automated safety monitoring, no Anthropic human review required". The reasoning given is specific and credible: regulated customers operate under rules governing who may see privileged legal material, non-public information and drug-safety reports, and their own staff are already cleared for it.

Two things did not move.

The data is still retained, on a rolling window, because that is the control rather than the flaw.

Anthropic's automated systems still analyse it. The announcement says automated systems "analyze a rolling window of traffic for signals of serious misuse". The analysis is the point of the arrangement, and it did not go away.

The commercial detail worth reading twice

Anthropic does not charge for Enterprise Frontier Safeguards. The announcement is explicit that none of the components "change model behavior, API pricing, or rate limits".

But the storage is not free, it has simply moved onto a different invoice. If a customer elects to store data in their own cloud account, their cloud provider bills them for that storage, and for reads, writes and data transfer.

For most enterprises that cost will be trivial next to their inference spend. It is still a line item that did not previously exist, it scales with usage, and it belongs in whoever's budget owns the cloud account rather than whoever's budget owns the AI contract. Those are frequently different teams.

Each component is opt-in: customer-owned storage, Customer-Managed Encryption Keys, and fully automated review are enabled separately. So "we have EFS" is not by itself a description of a control. The question is which components are on.

The three components, each of which is opt-in

Component	What it changes	What it does not change
Customer-owned storage	The activity data sits in the customer’s own AWS, Google Cloud or Azure account rather than Anthropic’s	That the data is stored at all, and that automated systems analyse a rolling window of it
Customer-Managed Encryption Keys	The customer holds the keys to that store	Anthropic’s automated access to the window for misuse detection
Fully automated review	No Anthropic human review is required; the customer’s own cleared staff do it	The existence of the review, and the retention that makes correlation across time and accounts possible

Not available yet

Enterprise Frontier Safeguards is "rolling out to customers in phases, starting later this fall". Nothing ships today.

The bridging arrangement is stated: eligible customers "will receive ZDR on Fable 5 and Fable 5.1 until EFS is ready". So there is an interim period in which eligible enterprises get conventional zero data retention on those two models, and then move onto the new architecture when it arrives.

If you are relying on this in a compliance narrative before it exists, that gap is the thing to write down.

This is the third time this pattern has appeared

The tension between retention for abuse detection and retention as a privacy risk is now a recurring subject on this site rather than a one-off. Anthropic and OpenAI reached the same architectural conclusion about bring-your-own-cloud retention independently, and OpenAI published its own zero data retention position for frontier models on 19 August.

Two competitors arriving at the same answer to the same problem, within a fortnight, is usually a sign that the constraint is real rather than commercial. The constraint here is that abuse detection at frontier scale needs correlation across time, and regulated buyers cannot let a vendor hold the corpus that makes correlation possible. Moving the corpus to the customer is the only answer that satisfies both, and both labs found it.

The position

The engineering here is good and the disclosure is better than the norm. A vendor explaining why it wanted your data, conceding that customers refused, and rebuilding the arrangement so the data sits in your account under your keys is a better outcome than the alternative, which is a vendor quietly keeping the corpus and saying less about it.

The thing to resist is the phrase. Zero data retention means something specific to a procurement function, and what is being described is not that. It is retention you control, which is a different and in most respects better thing, and it deserves its own name rather than an existing one.