Business Associate Agreements for AI Vendors
If a vendor hesitates on the BAA, the evaluation is already over.
Any vendor whose software hears, reads, or stores what your callers tell you is handling protected health information, and under HIPAA that makes them a business associate. The obligation to have a signed Business Associate Agreement in place before that happens sits with you, not with them. AI vendors complicate this in a way traditional software does not: most of them are a thin layer over someone else's speech recognition and someone else's language model, which means the PHI leaves their infrastructure the moment a caller starts speaking. This guide covers what the agreement has to reach, where AI vendors typically fail, and the questions that settle it in one call.
Why AI Vendors Are Different From Ordinary Software Vendors
A scheduling tool holds PHI in a database you can point to. An AI voice or chat product streams it through a chain of third parties in real time — a telephony carrier, a speech-to-text service, a large language model provider, sometimes a separate text-to-speech voice. Each link in that chain is a subcontractor under HIPAA, and each one needs to be covered by a downstream agreement. A vendor who will sign your BAA but cannot tell you who their subprocessors are has signed something they are not in a position to honor.
- PHI in an AI product is in motion across several providers, not at rest in one database
- Every subprocessor in that chain requires its own downstream BAA
- Consumer AI APIs are frequently not covered by any BAA at all, regardless of what the vendor tells you
- Model training on customer data is the failure that most often surfaces after signing, not before
What the Agreement Has to Actually Cover
A BAA that only restates the statute is close to worthless for an AI product. These are the provisions that decide whether the agreement means anything in practice, and the ones your compliance officer should be reading first.
| Provision | What to require | Common weak answer |
|---|---|---|
| Subprocessor disclosure | A named, current list of every third party that touches PHI, with notice before it changes | "We use industry-standard providers" |
| Model training | Explicit, written prohibition on using your PHI to train or fine-tune any model | Silence, or an opt-out buried in the terms of service |
| Data retention | Defined retention windows for recordings, transcripts, and derived data, with deletion on request | "Retained as long as necessary" |
| Breach notification | A specific number of days, ideally well inside the 60-day statutory ceiling | Restating the 60-day maximum |
| Data location | PHI processed and stored in named jurisdictions | No commitment, or "global infrastructure" |
| Termination | Return or certified destruction of all PHI, including transcripts and recordings | Deletion of the account only |
| Audit rights | The right to review controls, plus a current third-party attestation | A marketing security page |
Questions That Settle It in One Demo
These are deliberately specific. A vendor with real compliance infrastructure answers them immediately and in writing. A vendor without one asks to follow up with their team, and often never does.
- Name every subprocessor that touches PHI on a single inbound call, in order.
- Do you have a signed BAA with each of them, and will you show me the list?
- Is our data used to train or fine-tune any model, ever, including in aggregate or de-identified form?
- How long are call recordings and transcripts retained, and can we set that ourselves?
- Within how many days will you notify us of a breach?
- Who signs the BAA on your side, and how quickly can we have it?
- What happens to every copy of our PHI if we terminate?
The single most useful signal is speed. A vendor that routinely handles PHI has a BAA ready to send the same day. One that treats the request as unusual is telling you how many healthcare customers they actually have.
Where Behavioral Health Raises the Bar
Addiction treatment records carry protection beyond HIPAA. 42 CFR Part 2 governs substance use disorder treatment records and is materially stricter, particularly on redisclosure — information that HIPAA would permit to be shared for treatment, payment, or operations may still be prohibited under Part 2 without specific patient consent. A vendor fluent in HIPAA but unaware of Part 2 is a real risk for a treatment center, because the gap tends to appear in exactly the places AI products operate: call recordings, transcripts, CRM notes, and automated follow-up messaging to a patient who has not consented to be contacted that way.
- Part 2 restricts redisclosure more tightly than HIPAA, including to other providers
- Consent must be specific, and automated outreach has to respect its scope
- Transcripts and recordings of admissions calls are Part 2 records, not ordinary call logs
- Ask directly whether the vendor has other Part 2 customers — the answer is usually revealing
How MedSprout AI Handles It
We sign a BAA before any live call is handled, not after a pilot. Our subprocessor list is disclosed by name and is available before you sign rather than on request afterward. Customer PHI is never used to train or fine-tune models, under any condition, and that prohibition is written into the agreement rather than left to policy. Recordings and transcripts follow retention windows you configure, deletion is honored on request, and we operate under 42 CFR Part 2 constraints alongside HIPAA because our customers are treatment centers. If your compliance officer wants the agreement before the demo, that is the normal order of operations here.
Ask us for the BAA and the subprocessor list on the first call. Both are ready to send.