Which AI vendors offer HIPAA BAAs?

OpenAI, Anthropic, Microsoft Azure OpenAI Service, AWS Bedrock, and Google Cloud Vertex AI all offer BAAs to enterprise customers. The free-tier and consumer-tier versions of these vendors' products are excluded. Workforce use of ChatGPT consumer, Claude.ai free, or Gemini consumer to process PHI is a disclosure to a non-business-associate regardless of any enterprise relationship the organization has with the vendor.

Does the BAA cover model fine-tuning?

Fine-tuning is a separate disclosure pattern that requires explicit BAA coverage. The default position for most vendors is that fine-tuning data is retained for the duration of the customer's use of the fine-tuned model, plus a vendor-specific retention period after deprovisioning. The covered entity needs the BAA to specify retention, deletion on request, and the safeguards applied to the fine-tuning dataset. Several vendors will accept zero-retention terms for fine-tuning datasets on request, but the default needs to be checked and negotiated, not assumed.

What about embedded AI in SaaS tools we already use?

SaaS tools that have added AI features call the same model providers under the hood. The covered entity has a BAA with the SaaS vendor. Whether the SaaS vendor has a BAA with the underlying model provider is the operational question. Salesforce, Epic, Microsoft 365 Copilot, and ServiceNow each have published positions on AI subcontractor BAAs. Procurement contracts with AI-using SaaS vendors need to enumerate the AI subcontractors and confirm BAA coverage for each one.

How long should the AI BAA require records to be retained?

HIPAA does not specify a minimum retention for accounting-of-disclosures, but the right to receive an accounting covers the six years preceding the request under 45 CFR § 164.528. Most covered entities retain audit records for six years. AI usage records should follow the same retention. A seven-year retention is a reasonable upper bound that also covers EU AI Act Article 19 requirements for high-risk healthcare deployments serving EU patients.

Can we use one BAA to cover multiple AI workloads?

A single BAA can cover multiple workloads if the agreement describes the permitted uses broadly enough and the vendor's service offering supports the breadth. The risk in a single-BAA approach is that workload-specific safeguards get diluted. A clinical decision support workload may need zero-data-retention and modified abuse monitoring; an administrative workflow may not. A single BAA that defaults to the lower standard of safeguards leaves the clinical workload underprotected. Workload-specific addenda to the master BAA are the common pattern in practice.

HIPAA BAAs for AI Vendors: What the Agreement Has to Cover

A Business Associate Agreement is the contract that allows a covered entity to disclose Protected Health Information to a third party for permitted purposes under 45 CFR § 164.504(e). For AI vendors, the BAA covers what the vendor does with the prompts and responses, what training and retention restrictions apply, and what notification obligations the vendor accepts when an incident occurs. OpenAI, Anthropic, Microsoft Azure OpenAI Service, AWS Bedrock, and Google Cloud Vertex AI all publish BAA terms for enterprise customers. The agreements look similar at the headline level and differ in operationally important detail.

I want to walk through what a HIPAA-grade AI BAA has to cover, where the common terms diverge across vendors, and what residual obligations the covered entity still owns after signing.

What the BAA has to cover

The HIPAA Privacy Rule at 45 CFR § 164.504(e) lists the required elements of a Business Associate Agreement. The contract must describe permitted and required uses and disclosures of PHI by the business associate, prohibit uses or disclosures beyond what the contract or law permits, require the business associate to apply appropriate safeguards, require notification of breaches and security incidents, require subcontractor compliance, allow the covered entity to terminate for material breach, and require return or destruction of PHI at termination.

For AI vendor BAAs specifically, the operationally important clauses sit in three areas. The first is training data use. The default position for an AI vendor is that prompts and responses inform model improvement. A HIPAA-grade BAA must restrict that use. The second is retention. The default position is that prompts persist in logs for debugging, abuse monitoring, and trust-and-safety review. A HIPAA-grade BAA must limit retention to what the covered entity authorizes. The third is subcontractors. Most AI vendors run on cloud infrastructure provided by hyperscalers and use specialized tooling for content moderation, vector storage, and monitoring. Each subcontractor that touches PHI needs to be a business associate of the vendor.

How the vendors differ on training data

OpenAI's BAA terms for the API commit that data submitted through the API will not be used to train OpenAI's models. The terms apply to the API tier, not to the consumer ChatGPT product. ChatGPT Enterprise and ChatGPT Team have separate BAA-eligible terms.

Anthropic's commercial terms for the API commit that customer prompts and outputs will not be used to train Anthropic's foundation models. The Claude.ai free tier is excluded from BAA eligibility.

Microsoft Azure OpenAI Service operates under Microsoft's enterprise BAA. Prompts and completions are not used to train Microsoft's models or the underlying OpenAI models. Abuse monitoring uses prompts for limited-duration human review unless the customer is approved for the modified abuse monitoring exception.

