CompanyScope
by Janus Compliance

Topic guide

HIPAA for AI tools: what a Business Associate Agreement actually covers

Independent compliance reference from Janus Compliance. Reviewed by Michael K. Onyekwere, CIPP/E. Last reviewed 2026-05-30. Not legal advice.

Share this HIPAA for AI tools: what a Business Associate Agreement actually covers profile:Share on XBluesky

TL;DR. HIPAA covers US protected health information (PHI), and the AI vendor only becomes a Business Associate when the deployment processes PHI on behalf of a Covered Entity or another Business Associate. OpenAI, Anthropic, Microsoft, and Google all sign BAAs on specific enterprise tiers; Perplexity Enterprise has an emerging position; consumer tiers and free products are never BAA-eligible. The BAA is necessary, not sufficient — the rest of the HIPAA Security Rule still has to land on the buyer's side.

When HIPAA enters the AI procurement conversation

HIPAA (the US Health Insurance Portability and Accountability Act, as amended by HITECH) applies to:

If the AI deployment will process PHI — meaning identifiable health information linked to a US Covered Entity — the AI vendor needs to sign a BAA before any PHI touches the system. Inputs that look benign (a transcribed clinical conversation, a summarised radiology report, a draft patient letter) can be PHI under the regulation, and HIPAA does not have a small-volume exemption.

Non-US healthcare buyers (NHS Trusts, EU public health bodies) do not have HIPAA exposure directly. They face the analogous obligations under their own jurisdictions (UK Data Protection Act 2018 plus NHS DSPT for the NHS; national health-data laws across the EU plus GDPR Article 9). HIPAA still matters indirectly when these buyers select a US-hosted AI vendor, because the BAA-eligible tier is usually the one with the strongest privacy controls overall.

What a BAA actually requires

A Business Associate Agreement is a HIPAA-specific contract that obligates the BA to:

  1. Use and disclose PHI only as the BAA permits
  2. Implement Security Rule administrative, physical, and technical safeguards for electronic PHI
  3. Report unauthorised use or disclosure to the Covered Entity
  4. Make information available for individual access and amendment requests
  5. Provide accountings of disclosure where required
  6. Make BA records available to HHS for compliance audits
  7. Return or destroy PHI at termination where feasible
  8. Pass equivalent terms down to any subcontractor that touches PHI

A BAA does not, on its own, satisfy the Security Rule. The Covered Entity still has to do its own risk analysis, design its own administrative safeguards, train its own workforce, and document its own decisions. The BAA pins the BA's obligations down; the Security Rule pins the CE's down.

Which AI vendors sign BAAs and on what tier

| Vendor | BAA-eligible tier | Consumer / free tier | Profile | |---|---|---|---| | OpenAI | Yes — ChatGPT Enterprise, ChatGPT Edu, OpenAI API on Enterprise agreement, certain Microsoft Azure OpenAI deployments | No — ChatGPT free, Plus, Team without explicit BAA addendum | OpenAI | | Anthropic | Yes — Claude Enterprise and Claude API on Enterprise agreement; sales-channel approval required | No — claude.ai free, Pro, Max | Anthropic | | Microsoft 365 Copilot | Yes — Microsoft signs BAAs for in-scope Microsoft 365 and Azure services; Copilot inherits this where in-scope | No — consumer Microsoft accounts | Microsoft 365 Copilot | | Google Gemini (Workspace) | Yes — Google Workspace BAA covers Workspace Gemini for Healthcare and Life Sciences customers on eligible plans | No — consumer Gemini, free Workspace | Google Gemini | | Perplexity | Emerging — Perplexity Enterprise has been pursuing BAA-readiness; confirm current status with sales | No — free Perplexity, Perplexity Pro | Perplexity | | ElevenLabs | Enterprise tier only — voice synthesis from PHI requires Enterprise contract and BAA; the consumer and creator tiers are not BAA-eligible | No — creator, starter, pro consumer tiers | ElevenLabs |

