What HIPAA and GDPR Actually Require of a Voice AI

All names, numbers, and identifiers in this post are anonymized. The patterns are real. This is engineering guidance, not legal advice: confirm your obligations with your own counsel and compliance team. Sources are listed at the end.

Someone asks, “is your voice AI HIPAA compliant?” The honest answer is a question back: which part of it? A voice agent is not one product. It is a chain of separate systems, and protected data passes through every link. Compliant is not a label you stick on the chain. It either holds at every link or it does not hold at all.

This post is the long version of that answer. It covers what HIPAA and GDPR actually require of a voice agent, where the requirements bite in production, and a checklist you can hand to a vendor or use on your own build. It is written from building these systems for healthcare and public-sector clients. The vendor-by-vendor detail, including which providers sign a BAA, is in the companion post on which voice AI vendors sign a BAA.

Compliance is a property of the whole stack

A voice AI system that touches patient or personal data has at least five layers:

1. A telephony carrier that routes the call.
2. A speech-to-text engine that transcribes the caller.
3. A language model that reads the conversation and your knowledge base.
4. A text-to-speech engine that speaks the reply.
5. Your own backend and database that hold the transcript, the extracted data, and the audit log.

Protected data flows through all five. The audio reaches the carrier and the speech-to-text engine. The transcript reaches the language model. The reply text, which can contain a name or a case detail, reaches the text-to-speech engine. The record lands in your database.

A single vendor can make its own layer compliant. No vendor can make the whole chain compliant, because no vendor owns the whole chain. So when a platform says “we are HIPAA compliant,” that is a claim about one link. The whole system is compliant only when every link is covered and the data stays inside the boundary your rules require. That is the frame for everything below.

What HIPAA actually requires

HIPAA applies when your agent handles protected health information, which is health data tied to a person. For a voice agent, the requirements are concrete.

A signed Business Associate Agreement for every layer that touches the data. This is the one buyers underestimate. If your agent sends the conversation to a hosted language model, that provider is a business associate and needs a BAA. So does the speech-to-text engine, the text-to-speech engine, and the telephony carrier. On bring-your-own-key platforms, holding those agreements is usually your job, not the platform’s. The common failure is a stack where four of five layers have a BAA and the fifth does not. That one gap breaks the chain.

Encryption in transit and at rest. Today HIPAA treats encryption as “addressable,” which means you must do it or document why not. Treat it as required. Audio and transcripts move between layers over TLS. Everything stored, the database, the recordings, the embeddings, is encrypted at rest with keys you can account for.

Role-based access control. Decide who on your team, and which service, can read a transcript or an extracted field. The answer should be as few as possible, enforced in code, not on trust.

An audit trail, kept for six years. Log every call and every action the agent took, and make it queryable. In a real security review, the audit trail is the artifact the reviewer reads. It is how you prove what the system did.

Documented retention and deletion, and breach notification. Write down how long you keep data, enforce it in code rather than a policy slide, and have a defined process for reporting a leak.

The 2026 update: build to the stricter bar now

There is a change in flight. In January 2025, HHS published a Notice of Proposed Rulemaking to update the HIPAA Security Rule for the first time in over two decades. It would make several currently addressable safeguards mandatory: AES-256 encryption of health data at rest and in transit, multi-factor authentication for systems that access it, vulnerability scans at least every six months, penetration testing at least every year, and defined recovery timelines such as 72-hour data restoration. The HHS fact sheet lists the full set of proposed changes.

As of mid-2026, this is still a proposal. The final rule has not been issued, and it faces pushback over cost. So it is not law yet, and it may change.

The takeaway does not depend on the timeline. Encryption, multi-factor authentication, tested backups, and a real audit trail are good engineering whether or not a rule forces them. Build to the proposed bar now, and the final rule becomes paperwork instead of a rebuild.

What GDPR actually requires, and the part people miss

GDPR applies when your agent processes the personal data of people in the EU or UK. Health data spoken during a call is special-category data under Article 9, which carries the strictest rules. Most teams know that part. Here is the part they miss.

Voice itself can become special-category biometric data. Under Article 9, voice is biometric data when it is processed to uniquely identify a person: a voiceprint used to verify a caller, or speaker recognition that links one call to another. The moment you do that, you need explicit opt-in consent and a Data Protection Impact Assessment, and the fine tier for getting it wrong is the higher one.

The design decision follows directly. If you do not need to identify callers by their voice, do not build voiceprinting. A voice agent that transcribes and responds, without storing a voice template, does not trigger the Article 9 biometric rule at all. You still handle any health content as special-category data, but you have not added a second, avoidable category of risk.

The rest of GDPR maps onto the same stack idea as HIPAA. Every layer is a processor that needs a data processing agreement, the GDPR version of a BAA. You need a lawful basis for processing, a subprocessor map that names every layer, and data residency you can prove. Data subject rights are specific: a person can ask what you hold, ask you to correct it, and ask you to erase it, and your system has to be able to answer.

Where compliance actually breaks in production

