>

Is Claude HIPAA compliant? What the BAA covers and what it doesn't

Is Claude HIPAA compliant? What the BAA covers and what it doesn't

By Mat Steinlin, Head of Information Security at Aptible

Last updated August 2026

If you're building a healthcare product and want to use Claude, the question you need to answer before sending any patient data is straightforward: does Anthropic offer a BAA?

A BAA (Business Associate Agreement) is a legal contract required under HIPAA before you share protected health information with a vendor. It establishes what the vendor can do with your data, what safeguards they must maintain, and their liability if a breach occurs. Without one, sending PHI to any third-party service (including an LLM provider) is a HIPAA violation.

Yes, Anthropic offers a BAA. But which product you're using determines how you get it, what it covers, and what you still need to build.

The Anthropic product lineup: which version has BAA coverage

Anthropic offers several products with different compliance postures. This matters because a developer who uses Claude.ai for a quick test is in a completely different situation from a team running Claude's API in production with a signed BAA.

Product

BAA available

Notes

Claude.ai (Free, Pro)

No

Consumer product. Do not use with PHI. (Source)

Claude.ai Team

No

Not designed for regulated data. (Source)

Claude for Enterprise (HIPAA-ready plan)

Yes

Enterprise admins can sign the BAA directly in admin settings when activating HIPAA compliance. API and self-managed accounts require the sales-assisted path. (Source)

Claude API (pre-Dec 2025 BAA)

Legacy

API BAAs signed before December 2, 2025 cover API usage only (via ZDR) — not Enterprise plan access. BAAs signed after that date can cover both under one agreement. (Source)

Claude API (BAA signed on/after April 1, 2026)

Yes

Adds a non-ZDR "HIPAA-configured" API org option, covering specific API features (Token Counting, Models, Org Management, Compliance APIs, and select Messages API features) without requiring Zero Data Retention. (Anthropic HIPAA-Ready Offering Implementation Guide, version July 16, 2026)

Claude Code (CLI)

Eligible with ZDR

BAA coverage requires Zero Data Retention (ZDR) to be enabled. ZDR is available for qualified accounts only — not automatic on any plan. Contact Anthropic sales to arrange. (Source)

Claude Code (Desktop local mode)

Eligible with ZDR

Covered under BAA when ZDR is enabled, same as CLI. (Source)

Claude Code (Desktop remote, Web, Review, Security, Computer Use)

No

Not covered under the BAA; incompatible with ZDR. (Source)

The most important distinction: Claude.ai is a consumer product. Claude for Enterprise is a separate, sales-negotiated offering with HIPAA-ready configuration. A clinician who pastes patient data into Claude.ai because "Anthropic is HIPAA compliant" has sent PHI to a consumer product with no BAA coverage. This is already happening at scale: surveys show 17% of healthcare workers admit using unapproved AI tools at work, most commonly for documentation.

A secondary one that trips up developers: Claude Code's BAA coverage is conditional and limited to the CLI, and only when Zero Data Retention is explicitly configured on your account. Beta features have no coverage path. See the FAQ below for the full breakdown.

What Anthropic's BAA covers

When you execute a BAA with Anthropic, you're establishing a legal agreement that:

  • Defines Anthropic as a business associate under HIPAA

  • Requires Anthropic to implement appropriate safeguards for PHI on their end

  • Establishes that your data is not used to train Anthropic's underlying models

  • Sets data retention terms (API data is retained briefly for trust and safety purposes, then deleted; consult your actual BAA for specifics)

  • Creates shared liability for how your data is handled on Anthropic's infrastructure

One nuance: "not used to train underlying models" isn't the same as "never touched." Anthropic's Implementation Guide states that usage data, including PHI, may be indexed, stored, and processed to improve and customize the Eligible Services for your specific organization. For example, tailoring Claude's outputs to your team. That's a narrower and more contained use than training the base model, but it's not nothing.

What the Anthropic Implementation Guide requires of you

Signing the BAA is just the beginning of your obligations. Their BAA (Section D.7) explicitly requires customers to comply with Anthropic's Implementation Guide for HIPAA Entities, and states that data submitted in a manner that doesn't comply with the Implementation Guide is not considered PHI under the BAA.

  • Prohibited uses. Claude Enterprise may not be used for direct patient-provider interactions, to diagnose patients, or for treatment purposes. Worth noting: these restrictions are not HIPAA requirements. HIPAA governs confidentiality and integrity of health information; it says nothing about clinical accuracy or the appropriateness of AI-generated medical advice. Anthropic has bundled these restrictions into the BAA as a legal vehicle, primarily as civil and tort liability protections. They are still contractually binding (you agreed to them when you signed) but they exist to protect Anthropic from malpractice-adjacent claims, not to satisfy a HIPAA mandate. You must comply with them regardless of that distinction.

  • Healthcare activities. For any use involving charting, billing, coding, claims processing, or clinical research, the Implementation Guide requires you to: (i) test Claude for accuracy in your specific use cases, (ii) confirm such use complies with applicable laws, and (iii) ensure that only duly trained and qualified individuals with the appropriate licenses or certifications for those activities use Claude in connection with them.

  • Workforce training. You must inform and train your workforce members on the appropriate use and limitations of the Eligible Services, including PHI handling, before provisioning access.

  • Authentication and access controls. The Implementation Guide requires you to implement user identification and authentication, consider SSO and MFA, periodically review user access levels, configure account lockouts after invalid login attempts, and implement automatic logoffs after inactivity.

  • PHI prohibited fields. PHI may be used in chats, session names, attachments, artifacts, and project names. It may not appear in user profile data, skills names, workspace or organization names, support tickets, or billing information. If PHI appears in those fields, Anthropic has no HIPAA obligations around it. This extends to support interactions: if you contact Anthropic support (support@anthropic.com, privacy@anthropic.com, or notices@anthropic.com), you cannot include PHI in the request itself or in attached screenshots or documents.

  • Role-based access control has an additive-permissions gotcha. If you use RBAC to segment users by PHI exposure (a restrictive role for PHI-handling users, a permissive role for everyone else) be aware that capability permissions are additive across groups. A user assigned to both a restrictive and a permissive group gets the permissive group's access, not the restrictive one. Group membership for PHI-handling users needs to be exclusive, or the restriction does nothing.

  • Third-party integrations (including MCP servers). The BAA does not cover third-party integrations: MCP servers, connectors, Desktop Extensions, skills, plugins, and Enterprise Search connectors are all explicitly outside BAA coverage. You are responsible for determining whether a separate BAA with each third party is needed and executing it. If you enable integrations that transmit PHI to external services, that data is governed by those third parties' own terms, not Anthropic's BAA.

  • Audit log retention. Anthropic's Compliance API retains audit logs for up to one year only. You are responsible for exporting those logs and maintaining them independently for the remaining five-plus years required under HIPAA's six-year retention standard.

  • Data backup. You are responsible for implementing backup and recovery procedures for emergency access to PHI. Anthropic does not maintain a Designated Record Set or separate backup of your PHI.

What Anthropic's BAA does not cover

When you execute a BAA with Anthropic, it governs how Anthropic handles PHI within their infrastructure. It does not cover what happens before the request is sent or after the response is returned.

In practice, most HIPAA failures with LLM usage happen in this layer, not at the provider.

