The HIPAA-eligible AI stack: which LLM providers have a BAA in 2026

In 2026, the short list of large language model providers that will sign a HIPAA Business Associate Agreement (BAA) for protected health information (PHI) processing is narrower than the marketing pages suggest. AWS Bedrock, Microsoft Azure OpenAI Service, and Google Cloud Vertex AI sign BAAs and cover specific frontier and open-weights models running inside their own infrastructure. The direct consumer and developer APIs from OpenAI and Anthropic do not sign a BAA as of May 2026, which forces healthcare ISVs, payer innovation teams, and hospital CTOs to route every PHI prompt through one of the three hyperscalers or through self-hosted inference.

What "HIPAA-eligible" actually means

The HIPAA Security Rule (45 CFR Part 164, Subpart C) requires covered entities and business associates to apply administrative, physical, and technical safeguards to electronic PHI. The HHS Office for Civil Rights (HHS OCR) enforces this rule, and its 2024 Notice of Proposed Rulemaking on Security Rule modernization (published December 27, 2024, in the Federal Register) signaled tighter expectations around encryption, multi-factor authentication, and asset inventories. A BAA is the contractual instrument required by 45 CFR 164.502(e) whenever a covered entity discloses PHI to a vendor that creates, receives, maintains, or transmits PHI on its behalf.

The phrase "HIPAA-eligible" is what AWS, Microsoft, and Google use on their compliance pages to describe a specific service that the customer can include under a signed BAA. It is not the same as "HIPAA-compliant." A HIPAA-eligible service can still be configured by a private hospital network, a payer, or a medical-device manufacturer in a way that violates HIPAA. The provider gives the contractual hook and the technical controls. The covered entity or its business associate must operate them correctly.

The 2026 comparison table

The table below summarizes which LLM hosting paths are covered by a BAA as of May 2026, based on each provider's public HIPAA documentation pages and BAA terms. Healthcare ISVs and digital-health platforms should verify the exact service-level inclusion list with the provider before signing, because the eligible-services lists are updated frequently.

ProviderBAA availableHIPAA-eligible LLM modelsSubprocessor chainData residency optionsNotable exclusionsAWS BedrockYes. AWS BAA covers Bedrock as listed on the AWS HIPAA Eligible Services Reference.Anthropic Claude (Sonnet, Opus, Haiku families), Meta Llama 3 and 3.3, Amazon Titan, Amazon Nova, Cohere Command, Mistral. Verify the current list at the AWS HIPAA reference.AWS as primary processor. Model providers are subprocessors but do not receive prompts or responses when Bedrock is used in its private-by-default mode (per AWS Bedrock data protection documentation).US regions (us-east-1, us-west-2, GovCloud), plus EU regions including Frankfurt and Ireland for some models. Cross-region inference may move data outside the chosen region unless disabled.Bedrock Agents and Knowledge Bases inherit BAA coverage but require explicit VPC configuration. Bedrock Marketplace third-party models are evaluated case by case.Azure OpenAI ServiceYes. Microsoft signs a BAA covering Azure OpenAI under the Microsoft Online Services DPA and HIPAA BAA addendum.GPT-4o, GPT-4.1, GPT-5 family (where regionally available), o3 and o4-mini reasoning models, embeddings, DALL-E 3, Whisper. Confirm via the Microsoft Trust Center HIPAA service list.Microsoft as primary processor. OpenAI does not receive Azure customer prompts per Microsoft's published Azure OpenAI data, privacy and security documentation.Customer-selected regions including East US, West Europe, France Central, Sweden Central, Germany West Central, UK South. EU Data Boundary applies for European customers.Default abuse-monitoring stores prompts for up to 30 days. Healthcare customers can apply for the Modified Abuse Monitoring exception to disable the human review path; the BAA still applies but Microsoft requires an approved application.Google Cloud Vertex AIYes. Google Cloud BAA covers Vertex AI, listed in the Google Cloud HIPAA Compliance products list.Gemini 2.5 Pro, Gemini 2.5 Flash, Gemini 2.0 family, Imagen 3, Vertex AI embeddings, Llama and Mistral via Vertex AI Model Garden when deployed to a Google-managed endpoint. Verify with the Google Cloud HIPAA product list.Google as primary processor. Third-party Model Garden providers are subprocessors only for deployment metadata; prompts stay within the Google-managed serving infrastructure.US multi-region, EU multi-region, plus individual regions including europe-west3 (Frankfurt) and europe-west9 (Paris).Vertex AI Search grounding may call external sources; that path needs review. Generative AI App Builder features that index third-party content are not automatically inside the BAA scope.Anthropic API (direct)No public BAA available as of May 2026. Anthropic publishes a SOC 2 Type II report and ISO/IEC 27001:2022 certification but directs healthcare customers to access Claude through AWS Bedrock or Google Cloud Vertex AI for HIPAA workloads (per Anthropic Trust Center).Claude models are HIPAA-eligible only via Bedrock or Vertex AI.If used via Bedrock or Vertex, AWS or Google is the primary processor.Routed through the hyperscaler's region selection.Direct console use of api.anthropic.com is not BAA-covered. Verify with provider before any PHI test.OpenAI API (direct)No standard BAA on the public API tier as of May 2026. OpenAI's Enterprise and Business agreements do not include a default HIPAA BAA. Healthcare customers are directed to Azure OpenAI Service.OpenAI models are HIPAA-eligible only when accessed through Azure OpenAI Service.Microsoft Azure when routed through Azure OpenAI Service.Determined by the Azure region selection.ChatGPT Team, ChatGPT Enterprise, and the platform.openai.com API are not BAA-covered. Verify with provider.Hugging Face Inference Endpoints (Enterprise Hub)Yes, on the Enterprise Hub tier with a signed BAA addendum, per the Hugging Face Enterprise Hub compliance page. Verify with provider before reliance.Open-weights models hosted on dedicated Inference Endpoints inside the customer's chosen cloud (AWS, Azure, or GCP). The model weights are customer-selected from the Hub.Hugging Face as primary processor, with the underlying cloud as a subprocessor under its own BAA.AWS, Azure, GCP regions where Hugging Face offers dedicated endpoints.Hugging Face Spaces and the public Inference API are not HIPAA-covered. The Enterprise Hub BAA scope is limited to dedicated endpoints.

