A Business Associate Agreement (BAA) with an AI model provider is a contractual instrument that extends HIPAA’s Security and Privacy Rule protections to Protected Health Information (PHI) processed by the provider’s infrastructure on the customer’s behalf. In 2026, the major closed-model providers serving production healthcare AI deployments — OpenAI, Anthropic, AWS Bedrock-hosted Anthropic, Azure OpenAI, and Google Vertex AI — all offer BAAs at enterprise tiers, but coverage varies materially across endpoints, features, configurations, and sub-processor chains. Most healthcare AI teams that fail their first compliance review fail at this layer — assuming universal BAA coverage when actual coverage is feature-specific and configuration-dependent. This guide is the field-tested mapping Taction Software® uses on every healthcare AI engagement to verify BAA scope before week 1 of engineering.
What BAAs Actually Cover in Healthcare AI
A BAA is not a blanket grant of HIPAA coverage. It is a contract that defines:
- Which entity is acting as a Business Associate
- Which services or endpoints are within scope
- What configurations the customer must use to remain within scope
- What sub-processors are permitted in the data path
- What incident response, breach notification, and audit rights apply
Three structural realities make BAA scope harder to manage in healthcare AI than in traditional cloud deployments:
- AI providers evolve their feature surface rapidly. A BAA signed in Q1 covers the features that existed in Q1. New features released in Q3 may or may not fall within the existing BAA scope.
- Endpoints have different coverage profiles. The same provider may cover their core completion endpoints under BAA but exclude beta features, fine-tuning APIs, or agentic patterns.
- Configuration matters as much as the contract. Many BAA-covered endpoints require specific configurations (zero-data-retention, customer-managed keys, specific regions) to remain in scope. The default configuration is often not the BAA-covered configuration.
OpenAI BAA Coverage: What’s In and What’s Out
OpenAI offers BAAs at enterprise tiers. Coverage extends to specific endpoints and features under specific configurations.
What’s Typically Covered
- Direct API endpoints at enterprise tier — chat completions, embeddings, standard inference
- Zero-data-retention (ZDR) configuration enabled per-call — critical for HIPAA compliance
- ChatGPT Enterprise — the SaaS product for organizational use
- Standard model variants — GPT-4, GPT-4o, GPT-4 Turbo, and successors
What’s Often Not Covered (Verify Per Contract)
- Assistants API features
- Beta and preview features
- Fine-tuning APIs (varies by contract revision date)
- Specific tool-use and agentic features
- Consumer ChatGPT — never covered, regardless of plan tier
Configuration Discipline Matters
ZDR is not enabled by default on the OpenAI API. If your engineer makes the API call without ZDR explicitly configured, you are outside BAA scope on that specific call, even if your organization has a signed BAA.
This is the most common BAA failure pattern we see: signed contract, missing per-call configuration discipline. The fix is architectural — the inference gateway pattern enforces ZDR on every call regardless of which engineer wrote the application code.
Anthropic BAA Coverage: Three Contracting Paths
Anthropic offers three contracting paths for healthcare BAA coverage, each with different operational implications.
Path 1: Direct Anthropic API
- Covers Claude API endpoints at enterprise tier
- Feature-specific provisions apply
- Best for: organizations not already on AWS or Google Cloud
Path 2: AWS Bedrock-Hosted Claude
- Coverage extends through the existing AWS Healthcare BAA
- Anthropic operates as a sub-processor in the AWS BAA chain
- Often the fastest contracting path for healthcare customers already on AWS
- Best for: organizations standardized on AWS infrastructure
Path 3: Google Vertex AI Partnership
- Coverage extends through Google Cloud Healthcare BAA
- Faster operational deployment for GCP-based customers
- Some feature availability differences vs. direct Anthropic API
- Best for: organizations standardized on Google Cloud
Which Path to Choose
The contracting path often matters more than the model itself for operational deployment speed. A customer already on AWS with the existing AWS BAA can use Bedrock-hosted Claude with no new contracting cycle — typically saving 4-8 weeks of legal review compared to direct Anthropic contracting.
AWS Bedrock BAA Coverage
AWS Bedrock operates under the AWS Healthcare BAA, which is one of the most mature healthcare cloud BAAs in 2026 in terms of breadth.
Services Typically Covered
- Bedrock inference endpoints
- Foundation models hosted in Bedrock — Claude, Llama, Mistral, Titan, Cohere, others
- Bedrock Agents
- Bedrock Knowledge Bases (when configured with HIPAA-eligible underlying services)
- Bedrock Guardrails
Where Configuration Discipline Matters
- Region selection — specific AWS regions for HIPAA workloads
- Customer-managed encryption keys — required for some compliance postures
- Knowledge base underlying services must themselves be HIPAA-eligible (S3 buckets, OpenSearch instances, etc.)
- VPC isolation for production deployments
The Sub-Processor Chain
AWS Bedrock-hosted models involve a sub-processor chain: AWS hosts the infrastructure, the model provider (Anthropic, Meta, Mistral) sits in the sub-processor chain. The AWS BAA covers the chain provided each sub-processor is itself acknowledged in the BAA documentation. Verify the sub-processor list before assuming coverage.
Azure OpenAI BAA Coverage
Microsoft Azure OpenAI Service operates under Microsoft’s healthcare BAA, which is part of the broader Microsoft enterprise agreement.
What’s Typically Covered
- Azure OpenAI Service endpoints
- Specific model deployments — GPT-4, GPT-4o, embeddings, fine-tuned variants where supported
- Azure ML for fine-tuning workflows
- Specific Azure regions (not all regions are HIPAA-eligible)
What’s Not Covered
- Consumer Microsoft Copilot products — different agreement, different scope
- Preview features outside the BAA scope at the time of customer use
When Azure OpenAI Is the Right Path
Often the operationally simplest path for healthcare customers already standardized on Microsoft infrastructure. The BAA paperwork is part of the existing enterprise agreement; new contracting is minimal.
Google Vertex AI BAA Coverage
Google Vertex AI operates under the Google Cloud Healthcare BAA.
What’s Covered
- Vertex AI inference for Gemini models
- Vertex AI for Anthropic Claude (via the partnership)
- Vertex AI Search — Google’s RAG product
- Med-PaLM in specific availability terms
Healthcare-Specific Google Products
Google Healthcare API and Medical Imaging Suite have additional purpose-built BAA provisions designed specifically for healthcare workloads. These are separate from the general Vertex AI BAA scope.
The Five Questions to Verify Before Every Model Call
The structured verification we run at the inference gateway before any model call is permitted to a BAA-required path:
- Is this specific endpoint covered by the BAA? Not the provider in general — the specific endpoint URL or service identifier.
- Is this specific feature within the BAA scope? Function calling, structured outputs, agentic features, fine-tuning — verify per feature.
- Is the configuration correct for coverage? Zero-data-retention, encryption settings, region selection, customer-managed keys where required.
- Are sub-processors in the chain themselves covered? Particularly relevant for AWS Bedrock and Vertex AI partnership paths.
- Is the audit log capturing the BAA-coverage flag at event time? Six months from now when the auditor asks whether this specific call was in scope, can you reproduce the answer?
If you cannot answer all five questions for every model call in your architecture, you have BAA scope gaps that need closure before production launch.
Common BAA Failure Modes in Production
Failure 1: Coverage Assumption
The team assumes the BAA covers every endpoint, every feature, every configuration. Compliance review finds specific endpoints out of scope. The remediation requires either re-architecting the affected use cases or expanding the BAA — both expensive in time and engineering effort.
Resolution: Per-endpoint, per-feature BAA scope mapping is week-1 work.
Failure 2: Configuration Drift
Zero-data-retention or encryption configurations get changed by an engineer who didn’t know they were compliance-critical. Subsequent inference calls fall outside BAA scope until the configuration is restored. The audit log shows the drift only if it’s specifically tracking configuration state.
Resolution: Configuration enforcement at the inference gateway, not at application code level.
Failure 3: Sub-Processor Blindness
The model provider has BAA coverage but uses a sub-processor (data store, monitoring service, transcription service) that doesn’t have appropriate coverage. The chain breaks; PHI flows through an uncovered processor.
Resolution: Full sub-processor chain mapping; verification that every link is covered.
Failure 4: Feature Scope Creep
The team adopts a new provider feature — Assistants API, agentic patterns, new tool-use capabilities — without checking BAA scope on the new feature. The new feature is outside the existing contract.
Resolution: BAA scope re-verification when adopting new features. Treat feature adoption as a compliance event, not just an engineering decision.
Failure 5: Audit Log Gaps
The BAA-coverage flag isn’t captured at inference time. Six months later, the team can’t reconstruct which calls were in scope. The audit becomes a forensic exercise.
Resolution: The 30-field HIPAA audit log schema includes baa_in_scope as a captured field at event time.
The Operational Checklist for Week 1 of a Healthcare AI Engagement
The checklist Taction Software® uses on every healthcare AI engagement, executed before the first line of inference code:
Discovery (Days 1-3)
- Map every model the architecture will use
- Map every endpoint per model
- Map every feature per endpoint
- Identify the customer’s existing BAA paper trail
Verification (Days 4-7)
- Per-endpoint BAA scope verification
- Per-feature BAA scope verification
- Configuration requirement documentation
- Sub-processor chain mapping
Gap Remediation (Days 8-10)
- For endpoints/features outside existing BAA scope: contracting path identification
- For configurations not yet correct: configuration discipline documentation
- For sub-processor gaps: chain restoration or alternative path
Architecture Decisions (Days 11-14)
- Inference gateway design with BAA-coverage enforcement
- Audit log schema with BAA flags
- Configuration enforcement mechanism
- Monitoring for configuration drift
This 2-week discipline before engineering begins prevents the 4-8 week remediation cycle that comes from discovering BAA gaps during compliance review.
Pricing and Engagement Structure
The productized engagement progression Taction uses on healthcare AI deployments:
| Engagement | Duration | Price Range | Scope |
|---|---|---|---|
| Discovery Sprint | 4-6 weeks | $45,000 | BAA scope verification, architecture design, working prototype, production-readiness assessment |
| MVP Sprint | 8 weeks | $95,000 cumulative | Production-grade inference gateway, BAA-coverage enforcement, audit logging, content-safety filtering |
| Pilot-Ready Sprint | 12 weeks | $145,000 cumulative | Full deployment scope, EHR integration where applicable, compliance documentation, operational runbook |
| Production Rollout | 16-32 weeks | $200,000-$450,000 | Multi-use-case deployment, operational support, drift monitoring, quarterly compliance review |
For an estimate calibrated to your specific use case, the healthcare engineering cost calculator produces scoped estimates in under 5 minutes.
Frequently Asked Questions
Does OpenAI’s BAA cover the Assistants API?
Coverage varies by contract revision date. Earlier OpenAI BAAs typically excluded the Assistants API. More recent revisions may include specific Assistants API features. Verify your specific contract; do not assume coverage based on the BAA’s existence alone.
Is AWS Bedrock-hosted Claude the same BAA scope as direct Anthropic API?
No. AWS Bedrock-hosted Claude is covered under the AWS Healthcare BAA with Anthropic as a sub-processor. Direct Anthropic API access requires an Anthropic-specific BAA. The two paths have different feature scope, different incident response provisions, and different contracting timelines.
Does zero-data-retention (ZDR) apply by default?
No. ZDR must be explicitly configured per API call on OpenAI’s standard API. Without ZDR enabled, the API call is technically outside BAA scope even if your organization has a signed BAA. The inference gateway pattern enforces ZDR architecturally.
How long does BAA contracting typically take?
Direct contracting with a new provider typically takes 4-12 weeks depending on the provider’s legal review capacity and the customer’s legal team. Coverage extension through existing BAAs (AWS, Microsoft, Google) often takes 1-3 weeks because the underlying contract already exists.
What happens if PHI flows through an endpoint outside BAA scope?
This is a HIPAA violation. The remediation depends on severity and reporting requirements per §164.408 (breach notification). Minor scope gaps may be remediable through documentation and configuration changes; substantial gaps may trigger breach notification obligations. Consult institutional counsel.
Conclusion
BAA coverage in healthcare AI is feature-specific, configuration-dependent, and operationally critical. The major providers — OpenAI, Anthropic, AWS Bedrock, Azure OpenAI, Google Vertex AI — all offer BAAs at enterprise tier, but coverage varies materially across endpoints, features, and configurations. The teams that verify scope before week 1 of engineering ship deployments that pass compliance review on first audit. The teams that assume coverage produce 4-8 week remediation cycles when compliance review surfaces gaps.
If you are scoping a healthcare AI engagement and want a partner who runs BAA verification as week-1 work, book a 60-minute scoping call. Taction Software® has shipped 785+ healthcare implementations since 2013, with 200+ EHR integrations across Epic, Cerner-Oracle, Athena, and Allscripts, zero HIPAA findings on shipped software, and active BAA paper trails with every major AI provider. Our healthcare engineering team handles BAA verification as default scope on every engagement. For the engineering scope behind the engagement, see our healthcare software development practice and our hospital and health-system practice. For the data integration patterns this work depends on, see our healthcare data integration practice. Our verified case studies cover the production deployments behind these patterns.
