How to Choose a Text-to-Speech API: An Enterprise Buyer’s Guide (2026)

Last updated: August 2026

Most “how to choose a text-to-speech API” advice starts with voice quality. For an individual creator, that’s the right place to start. For an enterprise buyer, it’s usually the wrong place to start, because compliance and contractual terms eliminate vendors from the running before anyone listens to a sample. A vendor with the most natural-sounding voice in the world is not a candidate if it can’t sign a Business Associate Agreement and you’re processing patient data, or if it has no on-premise option and your security team has a hard no on sending regulated audio to a third-party cloud. None of that shows up in a side-by-side voice quality comparison, which is exactly why it needs to be checked first, not discovered after the technical evaluation is already finished.

Why is “which one sounds best” the wrong first question?

Voice quality is real, but it’s a tiebreaker, not a filter. The actual filtering questions, the ones that remove vendors from consideration entirely, are about what happens to your data, what you’re contractually owed if the service goes down, and what it costs you if you need to leave. A team that tests five vendors on voice quality first and only checks compliance at the contract stage routinely discovers their preferred vendor is disqualified, after the technical evaluation is already done. Reverse the order: filter on the five criteria below first, then let voice quality and pricing decide among whatever survives.

A 5-part scorecard you can apply to any vendor

This works the same way whether you’re evaluating the five providers in our TTS API comparison or a vendor that doesn’t exist yet. Score each vendor 0-2 on each criterion (0 = fails, 1 = partial/conditional, 2 = fully meets) before you look at a single pricing page.

• Compliance certifications. Does the vendor hold SOC 2 Type II (independently audited, not just self-attested), and can they sign a Business Associate Agreement if you handle health data under HIPAA? Ask specifically about the text-to-speech sub-service, not just “the platform” (more on why below).
• SLA and uptime guarantees. Is there a contractual uptime number (99.9%, 99.99%) with defined remedies (service credits) if they miss it, or just a marketing claim with no contractual backing? A number with no remedy attached isn’t a guarantee.
• Vendor lock-in and portability. Can you export your data and any custom-trained voice models if you leave? Is there an on-premise or VPC deployment option if a pure-cloud API is a non-starter for your security posture? Are you locked to that vendor’s specific model, or can you route elsewhere without a full rebuild?
• Security practices. Encryption in transit and at rest is table stakes now, ask instead about audit logging (can you see who accessed what, when), data retention controls, and whether customer data is used for model training by default (it should be opt-in, not opt-out).
• Support tier and escalation path. Is there a named technical contact and a defined response-time commitment for production incidents, or does every support ticket go into the same queue as free-tier users?

Does signing a BAA actually make you HIPAA compliant?

No, and this is the single most common misunderstanding in enterprise procurement for AI services. A Business Associate Agreement is a legal contract that establishes the vendor’s responsibilities as a business associate handling protected health information on your behalf. It does not automatically make your specific implementation compliant. Every major cloud provider operates on a shared responsibility model: the vendor secures the underlying infrastructure and signs the BAA, but you’re still responsible for how you configure the service, encryption enabled correctly, access properly controlled, audit logs actually retained. A signed BAA with an unconfigured service is not a compliant system.

There’s a second, narrower trap specific to voice AI: a general BAA with a cloud provider does not automatically extend to every sub-service under that provider’s umbrella. Microsoft’s own compliance documentation flags this directly for voice-related services, some voice and speech capabilities require separate approval or aren’t covered under a standard BAA even when the parent platform is. The practical takeaway: don’t assume “we have a BAA with Microsoft/Google/Amazon” settles the question. Ask the vendor to confirm, in writing, that the specific text-to-speech service you intend to use is explicitly covered.

Where do the major providers actually stand on compliance today?

This is a compliance snapshot only, for pricing and latency, see our full TTS API comparison. Verify current status directly with each vendor before relying on any of this for a regulated deployment.

