HIPAA compliance for AI voice agents: a buying checklist

I run an AI phone company, which means I sit on the vendor side of every HIPAA conversation a practice owner has. Most of them are polite. Some are sharp. Very few are systematic.

It is not that practice owners do not care about HIPAA. They care enormously. The problem is that AI voice is new enough that most owners do not have a mental checklist for it yet. So they ask whether you are HIPAA compliant, the vendor says yes, and everyone moves on.

That is a dangerous conversation, because HIPAA compliant is not a certification anyone issues. There is no license. There is no badge. Any vendor can claim it. Some are telling you the truth, some are technically wrong, and some are lying.

Below is the checklist I wish every practice owner would use, including on my own product. If MedPhone cannot answer these to your satisfaction, do not buy MedPhone. Then use the same list on everyone else you are evaluating.

First, voice recordings are PHI

One clarification before the list, because it comes up constantly. Some vendors will tell you voice recordings are not protected health information. That is wrong.

Under 45 CFR 160.103, PHI covers any individually identifiable health information transmitted or maintained by a covered entity or a business associate. A recording that identifies a patient and relates to their health, treatment, or payment for treatment is textbook PHI.

The seven questions

Ask every AI voice vendor these. Get the answers in writing.

1. Will you sign a BAA before deployment?

A good answer sounds like: yes, here is our standard business associate agreement, it follows 45 CFR 164.504(e), and we sign it before your first live call.

The red flags are we handle that later, our BAA is with legal, or, worst of all, we do not need one because we are not a covered entity. Some AI vendors genuinely do not understand that they become a business associate the moment they touch PHI on your behalf. Walk away from anyone who does not grasp that obligation.

2. How is PHI encrypted, at rest and in transit?

A good answer names standards. AES 256 at rest, TLS 1.3 in transit, keys held in a managed KMS with rotation, and every storage layer and network hop covered.

The red flags are we use HTTPS, which tells you about transit and nothing about storage, our cloud provider handles encryption, which is a partial answer at best, and anything that reaches for phrases like bank grade security.

3. Who are your subprocessors, and is each one under a BAA with you?

This is the question that catches most vendors off guard, and it is the one I would press hardest on.

Modern AI voice products stitch a lot of infrastructure together. A telephony carrier, a transcription layer, a model provider, a cloud host, often more. Every one of them is a subprocessor. Every one of them touches PHI in some form. Every one of them has to be under a BAA with your vendor, or the compliant boundary has a hole in it.

A good answer confirms that every subprocessor handling PHI is covered by an executed BAA, and offers you that list and those agreements for your compliance file on request. Most vendors will not publish their supplier list on a public web page, and honestly I would not expect them to. But refusing to give it to a customer under an NDA is a different thing entirely, and that is the refusal that should worry you.

The other red flag is an admission that some part of the stack sits outside HIPAA coverage. That is not a small gap. It is the whole thing.

4. Do you use PHI to train AI models?

This is the big one, and where a lot of vendors quietly lose their credibility.

A good answer is a flat no. Patient PHI is never used to train models, the restriction is written into the BAA, and it is enforced at the infrastructure level rather than by policy alone.

The answer to interrogate is we anonymize before training. De identification is genuinely hard and easy to get wrong. If audio is going through a general purpose training pipeline, it is very unlikely to be de identified to safe harbor standard. Ask them to walk you through the specific methodology. If they cannot, treat it as a no.

5. What is your incident notification SLA?

HIPAA requires a business associate to notify the covered entity of a breach involving PHI without unreasonable delay, and no later than sixty days after discovery. That is the legal floor, not a target.

A good answer is 24 to 72 hours on any suspected incident, with the notice covering what happened, which PHI was affected, what has been done, and what you need to do next as the covered entity.

Silence, or we follow HIPAA requirements with no specifics, means the vendor has not thought through what a real incident actually looks like at 2am.

6. How long are call recordings retained, and what happens when we leave?

