HIPAA-compliant AI voice agent: the BAA chain behind every call
HIPAA-compliant AI voice agent: the BAA chain behind every call
A HIPAA-compliant AI voice agent is only as compliant as every vendor its calls pass through. Here's the BAA chain behind one patient call: phone line, speech, model, voice and logs.
Ashish Tripathy, Founder, Pype AI | 15 October 2026 | 8 minute read
A HIPAA-compliant AI voice agent is a voice agent where every company that touches patient information during a call has signed a business associate agreement (BAA), and every one of them actually protects that data the way the agreement says. Not just the vendor you bought from. Every link behind it.
That's the part most people miss when they ask "is this voice AI HIPAA compliant?" The honest answer is always "show me the chain."
Quick context. At Pype AI we build voice agents that talk to patients for hospitals and clinics. Booking, reminders, follow-ups, triage. After millions of minutes of these calls, here's what I think matters most on compliance. It's not just the model. It's who else hears the call.
What a BAA is, in plain words
A BAA is a contract between a healthcare provider and a company that handles protected health information (PHI) on its behalf. Under HIPAA, the hospital or clinic is the covered entity. The vendor is a business associate.
The BAA says what the vendor may do with PHI, that it must protect it under the HIPAA Security Rule, and that it must report breaches. HHS publishes sample BAA provisions if you want to see what goes in one.
Here's the bit that matters for voice AI. A business associate that hands PHI to its own vendors must get BAAs from them too. HIPAA calls those vendors subcontractors, and since the 2013 Omnibus Rule they are directly liable under HIPAA as well (HHS guidance on business associates).
So it isn't one contract. It's a chain.
Your agent is as compliant as its weakest link.
Why a voice AI agent has a longer chain than most software
A normal web form sends patient data to one place. A voice call sends it through several, in real time, and most of them are separate companies.
One sentence from a patient touches five systems before the call ends.
Here's the typical stack behind a healthcare voice agent:
- Telephony. The phone line or cloud calling platform. It carries the audio and often records it.
- Speech-to-text. Turns the patient's voice into words. It hears every name, date of birth and symptom.
- The language model. Reads the transcript, often alongside the patient's record, and decides what to say and do.
- Text-to-speech. Speaks the agent's replies. Those replies contain PHI too ("your lisinopril refill is ready").
- Storage, logs and monitoring. Call recordings, transcripts, traces, QA tools. This is where PHI lives longest.
Then add the hospital systems the agent reads from and writes to, like the EHR or scheduling system. Those usually sit under the hospital's own agreements, but the connection to them is part of the vendor's job.
Let's take one call
Maria calls her clinic on a Tuesday morning:
"Hi, it's Maria Lopez, born March 4, 1961. I need my lisinopril refilled."
Her name, date of birth and medication together are PHI. Here's where they go, and what each hop needs.
| Hop | What it touches | Needs a BAA? |
|---|---|---|
| Phone line | Live audio, maybe a recording | Yes, if it records or stores anything. Pure pass-through may not |
| Speech-to-text | Every word Maria says | Yes |
| Language model | Transcript plus her refill history | Yes |
| Text-to-speech | "Thanks, Maria. I can see your lisinopril." | Yes |
| Recordings and logs | The whole call, kept for weeks or months | Yes |
| QA or analytics tool | Transcripts flagged for review | Yes |
A simplified example. Your own counsel decides what applies to your setup.
Two things in that table surprise people.
The phone line is not always exempt. HIPAA has a narrow "conduit" exception for services that only transmit data with transient access, like a courier or an internet provider. HHS's guidance on cloud computing is clear that it doesn't cover anyone who stores PHI. A calling platform that records calls, keeps voicemail or stores transcripts is storing PHI.
Encryption doesn't remove the need for a BAA. The same HHS guidance says a cloud provider that stores encrypted PHI is still a business associate, even if it doesn't hold the key.
How to check if a voice AI vendor is HIPAA compliant
There is no official "HIPAA certified" badge. HHS doesn't certify vendors. So when a website says "HIPAA compliant," treat it as the start of a conversation, not the end of one.
The clinic signs one BAA. The vendor is responsible for the rest of the chain.
What you actually want to see:
- A signed BAA with you, before any real patient calls. Not after the pilot.
- A named list of subprocessors. Phone, speech, model, voice, cloud. If a vendor won't name them, that tells you something.
- A BAA behind each subprocessor, for the exact service used. Most large cloud and model providers do offer BAAs, but usually only for specific services, plans or settings. "They offer a BAA" is not the same as "our account is covered by it."
- Security that matches the paperwork. Encryption in transit and at rest, access controls, and audit logs. The Security Rule requires audit controls for systems that hold electronic PHI.
- A clear retention policy. How long recordings and transcripts are kept, and who can see them.
If you're comparing vendors more broadly, I wrote up 10 questions to ask AI voice agent vendors. The BAA chain is one of them, but it's the one that's easiest to check on paper.
Where BAA chains usually break
In my experience, the big vendors are rarely the problem. They get reviewed by procurement. The gaps show up in the quiet places.
The tool added to chase a bug sees the same transcripts as everything else.
A few that come up again and again with a generic voice agent stack:
- A debugging or logging tool a developer added to chase a bug, quietly receiving full transcripts.
- A fallback model. The main model has a BAA. The backup that kicks in during an outage doesn't.
- A different product tier. The vendor's enterprise plan is covered, but the account in use is on a standard plan that isn't.
- Analytics and QA. Someone exports transcripts to a spreadsheet or a review tool to score calls.
- Test environments using real calls. "Just for testing" is still PHI.
None of these are exotic. They happen because the chain grows over time and nobody re-draws it.
Re-draw the chain every time you add a tool. Not once a year.
The BAA is the floor, not the ceiling
A complete BAA chain means everyone has promised to protect PHI. It doesn't tell you whether the agent behaves well on the call.
For that you need something different: a record of what the agent heard, what it decided, and why. We wrote about that in detail in how to build auditable AI agents for healthcare. The two fit together. The BAA chain proves where the data went. The decision trail proves what the agent did with it.
A short note on Pype, since people ask. We design our healthcare voice agents with HIPAA in mind from the first call flow, and we expect the "show me the chain" question in every US evaluation. Our earlier post on building secure and compliant voice AI for healthcare covers the security side.
Key takeaways
- A HIPAA-compliant AI voice agent needs a BAA with every company that touches PHI, not just the one you contract with.
- A voice call passes through telephony, speech-to-text, a language model, text-to-speech and storage. That's often five or more vendors.
- Storing PHI, even encrypted, makes a vendor a business associate. The conduit exception is narrow.
- There is no official HIPAA certification. Ask for the signed BAA and the subprocessor list.
- Chains break in quiet places: logging tools, fallback models, the wrong product tier.
Five questions. Get the answers in writing.
Compliance work isn't the fun part of building voice agents. But drawing the chain once, properly, saves a lot of awkward calls later :)
Frequently asked questions
What makes an AI voice agent HIPAA compliant?
A signed BAA between the healthcare provider and the vendor, BAAs between the vendor and every subcontractor that touches PHI, and real safeguards behind them: encryption, access control, audit logs and breach reporting. The paperwork and the practice both have to be there.
Do speech-to-text and LLM providers need a BAA?
Yes, if they receive PHI, and in a healthcare voice call they almost always do. Many large providers offer BAAs, but often only for specific services or settings, so check that the exact service in use is covered.
Does a phone or telephony provider need a BAA for voice AI?
If it only carries the call with transient access, it may fall under HIPAA's conduit exception. If it records calls, stores voicemail or keeps transcripts, it's storing PHI and needs a BAA. Confirm the details with your compliance team.
Is there a HIPAA certification for voice AI?
No. HHS doesn't certify vendors as HIPAA compliant. Third-party audits can help, but what you should ask for is a signed BAA and the vendor's list of subprocessors.
Is HIPAA compliant voice AI enough to keep patients safe?
No. HIPAA compliance protects the data. It doesn't tell you whether the agent heard the patient correctly or escalated an urgent symptom. For that you need testing and a decision trail for every call.
About the author
Ashish Tripathy is the founder of Pype AI, which builds voice AI agents for hospitals and healthcare providers. Pype also maintains Whispey, an open-source, OpenTelemetry-based observability tool for voice AI agents.