The requirements above are the theory. Here is where they bite, from our own deployments. Each has a longer write-up on this blog. The point is that these are all compliance decisions that first show up as ordinary engineering choices.

Data residency decides which models you can use. Residency is not only a storage rule. A managed provider’s model catalog is not the same in every region, so the voice in the demo may not exist in the region your rules require. On one deployment bound to in-country residency, the managed voice we wanted was not available in-region. We self-hosted an open model on an in-region GPU to keep both residency and quality, then moved back once the managed voice reached that region. Note that the text-to-speech engine is inside the data path, because the text you send it to speak can contain a name or an address. Residency covers the whole pipeline, not just the database. The full account is in why your region decides your voice.

Health data is protected even with no name attached. On a healthcare launch review, an endpoint returned a full assessment object, including pain locations, severity scores, and current medications, to an unauthenticated caller. There was no name in it. It was still protected data, because the session identifier also reached recordings and billing email, which makes the record identifiable. The fix was to trim the anonymous view to the minimum necessary and gate everything else. The lesson: “no name” is not the same as “not identifiable.” The full review is in can a voice AI pass a healthcare security review.

Every callback the agent makes is an authentication surface. The same review found an endpoint the agent wrote to that never checked the shared secret it was sent. Anyone who learned a session ID could inject messages into a patient transcript. The fix was to verify the secret on every agent callback, using a constant-time comparison so the secret cannot be recovered by timing. If your agent calls back into your systems, each of those routes is a door, and each door needs a lock.

The agent can over-disclose from its own knowledge base. A knowledge base written for the web is full of instructions and details that are wrong or unsafe to read aloud on a call. The durable fix is structural: strip the sensitive item from the retrieved text before the model sees it, so it cannot repeat what it cannot read, while keeping the original on a separate path so your audit and evaluation still see the truth. The mechanics are in redacting a number the caller is already on.

None of these arrived as a “compliance” ticket. They arrived as an endpoint, a model choice, a retrieved chunk. Compliance for voice AI lives in those decisions, which is why it has to be designed in, not reviewed on at the end.

The procurement checklist

Whether you are buying a voice AI or building one, these are the questions that separate a system built for a review from one that will fail it. Each maps to a requirement above.

The stack and its paperwork. What are the five layers of this system, and is there a signed BAA (HIPAA) or data processing agreement (GDPR) for every layer that touches the data? Who holds those agreements, us or the platform? Show me the subprocessor map. We cover this layer by layer, including which common vendors sign a BAA and the plan-level catches, in which voice AI vendors sign a BAA.

Residency. Where do the audio, the transcripts, and the embeddings live, and where are they processed? Does every model in the pipeline, including text-to-speech, run in my required region? What is the plan when a model I need is not available in-region?

Encryption and access. Is data encrypted in transit and at rest, with accountable keys? Who and what can read a transcript or an extracted field, and is that enforced in code?

Audit and retention. Can I see every call and every action the agent took, and can I export that for a review? How long is data kept, and where is that retention enforced, in code or in a document?

Identity and biometrics. Does the system store a voiceprint or identify callers by their voice? If yes, where is the explicit consent and the DPIA? If it is not needed, why is it there?

Breach and exit. What is the breach notification process? If we part ways, do we own the data, the audit trail, and the accounts the system runs in?

A vendor that answers these with documents, architecture diagrams, and a subprocessor map is built for a security review. A vendor that answers with adjectives like “enterprise-grade” or “fully compliant” has not shown you the chain.

Key takeaways

“HIPAA compliant” and “GDPR compliant” are not product features. They are properties of a whole stack, and they are decided when the system is designed. A voice agent touches protected data at five layers, and each layer needs its own agreement, its own place inside the residency boundary, and its own encryption and access rules. Under GDPR, storing a voiceprint pulls you into the strictest tier, so do not build voiceprinting unless you need it. The 2026 HIPAA update is not final, but its direction, mandatory encryption and MFA, is where you should already be. In practice, compliance breaks in an endpoint, a model choice, or a retrieved chunk, not in a policy document, which is why the only reliable way to pass a security review is to design for it on day one.

What this means if you are an IT services firm

If a client asks you for a voice agent in healthcare, finance, or the public sector, the build is the easy half. The half that wins or loses the contract is the security review, and that review is not testing whether the demo works. It is testing whether every layer of the stack is covered, whether the data stays where the client’s regulator requires, and whether you can show an audit trail on demand. Most teams treat that as a step at the end and find a gap the day procurement asks. The better approach is to design residency, retention, audit, and per-layer agreements in from the start, and to keep the evidence, the diagrams, the subprocessor map, the test results, ready before anyone asks. That is the work we do behind IT services firms, under their brand, and it is the substance of how we work with partners.

Sources

• HHS, HIPAA Security Rule Notice of Proposed Rulemaking (fact sheet): https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html
• Federal Register, “HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information” (published January 6, 2025): https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information
• GDPR Article 9, Processing of special categories of personal data (official text): https://gdpr-info.eu/art-9-gdpr/