OpenAI BAA vs Anthropic BAA (2026): The HIPAA Decision

The HIPAA Privacy Rule (45 CFR 164.502(e) and 164.504(e)) requires Covered Entities to obtain satisfactory assurances from Business Associates that they will safeguard PHI. The BAA is the contractual vehicle for those assurances. HHS publishes sample BAA provisions at hhs.gov/hipaa/for-professionals/covered-entities/sample-business-associate-agreement-provisions/.

Minimum BAA requirements: (1) the Business Associate will not use or disclose PHI except as permitted by the BAA or required by law; (2) the BA will implement appropriate safeguards per the HIPAA Security Rule (45 CFR Part 164 Subpart C); (3) the BA will report breaches to the Covered Entity per the Breach Notification Rule (45 CFR Part 164 Subpart D); (4) the BA will ensure any sub-contractors that create, receive, maintain, or transmit PHI agree to the same restrictions; (5) the BA will make PHI available for individual access requests and HHS investigations; (6) the BA will return or destroy PHI at termination of the agreement, or extend protections if return/destruction is infeasible.

For an LLM vendor specifically, the practical BAA terms translate to: (a) no training on PHI inputs, (b) no persistent storage of PHI inputs/outputs beyond the operational minimum, (c) encryption in transit and at rest where data is persisted, (d) access controls and audit logging on the vendor's side, (e) breach notification with sufficient detail for the Covered Entity to comply with its own notification obligations, (f) sub-processor flow-down obligations, and (g) termination cleanup.

Both OpenAI's and Anthropic's BAA templates cover these obligations. The differences are in eligibility, endpoint scope, sub-processor enumeration, and incident notification mechanics — not in the fundamental obligations.

OpenAI offers a BAA for eligible Enterprise customers using the API for healthcare workloads. The published policy is at openai.com/policies/business-associate-agreement (verify the current text). Eligibility requires Enterprise-tier procurement (coordinate with the OpenAI Enterprise sales team), and the customer must configure Zero Data Retention on the project key used for HIPAA workloads.

ZDR on OpenAI: when configured, eliminates the default 30-day abuse-monitoring retention of inputs and outputs. With ZDR plus the BAA, OpenAI does not persist PHI inputs or outputs past the synchronous inference call. ZDR is not available on every endpoint — verify the current eligible models list before standardizing on a specific model for HIPAA traffic.

Endpoint scope under the OpenAI BAA generally includes Chat Completions, Responses API, Assistants v2 (with caveats around code interpreter and file persistence), Batch API, and embeddings. Code Interpreter sandboxes persist files for the lifetime of the thread; if you upload PHI to a Code Interpreter session, the session ID becomes a PHI-bearing resource until expiration. Fine-tuning eligible base models keeps the fine-tuned model in BAA scope.

Practical pattern: a healthcare buyer sets up a dedicated OpenAI organization for HIPAA workloads, requests Enterprise + BAA + ZDR, isolates the project keys to that organization, and routes only PHI-bearing traffic through it. Non-PHI traffic (marketing, internal R&D, public-facing chat) can use the standard organization. This pattern keeps the BAA-covered surface small and auditable.

Time to a signed BAA via OpenAI Enterprise is typically 2-6 weeks depending on procurement and legal review cadence on both sides. Existing OpenAI Enterprise customers can request the BAA addendum and have it executed faster.

Anthropic offers a BAA under its Enterprise commercial agreement. The Anthropic Trust Center (trust.anthropic.com) provides the BAA addendum template for review under NDA. ZDR is effectively the default for Anthropic's API — Anthropic does not log inputs/outputs to long-term storage outside of customer-opted-in logging — and the Enterprise BAA addendum reinforces this contractually.

Endpoint scope under the Anthropic BAA covers the Messages API for Claude (Opus 4.7, Sonnet 4.6, Haiku 4.5, and other GA models — verify the current per-model list). Tool use / function calling within the Messages API is in scope. Computer use (a research preview surface as of 2025-2026) has separate considerations; verify scope if you intend to deploy computer use for PHI workflows.

