Is Your AI Medical Receptionist HIPAA Compliant? 9 Questions to Ask Before You Sign

The U.S. Department of Health and Human Services, HHS, enforces the Health Insurance Portability and Accountability Act, HIPAA, through its Office for Civil Rights, OCR, and that office reached an OCR settlement with a software vendor serving oral healthcare practices over a breach that hit roughly 15 million records. The data that leaked was just names, phone numbers, addresses, birth dates, and appointment times, nothing about charts or diagnoses or clinical notes. But that alone was enough for the government to call it a full PHI breach at full scale. So if part of you has been thinking an AI answering service is lower risk because it only books appointments, that case is the one to sit with for a second.

Physician use of AI has more than doubled in three years, according to the American Medical Association, AMA, and a recent AMA survey puts adoption above 80 percent across practice settings. Front desk automation is riding that same wave, with practices signing these contracts faster than they’re reading them.

You’ll hear “we’re HIPAA compliant” in almost every vendor pitch, and it’s usually the sentence that shuts the compliance conversation down before it even starts, moving everyone straight to pricing and features. But that sentence, on its own, tells you nothing. A company doesn’t earn HIPAA compliance once and keep it like a badge. It has to show you the specific behaviors, in the specific way you plan to use the product, and proving that lands on you, not on them.

Here are the 9 questions worth asking before you sign anything.

Question 1: Will you sign a BAA, and does it name the specific product I’m using?

A Business Associate Agreement, BAA, is what makes a vendor legally on the hook for the patient data it touches. HHS’s own business associate guidance defines that relationship by what a vendor does, not what they call themselves, so any company that creates, receives, or transmits PHI for you counts, no matter what their sales deck says. No signed BAA means no legal standing when they mishandle a patient’s information, and you’re the one who answers to HHS for it, not them.

Practices get tripped up in a few specific ways:

• A vendor selling their “AI Voice Agent” might have a BAA that only covers their older call center platform, not the new AI layer running on top of it.
• Some tools bolt an AI feature onto a product built years before AI existed. The BAA was written for that old product, and nobody thought to update it when the AI got added.
• “We work with HIPAA-compliant infrastructure” is a sentence about their hosting provider, not about them. Amazon Web Services being HIPAA-eligible tells you nothing about the software sitting on top of it.

Catching any of that early just means asking for the BAA before the demo, not after you’ve signed, and reading the scope section closely. It should name the exact product, including the AI or voice piece, not just “our services generally.”

Reading that scope closely also means catching a specific dodge vendors like to use. Some vendors will still try to wriggle out of signing one at all, using something called a conduit exception. That only covers companies that transmit data without touching it, basically a digital mail carrier, and it doesn’t fit here. An AI system that listens to a call, turns it into text, pulls out a name and appointment time, and writes it into your scheduling system is doing far more than transmitting. It’s processing, which makes it a business associate, and OCR guidance has stayed consistent on this even as vendors keep trying the argument.

The AI receptionist you’re evaluating almost certainly isn’t running its own language model from scratch. It’s calling out to a foundation model provider behind the scenes, sometimes more than one, to do the real listening and understanding, which makes that provider a subcontractor. HIPAA needs your vendor to lock that subcontractor into the same restrictions through its own written agreement, so ask to see proof that agreement exists. A vendor with a clean BAA who never secured the model provider underneath has handed you a contract with a weak link nobody checked.

Question 2: Where does the recording sit, and for how long?

A signed BAA tells you the vendor is accountable, not what they’re doing with the audio and transcripts your patients generate all day long. You need specific answers here, not a reassuring paragraph.

Get the vendor to answer these in writing:

• Is raw audio stored, or just the transcript? Some tools drop the audio after transcribing. Some keep both, forever.
• What server region holds the data? “The cloud” isn’t an answer. US-based storage with encryption at rest and in transit is the bare minimum, not a perk.
• What’s the retention period, and can you shorten it below their default? A vendor that keeps calls forever by default is doing that to help their own analytics, not to lower your risk.
• Who at the vendor’s company can pull up raw recordings, and when? If the answer is “support, to troubleshoot,” ask how that access gets logged and limited.

Retention is the one vendors tend to go quiet on. Pay attention if a vendor talks a lot about encryption and says almost nothing about it, since that split usually means something. Encryption matters, but it only covers part of the risk. Under the Security Rule, encryption is what’s called an addressable safeguard, not a required one, and most sales reps don’t know that themselves. Addressable doesn’t mean optional, though. It means a vendor can pick a different safeguard instead, as long as they’ve documented why that safeguard protects the data just as well. So if a vendor tells you data isn’t encrypted, the next question is what documented alternative they’re using instead, because “we haven’t gotten to it yet” doesn’t count as one.