The architecture that keeps the AI call inside the compliance perimeter

A signed BAA is the legal floor. The architecture is what actually keeps PHI inside the perimeter that the BAA describes. The pattern that works for hospital networks, payer innovation teams, and healthcare ISVs is the same in shape across the three hyperscalers, with different product names.

The exclusions every CISO should know about

Every BAA has a perimeter, and the LLM provider BAAs all carve out specific behaviors. Public health systems and integrated delivery networks have been caught by these exclusions during HITRUST and SOC 2 audits.

What about open-source models running on-prem?

For hospital systems and medical-device manufacturers with existing Kubernetes platforms, running open-weights models on-prem or in a private cloud is a path that removes the LLM provider BAA from the chain entirely. Meta's Llama 3.3 70B and Llama 4 family, Mistral Large 2, Qwen 2.5 72B, and DeepSeek V3 can all be served on Amazon EKS, Azure AKS, Google GKE, or bare-metal Kubernetes with vLLM, TensorRT-LLM, or SGLang as the serving layer.

In this pattern, there is no model-provider BAA to sign because the model is software running on infrastructure the covered entity controls. The BAA chain reduces to the cloud provider (or the data center colocation provider) and any storage and observability vendors in the path. The covered entity owns the technical controls and the workforce policies. This is also the pattern that pharma, diagnostics, and lab IT teams pick when the regulatory file already includes the on-prem Kubernetes platform under ISO/IEC 27001:2022 and ISO 13485 scope.

The trade-off is operational. The covered entity now owns model serving uptime, GPU capacity planning, and security patching. For payer innovation teams and healthcare ISVs without a platform engineering function, the hyperscaler-routed path is the lower-effort starting point.

EU equivalents

Outside the United States, the regulatory floor is the General Data Protection Regulation (GDPR) Article 9 special category data rules and, for high-risk medical AI, the EU AI Act (Regulation 2024/1689), which entered into force on August 1, 2024, with the high-risk system obligations taking effect in stages through August 2027. The European Health Data Space Regulation (Regulation 2025/327) adds a sector-specific layer for electronic health data.

For LLM hosting in the EU, Azure OpenAI offers regions in Sweden Central, Germany West Central, France Central, and Switzerland North. Google Vertex AI offers europe-west3 in Frankfurt and europe-west9 in Paris. AWS Bedrock offers eu-central-1 in Frankfurt and eu-west-1 in Ireland. For German public health systems and hospitals, the BSI C5 attestation (Cloud Computing Compliance Criteria Catalogue) is the de facto procurement bar; Azure, AWS, and Google all hold C5 Type 2 attestations covering their core cloud services, and the LLM services are progressively being added to the C5 scope. For French hospitals and ARS-regulated entities, the Hebergeur de Donnees de Sante (HDS) certification under the French Public Health Code (Article L1111-8) is mandatory for hosting personal health data; Azure, AWS, and Google all hold HDS certification for their French regions.

EU customers should confirm the EU Data Boundary commitment with Microsoft for Azure OpenAI, the equivalent Google Sovereign Cloud commitment for Vertex AI, and the AWS European Sovereign Cloud roadmap (announced October 2023, with first regions scheduled to come online by end of 2025 per AWS public statements).

A 5-point procurement checklist

Insurance carriers, integrated delivery networks, healthcare ISVs, and medical-device VPs of digital can use the following checklist as the minimum bar for any LLM provider going into a procurement file. It maps directly to questions HHS OCR investigators ask in a breach response.

Where Life Value sits in this

Life Value's Custom AI Agents practice ships PHI-grade agents built inside the architecture described above, with the BAA chain documented and the audit logging configured before the first production prompt. The AI Prototyping engagement compresses the path from procurement to a working pilot inside a HIPAA-eligible region of AWS, Azure, or GCP, typically with the customer's existing SAML or OIDC identity provider in front of the LLM gateway. The AI Readiness Assessment is the lighter-weight starting point: a structured review of the LLM provider stack, the BAA chain, the audit logging configuration, and the workforce sanction policy gaps against 45 CFR 164.308.

If a CIO, CMIO, or payer innovation lead wants a sparring partner who has built under these constraints, this is what the engagement looks like. No vendor lock-in, no proprietary middleware, and the BAA chain stays in the customer's vendor file.

Further reading