The BAA does not cover:

  • Your audit logging. Anthropic does not log prompts and responses in a way that satisfies HIPAA audit requirements. If you cannot show who accessed what data and when, you have a gap.

  • Storage and retention of those logs. The logs you generate contain PHI. They must be encrypted at rest with controlled access. And critically: Anthropic's Compliance API only retains audit logs for one year. You must export and independently store them for the remaining five-plus years that HIPAA requires.

  • Key management: API keys must be scoped, rotated, and controlled across environments. The BAA does not address how your organization manages credentials

  • Access controls: you are responsible for enforcing which users and systems can send PHI to Claude and under what conditions.

  • Third-party integrations. MCP servers, connectors, Desktop Extensions, and Enterprise Search connectors are explicitly excluded from BAA coverage. PHI transmitted through these integrations is not covered by Anthropic's BAA. You must evaluate and execute separate BAAs with each third party, or disable the integrations entirely.

  • Other vendors in your stack: your database, logging pipeline, analytics tools, and any downstream systems that touch PHI all require their own controls and, where applicable, BAAs.

A signed BAA ensures Anthropic is operating as a compliant business associate. It does not make your system compliant.

A common failure pattern

A typical implementation looks compliant on the surface:

  • The team signs a BAA with Anthropic

  • PHI is sent only through approved API paths

  • Every prompt and response is logged for auditability

At this point, many teams believe they are covered.

The failure happens in the next step.

Those logs are often shipped into an existing observability or analytics stack such as a log aggregator, search index, or data warehouse. That system was designed for operational telemetry, not regulated data. As a result:

  • Logs may be stored in plaintext or with weak encryption

  • Access is broader than intended, often including engineering or support teams that do not require PHI access

  • Retention policies are short lived or inconsistent with HIPAA requirements

  • Data may be copied into downstream systems for debugging, dashboards, or machine learning workflows

At that moment, the compliance boundary has shifted.

The interaction with the model is compliant under the BAA. The system storing and exposing that same data is not.

Getting the BAA: what to expect

Anthropic's Enterprise plan can be purchased self-serve or through a sales-assisted process. The self-serve path gets you the plan, but it does not get you a BAA. BAA coverage and ZDR configuration are only available through the sales-assisted path.

The process: Contact Anthropic's sales team, review the BAA and implementation guide, execute the agreement, and configure the plan with your account team. Plan for this to take weeks, not days. If you're building toward a go-live with a health system customer and need a signed BAA before their security team will approve you, start this conversation early.

If you have an existing API BAA: BAAs signed with Anthropic before December 2, 2025 cover API usage only (via ZDR) and do not extend to the HIPAA-ready Enterprise plan. BAAs signed after that date can cover both under a single agreement. If you have an older API BAA and need Enterprise coverage, you'll need to sign a new one with your account team.

If your BAA was signed on or after April 1, 2026: You have an additional option for API coverage beyond ZDR. Anthropic added a non-ZDR "HIPAA-configured" API organization type, which covers a specific set of API features under the HIPAA configuration without requiring Zero Data Retention: Token Counting, Models, Org Management, and Compliance APIs, plus select Messages API features (Prompt Caching, Structured Outputs, Memory, Web Search, Bash tool, Text Editor tool). This is separate from ZDR-enabled API access, which still works and still covers the full API surface. Only API keys belonging to a HIPAA-configured or ZDR-enabled organization should be used to transmit PHI (keys on a standard organization are never covered, BAA or not).

Claude Code requires ZDR: The CLI can be covered under a BAA, but only if Zero Data Retention (ZDR) is enabled, and ZDR is available for qualified accounts only, not automatically on any plan. You need to contact Anthropic sales to arrange it. If you have an Enterprise agreement and haven't explicitly configured ZDR, your Claude Code usage is not covered. Claude Code's beta features (Web, Desktop, Review, Security, Computer Use) are not covered under the BAA and are incompatible with ZDR entirely; there is no path to coverage for those.

Claude Code: CLI coverage requires Zero Data Retention to be configured; available for qualified accounts only, not automatic on any plan. Beta features (Web, Desktop, Review, Security, Computer Use) cannot be covered regardless of plan or configuration. Contact Anthropic sales to discuss eligibility.

What affects timeline: Anthropic is a fast-growing company and their enterprise compliance process reflects that. Teams have encountered delays getting BAAs executed, particularly compared to cloud providers like AWS where a BAA is part of the standard enterprise agreement. Don't assume you can close a healthcare deal and then get the BAA in place before your customer's onboarding date.

The multi-model problem: If your application uses Claude for some tasks and OpenAI or AWS Bedrock for others, you need separate BAAs with each provider. This creates contract management overhead and increases the risk of accidentally routing PHI through an uncovered path when models are swapped for testing or performance reasons. An LLM gateway that covers all your LLM traffic under a single BAA eliminates this problem.

What you still need to build

Executing a BAA with Anthropic is step one. The infrastructure underneath it is still your responsibility.

HIPAA's technical safeguards (45 CFR 164.312) require controls on any system that handles PHI. When your system calls Claude with patient data, those controls apply to the call:

Audit logging. Every prompt and response that involves PHI needs to be logged with timestamps, user attribution, and model identity. Anthropic provides a Compliance API that supports access and activity monitoring, but it only retains logs for up to one year. You are responsible for exporting those logs and storing them independently for the full six years HIPAA requires.

Log retention and access controls. Logs must be retained for six years and access-controlled so only authorized personnel can view them. Retention is typically the harder problem; encryption at rest is often provided by default, but maintaining six years of logs in a queryable, access-controlled system requires explicit infrastructure decisions. Equally important: giving developers broad access to logs containing unredacted PHI for debugging is itself a HIPAA violation. HIPAA requires least-privilege access to PHI regardless of whether the underlying model interaction was covered. Logs are not exempt from that requirement.

Log retention. Audit logs must be retained for six years under HIPAA. Your operational log pipeline probably isn't designed for this. You need a log drain to long-term storage with appropriate retention enforcement.

PHI de-identification (defense in depth, not required). De-identification is not required by HIPAA or by Anthropic's BAA; if you have a valid BAA in place, sending PHI to Claude is a permitted use. But de-identifying before the prompt and re-identifying after the response reduces your exposure if controls elsewhere fail. It limits breach scope and adds a meaningful layer of protection for high-sensitivity workflows.

Key management. Anthropic gives you API keys. For a small team, that's manageable. For a growing organization, you need scoping by application, team, and environment — and the ability to rotate or revoke keys without affecting unrelated systems.

Access controls. Which users and systems in your organization can send PHI to Claude? How is that enforced? For HIPAA, you need to be able to demonstrate who accessed what and when.

For a full breakdown of these requirements in the context of LLM usage, see HIPAA-Compliant AI: What Developers Need to Know.

The developer workflow risk

Production AI features are not the only surface to worry about.

Engineers use Claude in debugging workflows, internal tooling, and data exploration. When a developer runs Claude Code in a codebase that contains PHI (in test fixtures, database dumps, or log files) those interactions are in scope. If your team's development environment isn't covered by your BAA and doesn't have the same controls as production, you have a gap.

The same applies to any automated tooling that calls Claude as part of its operation. A tool that uses Claude to analyze your AWS compliance posture, for example, may not have PHI flowing through it directly, but if it operates in an environment where PHI is present, the configuration matters.