Question 3: What happens when the AI can’t understand the caller?

Every AI voice system fails sometimes. Heavy accents, bad connections, background noise, a patient mumbling a medication name, all of it trips these systems up eventually. The real question isn’t whether this happens. It’s what the system does the moment it does.

Some systems escalate to a human mid-call, which is fine as long as that human is also covered under the same BAA. Others fall back on texting the patient a link to finish things themselves, which shifts PHI onto a whole different channel, SMS text messaging, that needs its own security review. Some systems just keep guessing instead, feeding a garbled transcription into your scheduling system, and that creates a different problem entirely: bad data lands in a patient’s record with nothing flagging it as uncertain.

Ask specifically:

• What’s the escalation path once confidence in the transcription drops below a threshold?
• If it escalates to SMS, is that texting system covered by the same BAA, or is it a separate vendor you’ve never vetted?
• Does the system flag low-confidence entries for a human to double-check before they hit the chart?

A vendor who’s thought this through will have a specific answer ready for each of these. One who hasn’t will describe the happy path, then change the subject the second you push on failure.

The confidence threshold that triggers escalation makes a risk decision for your practice, whether you notice it or not, even though it looks like a simple technical setting. A vendor tuned for speed lets more borderline calls through untouched, while one tuned for accuracy escalates more often, costing a bit more human time but leaving fewer garbled entries sitting in a chart. Ask if that threshold can even be adjusted, and what it defaults to.

Question 4: Is my patients’ data used to train your models?

This is the one vendors dodge the most, because the honest answer sometimes hurts the pitch. Some AI companies improve their models on customer data by default, then bury the opt out somewhere in a settings page nobody finds.

Using patient calls to train a general-purpose model that other customers benefit from goes beyond the treatment, payment, and operations purposes HIPAA generally allows without special authorization. That has to be spelled out in the BAA itself, not tucked into a terms of service document patients never see and you never negotiated.

Push for this in writing:

• Is patient data used to train or fine-tune models, by default or otherwise?
• If there’s an opt out, is it on or off by default for new contracts?
• Does the opt out cover calls they’ve already collected, or only new ones from here on?

Once you have those answers, push harder if a vendor says the training data gets anonymized first, since that word gets thrown around loosely. HIPAA only recognizes two real ways to strip data of its identity: removing a specific list of eighteen identifiers, called the Safe Harbor method, or having a qualified statistician certify that the re-identification risk is very small. “We anonymize it” is a marketing line, nothing more. Ask which of the two methods they use, and ask for the paperwork behind it, because most vendors who say “anonymized” have done neither.

Question 5: What counts as minimum necessary in your system?

HIPAA’s minimum necessary standard says a business associate should only touch the smallest amount of PHI needed to do its job. For an AI receptionist, this gets specific fast. Does the system need a patient’s full diagnosis history to book a follow-up? Almost never. Does it need her date of birth to confirm who she is? Often, yes.

Most platforms don’t draw that line on their own, though. A lot of these platforms run on general-purpose language models with no built-in concept of minimum necessary. They see whatever text comes in, and unless a developer specifically restricted what the system pulls from your electronic health record, EHR, or writes back into it, the AI can end up touching more of a patient’s record than the task ever called for.

Ask the vendor to walk you through, field by field, exactly what data their scheduling assistant pulls from your practice management system for a routine reschedule call. For a task that basic, the reasonable fields look like this:

• Name and date of birth, to confirm who’s calling
• Appointment date, time, and provider
• Contact details, so the system can send a confirmation

Anything beyond that is a red flag, especially:

• Full diagnosis or visit history
• Billing or insurance codes
• Medication lists or lab results

If the answer includes fields from that second list for a task as simple as moving an appointment, that’s the system collecting more than the task needs, and it’s exactly the kind of thing an auditor flags right away.

Minimum necessary doesn’t apply, though, when information moves between providers for a patient’s treatment. It applies at full force to healthcare operations, and scheduling, reminders, and intake all sit in that operations bucket, which leaves an AI receptionist with almost no legal cover for touching more data than the scheduling task calls for, no matter what the vendor’s roadmap eventually wants the tool to do.

Question 6: How does the system verify a caller is who they say they are?

A receptionist who’s worked at your practice for years recognizes regular patients by voice, catches a strange request, and knows when to ask a follow-up question. An AI system doesn’t have that instinct. It verifies identity through whatever rules a developer coded, and those rules swing wildly between vendors.

