Anthropic says zero data retention means Claude prompts aren't stored, and the buyer now has to prove it on the org setting, the API, and their logs.
Anthropic now offers zero data retention on Claude for opted-in organizations. Proving the policy actually held for any given org is the buyer's job, not the vendor's.
The flip landed on September 1, 2026, according to CNBC, after weeks of enterprise pushback that Bloomberg first reported on August 20. Anthropic now says that for covered Claude models, prompts and outputs aren't stored once the request completes, provided the customer's account is configured for zero retention. The catch lives in the word "provided." The Register's coverage of the change makes the burden explicit: customers have to verify the setting actually took effect.
The "zero retention" label can break at three different layers, and a buyer who checks only one is exposed at the others.
First, the org or workspace setting. Anthropic's enterprise documentation, the Fable page and the help-center article on data retention for Covered Models, describes how an organization opts into ZDR. The setting is per-workspace; if a security team enables ZDR on the parent org but a single developer creates a child workspace under the default policy, that workspace still retains. A screenshot of the org toggle is not, by itself, evidence that every downstream call is covered.
Second, the API layer. The platform docs on API and data retention describe the difference between API traffic that is logged and traffic that is not. A customer who routes Claude through a proxy, a fine-tuning pipeline, or a third-party observability tool is adding logging that Anthropic's policy doesn't control. ZDR in the vendor's contract doesn't erase what the customer's own stack writes.
Third, the enterprise frontier safeguards layer governs what Anthropic itself can see for safety and abuse-review purposes. Even with ZDR enabled, a safety review can re-introduce human inspection of specific prompts. The docs explain when that happens; a buyer who hasn't read that page doesn't know what zero actually means for their highest-stakes content.
The drift between policy and runtime is not hypothetical. Developers Digest reported that a Fable 5 update broke existing enterprise ZDR agreements earlier this year, forcing dev teams to re-verify their configurations after the fact. The post is a single source for the claim and warrants confirmation, but the shape of the problem is familiar: a vendor ships a model or platform change, the config UI says ZDR is on, and the actual request path is logging data the customer believed wouldn't be retained. The fix in that case was not a refund. It was a re-audit.
Three lightweight checks don't require a rebuild. Confirm the org or workspace ZDR setting on every workspace that touches production traffic, not just the parent org. Audit any proxy, observability, or fine-tuning layer between the application and the Claude API for logs that capture prompt or output text. Pull the Anthropic data retention documentation for Covered Models and the enterprise frontier safeguards note and confirm in writing which retention and safety-review exceptions still apply.
The next Fable release is the test. Each model upgrade so far has required a fresh verification pass from buyers, and there is no public commitment that future upgrades will preserve ZDR-by-default across every workspace tier. The current "zero data retention" label on Claude is a setting a buyer has to defend, not a guarantee Anthropic hands them.