Claude now has BAA coverage. Here's why that's not enough.
Anthropic offers a BAA for the Claude API under HIPAA-ready configurations. What healthcare teams actually need to understand before building with Claude and PHI.
- Anthropic now offers a BAA for the Claude API — under HIPAA-ready configurations with 30-day data retention
- A BAA is a legal contract: it does not prevent PHI from reaching Anthropic’s servers
- Zero data retention (ZDR) configurations cannot access BAA-covered Claude models
- The architectural alternative: tokenize before transmission — PHI never leaves your network regardless of which provider you use
Anthropic recently published its list of Claude models covered under a Business Associate Agreement (BAA). For healthcare teams evaluating Claude for clinical AI, this is meaningful news — and it’s easy to misread what it actually means for compliance.
The short version: the BAA is necessary, and it’s not sufficient. Here’s the distinction that matters.
What the Anthropic BAA actually covers
When you sign a BAA with Anthropic and access Claude through a HIPAA-ready configuration, Anthropic becomes your business associate under 45 CFR § 164.308(b). This creates contractual obligations: they must handle PHI in accordance with HIPAA, report breaches, and restrict use to the purposes specified in the agreement.
The covered models require 30 days of data retention on the platform. This is worth noting carefully: it means Anthropic retains request data for 30 days. The BAA governs what they can do with that data — but the data is there.
One specific detail from Anthropic’s guidance: zero data retention (ZDR) configurations cannot access BAA-covered Claude models. This creates a forced choice. If you want maximum data retention control (ZDR), you cannot use the BAA-covered API. If you want BAA coverage, you accept 30-day retention.
What the BAA does not cover
A BAA is a contract between you and Anthropic. It does not:
- Prevent PHI from being transmitted — patient names, diagnoses, and identifiers in your prompts travel to Anthropic’s infrastructure, BAA or not
- Implement technical safeguards for you — HIPAA’s Security Rule (§164.312) requires access controls, audit logs, and transmission security. These are your responsibility
- Apply to your application’s logic — if your code logs prompts, stores them in a database, or forwards them to another service, the BAA is irrelevant to those flows
- Cover subprocessors automatically — Anthropic uses infrastructure providers of its own; your BAA does not automatically extend to every system in their stack
The minimum necessary standard (45 CFR § 164.502(b)) still applies. Even with a BAA, HIPAA requires you to think carefully about what PHI actually needs to be in the prompt, and whether you have legal standing to transmit each piece of it.
The ZDR paradox
Here’s the tension this creates for security-conscious teams: the strongest data minimization posture (ZDR) is explicitly incompatible with BAA coverage. You can have one or the other.
This is not a criticism of Anthropic — it reflects a genuine architectural constraint. Providing BAA compliance guarantees requires retaining data long enough to fulfill breach reporting obligations. But it means that teams who want both maximum privacy and BAA coverage need a different architectural approach.
The alternative: prevent before transmit
The most robust approach doesn’t depend on which provider you use or whether they have a BAA. It operates at the architecture layer: PHI is tokenized before the prompt leaves your network.
When your application routes through an inference proxy that applies reversible pseudonymization at the edge:
- Names become
[PERSON_1] - Medical record numbers become
[MRN_1] - SSNs become
[SSN_1] - Diagnoses tied to individuals become
[CONDITION_1]
The model — Claude, GPT, or any other — receives anonymized tokens. It reasons over the structure. Your system rehydrates the response with real values on the return path, in your infrastructure, before the user sees it.
The result: Anthropic (or any provider) never receives identifiable PHI. The 30-day retention policy retains tokens, not patient data. The ZDR paradox disappears, because there’s no PHI to retain in the first place.
The BAA still matters — it’s a legal requirement and provides breach notification coverage. But it becomes a secondary safeguard over a system where PHI leakage is architecturally prevented, not a primary compliance mechanism.
This is the principle behind Privedge: a single-line drop-in for any LLM SDK that tokenizes PHI at the Cloudflare edge before any external API call. Claude, OpenAI, Gemini — the provider’s BAA status becomes less critical when identifiable data never reaches them.
// Before — PHI reaches Claude verbatim
import Anthropic from '@anthropic-ai/sdk'
const anthropic = new Anthropic({ apiKey: process.env.ANTHROPIC_KEY })
// After — PHI anonymized at the edge before transmission
import Privedge from '@privedge/sdk'
const ai = new Privedge({
apiKey: process.env.PRIVEDGE_KEY,
workerUrl: 'https://edge.privedge.io',
})
const res = await ai.chat.completions.create({
model: 'claude-sonnet-4-6',
messages: [{ role: 'user', content: prompt }],
pii_strategy: 'anonymize',
})
Your existing code doesn’t change. What changes is that "Summarize treatment plan for John Smith (SSN 123-45-6789)" becomes "Summarize treatment plan for [PERSON_1] (SSN [SSN_1])" before it reaches any provider — BAA or not.
What this means in practice
If you’re evaluating Claude for healthcare AI in 2026, the right framing isn’t “does Anthropic have a BAA?” It’s:
- What PHI actually needs to reach the model? In most clinical AI use cases, the model needs clinical context — not patient identifiers. These are separable.
- What happens to the data that does reach the model? Under a BAA, Anthropic retains it for 30 days. Under ZDR, you can’t use BAA-covered models. Under an architectural proxy, there’s no identifiable data to retain.
- What are your audit trail obligations? HIPAA requires you to demonstrate what PHI was accessed and by whom. An inference proxy that logs metadata (not prompt content) provides this without retaining clinical data.
The Anthropic BAA is a step in the right direction for the healthcare AI ecosystem. It’s also a reminder that the hard part of HIPAA compliance isn’t finding a provider who will sign a BAA — it’s building an application where the right data reaches the right system, and nothing more.
If you want architectural HIPAA compliance that works with Claude, GPT, or any future model — without depending on any single vendor’s BAA status — Privedge is the starting point.
Protect your AI prompts with Privedge
Intercept personal data before it reaches OpenAI or any other provider. One-line change. No refactoring.
Get started freeFull guide
HIPAA-Compliant AI