On a given call, the system might be checking:

• Just a name and date of birth
• A name and date of birth, plus a third factor like the last four digits of a phone number on file
• Whatever the caller happens to volunteer, with nothing independently checked at all

That last tier is the risky one, since a patient’s name and birthday are often public or easy enough to guess. That gap means anyone could reschedule an appointment or ask about someone else’s visit.

That gap is a real way a breach can happen here, with an AI system doing exactly what it was built to do while handing PHI to the wrong person entirely. So ask:

• What the verification steps are
• Whether they’re adjustable to your practice’s risk tolerance
• What happens when verification fails

A system that says “I’m sorry, I couldn’t verify you” and ends the call is safer than one that just answers the question anyway.

The part of HIPAA that covers confirming who’s accessing a system is built for verifying who’s logging into a system holding electronic protected health information, ePHI, not for verifying who’s calling in on a phone line, which is why this question has no clean regulatory answer to check against. Caller verification instead falls under the general rule that you have to run a risk analysis and pick safeguards that make sense for your practice, which means the real standard is whatever your own documented risk analysis says it should be. A vendor offering one fixed verification method for every practice hasn’t done that analysis for you. They just picked a default and hoped it fits.

Question 7: What does your audit trail capture?

If something goes wrong, an OCR investigation or an internal review is going to ask who accessed what, when, and why. So when a vendor says “we have full audit logging,” test that against what an audit log needs to contain to matter under a HIPAA Security Rule review.

Unlike encryption, the audit controls rule isn’t addressable. It’s required, with no documented workaround that lets a vendor off the hook, so if a vendor gives you a vague answer on logging the way they might on encryption, that’s a different kind of gap, and a harder one to excuse.

A log that only says “call received, appointment booked” is close to worthless during an investigation. A log that holds up under review captures:

• Timestamp and duration of every interaction involving PHI
• What specific data fields were accessed, viewed, or written
• Whether a human agent got involved at any point, and who that was
• What triggered any escalation or fallback behavior

Those four things aren’t optional extras, so ask the vendor to pull a sample log for one call and check whether it has them. If they hesitate, or the sample looks thin, that tells you how seriously logging was built into the product versus bolted on later because a customer asked.

Question 8: What happens to my data if I cancel the contract?

Vendor relationships end eventually, whether a practice switches systems, gets acquired, or simply decides the product isn’t working out. Whatever the reason, the BAA should already say, in plain terms, what happens to every recording, transcript, and derived data point once that relationship is over.

Pin down two things specifically:

• Does the vendor return your data, destroy it, or both, and on what timeline after termination?
• If they used your data to improve a shared model, does anything of your patients’ data live on inside that model after the contract ends? Some vendors will say the data itself got deleted while the model that learned from it stays exactly as it is, which is a very different answer than full destruction.

That second question already points to the answer. HIPAA requires a BAA to spell out that PHI gets returned or destroyed when the relationship ends, and if that’s not feasible, the protections have to keep applying anyway, indefinitely. A trained model is basically the scenario the rule had in mind without naming it directly: you can delete the original recordings, but nobody can cleanly pull one specific patient’s influence back out of a model that already learned from it. If that’s the vendor’s situation, the BAA needs to say those protections keep running on the model for good, not just on the files you can point to and delete.

A BAA that stays silent on what happens after termination is a BAA that leaves you exposed long after you’ve stopped thinking about that vendor at all.

Question 9: Who carries liability when the AI gets it wrong?

A signed BAA makes the vendor responsible, by contract, for their own mistakes, but it doesn’t make the government stop holding your practice responsible too. If an OCR investigation finds a violation, the fines and the corrective action plan land on the covered entity. That’s you, no matter what your contract says about who pays for it.

Those fines are not small. HHS raised these tiers for inflation in a 2026 penalty update, effective January 28, 2026. The four tiers now break down like this, all with an annual cap of $2,190,294 per violation category:

• Didn’t know, and couldn’t reasonably have known: $145 to $73,011 per violation
• Reasonable cause, not willful neglect: $1,461 to $73,011 per violation
• Willful neglect, corrected within 30 days: $14,602 to $73,011 per violation
• Willful neglect, never corrected: $73,011 up to the full $2,190,294 cap

Those numbers hit you as the covered entity first. Recovering damages from a vendor afterward through a lawsuit is a separate, slower, far less certain road than an OCR investigation that’s already underway.

