Compliance Checklist

Dental AI Receptionist HIPAA Compliance: 14 Questions Before Live Calls Move

An AI receptionist that touches a patient call is touching protected health information. The HIPAA gate matters more than any feature on the marketing page. Use this checklist to separate vendors who can describe their actual data handling from vendors selling generic compliance language.

Problem framing

Security claims can sound complete while leaving out the operational details that decide whether patient data is safe in practice. A SOC 2 logo on the marketing page is not the same answer as a clear description of who can read a transcript and for how long.

Most HIPAA failures in dental software are not encryption failures. They are access-control failures, retention failures, BAA gaps, and incident-communication failures — operational details that only surface when someone asks the right questions before live calls move.

The front desk is not the team that should be sorting through a vendor's security posture during onboarding. Owner-operator dentists and office managers need a short list of plain questions that get clear answers — or get the vendor disqualified before contracts move.

Implementation checklist

Ask when the BAA is offered and who from the vendor signs it.

Confirm the BAA is signed before any live patient call routes through the system.

Verify which records are encrypted in transit and at rest.

Ask for the data retention policy in days, not adjectives.

Confirm how access is limited — by role, by practice, by audit log.

Ask which subprocessors touch patient data and where the BAA chain extends to.

Confirm how transcripts and call summaries are delivered, and where they live.

Verify access controls for support staff at the vendor itself.

Ask how a security incident would be communicated and how fast.

Confirm patient consent and disclosure expectations for AI-handled calls.

Review how the backup number is tested before live calls move and where callers land if that line rings out.

Ask for the data return and export path on cancellation.

Confirm whether the vendor maintains an audit log of admin actions.

Verify the difference between PHI in production logs versus PHI in error tracking — they are not the same risk surface.

Security posture should be operational, not abstract

The best vendor answers describe the actual setup. When the BAA is sent. How access is limited at the role level. What gets configured before any patient call moves. How incidents are communicated and on what timeline. That level of detail is more useful than a compliance badge displayed on a marketing page.

Generic claims — "enterprise-grade security," "HIPAA-compliant by design," "bank-level encryption" — are marketing phrases. They are not answers. A vendor confident in its security posture can describe specific data flows, retention windows, and access boundaries in plain language.

Practices evaluating an AI receptionist should treat the security review as part of the operational review, not as a separate compliance checkbox. The questions in this guide overlap with the questions a practice asks about call routing, BAA signing, and pilot rollout — because they are the same decision, viewed from different angles.

The BAA is the gate, not a footnote

A Business Associate Agreement is required before any vendor can lawfully handle protected health information from a covered entity. For a dental practice, that means before any patient call routes through the AI system, the BAA needs to be signed.

The right answer from a vendor is that the BAA is offered up front, sent during the initial onboarding conversation, and signed before live calls move. Not after onboarding. Not on a verbal commitment. Not under a temporary arrangement.

If a vendor offers to "get the BAA over to you next week" while suggesting calls could start in the meantime, the practice has a compliance problem before it has a software problem. A signed BAA is the legal precondition for the relationship. If the vendor cannot complete that step quickly, that says something about how seriously the rest of the security posture is treated.

BAAs should also be readable. A 40-page document with vague boilerplate is harder to evaluate than a focused agreement that names the specific scope of services, the data being handled, and the practice's rights on termination.

Access controls in plain English

Access control is the single most important question after the BAA. The right answer describes who can see what, on what basis, and with what audit trail. "Encrypted at rest and in transit" is necessary but not sufficient — encryption protects data in storage and transit, but access control determines who can decrypt and read it.

Look for role-scoped access where practice users can only see their own practice's data, and where vendor support staff can only access patient records when there is a specific support reason. Logged admin actions are a strong signal: a vendor that logs every internal access creates an auditable trail that protects both sides of the relationship.

A useful follow-up question: "If a support engineer at your company needs to view a transcript to debug a problem, what happens?" The right answer involves a ticketed access request, a time-boxed permission, and a logged event. The wrong answer is silence or vagueness.

Encryption, retention, and the data trail

Encryption in transit (TLS) and encryption at rest are table stakes — every serious vendor has both. The harder question is what data is kept, for how long, and where.

Ask for retention policy in days. "As long as needed" is not an answer. A clear policy specifies how long call audio is retained (usually shorter), how long transcripts and summaries are retained (usually longer because they have ongoing operational value), and what triggers deletion.

Patient data should live in databases the vendor controls, not scattered across third-party logging services, analytics platforms, or developer dashboards. Production logs in particular are a common gap — a vendor might encrypt the database carefully but write transcripts in plain text to a log file that anyone with engineering access can read. Ask specifically: does PHI appear in production logs or error-tracking systems?

Incident communication: what should happen when something breaks

Every system has incidents. The question is how the vendor communicates them — to the practice, to affected patients if relevant, and on what timeline. HIPAA requires notification of certain breaches within specific windows, but the operational discipline matters more than the legal minimum.

A vendor with mature incident communication has a public status page, an incident-response playbook, and clear escalation paths. They can answer the question "how would you tell us the system was down for 20 minutes during lunch yesterday?" with specifics.

A weaker answer is "we'd send an email if there was a problem." That is reactive, not procedural. Practices should know in advance how outages are communicated, how breach notifications work, and what the timeline expectations are — before the first incident, not after.

Subprocessors and where call data actually travels

