Zero Data Retention: Eligibility Varies by Model and Platform

An Agreement Is Not a Blanket Guarantee

Zero Data Retention (ZDR) is a configuration an organization can have in place with Anthropic so that request/response data isn't retained. It's tempting to treat an existing ZDR agreement as a single switch that covers everything an organization does with Claude -- but that's exactly the assumption that creates a scoping surprise later. ZDR eligibility varies by model and by platform, and it is not automatically guaranteed just because an organization already has a ZDR agreement in place. Not every current model is ZDR-eligible, and this isn't limited to the direct Claude API: it applies just as much across Amazon Bedrock, Google Vertex AI, and Microsoft Foundry.

Concretely, a team could have a fully executed ZDR agreement at the organization level, deploy a newer or higher-capability model that simply hasn't had its ZDR status confirmed yet, and discover mid-project that the specific model/platform combination they picked isn't covered -- even though "ZDR" appears in their contract.

The Practical Guidance

The fix for this is procedural, not architectural: confirm current ZDR coverage for the specific model/platform combination in use, at scoping time -- before the deployment surface is locked in, not after. Anthropic's Trust Center is the reference point for checking a given model's current ZDR status; for Bedrock, Vertex AI, or Microsoft Foundry, confirm data retention under that specific platform as well, since platform and model are two separate variables that both have to check out. "We have a ZDR agreement" is not itself an answer to "is this specific model, on this specific platform, ZDR-eligible right now" -- those are two different questions, and only the second one is the one that actually matters for a given deployment.

Why This Belongs With Identity and Access, Not Just Prompting

This is a platform-configuration question, not a prompt-level technique -- it sits alongside identity, secrets, and access management because it's resolved the same way those are: at scoping and deployment-configuration time, by checking the actual current state of a specific model/platform pairing, rather than assumed once and carried forward indefinitely. A regulated customer's review will ask about ZDR coverage the same way it asks about credential handling and access logging -- as a fact to be verified for the exact configuration being deployed, not a property inferred from an organization-level contract.

Common exam traps

• Assuming an organization-wide ZDR agreement automatically covers every model and every platform the organization uses. Eligibility is scoped to the specific model/platform combination, not granted globally by the agreement.
• Assuming ZDR is a direct-API-only concern. The same eligibility-varies-by-model-and-platform caveat applies on Bedrock, Vertex AI, and Microsoft Foundry, not just the first-party API.
• Deferring the ZDR check to after a model/platform choice is already built and shipped, rather than confirming eligibility at scoping time when the choice can still change cheaply.