"HIPAA-compliant" is the easiest claim in this whole market to put on a homepage and the hardest to verify. Every AI phone vendor selling to clinics says it. Most of them mean it. But the word does no work until you've checked the things underneath it, and the gap between a vendor who has genuinely built for HIPAA and one who's pasted the phrase onto a marketing page is exactly the kind of gap that ends in a breach notification and a fine.
If you're putting an AI receptionist on your phones, it's going to hear names, birthdates, symptoms, insurance details, appointment reasons. That's protected health information, full stop, which makes the vendor a business associate and puts the whole arrangement under HIPAA. This is the part you cannot hand-wave. So here's what to actually check, in the order that matters.
The one that's non-negotiable: a signed BAA
Start here, because it's a clean pass-fail. A Business Associate Agreement is a legally required contract that binds the vendor to protect patient data to HIPAA's standard and lays out what happens if something goes wrong. No BAA, no deal. If a vendor hesitates, points you to their terms of service instead, or treats the request as unusual, the conversation is over. A vendor built for healthcare hands you a BAA without friction, because they've done it many times.
And read it, don't just collect it. A real BAA spells out the security obligations, breach-notification timelines, how subcontractors are handled, and what happens to your data when you leave. Vague language here is itself a warning.
Encryption, everywhere the data goes
Every piece of patient data the system touches needs to be encrypted, and that includes the parts people forget. Call audio. Transcripts. Anything stored. The standard to ask for is encryption both in transit, while the call and data move between systems, and at rest, while they sit in storage. This isn't exotic; it's table stakes. But ask the question explicitly, because "we take security seriously" is not an answer and encryption of recordings and transcripts specifically is where weaker vendors get thin.
Access logs and an audit trail
HIPAA expects you to know who touched patient data, when, and what they did. That means the system has to keep detailed access logs. Ask whether you can see who accessed a given patient's information and when. A vendor that can't produce an audit trail can't actually support your compliance obligations, no matter what the homepage says. This is also what protects you if there's ever a dispute or an investigation, because the log is the evidence.
The question most clinics forget: is my data training their model?
Here's the one that slips past people. Ask, directly and in writing: are our patients' calls used to train your AI models? For a lot of general-purpose voice platforms, the default answer has historically been yes, and that's a problem when the audio contains PHI. You want a clear contractual commitment that your patient data is not used for model training, and that it's segregated, not pooled with everyone else's. If the answer is fuzzy, treat it as a no until proven otherwise.
Data retention and deletion
Know how long the vendor keeps recordings and transcripts, where they're stored, and how data gets deleted when you end the relationship. "Forever, somewhere, we'll figure it out later" is not acceptable for PHI. The BAA should cover return and destruction of data on termination. Storage location can matter too, depending on your situation, so ask where the servers are.
Subcontractors and the chain of trust
Most AI voice systems aren't built entirely in-house. They lean on other providers for speech recognition, voice synthesis, sometimes the underlying language model. Every one of those that touches PHI is a subcontractor in HIPAA terms and has to be bound by the same obligations. Ask who's in the chain and whether they're all under appropriate agreements. The weakest link defines your real exposure, not the company whose logo is on the invoice.
Beyond the checklist: minimum necessary and good design
Compliance isn't only contracts and encryption. HIPAA's "minimum necessary" principle means the system should collect and expose only the patient information it actually needs for the task. A well-designed AI receptionist doesn't read back a patient's full record to confirm an appointment, and it doesn't ask for more than the job requires. When you're evaluating a system, notice how it handles information in practice, not just what the security page promises. Thoughtful design is itself a signal that the vendor understands the domain.
A red-flag summary
Walk away, or at least dig much deeper, if a vendor won't sign a BAA, can't clearly explain its encryption, can't produce access logs, gives a fuzzy answer on model training, won't commit to a data-deletion process, or can't tell you who its subcontractors are. Any one of these is a reason to slow down. Several together mean the "HIPAA-compliant" label is decoration.
Frequently asked questions
Is an AI receptionist automatically HIPAA-compliant?
No. Compliance depends on the contract and the configuration, not the technology by itself or the claim on a website. A system is only compliant when there's a signed BAA, proper encryption, access logging, clear data-retention rules, and a commitment that patient data isn't used to train models.
What is a BAA and why does it matter?
A Business Associate Agreement is a legally required contract that obligates a vendor handling protected health information to safeguard it to HIPAA's standard, and it defines breach-notification and data-handling responsibilities. If a vendor won't sign one, you can't use them compliantly. It's the single clearest pass-fail test.
Should I worry about my patients' calls being used to train AI?
Yes, this is one of the most overlooked risks. Some voice platforms use call data to improve their models by default, which is a problem when that audio contains PHI. Get a written commitment that your patient data is not used for training and is kept segregated.
What encryption should an AI phone system have?
Patient data should be encrypted both in transit and at rest, and that explicitly includes call recordings and transcripts, not just stored database records. Ask the vendor to confirm encryption of audio and transcripts specifically.
Who is responsible if there's a data breach?
Both the practice and the vendor have obligations, which is exactly why the BAA matters: it defines the vendor's responsibilities and breach-notification duties. As the covered entity, you remain accountable for choosing and overseeing compliant vendors, so due diligence on the items above is part of your responsibility.
The bottom line
"HIPAA-compliant" is a starting point for a conversation, not the end of one. Get the BAA and read it. Confirm encryption of recordings and transcripts. Check for access logs, pin down data retention, ask who the subcontractors are, and get the model-training answer in writing. None of this is hard to ask, and a vendor genuinely built for healthcare will have clean answers ready. The ones who stumble are telling you something, and it's worth listening before patient data is on the line.
Related reading
- What an AI receptionist actually does for a clinic
- AI receptionist for dental practices
- AI receptionist vs. traditional answering service
Hear it answer your phone
Book a 20-minute demo and hear an AI receptionist take a real call for a practice like yours.
Book a demo →