Regulated teams often approve "the model" and then discover that the system they built uses features the approval does not cover. Anthropic publishes a feature eligibility table for two arrangements: zero data retention (ZDR) and HIPAA readiness. This article summarizes it as of November 2026. The table changes, and your signed agreement is the authority, so read the source before you design.
What the two arrangements mean
ZDR means prompts and outputs are not stored by Anthropic for eligible features. HIPAA readiness means that, with a signed business associate agreement and a HIPAA-enabled organization, you can process protected health information on eligible features. The API enforces the boundary: a HIPAA-enabled organization that sends a request using an ineligible feature gets a 400 error.
The table, summarized
| Feature | ZDR | HIPAA | Note |
|---|---|---|---|
| Messages API | Yes | Yes | The base case. |
| Citations | Yes | Yes | Source-linked answers over your documents. |
| PDF support | Yes | Yes | HIPAA applies to PDFs sent inline, not through the Files API. |
| Structured outputs | Yes (qualified) | Yes | The JSON schema is cached for up to 24 hours. Never put PHI in a schema. |
| Prompt caching | Yes | Yes | Prompts and outputs are not stored. |
| Thinking, effort | Yes | Yes | |
| Memory tool, bash, text editor | Yes | Yes | Client-side. They run in your environment. |
| Web search | Yes | Yes | Dynamic filtering is not eligible. |
| Web fetch, browser use | Yes | No | Not covered under HIPAA readiness. |
| Context editing, compaction | Yes | No | |
| Batch processing | No | No | Retained 29 days. |
| Files API | No | No | Kept until deleted or expired. |
| Code execution | No | No | Container data kept up to 30 days. |
| MCP connector | No | No | Standard retention. |
| Agent Skills | No | No | Standard retention. |
| Claude Managed Agents | No | No | Sessions are stateful and transcripts persist until you delete them. |
Outside the table, a few boundaries matter. HIPAA readiness does not cover Claude Code or processing PHI through the Console. It is not available on Claude Platform on AWS. On Amazon Bedrock and on Google Cloud when Google manages the service, the cloud provider is the data processor, so those platforms' own terms apply. Features in beta are generally not covered unless the table lists them. Separately, Anthropic may retain flagged content for up to two years even under these arrangements.
What this does to the architecture
The pattern is that the convenient, managed features are the stateful ones, and stateful features are the ones outside the arrangements. A regulated build therefore tends to look more conservative than a demo.
- Batch is out, concurrency is in. Run real-time requests in parallel instead. You give up the batch discount, and you keep your data posture.
- Send documents inline. Use PDF support in the request instead of uploading through the Files API.
- Build the agent loop yourself. Managed Agents and Skills are outside both arrangements. A Messages API loop with client-side tools, run in your environment, stays inside. Anthropic's skill pattern of loading instructions on demand is still a good design. Implement it against your own store.
- Run code on your side. The hosted code execution tool is not eligible. A client-side bash or code tool in your own sandbox is.
- Keep PHI out of schemas. That includes property names, enum values, constants, and patterns. Patient-specific data belongs in message content only.
- Check the cloud you deploy on. The same model has different data terms on different platforms.
- Your environmentdata, sandbox, tools
- Messages APIeligible features only
- Client-side toolsbash, memory, retrieval
- Personapproves
- Your audit loginputs, outputs, edits
A review checklist
- List every API feature the system calls, including ones a framework enables for you.
- Check each against the current eligibility table, for ZDR and for HIPAA separately.
- Confirm your signed agreement lists the same features.
- Confirm which platform you deploy on and whose terms govern it.
- Add a test that fails the build if a new feature appears in a request.
The fifth item is the one people skip. Frameworks add features between versions, and a regulated system should find out in a test, not in an audit.
This is a reference design. It describes how we would build the system and cites Anthropic's documentation for platform facts. It is not a client case study, and the figures it uses are list prices or worked examples, not results.
Have a process like this?
Bring it to a 45-minute working session.