The scary headline numbers usually leave out the more common outcome, though. Most enforcement never gets close to those ceiling figures. It ends in a resolution agreement, a negotiated settlement paired with a corrective action plan that OCR keeps checking on for years. The software vendor breach mentioned earlier, the one that hit 15 million records, settled for a fairly small sum, and the real cost wasn’t the check written to the government. It was years of required risk reviews, rewritten policies, and reports OCR kept following up on, on top of every patient relationship that took a hit along the way. That’s the liability to price in before you sign anything, not the maximum figure sitting on the tier table.

Final Thoughts

Every one of these questions is really asking whether this system was built by people who thought about a patient before they thought about a sale. That used to be an easy thing to check. A receptionist who has worked your front desk for years already knows what shouldn’t leave the building, even without anyone writing her a policy that says so, while an AI system knows nothing until someone programs it to know. That gap, between what a vendor built in and what your patients need protected, is where most of the real risk in this technology lives.

That gap only gets harder to see from the outside as these systems get better at sounding warm and careful on a call. That warmth is easy for a vendor to script into a voice. Building real privacy protection into the system underneath is a separate, harder job, and it’s the only one that protects anybody. Asking a vendor these questions, in writing, before you sign, is how you find out which one you’re dealing with, well before a patient finds out the hard way.

Frequently Asked Questions

Is an AI medical receptionist HIPAA compliant?

No software is HIPAA compliant on its own, because HIPAA regulates how an organization behaves, not what a product is. An AI receptionist can be used in a compliant way when the vendor signs a BAA that names the AI component specifically, secures its own foundation model subcontractor in writing, limits what patient data the system touches, and logs every interaction involving PHI. Ask for proof of each of those four things rather than accepting “we’re HIPAA compliant” as an answer.

Does a HIPAA compliant answering service need to sign a BAA?

Yes. Any service that creates, receives, maintains, or transmits PHI on your behalf is a business associate under HHS guidance, and that relationship is defined by what the vendor does rather than what it calls itself. An answering service that takes a patient’s name, reason for calling, and appointment details is handling PHI, so a signed BAA is required before any call is routed to it.

Are voicemails HIPAA compliant?

Leaving a voicemail for a patient is permitted under HIPAA, but the minimum necessary standard applies, so the message should carry only what the situation requires, typically a name, a callback number, and a request to call back rather than clinical detail. The picture changes when an AI system records, transcribes, or stores voicemails, because that transcript becomes PHI held by your vendor and falls under the same BAA, retention, and audit logging questions covered above.

Which texting service is HIPAA compliant?

Standard carrier SMS is not encrypted and no texting platform is compliant by default. A texting vendor becomes usable for PHI only once it signs a BAA and provides encryption, access controls, and audit logging. This matters specifically for AI receptionists, because a system that falls back to texting a patient a link has moved PHI onto a second channel. Confirm that channel is covered by the same BAA and is not an unvetted third-party vendor.

Who is liable if an AI receptionist causes a HIPAA breach?

Your practice is. As the covered entity, you face the OCR investigation, the fines, and the corrective action plan regardless of what your vendor contract says. A BAA gives you contractual recourse against the vendor afterward, but recovering from them is a separate and far slower process than the enforcement action already running against you. That asymmetry is the reason to vet a vendor before signing rather than after an incident.

What should I ask an AI receptionist vendor about data retention?

Ask four things in writing: whether raw audio is kept or only the transcript, what server region stores the data, what the default retention period is and whether you can shorten it, and who inside the vendor can access raw recordings and how that access is logged. A vendor that talks at length about encryption but goes quiet on retention is telling you something worth noticing. For a wider view of vendor evaluation beyond compliance, see our AI medical receptionist buyer’s guide and our breakdown of the top AI medical receptionist companies.

Disclaimer: This article is for general informational purposes only and does not constitute legal, compliance, or regulatory advice. HIPAA rules, OCR enforcement guidance, and civil monetary penalty amounts are updated periodically and can be interpreted differently depending on your practice’s circumstances, state law, and specialty. Penalty figures, settlement references, and adoption statistics cited here reflect publicly available information at the time of writing and may have since changed; always confirm current figures directly with HHS and the Office for Civil Rights. Vendor practices around BAAs, data retention, model training, and audit logging vary widely and change without notice, so confirm all of them in writing with each vendor. Nothing in this article should be taken as a guarantee of HIPAA compliance or of any regulatory outcome. Practices should consult a qualified healthcare attorney or compliance officer before selecting, contracting with, or deploying an AI receptionist or answering service.