The practical question is not just "did we sign a BAA?" but "do we have visibility into everywhere Claude is being used, and are all of those paths covered?"

How Aptible AI Gateway covers what Anthropic's BAA doesn't

Aptible LLM Gateway is a managed compliance layer that sits between your application and LLM providers. When you route Claude traffic through AI Gateway:

  • One BAA covers everything. Your Aptible BAA covers all AI Gateway usage, across all supported models. You don't need separate BAAs with Anthropic, OpenAI, or AWS Bedrock.

  • Audit logging is automatic. Every prompt and response is logged with full metadata, encrypted at rest, and available for compliance review. You don't build the logging pipeline.

  • PHI de-identification is built in. Sensitive data is scrubbed before it reaches the model and restored after the response returns.

  • Key management is handled. Scopes for applications, teams, and environments give you attribution and control without managing it in application code.

  • Switching models doesn't restart compliance. You can move between Claude, OpenAI, and Bedrock models without re-implementing controls or negotiating new BAAs.

For teams building in digital health who want to use Claude without building the compliance infrastructure themselves, LLM Gateway removes the implementation burden.

FAQs

Is Claude HIPAA compliant?

Not by default. Claude for Enterprise with a signed BAA can be used in a HIPAA-compliant implementation; if you've also built the required infrastructure around it (audit logging, encryption, access controls). Claude.ai in all its consumer tiers (Free, Pro, Team) does not offer a BAA and should not be used with PHI. Compliance depends on implementation, not the product itself.

Is Claude.ai HIPAA compliant?

No. Claude.ai Free, Pro, and Team do not offer BAAs. Do not use them with real patient data, including in testing or debugging. Claude for Enterprise is a separate, sales-negotiated product.

How do I get a BAA with Anthropic?

It depends on how you're using Claude. Enterprise admins can sign the BAA directly in admin settings when activating HIPAA compliance. For API or self-managed accounts, you'll need to go through Anthropic's sales team. If you have a legacy API BAA from before December 2, 2025, it covers API usage only (via ZDR) and does not extend to the Enterprise plan. BAAs signed after that date can cover both. BAAs signed on or after April 1, 2026 add a further option: a non-ZDR "HIPAA-configured" API org covering a specific set of API features without requiring Zero Data Retention.

Can I use Claude Code with PHI?

It depends on which Claude Code surface and whether your account has Zero Data Retention (ZDR) enabled.

The CLI can be covered under an Anthropic BAA, but only if ZDR is enabled on your account. ZDR is not automatic — it's available for qualified accounts only and requires working with Anthropic sales to configure. If you have an Enterprise agreement but haven't set up ZDR, your Claude Code CLI usage is not covered.

One additional constraint: Fable and Mythos are covered under the BAA generally, but Anthropic's Implementation Guide states they are incompatible with any product using Zero Data Retention. This isn't unique to Claude Code. It applies to any ZDR-based path, which historically has included ZDR-enabled API access as well. Enterprise Chat, which uses the HIPAA configuration rather than ZDR, is not affected by this restriction. If your team needs BAA-covered Claude Code CLI usage (which requires ZDR) alongside BAA-covered access to Fable or Mythos in another context, those require separate Anthropic organization configurations; check with your Anthropic account team for the current setup, since Anthropic's coverage details for these models have changed more than once in 2026.

Desktop local mode is also covered when ZDR is enabled. Desktop remote mode, the web version, and features including Code Review, Security, Computer Use, and Remote Control are not covered under the BAA and are incompatible with ZDR. There is no coverage path for those surfaces under the current Anthropic offering.

The practical default: if your developers use Claude Code in environments where PHI may be present, assume that usage is outside your BAA unless you've explicitly verified ZDR is configured on your account.

Does Anthropic train on my data?

Not for training the underlying models; that's consistent across API and Enterprise use. But Anthropic's Implementation Guide draws a distinction worth knowing: your usage data, including PHI, may still be indexed, stored, and processed to customize and improve the Eligible Services specifically for your organization. That's a narrower use than training Anthropic's base models, but it means "no training" doesn't mean your data is entirely untouched. What matters legally is what your BAA and the Implementation Guide say, not what a policy page implies (policies can change, contracts are enforceable).

What's the difference between HIPAA eligible and HIPAA compliant for Claude?

"HIPAA eligible" means Anthropic will sign a BAA. "HIPAA compliant" means your full implementation meets HIPAA requirements. Getting a BAA is necessary. Your audit logging, encryption, access controls, and the rest of the compliance infrastructure are still your responsibility to implement correctly.


__

For the full technical requirements for HIPAA-compliant LLM usage, see HIPAA-Compliant AI: What Developers Need to Know. For BAA requirements more broadly, see What is a HIPAA BAA. For details on how AI vendor BAA works specifically, see What an AI BAA Actually Covers.

>

Is Claude HIPAA compliant? What the BAA covers and what it doesn't

Is Claude HIPAA compliant? What the BAA covers and what it doesn't

By Mat Steinlin, Head of Information Security at Aptible

Last updated August 2026

If you're building a healthcare product and want to use Claude, the question you need to answer before sending any patient data is straightforward: does Anthropic offer a BAA?

A BAA (Business Associate Agreement) is a legal contract required under HIPAA before you share protected health information with a vendor. It establishes what the vendor can do with your data, what safeguards they must maintain, and their liability if a breach occurs. Without one, sending PHI to any third-party service (including an LLM provider) is a HIPAA violation.

Yes, Anthropic offers a BAA. But which product you're using determines how you get it, what it covers, and what you still need to build.

The Anthropic product lineup: which version has BAA coverage

Anthropic offers several products with different compliance postures. This matters because a developer who uses Claude.ai for a quick test is in a completely different situation from a team running Claude's API in production with a signed BAA.

Product

BAA available

Notes

Claude.ai (Free, Pro)

No

Consumer product. Do not use with PHI. (Source)

Claude.ai Team

No

Not designed for regulated data. (Source)

Claude for Enterprise (HIPAA-ready plan)

Yes

Enterprise admins can sign the BAA directly in admin settings when activating HIPAA compliance. API and self-managed accounts require the sales-assisted path. (Source)

Claude API (pre-Dec 2025 BAA)

Legacy

API BAAs signed before December 2, 2025 cover API usage only (via ZDR) — not Enterprise plan access. BAAs signed after that date can cover both under one agreement. (Source)

Claude API (BAA signed on/after April 1, 2026)

Yes

Adds a non-ZDR "HIPAA-configured" API org option, covering specific API features (Token Counting, Models, Org Management, Compliance APIs, and select Messages API features) without requiring Zero Data Retention. (Anthropic HIPAA-Ready Offering Implementation Guide, version July 16, 2026)

Claude Code (CLI)

Eligible with ZDR

BAA coverage requires Zero Data Retention (ZDR) to be enabled. ZDR is available for qualified accounts only — not automatic on any plan. Contact Anthropic sales to arrange. (Source)

Claude Code (Desktop local mode)

Eligible with ZDR

Covered under BAA when ZDR is enabled, same as CLI. (Source)

Claude Code (Desktop remote, Web, Review, Security, Computer Use)

No

Not covered under the BAA; incompatible with ZDR. (Source)