AWS Bedrock operates under AWS's enterprise BAA. Input and output data are not used to train Bedrock's foundation models or the third-party model providers' models. AWS does not share data with model providers without customer authorization.

Google Cloud Vertex AI operates under Google's enterprise BAA for healthcare workloads. Customer data is not used to train Google's foundation models.

The convergence on no-training is the default for enterprise tiers. The divergence sits in abuse-monitoring exceptions, log retention defaults, and the granularity of customer-controlled deletion.

Abuse monitoring as a residual exposure

Most AI vendors retain prompts for abuse monitoring, typically 30 days, sometimes longer. The retention applies to all customers by default. The covered entity that does not negotiate the modified abuse monitoring exception accepts that 30 days of PHI sits in the vendor's monitoring pipeline.

Microsoft Azure OpenAI offers a modified abuse monitoring exception that disables human review of prompts and completions on approval. The approval process requires the customer to document why the standard monitoring is incompatible with the use case. Healthcare deployments are typical approval cases.

OpenAI's API retention policy under the standard BAA is 30 days. Zero-data-retention is available on approval for specific endpoints and use cases. Anthropic has comparable 30-day retention with negotiated zero-retention for enterprise customers.

A HIPAA-grade vendor BAA for a healthcare deployment should specify the abuse monitoring posture in writing. The default monitoring posture is a defensible exposure only if the covered entity documents that the residual risk is acceptable under its own risk management process.

What the BAA does not eliminate

Signing a BAA changes the legal basis for the disclosure. The covered entity still owns several residual obligations.

The covered entity must record what PHI was disclosed, to which business associate, on whose behalf, and under what authorization. The HIPAA accounting-of-disclosures requirement at 45 CFR § 164.528 applies whether or not a BAA is in place. The covered entity must produce that accounting on patient request.

The covered entity must apply reasonable and appropriate safeguards under the Security Rule at 45 CFR § 164.312. The BAA covers what the vendor does with PHI after disclosure. It does not cover what the covered entity does to authorize, classify, and record the disclosure before it happens.

The covered entity must respond to breach incidents under the HIPAA Breach Notification Rule. If the vendor reports a security incident or breach, the covered entity owns the assessment, the patient notifications, and the HHS report. The BAA shifts the discovery obligation to the vendor; the response obligation stays with the covered entity.

The architecture for BAA-bound AI usage

Even with all the right BAAs in place, the operational gap is recording. Most covered entities discover at audit time that they cannot produce the accounting-of-disclosures for AI usage. The application logs show that the AI service was called. The application logs do not show what PHI was in the prompt, what workforce member submitted it, what patient the prompt referenced, or what policy authorized the disclosure.

The architecture that closes this gap places a recording layer between the workforce or agent and the AI vendor. Every prompt is inspected, classified for PHI, and either redacted, blocked, or allowed under a per-route policy. Every decision produces a record that captures identity, role, patient identifier where authorized, classification, decision outcome, policy version, timestamp, and a tamper-evident hash.

The recording layer also enforces which vendors are permitted recipients. A prompt destined for a vendor without a signed BAA is blocked or redirected. A prompt destined for a BAA-covered vendor at a tier that includes the modified abuse monitoring exception is allowed. The enforcement is deterministic, not advisory.

How vendor selection interacts with risk classification

The covered entity should match the AI vendor's BAA scope to the data classification of the workload. Routine clinical summarization with limited PHI exposure may run on the standard BAA tier. Sensitive workloads involving substance use disorder records under 42 CFR Part 2, psychotherapy notes under 45 CFR § 164.508(a)(2), or HIV status under state law may require zero-data-retention and modified abuse monitoring even from a BAA-covered vendor.

A vendor selection matrix that aligns workload classification to vendor BAA tier is a documentable safeguard under the HIPAA Security Rule. The matrix lives in the covered entity's HIPAA risk analysis and ties to the per-request policy enforced at the AI traffic boundary.

DeepInspect

This is the architecture DeepInspect was built to provide. DeepInspect sits at the AI request boundary as a stateless proxy between authenticated workforce members or agents and any LLM endpoint. Per-route policies enforce which vendors are permitted recipients of which workload classifications, with the BAA scope wired into the policy decision. Every prompt is inspected for PHI, classified, and either redacted, blocked, or allowed.

Every decision produces a signed audit record covering identity, role, classification, vendor selected, policy version, decision outcome, and timestamp. The record format satisfies the HIPAA accounting-of-disclosures requirement and the Security Rule audit-controls expectation. The same records support EU AI Act Article 12 for healthcare deployers serving EU patients.

If you have BAAs in place with multiple AI vendors and the policy that decides which vendor gets which workload lives in application code, the enforcement is fragile. Book a demo today.