An AI receptionist almost certainly uses third-party services — telephony providers, speech-to-text, language models, monitoring tools. Each of those is a subprocessor that may touch patient data. HIPAA requires the BAA chain to extend to subprocessors that handle PHI.

Ask for the list of subprocessors that handle patient data. A confident vendor publishes this list and updates it when it changes. Each subprocessor should have a BAA in place with the vendor. The practice does not sign BAAs with subprocessors directly; the vendor's BAA covers the chain.

Common subprocessors in voice-AI systems include the telephony provider, the language model provider, the database hosting platform, and the error-tracking system. Of those, the language model provider matters most — the call audio or transcript needs to pass through their system for the AI to do its job, so the BAA with that provider is non-negotiable.

How HIPAA applies to call transcripts and summaries

Call transcripts contain PHI by default: the caller's name, the reason for the call, any clinical details the patient mentioned. Summaries derived from those transcripts inherit the same protection. The vendor's job is to ensure both are handled under the BAA, with appropriate access controls, retention limits, and audit logging.

A subtler question: where do summaries get delivered? If the vendor sends a callback task with a transcript snippet to the front desk's email inbox, the email channel itself becomes part of the PHI handling surface. The right answer routes operational summaries through an authenticated portal interface, not unencrypted email.

Practices should also confirm that no PHI flows through public-facing systems like marketing analytics, third-party form submissions, or unauthenticated webhooks. Those surfaces are common in SaaS architectures and routinely become accidental PHI leak points if not deliberately scoped.

What a legacy answering service cannot promise that an AI receptionist can

Traditional human-staffed answering services have their own HIPAA considerations: agents in physical call centers, screen recordings for training, message-board systems shared across clients. Those workflows can be made HIPAA-compliant, but the surface area is large and the audit trail is rarely as crisp as a software system's.

A well-designed AI receptionist can offer tighter, more auditable controls: every access logged, every retention window enforced by the database, every access boundary checked by code. The cost is a different risk profile — the model itself becomes a system the practice has to evaluate.

Neither model is automatically better. What matters is whether the vendor can describe its data handling specifically enough that the practice can verify the claim. Generic "we're HIPAA-compliant" answers from either side of the AI-versus-human comparison should be a disqualifier.

Pair security review with your setup review

Security and patient experience are connected. Emergency rules, summary delivery format, access controls, and routing decisions all shape the data flow that has to be HIPAA-defensible. A practice that reviews them together avoids the surprise of discovering, three weeks into the pilot, that callback summaries are landing somewhere the BAA does not cover.

The pilot-first rollout pattern works here too. Live calls do not move until the security review and the setup review are both complete. If a vendor pushes to start before either is settled, that is a process problem the practice should not absorb.

A useful sequencing rule: BAA signed, then access controls and retention policy confirmed, then routing rules walked through, then a pilot window with controlled call volume. Each step gates the next. Skipping a step usually means absorbing risk that the vendor should have handled.

FAQ

Does HIPAA alignment mean live calls can move right away?

No. Practices should confirm scripts, routing rules, handoff paths, access controls, and the BAA path before live calls are routed. HIPAA compliance is necessary but not sufficient — the operational setup needs to be reviewed alongside the compliance posture.

Why does a public security page matter for evaluating a vendor?

A public security page gives buyers a reviewable explanation of how the vendor handles setup, access, BAA, retention, and incident communication. If a vendor cannot publish that information publicly, the practice has no way to verify claims made in sales calls or compare across vendors.

Are AI dental receptionists riskier than legacy answering services for HIPAA?

Not categorically. Both models carry HIPAA obligations. AI receptionists can offer tighter access controls, more granular audit logging, and enforced retention windows. Legacy answering services often have larger physical surface areas and looser audit trails. The right question is whether the specific vendor — AI or human-staffed — can describe its data handling clearly enough for the practice to verify the controls.

What subprocessors should a dental practice ask about?

The telephony provider, the language model provider (if voice AI), the database hosting platform, the speech-to-text service if separate, and the error-tracking system. Each should be named, each should have a BAA in place with the vendor, and the list should be available on request — ideally published.

How long should AI receptionist call data be retained?

Retention depends on the data type. Call audio is typically retained shortest because it is highest-risk and most easily reconstructed from transcripts. Transcripts and call summaries usually live longer because they have ongoing operational value for the practice. The vendor should publish specific retention windows in days, and the practice should be comfortable with both the windows and the deletion path.

What is a reasonable incident communication timeline from a vendor?

Service incidents (system down, calls not answering) should be communicated proactively within an hour or less, ideally via a public status page plus direct notification. Security incidents involving potential PHI exposure trigger HIPAA breach-notification timelines: investigation begins immediately, and notifications to affected practices generally happen within days, not weeks. The vendor should describe both timelines specifically before any contract is signed.

Can a vendor's support team read patient call transcripts?

Sometimes, for debugging or support cases — but only with logged, time-boxed access. The right answer involves a ticketed access request, a specific reason, and an audit trail the practice can review on request. Unlimited or undocumented access to PHI by support staff is a control gap, not a feature.

What happens to patient data if the practice cancels?

The vendor should publish a clear data-return policy. Typically, call logs, transcripts, and any patient-identifying records are exported in a usable format within a defined window after cancellation, then deleted from the vendor's systems on the published retention timeline. The BAA should describe the cancellation data handling — if it does not, push for written clarification before signing.