The most important distinction: Claude.ai is a consumer product. Claude for Enterprise is a separate, sales-negotiated offering with HIPAA-ready configuration. A clinician who pastes patient data into Claude.ai because "Anthropic is HIPAA compliant" has sent PHI to a consumer product with no BAA coverage. This is already happening at scale: surveys show 17% of healthcare workers admit using unapproved AI tools at work, most commonly for documentation.

A secondary one that trips up developers: Claude Code's BAA coverage is conditional and limited to the CLI, and only when Zero Data Retention is explicitly configured on your account. Beta features have no coverage path. See the FAQ below for the full breakdown.

What Anthropic's BAA covers

When you execute a BAA with Anthropic, you're establishing a legal agreement that:

  • Defines Anthropic as a business associate under HIPAA

  • Requires Anthropic to implement appropriate safeguards for PHI on their end

  • Establishes that your data is not used to train Anthropic's underlying models

  • Sets data retention terms (API data is retained briefly for trust and safety purposes, then deleted; consult your actual BAA for specifics)

  • Creates shared liability for how your data is handled on Anthropic's infrastructure

One nuance: "not used to train underlying models" isn't the same as "never touched." Anthropic's Implementation Guide states that usage data, including PHI, may be indexed, stored, and processed to improve and customize the Eligible Services for your specific organization. For example, tailoring Claude's outputs to your team. That's a narrower and more contained use than training the base model, but it's not nothing.

What the Anthropic Implementation Guide requires of you

Signing the BAA is just the beginning of your obligations. Their BAA (Section D.7) explicitly requires customers to comply with Anthropic's Implementation Guide for HIPAA Entities, and states that data submitted in a manner that doesn't comply with the Implementation Guide is not considered PHI under the BAA.

  • Prohibited uses. Claude Enterprise may not be used for direct patient-provider interactions, to diagnose patients, or for treatment purposes. Worth noting: these restrictions are not HIPAA requirements. HIPAA governs confidentiality and integrity of health information; it says nothing about clinical accuracy or the appropriateness of AI-generated medical advice. Anthropic has bundled these restrictions into the BAA as a legal vehicle, primarily as civil and tort liability protections. They are still contractually binding (you agreed to them when you signed) but they exist to protect Anthropic from malpractice-adjacent claims, not to satisfy a HIPAA mandate. You must comply with them regardless of that distinction.

  • Healthcare activities. For any use involving charting, billing, coding, claims processing, or clinical research, the Implementation Guide requires you to: (i) test Claude for accuracy in your specific use cases, (ii) confirm such use complies with applicable laws, and (iii) ensure that only duly trained and qualified individuals with the appropriate licenses or certifications for those activities use Claude in connection with them.

  • Workforce training. You must inform and train your workforce members on the appropriate use and limitations of the Eligible Services, including PHI handling, before provisioning access.

  • Authentication and access controls. The Implementation Guide requires you to implement user identification and authentication, consider SSO and MFA, periodically review user access levels, configure account lockouts after invalid login attempts, and implement automatic logoffs after inactivity.

  • PHI prohibited fields. PHI may be used in chats, session names, attachments, artifacts, and project names. It may not appear in user profile data, skills names, workspace or organization names, support tickets, or billing information. If PHI appears in those fields, Anthropic has no HIPAA obligations around it. This extends to support interactions: if you contact Anthropic support (support@anthropic.com, privacy@anthropic.com, or notices@anthropic.com), you cannot include PHI in the request itself or in attached screenshots or documents.

  • Role-based access control has an additive-permissions gotcha. If you use RBAC to segment users by PHI exposure (a restrictive role for PHI-handling users, a permissive role for everyone else) be aware that capability permissions are additive across groups. A user assigned to both a restrictive and a permissive group gets the permissive group's access, not the restrictive one. Group membership for PHI-handling users needs to be exclusive, or the restriction does nothing.

  • Third-party integrations (including MCP servers). The BAA does not cover third-party integrations: MCP servers, connectors, Desktop Extensions, skills, plugins, and Enterprise Search connectors are all explicitly outside BAA coverage. You are responsible for determining whether a separate BAA with each third party is needed and executing it. If you enable integrations that transmit PHI to external services, that data is governed by those third parties' own terms, not Anthropic's BAA.

  • Audit log retention. Anthropic's Compliance API retains audit logs for up to one year only. You are responsible for exporting those logs and maintaining them independently for the remaining five-plus years required under HIPAA's six-year retention standard.

  • Data backup. You are responsible for implementing backup and recovery procedures for emergency access to PHI. Anthropic does not maintain a Designated Record Set or separate backup of your PHI.

What Anthropic's BAA does not cover

When you execute a BAA with Anthropic, it governs how Anthropic handles PHI within their infrastructure. It does not cover what happens before the request is sent or after the response is returned.

In practice, most HIPAA failures with LLM usage happen in this layer, not at the provider.

The BAA does not cover:

  • Your audit logging. Anthropic does not log prompts and responses in a way that satisfies HIPAA audit requirements. If you cannot show who accessed what data and when, you have a gap.

  • Storage and retention of those logs. The logs you generate contain PHI. They must be encrypted at rest with controlled access. And critically: Anthropic's Compliance API only retains audit logs for one year. You must export and independently store them for the remaining five-plus years that HIPAA requires.

  • Key management: API keys must be scoped, rotated, and controlled across environments. The BAA does not address how your organization manages credentials

  • Access controls: you are responsible for enforcing which users and systems can send PHI to Claude and under what conditions.

  • Third-party integrations. MCP servers, connectors, Desktop Extensions, and Enterprise Search connectors are explicitly excluded from BAA coverage. PHI transmitted through these integrations is not covered by Anthropic's BAA. You must evaluate and execute separate BAAs with each third party, or disable the integrations entirely.

  • Other vendors in your stack: your database, logging pipeline, analytics tools, and any downstream systems that touch PHI all require their own controls and, where applicable, BAAs.

A signed BAA ensures Anthropic is operating as a compliant business associate. It does not make your system compliant.

A common failure pattern

A typical implementation looks compliant on the surface:

  • The team signs a BAA with Anthropic

  • PHI is sent only through approved API paths

  • Every prompt and response is logged for auditability

At this point, many teams believe they are covered.

The failure happens in the next step.

Those logs are often shipped into an existing observability or analytics stack such as a log aggregator, search index, or data warehouse. That system was designed for operational telemetry, not regulated data. As a result:

  • Logs may be stored in plaintext or with weak encryption

  • Access is broader than intended, often including engineering or support teams that do not require PHI access

  • Retention policies are short lived or inconsistent with HIPAA requirements

  • Data may be copied into downstream systems for debugging, dashboards, or machine learning workflows

At that moment, the compliance boundary has shifted.

The interaction with the model is compliant under the BAA. The system storing and exposing that same data is not.

Getting the BAA: what to expect

Anthropic's Enterprise plan can be purchased self-serve or through a sales-assisted process. The self-serve path gets you the plan, but it does not get you a BAA. BAA coverage and ZDR configuration are only available through the sales-assisted path.

The process: Contact Anthropic's sales team, review the BAA and implementation guide, execute the agreement, and configure the plan with your account team. Plan for this to take weeks, not days. If you're building toward a go-live with a health system customer and need a signed BAA before their security team will approve you, start this conversation early.

