HIPAA Compliance for AI Voice Agents in Healthcare

HIPAA compliance is the first gate for any voice AI deployment in US healthcare. Get it wrong and you're exposed to federal penalties, state attorney-general actions, and class-action litigation. Get it right and it becomes boring — signed BAAs, audited vendors, documented policies, and a deployment that's defensible. The good news in 2026: HIPAA-compliant voice AI is a mature category. The major vendors all offer BAAs, their sub-processors are compliant, and the deployment playbooks are well-understood.

This piece walks through what HIPAA actually requires for a voice AI deployment, how to evaluate vendors, and the operational practices that keep you compliant over time.

TL;DR

• Voice AI handling PHI is a Business Associate; requires a Business Associate Agreement (BAA).
• All sub-processors in the voice pipeline (LLM, STT, TTS, telephony) need to be BAA-covered.
• Minimum-necessary principle — limit PHI exposure to what's needed.
• Audit logs, access controls, encryption (in transit and at rest) are non-negotiable.
• Retention and deletion policies need to be explicit and enforceable.

What counts as PHI in a voice agent

Protected Health Information, per HIPAA, is health information combined with any of 18 identifiers. For a voice agent, commonly triggered by:

• Name + appointment time (creates a medical-care record).
• Name + medication (treatment information).
• Name + insurance member ID (care-related financial info).
• Name + condition (obvious PHI).
• Phone number + any health context.
• Voice recordings where the caller self-identifies.
• Transcripts of any of the above.

If the agent handles any of these — which it will in essentially any healthcare use case — the whole pipeline is in HIPAA scope.

The BAA requirement

A covered entity (you, the clinic) working with a business associate (the voice AI vendor) needs a Business Associate Agreement in place before PHI flows.

What a BAA does:

• Contractually obligates the business associate to comply with HIPAA.
• Specifies permitted uses and disclosures of PHI.
• Defines breach notification obligations.
• Sets retention and destruction expectations.
• Establishes audit rights.

Without a signed BAA, you've breached HIPAA at the moment PHI flows. This is non-negotiable.

The sub-processor chain

Voice AI pipelines have multiple parties touching data. All of them need BAAs.

A typical stack:

• Telephony provider (Twilio, Vonage, etc.).
• STT vendor (Deepgram, AssemblyAI, the vendor's own).
• LLM provider (OpenAI, Anthropic, Google, open-source self-hosted).
• TTS vendor (Simba, Cartesia, Deepgram Aura, etc.).
• Voice agent platform (Vapi, Retell, SIMBA, etc.).
• CRM / EMR integration middleware (NexHealth, Redox, direct).

Each of these is a sub-processor. BAAs cascade — the primary vendor needs BAAs with all sub-processors. Ask for the sub-processor list in writing.

Minimum necessary

HIPAA's minimum-necessary principle: use and disclose only the PHI needed for the purpose.

Practical implications:

• Log sparingly. Don't log entire call transcripts if you only need metadata.
• Access controls. Your staff (and the vendor's) should only see PHI they need.
• Prompt engineering. Don't inject more patient context than the agent needs for the current turn.
• Retention. Keep PHI only as long as necessary for the purpose.

This is an ongoing discipline, not a one-time setup.

For the operational patterns, see how to handle personally identifiable information in voice agents.

Encryption — in transit and at rest

Baseline requirements:

• TLS 1.2+ for all transport, including API calls between pipeline components.
• AES-256 (or equivalent) for data at rest.
• Key management that's clear — where are keys stored, who can access them?
• End-to-end encryption is ideal but not always practical; TLS hop-to-hop is acceptable if each hop is BAA-covered.

Any vendor who can't answer these concretely is not ready for healthcare deployment.

Audit logs

HIPAA requires logs of:

• Who accessed PHI.
• When they accessed it.
• What they accessed.
• Why (if role-based access, the role serves as the why).

For voice AI:

• Every call has a log entry.
• Every transcript access is logged.
• Every staff review (QA, prompt tuning) is logged.
• Every admin action is logged.

Logs themselves should be immutable and retained per your retention policy (typically 6 years).

Access controls

Role-based access to PHI:

• Vendor staff. Which vendor employees can access your data? Typically limited to support/engineering with audit oversight.
• Your staff. Which of your people can review calls, transcripts, analytics?
• Sub-processor staff. Varies by vendor; should be documented.

Default to least privilege. Review access quarterly.

Retention policies

Define:

• Call audio: typical range 30–90 days. Some use cases require longer.
• Transcripts: 1–6 years depending on use.
• Metadata / analytics: may be longer, especially if de-identified.
• Training data: if the vendor retains any for model improvement, document and understand.

Retention should be documented policy, not vendor default. Know what your policy is and enforce it.

De-identification

PHI is strictly controlled; de-identified data is much freer. Vendors sometimes de-identify data for analytics or improvement.

HIPAA has two paths to de-identification:

• Safe Harbor — removing 18 specific identifiers (names, dates, addresses, etc.).
• Expert Determination — a qualified expert certifies the risk of re-identification is minimal.

If your vendor uses any of your call data for product improvement, make sure it's genuinely de-identified. "Anonymized" without specifying which method is a yellow flag.

Incident response

When something goes wrong:

• Vendor notifies you of any potential breach within the BAA-defined window (typically 60 days max; most require 24–72 hours for significant incidents).
• You notify patients if the breach triggers reporting requirements.
• You notify HHS for breaches affecting 500+ individuals.
• Media notification may be required for large breaches.

Know your vendor's incident history. A clean 5-year record is a strong signal.

State-level layers

HIPAA is federal; states layer additional requirements:

• California (CMIA) — more stringent in some areas.
• New York (SHIELD Act) — broader cybersecurity requirements.
• Texas (HB 300) — specific disclosures required.
• Mass., Ill., others — various breach-notification and consent rules.

Your compliance posture needs to cover the union of applicable state laws, not just HIPAA.

42 CFR Part 2 for SUD programs

If your deployment touches substance use disorder (SUD) records, 42 CFR Part 2 applies in addition to HIPAA. It's stricter — limits disclosures more tightly. Few voice AI vendors are explicitly Part 2 compliant; verify before deployment in any SUD context.

Vendor evaluation checklist

When evaluating a voice AI vendor for healthcare:

• ✅ Signed BAA available.
• ✅ Full sub-processor list, all BAA-covered.
• ✅ Encryption in transit and at rest documented.
• ✅ Access controls and audit logs.
• ✅ Retention policies clear and configurable.
• ✅ De-identification approach documented (if they use your data).
• ✅ Incident response process with defined timelines.
• ✅ SOC 2 Type II or equivalent audit.
• ✅ HITRUST certification (for larger deployments).

Any vague answer here is a deal-breaker.

Deployment checklist

Before go-live:

• ✅ BAA signed and on file.
• ✅ Sub-processor BAAs verified.
• ✅ Retention policies agreed and configured.
• ✅ Access controls set for your staff.
• ✅ Audit logs accessible to your compliance team.
• ✅ Incident response process tested.
• ✅ Staff training on handling PHI via the voice AI.
• ✅ Privacy notice updated if required.
• ✅ Risk assessment completed per your security program.

Document everything. In an audit, the documentation matters as much as the actual practices.

Related reading

• Voice AI in Healthcare: A 2026 Field Guide
• How Healthcare Providers Use Voice Agents for Intake
• Compliance and Accessibility for Government Voice AI
• Voice AI for Government Agencies
• Voice Agents for Loan Servicing and Collections

FAQ

Can we use consumer-grade voice AI (ChatGPT voice, etc.) for healthcare? No. Consumer offerings don't offer BAAs. You need an enterprise or purpose-built healthcare tier.

What about call recordings for quality purposes? Fine, with appropriate controls. Document why you record, who accesses them, and how long you keep them.

Do we need patient consent to use voice AI? HIPAA doesn't specifically require it for treatment/operations uses. Some states do (AI disclosure). Best practice: disclose in the call regardless.

What if the vendor has a breach? BAA defines the notification and response process. Have a playbook before you need one.

Can we share call data with a research partner? Only if specifically authorized by BAA and patient consent (as applicable) and de-identified appropriately.