A good answer has a defined retention period, typically anywhere from 90 days to seven years depending on state law and your own preference, configurable per practice. On termination, PHI is returned or destroyed per the BAA, with certification of destruction available if you ask.

The red flags are indefinite retention, no answer at all about what happens after termination, or the sentence we cannot delete it because our models depend on it, which loops you straight back to question four.

7. Can we get our own audit logs on demand?

A good answer is yes, exported from the dashboard or on request, covering every call, every EHR action, every admin access, retained for the required audit period.

We have logs internally is not the same answer. If you cannot pull your own audit trail, you cannot demonstrate compliance in your own audit, and the logs may as well not exist.

Reading a BAA in ten minutes

You do not need to be a lawyer to read a business associate agreement. You need to check that six things are present and specific. If any of them are missing or vague, ask for a revision or walk.

• Permitted uses and disclosures. Exactly what the vendor may do with your PHI. Broad permissions are a defect, not boilerplate
• Safeguards. Administrative, physical and technical. Look for named commitments such as encryption standards and access controls, not the phrase reasonable safeguards
• Subcontractors. Any subcontractor touching PHI must be under a matching BAA with the vendor, and the agreement has to say so explicitly
• Breach notification. The SLA and the process, both defined. Ideally 24 to 72 hours from discovery
• Return or destruction on termination. What happens to your patient data when the contract ends. Any exception should be justified in the text, usually because law requires retention
• Term and termination. How it ends, including your right to terminate for material breach

That is a ten minute read on a standard agreement. It is not legal advice, but a practice owner should be able to spot the deal breakers without paying for an hour of counsel first.

Three gaps I keep finding

These are patterns I have run into looking at other products in this category. Recognizing them might save you a bad procurement decision.

• Compliance claimed without a BAA. The vendor describes a HIPAA compliant technical stack, then will not sign. That is not compliance, it is marketing. Without a BAA, HIPAA does not attach to them at all
• Compliance that stops at the vendor boundary. Their own systems are fine, but the transcription or model layer underneath is not, so PHI leaves the compliant boundary the moment a call connects. This is why question three matters more than it looks
• Compliance alongside model training on PHI. Even with de identification in the middle, this is a minefield. If a vendor will not commit in writing that your data stays out of training, assume it does not

Use it on us too

I am not going to spend a page pitching MedPhone here. This is a checklist, not an ad.

But we do publish how we answer all seven of these, in full, on our compliance page. Every question above is answered there, so you can score us on the same rubric you are about to use on everyone else. That is the point. If the whole category gets asked these questions often enough, the whole category gets better at answering them.

The one page version

Take this into your next vendor call. Nine boxes. A vendor that comes back clean on all nine is worth a demo. Anything less, dig before you commit.

1. Will you sign a BAA before deployment?
2. What is the encryption standard at rest?
3. What is the encryption standard in transit?
4. Will you provide the list of subprocessors handling PHI, and confirm each is under a BAA?
5. Do you use PHI to train AI models?
6. What is the incident notification SLA?
7. What is the retention period for call recordings, and is it configurable?
8. Is PHI returned or destroyed on termination, with certification?
9. Can we export our own audit logs on demand?

See how MedPhone answers all nine

Questions people ask

Do I need a HIPAA lawyer to evaluate an AI voice vendor?

Not for the first pass. The seven questions are a good enough filter to sort the serious vendors from the rest. Once someone clears that bar and you are close to signing, that is the right moment to bring in counsel.

What if a vendor will not answer these in writing?

Do not buy. Anyone who will not commit to these answers on paper is either not compliant or not willing to defend their compliance later. Neither is what you want in a business associate.

Is any of this different for dental practices?

The HIPAA framework is identical. What differs is the state law layer on top. Some states add patient data protections beyond HIPAA, so ask any vendor how they handle state specific requirements rather than assuming federal compliance covers it.

Is HIPAA the only thing I need to worry about?

No. TCPA governs outbound calling and recording consent, and state law adds more on top. For AI voice specifically, check with your state medical board on whether disclosure to patients that they are speaking to an AI is required. Several states are moving that way.