If you have an existing API BAA: BAAs signed with Anthropic before December 2, 2025 cover API usage only (via ZDR) and do not extend to the HIPAA-ready Enterprise plan. BAAs signed after that date can cover both under a single agreement. If you have an older API BAA and need Enterprise coverage, you'll need to sign a new one with your account team.

If your BAA was signed on or after April 1, 2026: You have an additional option for API coverage beyond ZDR. Anthropic added a non-ZDR "HIPAA-configured" API organization type, which covers a specific set of API features under the HIPAA configuration without requiring Zero Data Retention: Token Counting, Models, Org Management, and Compliance APIs, plus select Messages API features (Prompt Caching, Structured Outputs, Memory, Web Search, Bash tool, Text Editor tool). This is separate from ZDR-enabled API access, which still works and still covers the full API surface. Only API keys belonging to a HIPAA-configured or ZDR-enabled organization should be used to transmit PHI (keys on a standard organization are never covered, BAA or not).

Claude Code requires ZDR: The CLI can be covered under a BAA, but only if Zero Data Retention (ZDR) is enabled, and ZDR is available for qualified accounts only, not automatically on any plan. You need to contact Anthropic sales to arrange it. If you have an Enterprise agreement and haven't explicitly configured ZDR, your Claude Code usage is not covered. Claude Code's beta features (Web, Desktop, Review, Security, Computer Use) are not covered under the BAA and are incompatible with ZDR entirely; there is no path to coverage for those.

Claude Code: CLI coverage requires Zero Data Retention to be configured; available for qualified accounts only, not automatic on any plan. Beta features (Web, Desktop, Review, Security, Computer Use) cannot be covered regardless of plan or configuration. Contact Anthropic sales to discuss eligibility.

What affects timeline: Anthropic is a fast-growing company and their enterprise compliance process reflects that. Teams have encountered delays getting BAAs executed, particularly compared to cloud providers like AWS where a BAA is part of the standard enterprise agreement. Don't assume you can close a healthcare deal and then get the BAA in place before your customer's onboarding date.

The multi-model problem: If your application uses Claude for some tasks and OpenAI or AWS Bedrock for others, you need separate BAAs with each provider. This creates contract management overhead and increases the risk of accidentally routing PHI through an uncovered path when models are swapped for testing or performance reasons. An LLM gateway that covers all your LLM traffic under a single BAA eliminates this problem.

What you still need to build

Executing a BAA with Anthropic is step one. The infrastructure underneath it is still your responsibility.

HIPAA's technical safeguards (45 CFR 164.312) require controls on any system that handles PHI. When your system calls Claude with patient data, those controls apply to the call:

Audit logging. Every prompt and response that involves PHI needs to be logged with timestamps, user attribution, and model identity. Anthropic provides a Compliance API that supports access and activity monitoring, but it only retains logs for up to one year. You are responsible for exporting those logs and storing them independently for the full six years HIPAA requires.

Log retention and access controls. Logs must be retained for six years and access-controlled so only authorized personnel can view them. Retention is typically the harder problem; encryption at rest is often provided by default, but maintaining six years of logs in a queryable, access-controlled system requires explicit infrastructure decisions. Equally important: giving developers broad access to logs containing unredacted PHI for debugging is itself a HIPAA violation. HIPAA requires least-privilege access to PHI regardless of whether the underlying model interaction was covered. Logs are not exempt from that requirement.

Log retention. Audit logs must be retained for six years under HIPAA. Your operational log pipeline probably isn't designed for this. You need a log drain to long-term storage with appropriate retention enforcement.

PHI de-identification (defense in depth, not required). De-identification is not required by HIPAA or by Anthropic's BAA; if you have a valid BAA in place, sending PHI to Claude is a permitted use. But de-identifying before the prompt and re-identifying after the response reduces your exposure if controls elsewhere fail. It limits breach scope and adds a meaningful layer of protection for high-sensitivity workflows.

Key management. Anthropic gives you API keys. For a small team, that's manageable. For a growing organization, you need scoping by application, team, and environment — and the ability to rotate or revoke keys without affecting unrelated systems.

Access controls. Which users and systems in your organization can send PHI to Claude? How is that enforced? For HIPAA, you need to be able to demonstrate who accessed what and when.

For a full breakdown of these requirements in the context of LLM usage, see HIPAA-Compliant AI: What Developers Need to Know.

The developer workflow risk

Production AI features are not the only surface to worry about.

Engineers use Claude in debugging workflows, internal tooling, and data exploration. When a developer runs Claude Code in a codebase that contains PHI (in test fixtures, database dumps, or log files) those interactions are in scope. If your team's development environment isn't covered by your BAA and doesn't have the same controls as production, you have a gap.

The same applies to any automated tooling that calls Claude as part of its operation. A tool that uses Claude to analyze your AWS compliance posture, for example, may not have PHI flowing through it directly, but if it operates in an environment where PHI is present, the configuration matters.

The practical question is not just "did we sign a BAA?" but "do we have visibility into everywhere Claude is being used, and are all of those paths covered?"

How Aptible AI Gateway covers what Anthropic's BAA doesn't

Aptible LLM Gateway is a managed compliance layer that sits between your application and LLM providers. When you route Claude traffic through AI Gateway:

  • One BAA covers everything. Your Aptible BAA covers all AI Gateway usage, across all supported models. You don't need separate BAAs with Anthropic, OpenAI, or AWS Bedrock.

  • Audit logging is automatic. Every prompt and response is logged with full metadata, encrypted at rest, and available for compliance review. You don't build the logging pipeline.

  • PHI de-identification is built in. Sensitive data is scrubbed before it reaches the model and restored after the response returns.

  • Key management is handled. Scopes for applications, teams, and environments give you attribution and control without managing it in application code.

  • Switching models doesn't restart compliance. You can move between Claude, OpenAI, and Bedrock models without re-implementing controls or negotiating new BAAs.

For teams building in digital health who want to use Claude without building the compliance infrastructure themselves, LLM Gateway removes the implementation burden.

FAQs

Is Claude HIPAA compliant?

Not by default. Claude for Enterprise with a signed BAA can be used in a HIPAA-compliant implementation; if you've also built the required infrastructure around it (audit logging, encryption, access controls). Claude.ai in all its consumer tiers (Free, Pro, Team) does not offer a BAA and should not be used with PHI. Compliance depends on implementation, not the product itself.

Is Claude.ai HIPAA compliant?

No. Claude.ai Free, Pro, and Team do not offer BAAs. Do not use them with real patient data, including in testing or debugging. Claude for Enterprise is a separate, sales-negotiated product.

How do I get a BAA with Anthropic?

It depends on how you're using Claude. Enterprise admins can sign the BAA directly in admin settings when activating HIPAA compliance. For API or self-managed accounts, you'll need to go through Anthropic's sales team. If you have a legacy API BAA from before December 2, 2025, it covers API usage only (via ZDR) and does not extend to the Enterprise plan. BAAs signed after that date can cover both. BAAs signed on or after April 1, 2026 add a further option: a non-ZDR "HIPAA-configured" API org covering a specific set of API features without requiring Zero Data Retention.

Can I use Claude Code with PHI?

It depends on which Claude Code surface and whether your account has Zero Data Retention (ZDR) enabled.