• Amazon Polly: Explicitly confirmed HIPAA-eligible by AWS, meaning it can be used to process protected health information once a BAA is in place and the service is properly configured (encryption, access controls, audit logging). AWS publishes an authoritative list of HIPAA-eligible services separately from general platform compliance, worth checking directly rather than assuming.
• Azure AI Speech: Microsoft’s Azure platform broadly supports HIPAA compliance through a BAA available to Enterprise Agreement and equivalent customers, but voice-specific services have been flagged in Microsoft’s own guidance as sometimes requiring separate approval or falling outside standard BAA coverage. Confirm explicitly that Speech (not just Azure generally) is covered before committing.
• Google Cloud Text-to-Speech: Google Cloud’s BAA covers its infrastructure broadly, and Google Cloud carries SOC 2 and ISO 27001 attestations at the platform level. Confirm with your account team that the specific Text-to-Speech API is named on your BAA’s covered-services list, rather than assuming platform-level coverage extends automatically.
• OpenAI TTS: Enterprise-tier OpenAI customers can access SOC 2 Type II documentation and BAA availability, but this is tied to OpenAI’s enterprise agreements specifically, not the consumer or standard developer API tier. If your team is calling the standard TTS endpoint without an enterprise agreement, don’t assume the same compliance coverage applies.

What about GDPR and data residency?

HIPAA and BAAs cover US healthcare data specifically, but they’re not the only compliance question that eliminates vendors before pricing matters. If you’re processing EU user data, whether that’s a voice sample being converted to speech or transcript text being synthesized, GDPR imposes its own requirements around where that data is processed and stored, separate from whatever HIPAA status a vendor has for US healthcare workloads. A vendor can be fully HIPAA-eligible and still be a poor fit for a GDPR-governed deployment if it can’t guarantee EU-only data processing.

The practical question to ask each vendor is narrower than “are you GDPR compliant,” which every vendor will answer yes to in some generic sense. Ask instead: can you guarantee that audio input and generated output for this specific service are processed and stored exclusively within EU regions, with no fallback routing to US or other non-EU infrastructure during outages or load balancing? Several major cloud providers offer EU-specific regions and data residency commitments for their broader platforms, but the same caveat that applies to HIPAA BAAs applies here: platform-level data residency commitments don’t automatically extend to every individual API or sub-service without being explicitly confirmed. Get the residency guarantee in writing, scoped to the specific text-to-speech endpoint you’re using, not the vendor’s data residency page for their platform in general.

How should you actually run a vendor evaluation?

The scorecard above tells you what to check. Here’s a practical process for checking it without turning procurement into a six-month project:

• Start with a written questionnaire, not a sales call. Send each vendor the same five questions from the scorecard above in writing, and require written answers. A sales engineer’s verbal “yes, we support that” on a call is not something you can hold a vendor to later; a written response referencing specific documentation is.
• Involve security and legal before the technical evaluation, not after. The team most likely to discover a disqualifying compliance gap is rarely the engineering team running the voice-quality bake-off. Loop in whoever owns your compliance posture at the questionnaire stage, not after your engineers have already built a proof of concept against a vendor that turns out to be disqualified.
• Run a time-boxed pilot with your actual data, not vendor demos. A two-to-four week pilot using your real content types (not the vendor’s curated demo script) surfaces quality and integration issues a sales demo won’t. This is also when to test the vendor’s actual support responsiveness, file a real support ticket during the pilot and see how it’s handled, not just what the SLA document promises.
• Get the compliance answers in writing before signing, not as a follow-up after. A vendor that’s slow or evasive about confirming BAA coverage for the specific service, in writing, during procurement is unlikely to become more forthcoming after you’ve signed and are dependent on them.

What does switching providers actually cost later?

Vendor lock-in is easy to underweight during initial procurement because the cost shows up later, after you’ve already built against one vendor’s specific API shape, voice IDs, and SSML dialect. Migration cost estimates for switching a production speech API integration commonly run to three months of engineering time at minimum, according to infrastructure vendor Telnyx, covering re-testing voice quality across your actual use cases, rebuilding integration code around a different API contract, and re-validating compliance posture with the new vendor from scratch. That cost is rarely visible in the initial procurement decision, which is exactly why it belongs in the scorecard above rather than being discovered after the fact.

The practical mitigation isn’t necessarily “pick the vendor with the best exit terms,” most API-based TTS vendors have similar switching costs. It’s building your integration layer with an abstraction that doesn’t hard-couple your product to one vendor’s specific API contract, so that if you do need to switch, you’re rebuilding one integration layer instead of every call site across your codebase.

What are the actual red flags during procurement?

Beyond the scorecard, a few specific patterns during the sales and evaluation process are worth treating as warning signs rather than minor friction:

