AI phone agents and HIPAA: what to check before launch

HIPAA applies to covered entities: health plans, health care clearinghouses, and health care providers "who transmit any health information in electronic form in connection with a transaction" the rules cover (45 C.F.R. § 160.103). Bill insurance electronically, and you're in. A dental practice, a physical therapy clinic, a dermatologist, a behavioral health provider: almost all of them are covered entities.

The rules also reach business associates: anyone who "creates, receives, maintains, or transmits protected health information" on a covered entity's behalf, and their subcontractors. That is the part that matters for an AI phone agent, because every vendor in the call path is a candidate.

Protected health information is individually identifiable health information in any form. A caller's name and the fact that they have an appointment with your practice is PHI. So is "I need to reschedule my cleaning," once it's tied to a name or a number. The appointment-booking agent is handling PHI on every call.

A voice agent is a chain: the phone carrier, the voice platform, the speech-to-text service, the language model provider, the text-to-speech service, wherever recordings and transcripts are stored, and whatever the agent reads and writes (your scheduling system, your patient records). HHS's own list of business associate examples now includes a "third-party vendor Artificial Intelligence (AI) chatbot on a provider's patient portal that provides services involving the patient's PHI such as symptom assessment, medical reminders, and appointment scheduling," along with transcription vendors and cloud providers that store PHI.

The rule (45 C.F.R. § 164.502(e)) is that a covered entity may share PHI with a business associate only after obtaining "satisfactory assurance that the business associate will appropriately safeguard the information," documented in a written contract: the business associate agreement, or BAA. It has to say what the vendor may do with the PHI, that it won't do anything else, and that it will report breaches. Each vendor must have the same agreement with its own subcontractors.

Two things people get wrong

• "They can't see the data, so they're not a business associate." HHS says otherwise: a cloud provider that stores encrypted PHI "is a business associate, even if it does not hold a decryption key." Storage is enough.
• "They're just a conduit." The conduit exception covers the postal service and its electronic equivalents: transmission only, with at most transient storage. A platform that transcribes, stores or analyzes calls is not a conduit.

So the checklist question is simple and unforgiving: can you name every vendor that touches a call, and do you have a signed BAA with each one? Some voice and model platforms offer one, usually on a paid tier; some don't offer one at all. A vendor that won't sign can't be in the path.

Before disclosing PHI to someone whose identity isn't already known, a covered entity "must verify the identity of a person requesting protected health information and the authority of any such person to have access" (45 C.F.R. § 164.514(h)). On the phone, that means the agent confirms who it's talking to before it reads out an appointment, a balance or a result.

The minimum necessary standard (§ 164.502(b)) applies too: use or disclose only what the purpose needs. An agent confirming an appointment doesn't need to mention the procedure; a reminder doesn't need the diagnosis.

• Identity first. A date of birth plus the phone number on file, or a code you've sent, before anything account-specific is said.
• Never about someone else. "What time is my wife's appointment?" gets a hand-off, not an answer, unless the caller is on file as authorized.
• Voicemail and callbacks: name and a callback number, not the reason for the visit.
• No clinical advice. Symptoms and medication questions go to a person. The agent's never-do list should say so in as many words.

Recordings and transcripts of calls with patients are PHI in electronic form, which puts them under the Security Rule: access controls, audit logs, encryption in transit and at rest, and a risk analysis that covers the voice platform. Decide, in writing:

• Whether calls are recorded at all, and whether transcripts are kept when they aren't.
• Where recordings and transcripts live, who can open them, and how long they're kept.
• Whether any vendor uses call content to train models. Your BAA should say no.
• How a patient's request to see or delete their information reaches those systems.

Recording consent is a separate question with its own state rules; see call recording consent for AI agents.

The biggest exposure isn't what the agent says; it's what it can look up. An agent with read access to the scheduling system can, if talked into it, read out any patient's appointment. One with write access can cancel them. List every tool and every field the agent can touch, cut it to what the jobs need, and put an identity check in front of anything patient-specific. That is the same discipline as the pre-launch checklist, with a regulator behind it.

1. Confirm you're a covered entity. If you bill insurance electronically, assume yes.
2. List every vendor in the call path: carrier, voice platform, speech-to-text, model, text-to-speech, storage, and anything the agent reads or writes.
3. A signed BAA with each one, before launch. No BAA, not in the path.
4. Identity verified before any patient-specific information is spoken.
5. Minimum necessary: the agent says what the task needs and no more.
6. Nothing about another person without authorization on file.
7. No clinical advice; symptoms and medications go to a person.
8. Recording and transcript policy written down: what, where, who, how long, and no training on it.
9. Tools and fields cut to what the jobs need.
10. The voice platform is in your risk analysis and your breach-notification plan.