A patient calls a multi-specialty clinic at 8:47 PM. The front desk is closed. An AI voice agent answers, asks why they're calling, and the patient says: "I need to reschedule my Wednesday oncology infusion because my port site is infected and I'm running a fever of 101.4."
That sentence contains diagnosis, treatment, symptoms, and an identifiable condition tied to a specific appointment. It's Protected Health Information. The audio is PHI. The transcript is PHI. The structured fields the agent extracts are PHI. The LLM call that decides what to say next processes PHI. The TTS API that voices the reply receives PHI in the prompt context.
If the clinic's voice vendor doesn't have a Business Associate Agreement covering every link in that chain, the clinic is the one on the hook with the Office for Civil Rights.
This post is a working overview, not legal advice. Statutes change, OCR guidance evolves, and your counsel needs to map this to your specific deployment.
HIPAA applies the moment the audio touches your vendor's infrastructure
HIPAA's Privacy Rule (45 CFR Part 164, Subpart E) and Security Rule (Subpart C) cover PHI created, received, maintained, or transmitted by a Covered Entity or its Business Associates. Covered Entities are healthcare providers, health plans, and clearinghouses. Business Associates are anyone who handles PHI on their behalf.
A voice agent vendor that takes patient calls is a textbook Business Associate. The 2013 Omnibus Rule made this explicit: vendors that "create, receive, maintain, or transmit" PHI for a Covered Entity are Business Associates regardless of whether they read the data. Hosting it counts. Routing it counts. Letting an LLM see it counts.
The BAA is the contract that flows HIPAA obligations from the Covered Entity to the vendor. Without one in place before PHI flows, the Covered Entity has committed an impermissible disclosure. The vendor has too, under 45 CFR § 164.502(e).
The trigger is not "we plan to record calls." The trigger is "patient said something only patients say."
What a real BAA actually requires (four parts, not one)
Most vendor BAAs you'll see in the wild are a one-page acknowledgment that says "we're HIPAA compliant" and a signature block. Real BAAs have four operative sections.
1. Permitted and required uses. The BAA must specify exactly what the Business Associate may do with PHI. Marketing analytics across customers? Not permitted unless the BAA says so. Training a shared model on call transcripts? Not permitted unless the BAA says so, and even then a Covered Entity probably shouldn't sign it.
2. Security safeguards. The Business Associate must implement administrative, physical, and technical safeguards mirroring the Security Rule. This is where most vendor due diligence falls apart, because "we use AWS" is not a safeguard inventory.
3. Breach notification. Under 45 CFR § 164.410, the Business Associate must notify the Covered Entity of any breach without unreasonable delay and no later than 60 days. The BAA should specify the notification path, the forensic detail required, and who pays for breach response.
4. Sub-processor management. Any sub-processor that touches PHI must be bound by a BAA flowing down equivalent obligations. This is the single most-skipped requirement in AI voice deployments.
The Security Rule technical safeguards translate to specific architecture choices
The Security Rule's technical safeguards live at 45 CFR § 164.312. Four standards, each with implementation specifications. For an AI voice agent, they look like this:
Access control (§ 164.312(a)). Unique user identification per support engineer who can pull a recording. Automatic logoff in admin consoles. Encryption-at-rest as an addressable specification (which OCR has consistently treated as required in practice). If your vendor has a "support shared login" for their on-call team, that fails this standard.
Audit controls (§ 164.312(b)). The system must record and examine activity in systems containing PHI. Every access to a recording, every transcript export, every admin who pulled a call to debug a routing bug. Logs need to be tamper-evident and retained for the same six years OCR can reach back.
Integrity (§ 164.312(c)). PHI must not be improperly altered or destroyed. For voice, this means immutable storage of the original recording and any derivative transcripts, plus logging on any redaction or correction.
Transmission security (§ 164.312(e)). Encryption in transit. TLS 1.2+ on every API call between the voice agent and the LLM, the STT, the TTS, the EHR connector, the SMS provider for confirmations. SRTP on the carrier leg if recording is in scope.
These are not aspirational. OCR has cited Business Associates for missing audit logs and for unencrypted backups in the same breath as the breach itself.
Sub-processors are where AI voice vendors quietly fail
A modern AI voice agent is a pipeline of vendor APIs. Speech-to-text (Whisper, Deepgram, AssemblyAI, Google), large language model (GPT-4, Claude, and other frontier providers), text-to-speech (ElevenLabs, Cartesia, OpenAI), plus the orchestration layer, the telephony provider, the storage backend, and any analytics or QA tooling.
Each one of those vendors processes PHI. Each one is a sub-processor under your BAA. Each one needs a flow-down BAA from the voice agent to that sub-processor.
The catch: most consumer-tier APIs explicitly do not sign BAAs. OpenAI's standard API offers a BAA only on their Enterprise tier or via a specific HIPAA addendum. Google's LLM offerings require enterprise Vertex AI deployment for HIPAA coverage; the public consumer APIs are not BAA-eligible. Deepgram offers a BAA. Whisper via the public OpenAI API does not unless covered by the OpenAI HIPAA addendum. ElevenLabs offers a HIPAA-eligible plan as of 2025; the standard tier does not include a BAA. AssemblyAI offers BAAs on enterprise contracts.
When you ask a voice agent vendor "are you HIPAA compliant," the answer you actually need is the sub-processor list and the BAA status of each one. A vendor that hesitates on this question, or that treats their model provider as a trade secret, has not built for healthcare.
The clinic ends up holding the bag because OCR's enforcement actions reach the Covered Entity first. The vendor gets a ride-along under the 2013 Omnibus Rule, but the clinic is the one whose name appears on the resolution agreement.
Recordings are PHI even when they sound like scheduling calls
HIPAA itself does not mandate recording disclosure on patient calls. State two-party consent laws do, and we covered that separately at /blog/state-call-recording-laws-ai-voice-agents.
What HIPAA does require: any recording that contains PHI is itself PHI, and storage, retention, retrieval, and deletion are all in scope. A "schedule a routine cleaning" call from a patient who then mentions they're pregnant just became a recording with PHI in it. The retention policy that applies to your medical records arguably extends to that audio file.
Specific implications:
- Recordings stored by the voice vendor must be in BAA-covered storage with documented encryption-at-rest.
- Retention windows should match the Covered Entity's record-retention policy or be configurable per-customer.
- Patient access requests under the Privacy Rule (§ 164.524) can reach the audio. Your vendor needs an export path.
- Deletion requests, where applicable, need to propagate through every sub-processor that may have cached or logged the audio.
A voice vendor whose retention is "we keep everything forever for QA" is incompatible with a healthcare deployment without contract language overriding it.
OCR enforcement in 2024-2025 has been moving toward smaller actors
The 2024-2025 enforcement cycle has shown OCR willing to pursue smaller Covered Entities and Business Associates, not just the headline million-record breaches. The Risk Analysis Initiative, announced in late 2024, specifically targets organizations that have not conducted documented risk analyses under § 164.308(a)(1)(ii)(A).
Civil penalty tiers (45 CFR § 160.404) as of the 2025 inflation adjustments:
- Tier 1, lack of knowledge: roughly $137 to $68,928 per violation.
- Tier 2, reasonable cause: roughly $1,379 to $68,928 per violation.
- Tier 3, willful neglect (corrected): roughly $13,785 to $68,928 per violation.
- Tier 4, willful neglect (uncorrected): roughly $68,928 to $2,067,813 per violation.
Annual cap per identical violation type: roughly $2.07 million in the most recent adjustment. "Per violation" can mean per record, per day, or per category depending on how OCR frames it.
The pattern in recent settlements: OCR is calling out missing risk analyses, missing BAAs with sub-processors, and inadequate audit logging as standalone findings, separate from any breach. You do not need a breach to be cited.
Architecture concerns specific to HIPAA voice deployments
Beyond the BAA paperwork, the technical choices that matter:
Training data isolation. Call audio and transcripts must not flow into shared model training. The vendor's BAA should explicitly state PHI is not used to train models, fine-tune publicly-shared adapters, or improve services for other customers. "Aggregated and de-identified analytics" is a phrase that needs definition: HIPAA's Safe Harbor de-identification (§ 164.514(b)) is a specific 18-identifier removal standard, not a vibe.
Multi-tenant isolation. A voice vendor's database design needs to prevent cross-tenant data leakage even under bug conditions. Row-level security, per-tenant encryption keys where feasible, and tested isolation are reasonable asks.
Vendor employee access. Who at the vendor can listen to recordings? Under what circumstances? Logged how? "Anyone on the engineering team for debugging" is not a HIPAA-acceptable answer. "Named on-call engineers, with access logged and reviewed monthly, only on customer-initiated support tickets" is closer.
EHR and downstream system integration. When the voice agent writes back to Athenahealth, Epic, eClinicalWorks, or a custom intake system, that connector is in scope. Authentication, scope-limiting, and logging on the integration matter as much as the voice pipeline itself.
Five HIPAA-specific questions before you sign
When evaluating an AI voice vendor for a healthcare deployment, the questions that actually separate vendors:
-
List every sub-processor that touches PHI in a typical call, and provide the BAA or HIPAA addendum status of each one. A vendor that cannot produce this list in writing within a week is not ready for healthcare.
-
Where is the original audio stored, with what encryption, for how long, and who at your company can retrieve it? Map this to physical storage region too if you operate in a state with health data residency rules.
-
Confirm in the BAA that PHI is never used to train models, fine-tune adapters, or improve service quality for other customers. Get the language in writing, not in a sales call.
-
Provide your most recent risk analysis under § 164.308(a)(1)(ii)(A) and your incident response plan. Vendors who treat this as confidential are signaling they do not have one ready.
-
Walk through the breach notification path: detection, forensic capture, customer notification SLA, and who at your company holds the pen. A 60-day statutory window with no operational plan is just a deadline waiting to be missed.
A vendor who answers all five clearly is not necessarily HIPAA-ready, but a vendor who can't is definitely not.
The hard part isn't the BAA, it's the architecture you signed it on top of
Most AI voice vendors will sign a BAA. Most BAAs are template language pulled from HHS sample text. The signature is the easy part. What the signature commits the vendor to is a security posture, a sub-processor stack, an access control regime, and a breach response capability that takes years to build and is difficult to retrofit onto a system designed for low-stakes use cases.
The vendors who will be standing in healthcare in three years are the ones that designed for HIPAA before they had a single healthcare customer. The vendors who treat HIPAA as a contract addendum will discover, the way several have already, that an OCR investigation reads architecture, not paperwork.
If you're a clinic operator or healthcare CIO doing this evaluation, the parallel reading list:
- Attorney-client privilege and AI voice intake covers the same architectural questions in a different regulated vertical.
- State call recording laws and AI voice agents covers the disclosure piece HIPAA leaves to states.
- AI voice agents: 30-day failures covers the production realities that show up after the contract is signed.
If you want to walk through how NeuraVoice handles BAAs, sub-processor management, and the technical safeguards above for a healthcare pilot, book a call, start free trial, or see the pricing page. Bring your security questionnaire. We've answered it before.