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.
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
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:
- 1Do you have zero risk appetite for third-party PHI processing? → Air-gapped self-hosted LLM. Stop reading.
- 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.
- 3Are you cloud-agnostic and want the best model quality? → Anthropic Enterprise or OpenAI Enterprise with signed BAA. Higher friction but fewer integration questions.
- 4Do you need voice / embeddings / vector DB in addition to LLM? → Verify each vendor separately. Assume no BAA at starter tiers.
- 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.