The pattern across the six: the BAA lives on the enterprise tier, gated by sales-channel approval. Anyone using the free or consumer product with PHI is creating a HIPAA breach risk that no later contracting can retroactively cure.

What the BAA does not cover

The BAA addresses the contractual relationship. The buyer still owns:

1. The Security Rule risk analysis

Required by 45 CFR § 164.308(a)(1)(ii)(A). The Covered Entity has to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic PHI. Adding an AI vendor to the workflow is a material change that triggers a fresh risk analysis, not an addendum to an old one.

2. The minimum-necessary rule

45 CFR § 164.502(b). The CE has to limit use and disclosure of PHI to the minimum necessary for the intended purpose. AI deployments tend to ingest more than needed by default — a clinical summarisation tool pointed at a full chart processes far more PHI than a tool that summarises only the consult note. Tightening the input set is a buyer-side design decision.

3. Workforce training

45 CFR § 164.308(a)(5). Workforce members have to be trained on the CE's policies and procedures with respect to PHI. Adding an AI tool to clinical workflow triggers training on the new policy, not just a software rollout.

4. Audit controls

45 CFR § 164.312(b). The CE has to record and examine activity in systems that contain or use electronic PHI. The AI vendor's logging is part of the picture; the CE's own audit policy is the rest.

5. Breach notification

45 CFR §§ 164.400-414. The CE owes 60-day notification on breaches affecting more than 500 individuals. AI-vendor breach affecting PHI on behalf of the CE flows up through the BA's breach notification to the CE, then out from the CE under the CE's own obligation.

6. State law

HIPAA preempts contrary state law only where state law is less protective. State laws on health information (Texas HB 300, California CMIA, New York SHIELD Act, Illinois BIPA for biometrics) often impose stricter obligations than HIPAA. The BAA does not address state-law exposure at all.

The HIPAA procurement checklist for AI tools

The checklist below assumes a US Covered Entity buying an AI tool that will process PHI.

  1. Confirm BAA eligibility on the specific product and tier. The marketing site rarely covers tier-by-tier eligibility; the sales channel is the reliable source.
  2. Execute the BAA before any PHI enters the system. Pilots, demos, and proof-of-concept work on real PHI without a BAA are technical breaches.
  3. Run a fresh Security Rule risk analysis covering the AI workflow. Existing risk analyses pre-AI rarely cover the new threat surface.
  4. Apply minimum-necessary on the input side. Decide what PHI elements the deployment actually needs and prevent the rest from reaching the vendor.
  5. Document the human oversight checkpoint. Clinician review of AI output for any clinical-decision-supporting deployment is the realistic floor.
  6. Train workforce on the new policy. Software training and HIPAA policy training are different artifacts and both need to land.
  7. Set audit cadence. Who reviews vendor logs, on what cadence, with what escalation path.
  8. Document state-law exposure. Texas, California, New York, Illinois, and other states with stricter health-information regimes need their own line items.

The non-US healthcare angle

UK and EU healthcare buyers do not face HIPAA directly but face analogous obligations:

The BAA does not satisfy any of these. UK and EU buyers should run their AI vendor reviews under the matching local regime, not against the HIPAA structure.

Related reading


Share this HIPAA for AI tools: what a Business Associate Agreement actually covers profile:Share on XBluesky

Talk to Michael about your AI compliance work — or your AI vendor governance more broadly

CompanyScope's public profiles cover the general picture. Michael runs Janus DPO-as-a-Service for businesses that need ongoing AI vendor governance, and writes one-off CIPP/E-reviewed Vendor Risk Notes for specific procurement decisions. Tell him what you're actually trying to clear.

Your context goes only to Michael. We don't share with the vendor or anyone else. Privacy notice.

AI vendor compliance updates

New profiles, regulatory deadline reminders, and the occasional AI vendor red flag. Written by Michael K. Onyekwere, CIPP/E. Free.

We don't share your address. Unsubscribe any time. Privacy notice.

For ongoing AI compliance support, work with Janus DPO-as-a-Service. Browse the vendor index or other topic guides.