The CLI can be covered under an Anthropic BAA, but only if ZDR is enabled on your account. ZDR is not automatic — it's available for qualified accounts only and requires working with Anthropic sales to configure. If you have an Enterprise agreement but haven't set up ZDR, your Claude Code CLI usage is not covered.

One additional constraint: Fable and Mythos are covered under the BAA generally, but Anthropic's Implementation Guide states they are incompatible with any product using Zero Data Retention. This isn't unique to Claude Code. It applies to any ZDR-based path, which historically has included ZDR-enabled API access as well. Enterprise Chat, which uses the HIPAA configuration rather than ZDR, is not affected by this restriction. If your team needs BAA-covered Claude Code CLI usage (which requires ZDR) alongside BAA-covered access to Fable or Mythos in another context, those require separate Anthropic organization configurations; check with your Anthropic account team for the current setup, since Anthropic's coverage details for these models have changed more than once in 2026.

Desktop local mode is also covered when ZDR is enabled. Desktop remote mode, the web version, and features including Code Review, Security, Computer Use, and Remote Control are not covered under the BAA and are incompatible with ZDR. There is no coverage path for those surfaces under the current Anthropic offering.

The practical default: if your developers use Claude Code in environments where PHI may be present, assume that usage is outside your BAA unless you've explicitly verified ZDR is configured on your account.

Does Anthropic train on my data?

Not for training the underlying models; that's consistent across API and Enterprise use. But Anthropic's Implementation Guide draws a distinction worth knowing: your usage data, including PHI, may still be indexed, stored, and processed to customize and improve the Eligible Services specifically for your organization. That's a narrower use than training Anthropic's base models, but it means "no training" doesn't mean your data is entirely untouched. What matters legally is what your BAA and the Implementation Guide say, not what a policy page implies (policies can change, contracts are enforceable).

What's the difference between HIPAA eligible and HIPAA compliant for Claude?

"HIPAA eligible" means Anthropic will sign a BAA. "HIPAA compliant" means your full implementation meets HIPAA requirements. Getting a BAA is necessary. Your audit logging, encryption, access controls, and the rest of the compliance infrastructure are still your responsibility to implement correctly.


__

For the full technical requirements for HIPAA-compliant LLM usage, see HIPAA-Compliant AI: What Developers Need to Know. For BAA requirements more broadly, see What is a HIPAA BAA. For details on how AI vendor BAA works specifically, see What an AI BAA Actually Covers.

>

Is Claude HIPAA compliant? What the BAA covers and what it doesn't

Is Claude HIPAA compliant? What the BAA covers and what it doesn't

By Mat Steinlin, Head of Information Security at Aptible

Last updated August 2026

If you're building a healthcare product and want to use Claude, the question you need to answer before sending any patient data is straightforward: does Anthropic offer a BAA?

A BAA (Business Associate Agreement) is a legal contract required under HIPAA before you share protected health information with a vendor. It establishes what the vendor can do with your data, what safeguards they must maintain, and their liability if a breach occurs. Without one, sending PHI to any third-party service (including an LLM provider) is a HIPAA violation.

Yes, Anthropic offers a BAA. But which product you're using determines how you get it, what it covers, and what you still need to build.

The Anthropic product lineup: which version has BAA coverage

Anthropic offers several products with different compliance postures. This matters because a developer who uses Claude.ai for a quick test is in a completely different situation from a team running Claude's API in production with a signed BAA.

Product

BAA available

Notes

Claude.ai (Free, Pro)

No

Consumer product. Do not use with PHI. (Source)

Claude.ai Team

No

Not designed for regulated data. (Source)

Claude for Enterprise (HIPAA-ready plan)

Yes

Enterprise admins can sign the BAA directly in admin settings when activating HIPAA compliance. API and self-managed accounts require the sales-assisted path. (Source)

Claude API (pre-Dec 2025 BAA)

Legacy

API BAAs signed before December 2, 2025 cover API usage only (via ZDR) — not Enterprise plan access. BAAs signed after that date can cover both under one agreement. (Source)

Claude API (BAA signed on/after April 1, 2026)

Yes

Adds a non-ZDR "HIPAA-configured" API org option, covering specific API features (Token Counting, Models, Org Management, Compliance APIs, and select Messages API features) without requiring Zero Data Retention. (Anthropic HIPAA-Ready Offering Implementation Guide, version July 16, 2026)

Claude Code (CLI)

Eligible with ZDR

BAA coverage requires Zero Data Retention (ZDR) to be enabled. ZDR is available for qualified accounts only — not automatic on any plan. Contact Anthropic sales to arrange. (Source)

Claude Code (Desktop local mode)

Eligible with ZDR

Covered under BAA when ZDR is enabled, same as CLI. (Source)

Claude Code (Desktop remote, Web, Review, Security, Computer Use)

No

Not covered under the BAA; incompatible with ZDR. (Source)

The most important distinction: Claude.ai is a consumer product. Claude for Enterprise is a separate, sales-negotiated offering with HIPAA-ready configuration. A clinician who pastes patient data into Claude.ai because "Anthropic is HIPAA compliant" has sent PHI to a consumer product with no BAA coverage. This is already happening at scale: surveys show 17% of healthcare workers admit using unapproved AI tools at work, most commonly for documentation.

A secondary one that trips up developers: Claude Code's BAA coverage is conditional and limited to the CLI, and only when Zero Data Retention is explicitly configured on your account. Beta features have no coverage path. See the FAQ below for the full breakdown.

What Anthropic's BAA covers

When you execute a BAA with Anthropic, you're establishing a legal agreement that:

  • Defines Anthropic as a business associate under HIPAA

  • Requires Anthropic to implement appropriate safeguards for PHI on their end

  • Establishes that your data is not used to train Anthropic's underlying models

  • Sets data retention terms (API data is retained briefly for trust and safety purposes, then deleted; consult your actual BAA for specifics)

  • Creates shared liability for how your data is handled on Anthropic's infrastructure

One nuance: "not used to train underlying models" isn't the same as "never touched." Anthropic's Implementation Guide states that usage data, including PHI, may be indexed, stored, and processed to improve and customize the Eligible Services for your specific organization. For example, tailoring Claude's outputs to your team. That's a narrower and more contained use than training the base model, but it's not nothing.

What the Anthropic Implementation Guide requires of you

