Voice AI Subprocessors: Which Vendors Sign a BAA

Vendor facts are as of mid-2026 and change often. BAA coverage is scoped to specific plans and endpoints, so confirm current terms with each vendor. This is engineering guidance, not legal advice. Sources are listed at the end.

The pillar on what HIPAA and GDPR actually require of a voice AI makes one point: a voice agent is a stack, and compliance holds only when every layer of the stack is covered. This post is the layer-by-layer companion. It names the vendors that commonly sit in each layer, says which of them sign a Business Associate Agreement or a data processing agreement, and flags the catch that trips up most teams. The catch is that the agreement is almost never for the whole vendor.

First, one definition, because two regimes use two words for the same thing. Under GDPR, a vendor you pass personal data to is a subprocessor, and each one needs a data processing agreement and a place in your records. Under HIPAA, a vendor that touches protected health information is a business associate, and each one needs a signed BAA. Same idea, two names. Below, “signs a BAA” is shorthand for “will enter the agreement its regime requires.”

The layers, and who signs at each one

A production voice agent usually has six layers that touch data. Here is each one, the vendors you are most likely to use, and their status as of mid-2026. Treat this as a starting map to verify, not a replacement for reading each vendor’s current terms.

The telephony carrier. This layer carries the call audio. Twilio is the common choice. It is HIPAA eligible for the products a voice agent uses, such as Programmable Voice and Elastic SIP Trunking, and it signs a BAA, but only on its Security or Enterprise edition (Twilio HIPAA). SignalWire also signs a BAA. The audio is protected data the moment the caller speaks, so the carrier is in scope from the first second of the call.

The speech-to-text engine. This transcribes the caller. Deepgram signs a BAA and can be self-hosted or run on-premise, so the audio never leaves your environment, which helps with residency. AssemblyAI signs a BAA and builds in personal-data redaction and speaker labeling. The major clouds cover their own speech services under their BAA, such as Azure Speech and Google Speech-to-Text. Transcripts are where names, addresses, and case details first appear as text, so this layer matters as much as the carrier.

The language model. This reads the conversation. As of mid-2026 there are four common HIPAA-eligible tracks: OpenAI’s API, Anthropic Claude, AWS Bedrock, and Google Vertex. Both OpenAI and Anthropic sign a BAA through their API platforms, not their consumer apps. Scope matters most here. Anthropic’s BAA covers a defined set of API surfaces, such as the Messages API, and lists others as excluded, so check that the endpoints you call are in scope (Anthropic BAA). Reaching a model through a cloud provider, such as Claude on Bedrock or Vertex, folds it into a cloud BAA you may already hold. Where you can, also turn on zero-retention or no-training options, which are a separate setting from the BAA.

The text-to-speech engine. This speaks the reply. People forget this layer is in the data path, but the text you send it to voice can contain a name or an address, so it is. Azure Neural TTS is covered under Microsoft’s BAA. ElevenLabs signs a BAA on its Enterprise tier and offers a zero-retention mode. Cartesia documents HIPAA and SOC 2. Like the model layer, the voice layer tends to gate its BAA behind an enterprise plan.

The cloud host and database. This is where the app runs and the transcripts, records, and embeddings live. AWS, Azure, and Google Cloud all sign BAAs and publish a list of HIPAA-eligible services, and each lets you pin a region for data residency. A managed Postgres on one of those clouds is covered under that cloud’s BAA. The BAA covers the eligible services, not everything the cloud offers, so confirm each service you use is on the eligible list.

The orchestration platform. This is the voice-agent builder that ties the layers together, if you use one instead of assembling the pieces yourself. Retell offers a self-serve BAA and includes HIPAA in its standard plan. Vapi offers HIPAA as a paid add-on. LiveKit will sign a BAA and, because it is open source, can be self-hosted, which keeps everything inside your own boundary when you need that. The important caveat lives in this layer, and it gets its own section next.

The five catches that break the map

Naming the vendors is the easy part. A subprocessor map usually goes wrong for one of these five reasons. Each one is a question to ask before you sign.

A BAA is gated to a plan or edition, not the whole vendor. Twilio signs only on Security or Enterprise edition. ElevenLabs signs on Enterprise. Vapi charges for the HIPAA tier. The same company that signs for one account will not sign for another, so the account you actually run on has to be the one the agreement covers.

