Putting an AI on the front desk without breaking HIPAA

“Is it HIPAA compliant?” is the wrong question

It is the first thing a practice owner asks, and it is the right instinct pointed at the wrong object. HIPAA does not regulate software. It regulates covered entities — your practice — and the business associates you hand patient information to. Compliance describes an arrangement: who holds the data, under what contract, with which safeguards, for how long. Software cannot be compliant on its own.

The corollary catches people out. No product is HIPAA certified — no certifying body, no registry, no seal. What exists is evidence you can read: a signed Business Associate Agreement, a published list of which services may handle protected health information, an independent audit. A vendor claiming certification has still told you something useful, about itself.

So ask a duller question, one with a real answer. When someone calls my office, where does what they say travel, who can read or keep it at each stop, and which of those stops has signed for it? You will have to answer that anyway, the first time anyone asks how you assessed the risk.

Follow the call

The only method that works is boring: take one call and walk it end to end, refusing to hand-wave a step. Do it on paper before you do it in code.

1. The caller dials. Audio crosses the phone network to whichever carrier owns your number.
2. The carrier hands that audio to your application — a stream into a server you run, or a platform you rent.
3. Speech to text. A transcription service turns the audio into words, so somebody's servers now hold a sentence a patient said.
4. The model reads the conversation so far and decides what to do: answer, ask, look up, book, escalate.
5. Tool calls. The agent reads or writes the practice management system, checks a schedule, creates a record.
6. Text to speech. The reply — usually a name, a date and a reason for the visit — is rendered back into audio.
7. The audio returns through the carrier to the caller's ear.
8. Residue: transcripts, logs, any recording, monitoring traces, a confirmation text. The step everyone forgets, and the one that persists.

A caller who gives her name and says her retainer cracked has created protected health information in one breath: an identifier plus a fact about her care. It is PHI at step one and still PHI at step eight. Obligations travel with the data, not with your intentions.

Hop in the call path	Touches PHI?	What you need
Carrier and phone number	In transit only, if nothing is stored	Possibly a conduit. In writing: no recording, no storage, no transcription.
Carrier voicemail or recording	Yes — stored audio and text	A BAA, or switch the feature off entirely.
Media stream into your own server	In transit, into infrastructure you control	Encrypted transport, your access controls, your logging.
Speech to text	Yes — the patient's exact words	A BAA, or a service your cloud agreement already covers.
The language model	Yes — it reasons over the content	A BAA, plus a written no-training commitment.
Text to speech	Yes — the reply names the patient or the visit	A BAA. Easy to forget: it feels like “just a voice.”
Practice management system	Yes — this is the chart	A BAA you likely hold. Check it covers the API, not only the app.
Your database, transcripts and logs	Yes — at rest, forever, unless you decide otherwise	Encryption, least-privilege access, an enforced retention limit.
Confirmation SMS	Yes, once the body says anything about care	A BAA with the messaging provider, recorded consent, a thin body.
Error monitoring and analytics	Yes, whenever a payload lands in a stack trace	Scrub before it leaves your network, or bring the tool under a BAA.

Where the conduit exception ends

A Business Associate Agreement carries your obligations downstream. It commits the other party to safeguard the information, use it only as agreed, tell you when something goes wrong, and bind its own subcontractors the same way. Without one, handing a vendor patient information is itself the problem.

The exception people reach for is the conduit exception. It is real, and far narrower than sales calls suggest. It was written for couriers, the postal service and their electronic equivalents: entities that transport information and have, at most, transient access while moving it. A phone company carrying a call fits.

What does not fit is anything that stores. A vendor maintaining PHI on your behalf is handling it even if no human there ever looks — even where the data is encrypted and the vendor holds no key. Storage and access capability are the deciding facts.

This matters for voice because a telephony vendor is rarely just a wire. The account that routes your calls also sells recording, voicemail transcription, message storage and AI features. Plain routing may sit inside the conduit idea. The features stacked around it do not. Read the product list, not the posture.

One uncovered hop breaks the chain

Apply that to a voice agent and the picture gets uncomfortable fast. Transcription reads what the patient said. The model reasons over it. Speech synthesis speaks a reply containing a name and an appointment time. A text at the end carries content too. Four vendors before you count storage, every one processing patient information rather than transporting it.

Each needs to be under a BAA or replaced with something that is, and there is no partial credit. A stack where transcription, the model and the database are covered but the voice is not has an uncovered hop, and the chain is exactly as strong as that link. We have had to be ready to drop a component we liked because the paperwork was not available on terms worth signing. That is the process working, not failing.

Three vendor answers that sound alike and are not:

• “We will sign a BAA.” Good. Ask to read it before you build on the promise.
• “We have a BAA, and here are the products it covers.” Better. The list is the whole point, and the newest, most interesting service is often not on it.
• “We don't sign BAAs as a general matter, but we can discuss it.” Common and honest, especially from carriers who consider themselves conduits. It means case by case, through legal — your launch date now depends on somebody else's calendar.

The questions to ask a vendor

Print these. Ask on a call rather than by email — the hesitation tells you as much as the answer — and write down what you are told.