Signing the BAA is just the beginning of your obligations. Their BAA (Section D.7) explicitly requires customers to comply with Anthropic's Implementation Guide for HIPAA Entities, and states that data submitted in a manner that doesn't comply with the Implementation Guide is not considered PHI under the BAA.

  • Prohibited uses. Claude Enterprise may not be used for direct patient-provider interactions, to diagnose patients, or for treatment purposes. Worth noting: these restrictions are not HIPAA requirements. HIPAA governs confidentiality and integrity of health information; it says nothing about clinical accuracy or the appropriateness of AI-generated medical advice. Anthropic has bundled these restrictions into the BAA as a legal vehicle, primarily as civil and tort liability protections. They are still contractually binding (you agreed to them when you signed) but they exist to protect Anthropic from malpractice-adjacent claims, not to satisfy a HIPAA mandate. You must comply with them regardless of that distinction.

  • Healthcare activities. For any use involving charting, billing, coding, claims processing, or clinical research, the Implementation Guide requires you to: (i) test Claude for accuracy in your specific use cases, (ii) confirm such use complies with applicable laws, and (iii) ensure that only duly trained and qualified individuals with the appropriate licenses or certifications for those activities use Claude in connection with them.

  • Workforce training. You must inform and train your workforce members on the appropriate use and limitations of the Eligible Services, including PHI handling, before provisioning access.

  • Authentication and access controls. The Implementation Guide requires you to implement user identification and authentication, consider SSO and MFA, periodically review user access levels, configure account lockouts after invalid login attempts, and implement automatic logoffs after inactivity.

  • PHI prohibited fields. PHI may be used in chats, session names, attachments, artifacts, and project names. It may not appear in user profile data, skills names, workspace or organization names, support tickets, or billing information. If PHI appears in those fields, Anthropic has no HIPAA obligations around it. This extends to support interactions: if you contact Anthropic support (support@anthropic.com, privacy@anthropic.com, or notices@anthropic.com), you cannot include PHI in the request itself or in attached screenshots or documents.

  • Role-based access control has an additive-permissions gotcha. If you use RBAC to segment users by PHI exposure (a restrictive role for PHI-handling users, a permissive role for everyone else) be aware that capability permissions are additive across groups. A user assigned to both a restrictive and a permissive group gets the permissive group's access, not the restrictive one. Group membership for PHI-handling users needs to be exclusive, or the restriction does nothing.

  • Third-party integrations (including MCP servers). The BAA does not cover third-party integrations: MCP servers, connectors, Desktop Extensions, skills, plugins, and Enterprise Search connectors are all explicitly outside BAA coverage. You are responsible for determining whether a separate BAA with each third party is needed and executing it. If you enable integrations that transmit PHI to external services, that data is governed by those third parties' own terms, not Anthropic's BAA.

  • Audit log retention. Anthropic's Compliance API retains audit logs for up to one year only. You are responsible for exporting those logs and maintaining them independently for the remaining five-plus years required under HIPAA's six-year retention standard.

  • Data backup. You are responsible for implementing backup and recovery procedures for emergency access to PHI. Anthropic does not maintain a Designated Record Set or separate backup of your PHI.

What Anthropic's BAA does not cover

When you execute a BAA with Anthropic, it governs how Anthropic handles PHI within their infrastructure. It does not cover what happens before the request is sent or after the response is returned.

In practice, most HIPAA failures with LLM usage happen in this layer, not at the provider.

The BAA does not cover:

  • Your audit logging. Anthropic does not log prompts and responses in a way that satisfies HIPAA audit requirements. If you cannot show who accessed what data and when, you have a gap.

  • Storage and retention of those logs. The logs you generate contain PHI. They must be encrypted at rest with controlled access. And critically: Anthropic's Compliance API only retains audit logs for one year. You must export and independently store them for the remaining five-plus years that HIPAA requires.

  • Key management: API keys must be scoped, rotated, and controlled across environments. The BAA does not address how your organization manages credentials

  • Access controls: you are responsible for enforcing which users and systems can send PHI to Claude and under what conditions.

  • Third-party integrations. MCP servers, connectors, Desktop Extensions, and Enterprise Search connectors are explicitly excluded from BAA coverage. PHI transmitted through these integrations is not covered by Anthropic's BAA. You must evaluate and execute separate BAAs with each third party, or disable the integrations entirely.

  • Other vendors in your stack: your database, logging pipeline, analytics tools, and any downstream systems that touch PHI all require their own controls and, where applicable, BAAs.

A signed BAA ensures Anthropic is operating as a compliant business associate. It does not make your system compliant.

A common failure pattern

A typical implementation looks compliant on the surface:

  • The team signs a BAA with Anthropic

  • PHI is sent only through approved API paths

  • Every prompt and response is logged for auditability

At this point, many teams believe they are covered.

The failure happens in the next step.

Those logs are often shipped into an existing observability or analytics stack such as a log aggregator, search index, or data warehouse. That system was designed for operational telemetry, not regulated data. As a result:

  • Logs may be stored in plaintext or with weak encryption

  • Access is broader than intended, often including engineering or support teams that do not require PHI access

  • Retention policies are short lived or inconsistent with HIPAA requirements

  • Data may be copied into downstream systems for debugging, dashboards, or machine learning workflows

At that moment, the compliance boundary has shifted.

The interaction with the model is compliant under the BAA. The system storing and exposing that same data is not.

Getting the BAA: what to expect

Anthropic's Enterprise plan can be purchased self-serve or through a sales-assisted process. The self-serve path gets you the plan, but it does not get you a BAA. BAA coverage and ZDR configuration are only available through the sales-assisted path.

The process: Contact Anthropic's sales team, review the BAA and implementation guide, execute the agreement, and configure the plan with your account team. Plan for this to take weeks, not days. If you're building toward a go-live with a health system customer and need a signed BAA before their security team will approve you, start this conversation early.

If you have an existing API BAA: BAAs signed with Anthropic before December 2, 2025 cover API usage only (via ZDR) and do not extend to the HIPAA-ready Enterprise plan. BAAs signed after that date can cover both under a single agreement. If you have an older API BAA and need Enterprise coverage, you'll need to sign a new one with your account team.

If your BAA was signed on or after April 1, 2026: You have an additional option for API coverage beyond ZDR. Anthropic added a non-ZDR "HIPAA-configured" API organization type, which covers a specific set of API features under the HIPAA configuration without requiring Zero Data Retention: Token Counting, Models, Org Management, and Compliance APIs, plus select Messages API features (Prompt Caching, Structured Outputs, Memory, Web Search, Bash tool, Text Editor tool). This is separate from ZDR-enabled API access, which still works and still covers the full API surface. Only API keys belonging to a HIPAA-configured or ZDR-enabled organization should be used to transmit PHI (keys on a standard organization are never covered, BAA or not).

Claude Code requires ZDR: The CLI can be covered under a BAA, but only if Zero Data Retention (ZDR) is enabled, and ZDR is available for qualified accounts only, not automatically on any plan. You need to contact Anthropic sales to arrange it. If you have an Enterprise agreement and haven't explicitly configured ZDR, your Claude Code usage is not covered. Claude Code's beta features (Web, Desktop, Review, Security, Computer Use) are not covered under the BAA and are incompatible with ZDR entirely; there is no path to coverage for those.

Claude Code: CLI coverage requires Zero Data Retention to be configured; available for qualified accounts only, not automatic on any plan. Beta features (Web, Desktop, Review, Security, Computer Use) cannot be covered regardless of plan or configuration. Contact Anthropic sales to discuss eligibility.

What affects timeline: Anthropic is a fast-growing company and their enterprise compliance process reflects that. Teams have encountered delays getting BAAs executed, particularly compared to cloud providers like AWS where a BAA is part of the standard enterprise agreement. Don't assume you can close a healthcare deal and then get the BAA in place before your customer's onboarding date.

The multi-model problem: If your application uses Claude for some tasks and OpenAI or AWS Bedrock for others, you need separate BAAs with each provider. This creates contract management overhead and increases the risk of accidentally routing PHI through an uncovered path when models are swapped for testing or performance reasons. An LLM gateway that covers all your LLM traffic under a single BAA eliminates this problem.

What you still need to build

