All posts
Healthcare · HIPAA
August 4, 20268 min read

Which AI Providers Actually Sign HIPAA BAAs in 2026 (Buyer's Guide)

M

Moneeb Abbas

AI Systems Architect

If you work in healthcare and are evaluating AI tools, the first question is not 'which model is best' — it's 'who will legally sign a Business Associate Agreement covering my PHI'. That single question rules out most of the AI vendor landscape. This is a current, practical guide to which providers sign BAAs, what those BAAs actually cover, and when the correct answer is 'none of them — self-host'.

Why BAAs Exist and What They Actually Do

Under HIPAA, any third party that processes Protected Health Information (PHI) on behalf of a covered entity is a 'business associate' and must sign a Business Associate Agreement. The BAA is a legal contract that binds the vendor to HIPAA's Security Rule requirements — encryption, access logging, breach notification, and permitted uses of the data.

Without a BAA, sending PHI to a vendor is a HIPAA violation — regardless of how secure the vendor claims to be, regardless of what their marketing page says. This is why 'we use enterprise-grade security' is not a substitute for a signed BAA. It has to be the actual document.

Warning:A BAA does NOT automatically make a vendor safe to use. It shifts liability, but you still own the choice. If a covered vendor has a breach, you are still on the hook for the notification and remediation. Choose vendors whose security posture you actually trust — the BAA is necessary, not sufficient.

Major AI Providers: BAA Status (as of Q3 2026)

The below reflects publicly available information at time of writing. Always verify current status with the vendor directly before signing anything — BAA offerings change quarterly.

OpenAI

  • BAA available: Yes, via the ChatGPT Enterprise, ChatGPT Team (with specific configuration), and OpenAI API for eligible customers on Zero Data Retention
  • Coverage: Direct API usage of GPT-4, GPT-4o, and o-series models under the enterprise agreement
  • Watch out for: The standard OpenAI API is NOT covered — you must be explicitly enrolled in the HIPAA-eligible tier, which requires enterprise-tier billing and a separate signed agreement
  • Practical note: Fine-tuning workflows and Assistants API have caveats — confirm your specific use case is in-scope

Anthropic (Claude)

  • BAA available: Yes, for customers on their Enterprise plan or via AWS Bedrock
  • Coverage: Claude models accessed through the covered channels
  • Watch out for: The consumer Claude.ai product is NOT HIPAA-eligible by default — you need the enterprise agreement or route via AWS Bedrock's HIPAA-eligible services list
  • Practical note: For many healthcare teams, accessing Claude via AWS Bedrock is the cleanest path because you inherit AWS's existing BAA rather than negotiating a new one

Google (Gemini, Vertex AI)

  • BAA available: Yes, via Google Cloud Platform when using Vertex AI
  • Coverage: Gemini models served through Vertex AI in HIPAA-eligible regions
  • Watch out for: The consumer Gemini product and the Google AI Studio developer tier are NOT HIPAA-eligible — you must use Vertex AI specifically
  • Practical note: GCP's HIPAA-eligible services list is explicit about which regions and services are in-scope. Read it carefully.

AWS Bedrock

  • BAA available: Yes, as part of the standard AWS BAA covering HIPAA-eligible services
  • Coverage: Bedrock-hosted models including Anthropic Claude, Meta Llama, Mistral, Amazon Titan, and others in HIPAA-eligible regions
  • Watch out for: Not all Bedrock models in all regions are HIPAA-eligible — check the current AWS HIPAA services page for the exact list
  • Practical note: For most healthcare teams already on AWS, this is the path of least resistance — one BAA covers everything

Microsoft Azure OpenAI Service

  • BAA available: Yes, as part of Microsoft's standard cloud services BAA
  • Coverage: GPT-4, GPT-4o, and other OpenAI models served through Azure
  • Watch out for: Azure OpenAI has content filtering that logs prompts by default — you must explicitly opt out of abuse monitoring if you cannot allow Microsoft to review PHI-containing prompts
  • Practical note: For teams already using Microsoft 365 for healthcare, this integrates cleanly with existing compliance workflows

What About the Smaller / Newer Providers?

For voice AI providers (Deepgram, ElevenLabs, AssemblyAI), embedding providers (Cohere, Voyage AI), and vector database providers (Pinecone, Weaviate, Qdrant Cloud), BAA availability varies significantly by pricing tier. In general:

  • Free and starter tiers almost never include a BAA
  • Enterprise tiers usually do, but require separate negotiation and often significant minimum spend
  • Self-hosted or on-premises versions of vector databases (Qdrant, Weaviate, Milvus) bypass the BAA question entirely because the data never leaves your infrastructure
Tip:For any vendor NOT on the major-cloud list above, assume no BAA unless explicitly confirmed in writing. Sales reps will sometimes say 'we can offer one' — that is not the same as having one. Get the actual document reviewed by your compliance team before sending any PHI.

When to Skip Cloud AI Entirely

Even with a BAA, some healthcare organizations have zero risk appetite for third-party data processing. This is common for:

  • Small clinics and specialty practices where a single breach would end the business
  • Behavioral health providers handling highly sensitive PHI (substance abuse records under 42 CFR Part 2 have even stricter rules than HIPAA)
  • Research hospitals working with genomic or trial data that has additional regulatory overlay
  • Any organization whose board or legal counsel has directed 'no cloud AI, no exceptions'

For these organizations, the correct answer is not 'find a friendlier BAA'. It is to deploy an air-gapped LLM on-premises. Open-weight models like Llama 3, Qwen, and Mistral can be self-hosted with zero external data flow. Your compliance surface shrinks to your own network, which is a problem you already know how to solve.

I've written a full walkthrough of what an air-gapped HIPAA deployment actually looks like — hardware, stack, and the compliance checklist that passed a real audit — in the HIPAA architecture post linked at the end of this article.

Decision Framework

A simple decision tree for choosing your path:

  1. 1Do you have zero risk appetite for third-party PHI processing? → Air-gapped self-hosted LLM. Stop reading.
  2. 2Are you already on a major cloud (AWS / Azure / GCP)? → Use their native AI service (Bedrock / Azure OpenAI / Vertex AI) under your existing BAA. Fastest path.
  3. 3Are you cloud-agnostic and want the best model quality? → Anthropic Enterprise or OpenAI Enterprise with signed BAA. Higher friction but fewer integration questions.
  4. 4Do you need voice / embeddings / vector DB in addition to LLM? → Verify each vendor separately. Assume no BAA at starter tiers.
  5. 5Are you doing R&D on PHI, not production? → Even research use requires a BAA. There is no 'testing' exception under HIPAA.

Common Mistakes I See

  • Sending PHI to a vendor's free tier 'just to test' — this is a HIPAA violation, full stop, even if you never go to production with it
  • Assuming a SOC 2 report substitutes for a BAA — it does not. SOC 2 is about controls, BAA is about liability. Both are needed for healthcare.
  • Relying on a vendor's blog post claiming 'HIPAA compliance' instead of the actual signed BAA — marketing language is not a legal contract
  • Forgetting about the downstream vendors — if the AI vendor uses AWS to serve models, you need to confirm that AWS is a covered subprocessor in the BAA
  • Assuming that de-identified data escapes HIPAA — it does IF properly de-identified per Safe Harbor or Expert Determination, but most 'de-identification' in practice does not meet the standard

The Bottom Line

In 2026, HIPAA-compliant AI deployment is very achievable — but the vendor list is narrower than the general AI vendor landscape, and the details matter. The three viable paths are: (1) major-cloud managed AI services under your existing cloud BAA, (2) enterprise agreements with the frontier model providers, or (3) fully air-gapped self-hosted deployments for zero-third-party-risk scenarios.

If you are still figuring out which path fits your use case, that is exactly what a scoping conversation is for. I've deployed each of the three architectures above for real healthcare clients and I am happy to walk through the trade-offs against your specific requirements.

Working on something similar?

I take on 1–2 new projects per month. If you have a use case that needs this kind of engineering, tell me about it.

Get in touch