Sub-processor coverage: Anthropic's primary compute is on Google Cloud Platform and Amazon Web Services. The BAA flows down sub-processor obligations to the cloud providers. The Anthropic sub-processor list at trust.anthropic.com/sub-processors enumerates current processors.

Time to a signed BAA via Anthropic Enterprise is typically 2-6 weeks, depending on procurement cadence. Enterprise procurement is more streamlined for buyers who have already signed the standard Anthropic Commercial Terms.

Practical caveat for AI engineers: Anthropic's prompt caching feature is in BAA scope. Cached prefixes are stored encrypted in Anthropic's inference layer and evicted per TTL (5 minutes default, 1 hour optional). The cache eviction lifecycle is described in Anthropic's docs; HIPAA buyers should confirm with Anthropic Enterprise that the cache lifecycle meets their data-retention posture before relying on caching for PHI traffic.

For Covered Entities already on Azure with a Microsoft Online Services BAA in force, Azure OpenAI Service is covered by the existing BAA. No separate vendor relationship with OpenAI is required. Microsoft is the Business Associate; OpenAI is a sub-processor under the Microsoft–OpenAI commercial agreement, and Azure OpenAI inference does not surface customer data to OpenAI.

This is the lowest-friction path for healthcare buyers. The existing Azure procurement, security review, and BAA cover the AI workload. The only additional work is configuring the Azure OpenAI resource per Microsoft's responsible AI and security guidance (private link, customer-managed keys for stored fine-tuning data, RBAC scoped to clinical workload owners, Azure Monitor logging only to BAA-covered destinations).

Trade-off: Azure OpenAI typically lags OpenAI direct by 2-6 weeks on new model GA. For healthcare buyers whose workload is bounded (typically gpt-4o or gpt-4.1 for clinical assistant features), this lag is negligible. For buyers who must always be on the bleeding edge of model capability, OpenAI direct via Enterprise BAA may be preferable.

Practical guidance: any HIPAA buyer who is already on Azure should default to Azure OpenAI for AI workloads and only revisit if specific model needs require OpenAI direct. The contracting time saved (typically 4-12 weeks of procurement, legal, security review) is the largest cost savings of the decision.

For Covered Entities already on AWS with an AWS BAA in force, AWS Bedrock is on the HIPAA-eligible services list. Anthropic Claude on Bedrock is therefore covered by the existing AWS BAA. AWS is the Business Associate; Anthropic is a sub-processor under the AWS–Anthropic commercial agreement.

This is the cleanest path for healthcare buyers who want Claude without standing up a direct Anthropic Enterprise relationship. The same model (Opus 4.7, Sonnet 4.6, Haiku 4.5) is available on Bedrock typically within a few days of Anthropic direct GA. The contracting surface is one vendor (AWS).

AWS Bedrock also covers Meta Llama, Mistral, Cohere, Stability AI, and Amazon Titan / Nova models under the same eligibility. For healthcare buyers who want to evaluate multiple model families for clinical use cases without standing up a separate vendor relationship per family, Bedrock is the gold-standard procurement surface.