A BAA is gated to specific endpoints, not the whole product. Anthropic’s BAA covers some API surfaces and names others as excluded. A carrier is eligible for some products and not others. Using an out-of-scope endpoint puts protected data somewhere the agreement does not reach. That is the same as having no agreement for that hop.

HIPAA eligible is not HIPAA compliant. A vendor being eligible means it will sign and has a set of approved services. Compliant is a property of how you build. You can be on an eligible vendor and still be non-compliant, because you used a service outside the approved set, skipped the signature, or left retention on.

Bring-your-own-key means you hold the model agreements. On platforms where you plug in your own model, speech, or voice keys, the platform is not your business associate for those layers. You must hold a BAA directly with each model provider. The keys are yours, so the agreements are yours too.

The platform’s BAA does not flow down to the models. This is the big one. An orchestration platform signing a BAA covers the orchestration platform. It does not automatically cover the language model, the speech engine, or the voice engine underneath it, especially under bring-your-own-key. Four of five layers can be covered and the fifth is not. That one uncovered hop breaks the chain, and it is exactly the gap a security reviewer looks for.

Residency changes the shortlist

If your deployment is bound to a region, the list above gets shorter. A vendor that signs a BAA in general may not run in the region your rules require. This is the same problem covered in why your region decides your voice: a managed catalog is not identical in every region. Two moves help. Prefer vendors that can self-host or run on-premise inside your boundary, such as a self-hosted speech engine or an open model on an in-region GPU, so the data never leaves. And when you use a managed service, confirm not just that it signs a BAA but that it runs in the region you need, with the data processed and stored there. A BAA does not help if the vendor processes your data outside the region your rules require.

Build the register before procurement asks

The deliverable that ties this together is a subprocessor register. It is the most useful compliance artifact you can keep for a voice agent. It is a plain table with one row per layer and these columns:

• The layer, from carrier to orchestration.
• The vendor you actually use.
• What data that vendor sees: audio, transcript, extracted fields, or metadata.
• Whether a signed BAA or data processing agreement is on file.
• The specific plan or endpoint that makes that agreement valid.
• The region it runs in.
• The retention setting, including whether zero-retention or no-training is on.

At taritas we keep one of these for every deployment and hand it to the client’s security team before they ask. It doubles as a GDPR record of processing and a HIPAA business-associate inventory. When a reviewer asks “who else touches our data,” the answer is a document, not a meeting. Keeping it current is part of the work, because vendors change plans and you swap components. A register that was true at launch and never updated is worse than none.

Key takeaways

A voice agent hands your data to five or six outside vendors, and each one is a subprocessor under GDPR and a business associate under HIPAA when it touches protected data. As of mid-2026 the serious vendors at every layer will sign the agreement, so getting one is rarely the hard part. The hard part is scope. A BAA is gated to a plan and often to specific endpoints, an eligible vendor is not the same as a compliant build, bring-your-own-key means you hold the model agreements yourself, and an orchestration platform’s BAA does not cover the models beneath it. Residency narrows the list further, which is where self-hosting earns its cost. The way you keep all of this straight is a subprocessor register, updated as you go and ready to hand over on request.

What this means if you are an IT services firm

When a client asks whether your voice agent is compliant, the credible answer is a subprocessor register, not a yes. It shows every vendor in the chain, the agreement on file for each, the plan that makes it valid, and the region it runs in. Most teams cannot produce that document on the day procurement asks, because they treated the BAAs as a formality and never mapped which plan or endpoint they run on. The better habit is to build the register at design time, verify each vendor’s current terms rather than trusting last year’s, and keep it current as the stack changes. That, alongside the architecture in the HIPAA and GDPR guide, is the difference between a voice agent that clears a security review and one that stalls in it. It is the work we do behind IT services firms, under their brand, and the substance of how we work with partners.

Sources

• Twilio, HIPAA eligibility and Business Associate Addendum: https://www.twilio.com/en-us/hipaa
• Anthropic, Business Associate Agreements for commercial customers (covered and excluded API surfaces): https://privacy.claude.com/en/articles/8114513-business-associate-agreements-baa-for-commercial-customers
• For the underlying HIPAA and GDPR requirements and their primary sources, see the companion post: https://taritas.com/blog/hipaa-gdpr-compliant-voice-ai
• Each other vendor named here publishes its own HIPAA or trust page; confirm the current plan and endpoint scope directly with the vendor before you rely on it.