• “We’re SOC 2 compliant” with no report offered. A vendor that claims SOC 2 status but won’t provide the actual audit report (even under NDA) is asking you to trust a claim you can’t verify. Legitimate vendors share the report, or at minimum a bridge letter confirming current status, as a routine part of enterprise sales.
• Vague answers to the sub-service coverage question. If a vendor’s answer to “is your text-to-speech service specifically covered under our BAA” is a restatement of their general platform compliance page rather than a direct yes or no, that’s the answer. Push for specificity in writing before treating it as resolved.
• SLA language with no defined remedy. “We target 99.9% uptime” is a marketing statement. “99.9% uptime, with service credits of X% per hour of downtime beyond that threshold” is a contractual commitment. If the SLA document doesn’t specify what happens when the target is missed, there’s no real guarantee underneath it.
• Reluctance to discuss data export or offboarding. A vendor confident in their product doesn’t mind explaining how you’d leave if you needed to. Evasiveness on this question during procurement, before you’ve signed anything and still hold real negotiating power, is a preview of how that conversation goes later when you do need to leave and hold considerably less of it.

Sources

• AWS, “Amazon Polly Achieves HIPAA Eligibility,” official AWS Machine Learning Blog, retrieved 2026-08-03
• AWS, HIPAA Compliance and HIPAA-eligible services documentation, aws.amazon.com/compliance/hipaa-compliance, retrieved 2026-08-03
• Google Cloud, HIPAA Compliance documentation, cloud.google.com/security/compliance/hipaa, retrieved 2026-08-03
• Microsoft, Azure HIPAA Compliance Scope documentation (Microsoft Learn), retrieved 2026-08-03
• Telnyx, “How to build voice AI that survives your next provider switch,” telnyx.com/resources/vendor-lock-in-voice-ai-stt-tts, retrieved 2026-08-03

Compliance status, BAA coverage, and certification scope change frequently and vary by contract tier and specific service. We verified the claims above against the sources listed at the time of writing; confirm current status directly with each vendor and your own legal or compliance team before any regulated deployment.

Frequently Asked Questions

Does signing a BAA with a cloud provider make my app HIPAA compliant?

No. A BAA establishes the vendor’s contractual responsibilities as a business associate, but you’re still responsible for configuring the service correctly under the shared responsibility model, encryption, access controls, and audit logging all have to be set up properly on your end. A signed BAA with a misconfigured service is not a compliant system.

Is Amazon Polly HIPAA compliant?

Amazon Polly is confirmed HIPAA-eligible by AWS, meaning it can be used with protected health information once a BAA is in place and the service is properly configured. Check AWS’s official HIPAA-eligible services list to confirm current status.

Does a general BAA with Microsoft or Google automatically cover their text-to-speech service?

Not necessarily. Some voice and speech-related services have been flagged as requiring separate approval or falling outside standard BAA coverage even when the parent platform is covered. Always confirm in writing that the specific service you intend to use is named on your BAA’s covered-services list.

What does it actually cost to switch text-to-speech vendors later?

Migration estimates commonly run to three months of engineering time at minimum for a production integration, covering re-testing voice quality, rebuilding integration code, and re-validating compliance with the new vendor. Building an abstraction layer rather than calling one vendor’s API directly throughout your codebase reduces this cost.

What’s the difference between SOC 2 Type I and Type II?

Type I evaluates whether a vendor’s security controls are designed appropriately at a single point in time. Type II evaluates whether those controls actually operated effectively over a period, typically 6-12 months. Type II is the stronger signal for enterprise procurement since it demonstrates sustained operation, not just a paper design.

Should I evaluate voice quality before or after checking compliance?

After, if you’re an enterprise buyer with regulated data or strict security requirements. Compliance and contractual terms eliminate vendors before voice quality becomes relevant, testing quality first often means discovering your preferred vendor is disqualified after the technical work is already done.

Compliance certifications, BAA availability, and contractual terms referenced here change frequently. Always confirm current status directly with each vendor and consult your own legal or compliance team before a regulated deployment.

About the author

Richard Johnson

Richard Johnson is an AI specialist with over five years of experience guiding large organizations through AI adoption, across more than 100 customers. He founded CognitiveFuture to research and compare AI tools across design, development, writing, research, voice and business, cutting a crowded, fast-moving market down to the right choice for the job in front of you.