Does Every Vendor in Your Voice AI Stack Have a BAA?

I had a nervous breakdown in a meeting once.

Not a dramatic one. I just started crying, in a room with people I was supposed to be leading, about something that genuinely did not warrant it. My brain had been running hot for about two years and I'd told myself the whole time that I was handling it, because nothing had visibly broken yet.

That's the thing about the stuff you don't check. It doesn't fail on the day you skip the check. It fails eighteen months later, all at once, in the worst available room.

I think about that whenever a clinic tells me their voice AI vendor is HIPAA compliant and they've got the BAA on file, and I ask which BAA and they say what do you mean which.

Who counts as a business associate in a voice AI deployment?

Anyone who touches the audio. That's the short version, and it's more people than most buyers realize.

Under 45 CFR 164.502(e), any vendor that transcribes, analyzes or stores audio from a patient call is handling electronic protected health information, which makes them a business associate requiring a signed BAA. Not the primary vendor. Every vendor.

A voice agent is not one company. It's usually four or five stacked on top of each other. There's the orchestration platform you actually signed with. Underneath that, a speech-to-text provider. A large language model provider. A text-to-speech provider. Telephony. Sometimes a separate recording or analytics layer.

Your patient's voice, saying their name and their symptoms, passes through all of them.

What does the paperwork usually look like in practice?

Thinner than the marketing page.

The common pattern is that the platform you contracted with has a BAA with you, and has BAAs with some of its subprocessors, and has a "we're working on it" with at least one. Sometimes the model provider is being used under a standard commercial agreement with no BAA at all, because the platform assumed de-identification was happening upstream when it wasn't.

Nobody's being malicious here. The stack got assembled fast, the subprocessor list changed three times during development, and the compliance paperwork lagged the architecture. Extremely normal engineering behaviour. Also exactly the kind of quiet debt that doesn't fail on the day you incur it.

The question that actually surfaces this is not "are you HIPAA compliant." Every vendor says yes to that. The question is: give me your current subprocessor list, and tell me which of them have executed BAAs and which don't.

Watch what happens to the room.

Why does the architecture change the answer?

Because where the audio goes determines how many BAAs you need in the first place.

If your vendor runs models through third-party APIs, every one of those API providers is in scope. If the vendor self-hosts open models inside its own infrastructure, that entire category of exposure disappears, because there's no third party receiving the audio.

This is one of the reasons HANA is fully open-source and self-hostable with no dependency on external model APIs, and honestly it started as an engineering preference before it became a compliance argument. It turned out to be the single thing enterprise security reviews cared most about. Some of our deployments run entirely inside the customer's own perimeter, which reduces the BAA conversation to one signature instead of five.

Not saying every clinic needs that. A small practice with a straightforward workflow probably doesn't. But you should know which architecture you're buying, because it determines how much paperwork you're responsible for chasing.

What else breaks during a security review?

EHR integration, usually, and later than anyone plans for.

Voice agents that book appointments have to write to the EHR, and write access is where the timeline goes sideways. Epic's booking operations run on FHIR STU3 rather than R4. Oracle Health requires mapping to proprietary code sets. Real-time appointment event notifications through athenahealth's FHIR Subscriptions have been sitting in Alpha. And every Epic instance varies by version and local configuration, so an integration that works at one hospital is not a guarantee at the next one in the same system.

The practical consequence: if a vendor tells you they're "integrated with Epic," that sentence carries almost no information. Ask which operations, on which FHIR version, at which specific instance, and whether it's read-only or bidirectional. Read-only is a lot easier and a lot less useful.

Our integration documentation is public precisely so this conversation can happen before a contract instead of during implementation, and the use case pages note which workflows need write access and which don't.

What should a clinic ask before signing?

Five questions, in this order, and none of them are about the demo.

Give me your subprocessor list and BAA status for each. Where does audio get stored, for how long, and can we set that retention. Is patient audio used for model training, and can we opt out in writing. Which EHR operations do you write to and on what FHIR version. Who is liable if a subprocessor has a breach.

Then ask for the answers in the contract rather than in an email. Sales teams answer these honestly in conversation and then the paper says something looser, which is not deception so much as the ordinary gap between what a salesperson knows and what legal will commit to.

If a vendor can't produce a subprocessor list within a day, that tells you something real about their internal clarity. Ours is in the deployment docs, and our pricing page spells out what changes if you self-host versus use our managed environment.

Key Takeaways

A voice AI deployment is a stack of vendors, not a single vendor, and under 45 CFR 164.502(e) every layer that transcribes, analyzes or stores patient audio needs its own executed BAA rather than an assurance that the primary platform is compliant. The fastest way to surface the real state of things is to ask for the current subprocessor list with BAA status per entry, since the answer is frequently incomplete and the incompleteness is usually accidental rather than deliberate. Architecture determines exposure, so a self-hosted stack with no external model API calls collapses a five-party paperwork problem into a one-party one. Budget separately for EHR write access, because claims of Epic integration mean very little without specifics on operations, FHIR version, instance and direction.

Frequently Asked Questions

Is a HIPAA compliance badge on a vendor website meaningful?

Not on its own. It usually reflects the vendor's own infrastructure and says nothing about the subprocessors handling audio downstream. Treat it as a starting point for questions rather than an answer to them, and ask for the executed agreements.

Should patient audio recordings be retained at all?

It depends on what you need them for. Quality review and dispute resolution are legitimate reasons to keep audio, but the retention window should be deliberately set and contractually specified rather than left at a vendor default. Shorter retention is a smaller breach surface, so default to the shortest window your clinical and legal requirements allow.

Does self-hosting actually reduce compliance burden or just move it?

It moves some and eliminates some. You take on infrastructure responsibility, which is real work. You eliminate the third-party audio exposure entirely, which removes several BAAs and the ongoing job of monitoring whether a vendor changed subprocessors without telling you. For organizations with existing infrastructure teams, that trade is usually worth it. You can see how it's worked across our deployments in five countries.

If you want someone to go through this list against a vendor you're actually evaluating, including us, I'm happy to do it straight. Grab 30 minutes.