Is Claude HIPAA Compliant? Four Gates Decide the Answer
Claude can support HIPAA-regulated workloads only when an eligible Anthropic commercial service is covered by an accepted Business Associate Agreement, HIPAA mode is activated where required, the chosen capability is included, and the healthcare organization applies its own access and audit controls. This guide follows one PHI-bearing request through those four gates and marks the exact limits of API enforcement.

Anthropic gives Claude Enterprise customers a specific activation path for HIPAA use. The organization's Primary Owner opens Data and privacy and activates HIPAA compliance. The Primary Owner then accepts Anthropic's Business Associate Agreement. Standard Enterprise service lacks automatic BAA coverage. API customers have a separate enablement path through Anthropic or its sales team.
That sequence makes the answer conditional. Claude can sit inside a HIPAA-regulated workflow after the covered-service and BAA gates pass, along with the capability and deployer-control gates. I would strike any unqualified "Claude is HIPAA compliant" sentence from a security review because it hides every condition that determines the real answer.
TL;DR
- Claude Enterprise gains BAA coverage only after the Primary Owner activates HIPAA compliance and accepts Anthropic's BAA.
- API use with PHI requires a signed BAA plus Anthropic enablement.
- Claude Console and cloud-mode Cowork are excluded, as are specified beta capabilities under Anthropic's current guidance.
- Local-mode Claude Code and Cowork require the HIPAA configuration to be applied separately.
- DeepInspect can govern routed HTTP LLM requests; it cannot create BAA coverage or control excluded and bypassing surfaces.
Gate one is an eligible Anthropic commercial service
Anthropic's BAA guidance for commercial customers divides Claude use by service and mode. Claude Enterprise can receive coverage through its HIPAA activation process. First-party API use follows a separate approval and enablement path. Anthropic also names exclusions, including Claude Console and cloud-mode Cowork. Specified beta capabilities are also excluded.
The review should begin with the exact service shown on the invoice and in the administrator's console. "Claude" is a model and product family, rather than one contractual boundary. A claims analyst using an enabled Enterprise workspace and a clinical application calling the API create two different flows. A developer experimenting in Claude Console creates a third.
Draw those flows before approving PHI. One page with boxes for the user and application, plus the Anthropic service and any connected system, will expose ambiguous hops quickly. The broader Claude Enterprise security review covers account controls. HIPAA eligibility starts with the specific commercial service handling the data.
Gate two is an activated and accepted BAA
Anthropic says the organization's Primary Owner must activate HIPAA compliance under Data and privacy and accept the BAA for Claude Enterprise. Buying the standard Enterprise plan leaves that step unfinished. The activation record and accepted agreement belong in the deployment evidence package, along with the workspace identifier and responsible owner.
For first-party API use, Anthropic requires a signed BAA and enablement through Anthropic or its sales team. That means the API key alone carries no proof of HIPAA eligibility. Security should bind approved credentials to the enabled account and block PHI routes that use experimental or personal credentials, or any other unapproved credentials.
HHS's cloud computing guidance treats a cloud provider handling ePHI as a business associate under the stated conditions, including cases where the provider lacks the decryption key. The contract follows the data-handling role. The HIPAA BAA guide for AI vendors provides the wider contracting context.
Gate three is the covered capability and configuration
Claude Console and cloud-mode Cowork are excluded from Anthropic's HIPAA coverage. Specified beta capabilities are also excluded. Local-mode Claude Code and Cowork require the HIPAA configuration to be applied separately. A green light for one Enterprise workspace cannot be copied across these modes.
Inventory the capability at the same granularity used in Anthropic's guidance. Record the client and operating mode. Add the workspace and enabled beta capabilities. Then record connected systems and the destination of generated artifacts. Match each row to the BAA and HIPAA configuration. The small switch under Data and privacy carries more compliance weight than a polished vendor deck because it records the state Anthropic requires.
This gate also needs change control. A team can begin on an approved surface and later enable a beta capability that follows different terms. Assign an owner to review release changes before the capability handles PHI. My view is that beta capabilities belong outside clinical workflows until written coverage says otherwise. Curiosity is welcome in a sandbox with synthetic data.
Gate four is the healthcare organization's control set
Anthropic's commercial terms state that Anthropic may not train models on commercial Customer Content and distinguish commercial services from consumer Claude offerings.
The healthcare organization still decides which workforce member may disclose which PHI for which purpose. HHS's minimum necessary guidance requires reasonable efforts to limit PHI to the minimum needed for the intended purpose, subject to stated exceptions. Translate that duty into rules for role and task purpose. Add data class and approved Claude destination, plus the permitted action.
The healthcare organization must classify the prompt and attach the originating clinician's identity to an API call. It also needs an audit record showing the decision. See the AI and HIPAA compliance guide for the program-level responsibilities surrounding the vendor configuration.
The API path supports a stronger decision record
The first-party Anthropic API creates a point where the healthcare application can attach verified caller context before sending an HTTP model request. That point can evaluate a nurse or physician, or an analyst or agent, against the intended use and the PHI in the prompt. It can also produce a record that names the policy version and outcome.
Design the record around one request. Capture the supplied identity and role, plus the workspace and destination. Record the classification result and policy decision, along with the timestamp and a reference to the relevant policy. Keep content retention separate from decision evidence so the organization can prove that a rule ran without retaining a second uncontrolled copy of the full prompt.
This architectural option applies to traffic the organization deliberately routes. Consumer Claude sessions and excluded Anthropic surfaces remain outside that enforcement point. Direct calls that bypass the approved path also remain outside it. The HIPAA-compliant AI tools guide uses this same distinction when evaluating a vendor's controls against the deployer's remaining duties.
Enterprise and consumer terms lead to different answers
Anthropic's commercial terms apply to its commercial services and describe the Customer Content training restriction for that relationship. Consumer Claude offerings follow a different service category. A workforce policy should name the approved commercial entry points and prevent PHI use through personal accounts.
SSO and user provisioning can make the approved Enterprise route recognizable, but training alone leaves room for the wrong tab. Pair the policy with technical restrictions on credentials and destinations. For API applications, issue credentials only inside the enabled account and maintain a route inventory. For user-facing service, document the workspace and HIPAA activation state in the access review.
The operational question is concrete: the privacy officer must take one PHI-bearing interaction and show the eligible service and accepted BAA, plus the approved capability and authorized user. The same request trace must show the minimum-necessary decision and retained evidence, a level that a generic vendor questionnaire rarely reaches.
DeepInspect
DeepInspect governs authenticated HTTP traffic that an application or agent deliberately routes to an LLM. On an enabled Anthropic API path, it can use identity context supplied by the application and classify the prompt. It can enforce role and destination policy and block an unapproved disclosure. It can also write a per-decision audit record before returning the model response.
DeepInspect cannot activate Anthropic's HIPAA setting or accept the BAA. It cannot convert an excluded capability into a covered one or inspect consumer and vendor-managed traffic that bypasses the configured HTTP path. Anthropic defines its covered services. The healthcare organization owns its use. DeepInspect enforces policy on the routed model request between them.
Book a demo today.
Frequently asked questions
- Does Claude Enterprise include a BAA by default?
Anthropic says standard Enterprise plans lack automatic BAA coverage. The organization's Primary Owner must activate HIPAA compliance in Data and privacy and accept Anthropic's BAA. Preserve evidence of both the agreement and the workspace configuration.
- Can a healthcare application send PHI through the Claude API?
The first-party API can support that workload after the organization signs a BAA and Anthropic enables the account for HIPAA use. The healthcare organization must still apply access and minimum-necessary controls, plus route and audit controls, to its application.
- Are all Claude tools covered after activation?
Review the named capability before PHI enters it because coverage and configuration requirements differ across Claude surfaces.