Executing a BAA with Anthropic is step one. The infrastructure underneath it is still your responsibility.

HIPAA's technical safeguards (45 CFR 164.312) require controls on any system that handles PHI. When your system calls Claude with patient data, those controls apply to the call:

Audit logging. Every prompt and response that involves PHI needs to be logged with timestamps, user attribution, and model identity. Anthropic provides a Compliance API that supports access and activity monitoring, but it only retains logs for up to one year. You are responsible for exporting those logs and storing them independently for the full six years HIPAA requires.

Log retention and access controls. Logs must be retained for six years and access-controlled so only authorized personnel can view them. Retention is typically the harder problem; encryption at rest is often provided by default, but maintaining six years of logs in a queryable, access-controlled system requires explicit infrastructure decisions. Equally important: giving developers broad access to logs containing unredacted PHI for debugging is itself a HIPAA violation. HIPAA requires least-privilege access to PHI regardless of whether the underlying model interaction was covered. Logs are not exempt from that requirement.

Log retention. Audit logs must be retained for six years under HIPAA. Your operational log pipeline probably isn't designed for this. You need a log drain to long-term storage with appropriate retention enforcement.

PHI de-identification (defense in depth, not required). De-identification is not required by HIPAA or by Anthropic's BAA; if you have a valid BAA in place, sending PHI to Claude is a permitted use. But de-identifying before the prompt and re-identifying after the response reduces your exposure if controls elsewhere fail. It limits breach scope and adds a meaningful layer of protection for high-sensitivity workflows.

Key management. Anthropic gives you API keys. For a small team, that's manageable. For a growing organization, you need scoping by application, team, and environment — and the ability to rotate or revoke keys without affecting unrelated systems.

Access controls. Which users and systems in your organization can send PHI to Claude? How is that enforced? For HIPAA, you need to be able to demonstrate who accessed what and when.

For a full breakdown of these requirements in the context of LLM usage, see HIPAA-Compliant AI: What Developers Need to Know.

The developer workflow risk

Production AI features are not the only surface to worry about.

Engineers use Claude in debugging workflows, internal tooling, and data exploration. When a developer runs Claude Code in a codebase that contains PHI (in test fixtures, database dumps, or log files) those interactions are in scope. If your team's development environment isn't covered by your BAA and doesn't have the same controls as production, you have a gap.

The same applies to any automated tooling that calls Claude as part of its operation. A tool that uses Claude to analyze your AWS compliance posture, for example, may not have PHI flowing through it directly, but if it operates in an environment where PHI is present, the configuration matters.

The practical question is not just "did we sign a BAA?" but "do we have visibility into everywhere Claude is being used, and are all of those paths covered?"

How Aptible AI Gateway covers what Anthropic's BAA doesn't

Aptible LLM Gateway is a managed compliance layer that sits between your application and LLM providers. When you route Claude traffic through AI Gateway:

  • One BAA covers everything. Your Aptible BAA covers all AI Gateway usage, across all supported models. You don't need separate BAAs with Anthropic, OpenAI, or AWS Bedrock.

  • Audit logging is automatic. Every prompt and response is logged with full metadata, encrypted at rest, and available for compliance review. You don't build the logging pipeline.

  • PHI de-identification is built in. Sensitive data is scrubbed before it reaches the model and restored after the response returns.

  • Key management is handled. Scopes for applications, teams, and environments give you attribution and control without managing it in application code.

  • Switching models doesn't restart compliance. You can move between Claude, OpenAI, and Bedrock models without re-implementing controls or negotiating new BAAs.

For teams building in digital health who want to use Claude without building the compliance infrastructure themselves, LLM Gateway removes the implementation burden.

FAQs

Is Claude HIPAA compliant?

Not by default. Claude for Enterprise with a signed BAA can be used in a HIPAA-compliant implementation; if you've also built the required infrastructure around it (audit logging, encryption, access controls). Claude.ai in all its consumer tiers (Free, Pro, Team) does not offer a BAA and should not be used with PHI. Compliance depends on implementation, not the product itself.

Is Claude.ai HIPAA compliant?

No. Claude.ai Free, Pro, and Team do not offer BAAs. Do not use them with real patient data, including in testing or debugging. Claude for Enterprise is a separate, sales-negotiated product.

How do I get a BAA with Anthropic?

It depends on how you're using Claude. Enterprise admins can sign the BAA directly in admin settings when activating HIPAA compliance. For API or self-managed accounts, you'll need to go through Anthropic's sales team. If you have a legacy API BAA from before December 2, 2025, it covers API usage only (via ZDR) and does not extend to the Enterprise plan. BAAs signed after that date can cover both. BAAs signed on or after April 1, 2026 add a further option: a non-ZDR "HIPAA-configured" API org covering a specific set of API features without requiring Zero Data Retention.

Can I use Claude Code with PHI?

It depends on which Claude Code surface and whether your account has Zero Data Retention (ZDR) enabled.

The CLI can be covered under an Anthropic BAA, but only if ZDR is enabled on your account. ZDR is not automatic — it's available for qualified accounts only and requires working with Anthropic sales to configure. If you have an Enterprise agreement but haven't set up ZDR, your Claude Code CLI usage is not covered.

One additional constraint: Fable and Mythos are covered under the BAA generally, but Anthropic's Implementation Guide states they are incompatible with any product using Zero Data Retention. This isn't unique to Claude Code. It applies to any ZDR-based path, which historically has included ZDR-enabled API access as well. Enterprise Chat, which uses the HIPAA configuration rather than ZDR, is not affected by this restriction. If your team needs BAA-covered Claude Code CLI usage (which requires ZDR) alongside BAA-covered access to Fable or Mythos in another context, those require separate Anthropic organization configurations; check with your Anthropic account team for the current setup, since Anthropic's coverage details for these models have changed more than once in 2026.

Desktop local mode is also covered when ZDR is enabled. Desktop remote mode, the web version, and features including Code Review, Security, Computer Use, and Remote Control are not covered under the BAA and are incompatible with ZDR. There is no coverage path for those surfaces under the current Anthropic offering.

The practical default: if your developers use Claude Code in environments where PHI may be present, assume that usage is outside your BAA unless you've explicitly verified ZDR is configured on your account.

Does Anthropic train on my data?

Not for training the underlying models; that's consistent across API and Enterprise use. But Anthropic's Implementation Guide draws a distinction worth knowing: your usage data, including PHI, may still be indexed, stored, and processed to customize and improve the Eligible Services specifically for your organization. That's a narrower use than training Anthropic's base models, but it means "no training" doesn't mean your data is entirely untouched. What matters legally is what your BAA and the Implementation Guide say, not what a policy page implies (policies can change, contracts are enforceable).

What's the difference between HIPAA eligible and HIPAA compliant for Claude?

"HIPAA eligible" means Anthropic will sign a BAA. "HIPAA compliant" means your full implementation meets HIPAA requirements. Getting a BAA is necessary. Your audit logging, encryption, access controls, and the rest of the compliance infrastructure are still your responsibility to implement correctly.


__

For the full technical requirements for HIPAA-compliant LLM usage, see HIPAA-Compliant AI: What Developers Need to Know. For BAA requirements more broadly, see What is a HIPAA BAA. For details on how AI vendor BAA works specifically, see What an AI BAA Actually Covers.