Trade-off: Bedrock's exposed API surface is slightly different from Anthropic's direct API (different SDK, different streaming semantics, different access pattern to Anthropic's newest features). Engineering teams should evaluate the SDK delta during a small POC.

Practical guidance: any HIPAA buyer who is already on AWS and needs Claude should default to Bedrock. Buyers who need GPT family should default to Azure OpenAI. Buyers who need both should procure both, route per workload.

Under the HIPAA Breach Notification Rule (45 CFR 164.404), a Covered Entity must notify affected individuals within 60 days of discovering a breach of unsecured PHI. The Business Associate is contractually obligated to notify the Covered Entity 'without unreasonable delay' so that the Covered Entity can meet the 60-day clock. Specific contractual timing varies — many enterprise BAAs specify 24-72 hours from BA discovery.

OpenAI's BAA template requires notification without undue delay, typically interpreted as within the BA's documented incident response SLA. Specific timing should be verified during BAA review.

Anthropic's BAA template requires notification without undue delay, with the Anthropic incident response process documented in the Trust Center security overview.

Microsoft's BAA (Azure OpenAI in scope) provides specific contractual notification timing — Microsoft typically commits to notification within 72 hours of confirmed breach for GDPR-relevant or HIPAA-relevant incidents. This is one of the most favorable contractual timings in the cloud market.

AWS's BAA covers Bedrock under AWS's standard incident response SLAs, with notification without undue delay.

Practical pattern: regulated buyers should have an incident response runbook that assumes BA notification will arrive within 24-72 hours and accounts for the additional time required to investigate, identify affected individuals, and prepare the 60-day individual notification. The BA notification is the start of the clock, not the entire clock.

Signing a BAA does not make your AI application HIPAA-compliant. The BAA is one of many requirements. Your residual obligations include: (1) Security Risk Assessment per 45 CFR 164.308(a)(1); (2) administrative, physical, and technical safeguards per 45 CFR 164.308-312; (3) workforce training; (4) policies and procedures; (5) breach detection and response on your side; (6) minimum necessary use and disclosure (45 CFR 164.502(b)); (7) individual access and accounting of disclosures.

Specifically for an LLM-powered application: you are responsible for (a) what PHI you put into the prompt, (b) whether you store the prompt/response in your own systems (and how you secure that), (c) how you de-identify or pseudonymize PHI before sending if you don't need full PHI for the use case, (d) what use case the LLM is supporting and whether the use case itself is permissible under your HIPAA program, (e) audit logging of who accessed the LLM-generated content.

Many healthcare buyers under-invest in (c) and (e). De-identification (per HHS Safe Harbor at 45 CFR 164.514(b)) eliminates the PHI status entirely and removes the BAA requirement for the de-identified prompt — but de-identification has to be done correctly. Audit logging is required for any system that creates, modifies, or accesses PHI; the LLM-generated text becomes PHI as soon as it incorporates identifiers from the prompt.

Have HIPAA counsel and a HIPAA Security Officer review your full deployment, not just the vendor BAA. The vendor BAA is necessary but not sufficient.

Already on Azure, need GPT family: Azure OpenAI under existing Microsoft BAA. Lowest friction.

Already on AWS, need Claude: AWS Bedrock under existing AWS BAA. Lowest friction.

Already on AWS, need GPT family: either (a) procure Azure OpenAI for a second cloud relationship — $30-80k in legal/procurement time but minimal ongoing friction; or (b) procure OpenAI direct via Enterprise BAA — 2-6 week procurement, ZDR configuration, isolated org for HIPAA traffic.

Already on Azure, need Claude: either (a) procure AWS account with Bedrock — second cloud relationship; or (b) procure Anthropic direct via Enterprise BAA — 2-6 week procurement, ZDR configured, isolated workspace.

Not on either cloud yet (small healthcare startup): pick the cloud first based on broader cloud strategy (AWS or Azure), then default to that cloud's AI service for HIPAA-covered workloads. Standing up a second vendor relationship with OpenAI or Anthropic is rarely worth it for early-stage healthcare AI products.

Need fine-tuning of an LLM for a clinical use case: verify per-vendor that fine-tuned models are in BAA scope (they generally are on eligible base models). Verify that the fine-tuning dataset storage is under the BAA — both Azure OpenAI and Bedrock store fine-tuning data in the customer's region with KMS / Key Vault encryption.

Need to evaluate multiple model families for a clinical use case: AWS Bedrock is the lowest-friction multi-model BAA path; Azure OpenAI is single-vendor (OpenAI only). For broader evaluation, Bedrock wins.