1. Will you sign a Business Associate Agreement with us? Yes or no.
2. Is it self-serve, or does it go through sales and legal? Self-serve means today; sales-gated means weeks, and a possible no.
3. Which specific products does that agreement cover? Is the one we intend to use on the list?
4. Do you retain our content — audio, transcripts, prompts, message bodies — and for how long? A number, in days.
5. Is our content ever used to train or improve your models, including in de-identified form?
6. Where is it stored, in which region, and can we pin it there?
7. Who inside your company can access it, and is that access logged?
8. What happens to everything you hold when we terminate — deleted on what schedule, confirmed how?
9. Will you notify us of a breach, and within how many days?

Two follow-ups. If the first answer is a version of “we're a conduit,” ask which features they exclude from that claim — recording, storage, transcription, AI — and whether those can be switched off. If the fourth is “we don't retain it,” ask for it in the contract; a support engineer's word and a retention setting have different lifespans.

Design choices that shrink the problem

The most reliable way to survive a review of ten vendors is to have three. Every choice below removes surface you would otherwise defend.

• Keep the audio and the transcript on infrastructure you control. Streaming media into your own server puts the interesting content where your controls already are.
• Do not record calls unless you have a reason. Recording is on by default in most telephony products and is the easiest thing to switch off. If you keep recordings, write down where they go and when they die.
• Keep the text message thin. A confirmation should tell a patient what they already know: they have an appointment, when, and where. It need not name a procedure. Assume the phone is face-up on a kitchen counter.
• Shrink the vendor count. Each service is another agreement, retention policy, region and termination clause. Two adequate services under one agreement beat four excellent ones under four.
• Prefer what your cloud already covers. If your cloud signs a BAA and publishes a list of HIPAA-eligible services, building from that list is the cheapest compliance decision available to you.
• Separate what is protected from what is not. Dashboards, marketing analytics and error trackers do not need patient content and should never receive it. Scrub at the boundary.

The confirmation text is its own program

The text at the end of the call is not a footnote to the call. In carrier terms it is a separate messaging program with its own registration, consent record and rules, and a caller being happy to talk does not by itself make it acceptable to text them.

We treat it as a distinct object. The caller says yes out loud; that yes is stored as consent tied to the number they called from; the send leg refuses to fire to any other number; STOP and HELP work on every program. The registration has its own failure modes, which we wrote up in what actually gets an A2P 10DLC campaign through.

Then add the HIPAA layer on top of the carrier layer: the body is content, the vendor stores it, and storage means a BAA. A thin body is not only good manners toward whoever picks up the phone — it is the cheapest way to reduce what a vendor holds for you.

What the agent should refuse to do

Privacy architecture is half the job. The other half is behavior, and behavior is where a language model will cheerfully hurt you. Three refusals belong in every build.

• No clinical advice. Ever, including the softened version. “That sounds like it might be an infection” is clinical advice wearing a cardigan. The agent describes what the office does — a same-day slot exists, a doctor will call back — and nothing about the caller's body.
• No chart, record or history to an unverified caller. Somebody who knows a name and a date of birth is not authenticated; they are informed. Anything read back out loud is a disclosure. Confirm only what is needed to book.
• No improvising past the edge of what it knows. The failure mode of a helpful model is a confident guess. Insurance specifics, a balance, anything clinical, anything angry — stop, say plainly that a person will handle it, and hand off.

The handoff is a design problem, not an apology. Decide in advance which categories transfer immediately, where they go during hours and after them, what the caller hears while it happens, and what the human receives — transcript, callback number, reason — so nobody starts over.

How we build it

For a practice, our default shape is straightforward. Regulated workloads run on HIPAA-eligible cloud services under a signed BAA with the cloud provider, in one region, from a published list we can point at. We sign a BAA with the practice, so obligations run both ways and are written down before the first call. The voice application runs on infrastructure we control, so the audio and the transcript are ours to protect rather than someone else's to retain.

Two rules we do not bend. Consent is enforced in code, not in a prompt — the send leg checks a stored consent record and matches the destination against the caller's own number before a message is composed, so no wording of a prompt can talk it into texting a stranger. And the agent's boundaries are enforced by the code around the model, not by asking the model nicely — a tool that would disclose chart data is not callable in an unverified context.

The rest is unglamorous: least-privilege access, a retention window with a job that actually deletes, logs that carry identifiers instead of sentences, documentation in plain English. The full build is described on the AI receptionist service page. What changes in healthcare is the order of operations — the paperwork comes before the phone rings.

Take this to your vendors

One page, in order. If a vendor cannot get through it in one call, that is itself the answer.

1. Draw the call path. Every hop on one sheet of paper, including the ones that only store.
2. Mark each hop: transmits only, processes, or stores. Anything past “transmits only” needs a BAA.
3. Collect the agreements, and read which products each one actually names.
4. Find your uncovered hop. There is almost always one, and it is usually the newest thing in the stack.
5. Switch off every recording, transcription and storage feature you do not need.
6. Set a retention window for audio, transcripts and logs, then confirm something really deletes.
7. Treat the SMS program as separate: consent recorded, enforced in code, STOP and HELP live, body thin.
8. Write down what the agent refuses to do and how it hands off, then try to talk it into each one.
9. Have counsel review the whole arrangement before the first real patient calls.

The reason to do this up front is not fear of a penalty. A call path you can draw is a call path you can fix, and a practice that can name every hop can answer a patient who asks where their information went. For a second set of eyes on yours, tell us what your stack looks like and we will walk it with you on a free discovery call.