Voice AI compliance: what HIPAA actually requires (and doesn't)
A field guide to the voice AI compliance questions we hear most often from healthcare CIOs — and the misconceptions to leave behind.
TLDR
A field guide to the voice AI compliance questions we hear most often from healthcare CIOs — and the misconceptions to leave behind.
- A field guide to the voice AI compliance questions we hear most often from healthcare CIOs — and the misconceptions to leave behind.
The misconception that causes the most problems
The most common misconception we encounter when healthcare organisations evaluate voice AI is this: "We can't use voice AI because of HIPAA."
HIPAA does not prohibit voice AI. It establishes requirements for safeguarding protected health information. A voice AI system that meets those requirements is HIPAA-compliant. The question is not whether to use voice AI — the question is how to build it so it satisfies the administrative, physical, and technical safeguard requirements.
Here is what HIPAA actually requires for a voice AI deployment, and what it doesn't.
What counts as PHI in a voice context
Any information that identifies or could identify a patient and relates to their health condition, treatment, or payment for treatment is PHI. In a voice AI context: audio recordings of patient conversations are PHI if the conversation contains health information. Transcriptions are PHI. Conversation metadata — caller ID, timestamps — can constitute PHI in combination with other identifying information.
A voice agent that collects appointment dates, symptoms, insurance information, or treatment status is handling PHI from the moment the patient speaks.
The technical safeguard requirements
Encryption in transit and at rest. All audio data, transcription data, and conversation logs must be encrypted in transit (TLS 1.2 minimum) and at rest (AES-256). This applies to every leg of the pipeline: phone network to SIP provider, SIP to STT service, STT to LLM, LLM to TTS, and any storage layer.
Access controls. Systems that store or process PHI must implement role-based access controls. Logs and recordings should be accessible only to users with a legitimate operational need, with access logged and auditable.
Audit logging. Every access to PHI — including system-generated accesses during automated processing — must be logged with sufficient detail to reconstruct who or what accessed what data and when. This is often the most operationally demanding requirement and the one most commonly under-implemented in initial deployments.
Data retention and disposal. PHI may only be retained for as long as operationally necessary. Conversation recordings and transcriptions that are no longer needed must be deleted via certified disposal methods. Define retention periods before go-live, not after.
Business associate agreements
Any vendor that processes PHI on your behalf is a business associate and must sign a Business Associate Agreement before they can legally handle that data. This includes your telephony provider, your STT provider, your LLM provider, and any logging or analytics service that receives conversation data.
OpenAI, Anthropic, Google Cloud, AWS, Azure, and Twilio all offer BAA coverage under enterprise plans. Deepgram offers BAA coverage. Many smaller AI services do not. If a vendor in your voice AI stack cannot provide a BAA, they cannot receive PHI. Your architecture must route around them.
This requirement eliminates a significant portion of the plug-and-play voice AI tooling not built for regulated industries. Plan your vendor selection accordingly before you build.
What HIPAA does not require
HIPAA does not require that AI systems be human-reviewed before responding. An automated voice agent can make clinical appointment scheduling decisions without a human in the loop as long as the system operates within its authorised scope and the organisation has validated its accuracy.
HIPAA does not prohibit cloud infrastructure. Many organisations have incorrectly concluded that HIPAA requires on-premise deployment. It does not. AWS, GCP, and Azure all offer HIPAA-eligible service configurations.
HIPAA does not require that patients consent to AI specifically. Existing Notice of Privacy Practices disclosures, when properly updated to describe AI-based processing, are generally sufficient. Consult legal counsel on your specific disclosure language.
The implementation sequence we recommend
Map your PHI surface first. Before writing a line of code, document exactly what PHI your voice system will collect, process, and store. This is the foundation of your compliance design.
Validate your BAA chain before building. Confirm BAA coverage for every vendor in your stack before you build on them. Discovering a BAA gap after you've built is expensive.
Design audit logging from day one. Audit logging is the most underestimated requirement. It needs to be in the architecture from the start, not bolted on later.
Implement PHI redaction in transcripts. Before conversation transcripts reach any logging or analytics layer, run them through a redaction pipeline that strips PHI that isn't operationally necessary. This reduces your PHI surface area and your risk exposure.
Penetration test before go-live. Healthcare organisations subject to HIPAA should conduct a penetration test and risk analysis before deploying any new system that handles PHI. Document the results and the remediation actions.
HIPAA compliance for voice AI is achievable. The organisations that do it well treat compliance as an architectural requirement — not a legal review that happens after the system is already built.