When building voice products for healthcare, the roadmap bottleneck is rarely transcription accuracy. It is the procurement cycle, where legal teams block your launch because your speech-to-text vendor refuses to sign a BAA, uses customer audio for model training, or cannot tell you which geographic region processes your audio. A HIPAA violation for impermissible disclosure of protected health information carries civil penalties that scale with negligence tier under 45 CFR §160.404, reaching seven figures for systemic failures documented in HHS enforcement records, and penalties apply even when no data breach causes measurable patient harm.
This guide provides product leaders building clinical documentation tools, healthcare communication platforms, or contact center technology a BAA-specific blueprint. We cover the exact safeguards required, the JSON payloads that enforce them, and the five vendor questions that separate a compliant partner from a compliance liability.
What makes a speech-to-text API HIPAA compliant?
A speech-to-text API becomes HIPAA compliant when the vendor signs a Business Associate Agreement, encrypts data in transit using TLS 1.2+ and at rest using AES-256, and you configure the pipeline to enable PHI redaction on every request, select zero-data retention, and restrict processing to the required geographic region. Compliance is not a vendor property alone. It requires correct configuration and access controls on your side.
Essential HIPAA safeguards for voice APIs
PHI protection for audio workflows
The U.S. Department of Health and Human Services (HHS) defines Protected Health Information (PHI) as any individually identifiable health data that relates to an individual's past, present, or future physical or mental health condition, the provision of healthcare, or payment for care. In audio workflows, PHI is not limited to the transcript: the raw audio file itself is classified as PHI if it contains a patient's voice discussing clinical information. Your speech-to-text vendor touches PHI from the moment audio reaches their ingestion endpoint, a scope that extends to contact center call recordings, IVR audio, and any other voice channel where patient data may appear.
Determining BAA compliance needs
A Business Associate Agreement is legally required any time a third-party API creates, receives, maintains, or transmits PHI on behalf of a covered entity. That definition captures every interaction a transcription API has with clinical audio: receiving the file, processing it, and returning a transcript. Routing a single patient encounter through a vendor without a signed BAA is an unauthorized disclosure under HIPAA, regardless of whether the data is ever exposed publicly. Execute the BAA before any audio containing patient information reaches the vendor's endpoint, including during evaluation and pilot phases.
Who holds HIPAA responsibility
HIPAA operates as a shared responsibility model. The vendor is responsible for securing the underlying infrastructure: encryption of data in transit and at rest, physical access controls, subprocessor management, and breach notification procedures. The customer is responsible for secure API configuration: managing API credentials, enabling PHI redaction via the correct request parameters, selecting zero-data retention, and restricting audio processing to the appropriate geographic region.
A vendor holding SOC 2 Type II and ISO 27001 certifications satisfies the infrastructure side of this model, but those certifications do not make your pipeline compliant if you route audio without enabling redaction or store transcripts in an unencrypted data warehouse downstream.
Key BAA provisions for compliant AI transcription
Critical BAA provisions and vendor requirements
A HIPAA-compliant BAA must cover four areas. It must define the permitted uses and disclosures of PHI, limiting them to performing the contracted service. It must require the business associate to implement safeguards preventing impermissible use or disclosure. It must establish a breach notification obligation: HHS requires notification without unreasonable delay and no later than 60 calendar days after the business associate discovers a breach. Finally, it must require that any subcontractors accessing PHI are bound by equivalent obligations.
When reviewing a vendor's BAA, key areas to examine include: whether the breach notification window is explicitly defined rather than simply restating the 60-day regulatory maximum, whether subprocessors that may access PHI are identified, whether liability limits are proportionate to the volume and sensitivity of data being processed, whether PHI handling obligations survive contract termination to allow for secure destruction, and whether the vendor permits audit rights for your compliance team to verify adherence.
Defining your data governance obligations
Under the shared responsibility model, the product team carries obligations that no BAA can satisfy on its behalf. API credentials must never be committed to version control or exposed in client-side code. PHI redaction must be explicitly enabled in each API request. Zero-data retention must be confirmed as the active configuration on the plan tier in use.
For clinical audio, Growth and Enterprise plans are the correct tiers: customer audio is never used for model training on either, with no opt-out action required. This is a structural default, not a settings panel checkbox.
Steps to finalizing a BAA contract
- Request the BAA template early: Obtain the vendor's BAA during initial conversations so legal review can begin while you complete technical evaluation.
- Confirm the plan tier: Verify that the BAA scope covers the data handling configurations you intend to use in production, including model training isolation and data retention obligations. Contact our team to discuss BAA execution timelines for Growth and Enterprise deployments.
- Sign before routing real patient audio: Consider using synthetic clinical audio or test datasets that do not contain PHI during evaluation. HHS requires covered entities to retain BAAs for six years from creation or last effective date.
Automating PHI redaction for HIPAA compliance
18 HIPAA identifiers to redact
HHS defines 18 Safe Harbor identifiers that must be removed to de-identify protected health information:
- Names
- Geographic subdivisions smaller than a state
- All date elements except year directly related to an individual
- Telephone numbers
- Fax numbers
- Email addresses
- Social Security numbers
- Medical record numbers
- Health plan beneficiary numbers
- Account numbers
- Certificate and license numbers
- Vehicle identifiers
- Device identifiers
- Web URLs
- IP addresses
- Biometric identifiers including voice prints
- Full-face photographs
- Any other unique identifying code
Modern Named Entity Recognition (NER) models detect the highest-risk identifiers reliably but never at 100% recall, using a combination of contextual analysis and rule-based parsing to identify and classify identifiers across entity type and audio conditions. Modern clinical de-identification systems typically combine NER models with regex-based parsers to handle the identifier formats and regional variations that contextual models alone may miss.
Audio-level vs. transcript-level redaction
Transcript-level redaction replaces identified PHI with structured placeholders in the text output while leaving the original audio intact. Audio-level redaction masks the waveform itself by replacing PHI segments with silence, so the spoken words are not retrievable from the released file. For text-based Large Language Model (LLM) pipelines, transcript-level redaction is standard, but the original unredacted transcript should never reach your central storage. Audio-level masking is required when raw audio files are archived, since a compliant text transcript does not protect PHI that remains audible in the stored recording.
Optimizing PHI masking for data utility
Placeholder format affects how usable a redacted transcript is for downstream systems. A generic [REDACTED] tag tells an LLM only that something was removed. A structured tag like [PATIENT_NAME] preserves enough semantic context for a summarization model to understand that a patient name appeared at that position without exposing the actual value. This matters for audio-to-LLM pipelines where structured output feeds into CRM population, coaching scorecards, or clinical documentation workflows. Our API supports targeted entity categories, letting you redact names, dates, phone numbers, and locations while retaining clinically relevant content like medication names and symptom descriptions that do not map to the 18 Safe Harbor identifiers.
Ensuring zero PHI leakage
PII redaction is an optional feature that must be explicitly enabled in each API request. It is not active by default. The following payload shows a correctly configured request for a clinical audio file, with speaker diarization enabled for multi-speaker environments and PII redaction targeting the most common PHI categories. Verify field names and accepted values against the live API schema before implementing:
```json
{
"audio_url": "https://storage.example-clinic.io/encounter_2025_001.wav",
"detect_language": true,
"diarization": true,
"pii_redaction": true,
"pii_redaction_config": {
"entity_types": ["name", "date_time", "phone_number", "location"]
},
"region": "eu-west"
}
```
The corresponding response returns masked entities inline with word-level timestamps preserved:
```json
{
"prediction": [
{
"speaker": "Doctor",
"transcript": "Good morning, I am reviewing the chart for [PATIENT_NAME] born on [DATE_TIME].",
"words": [
{"word": "Good", "start": 0.1, "end": 0.3},
{"word": "[PATIENT_NAME]", "start": 1.2, "end": 1.8}
]
}
]
}
```
Managing PHI lifecycle and data retention
Encryption standards for HIPAA compliance
All audio transmitted to our API is encrypted in transit using Transport Layer Security (TLS) encryption, which protects data moving between your infrastructure and ours. Data at rest is encrypted using AES-256. Our security architecture documentation and independent audit reports are available to procurement teams through our compliance hub.
Defining audio retention and purge cycles
Zero-data retention means the vendor deletes all audio files and transcript data immediately after processing completes, leaving no recoverable copy on their infrastructure. This is the correct configuration for any clinical audio workflow where raw recordings contain PHI. On our Enterprise plan, zero-data retention is supported by default. Transcripts are delivered via callback and all audio is deleted immediately after processing completes, with nothing retained on our infrastructure. The delete transcription endpoint provides a direct API call to remove a specific transcription record and its associated data programmatically.
Restricting model training on PHI
Plan tier determines whether customer audio enters model training pipelines.
| Plan |
Data used for model training |
Opt-out required |
| Starter |
Can be used by default |
Not confirmed, check plan terms |
| Growth |
Never |
No |
| Enterprise |
Never |
No |
Using clinical audio on the Starter plan creates a compliance risk when that audio contains PHI, because customer data can be used for model training by default on that tier. Growth and Enterprise plans eliminate this risk structurally, with contractual guarantees that customer data is never used for model training.
Regional data residency requirements
Geographic data residency affects which infrastructure your audio traverses during processing. Our EU-west region keeps audio on EU infrastructure from ingestion through transcript delivery, satisfying data localization requirements for European deployments under GDPR. For US-based covered entities processing European patient data, EU-west infrastructure also supports HIPAA-eligible deployment, but HIPAA itself does not mandate EU data residency. Our US-west region routes processing entirely within US infrastructure for organizations whose contracts or internal policy require patient data to remain within US jurisdiction. Regional selection is configurable at the API request level.
Architecting secure API access and auditing
Role-based access control at the API layer means only the services and personnel who need transcript output to perform their function should hold credentials with access to the transcription endpoint. Implement API key rotation on a schedule consistent with your organization's security policy, use separate keys for development, staging, and production environments, and never store API keys in environment files committed to shared repositories. For audit trail requirements under the HIPAA Security Rule, log every transcription request with a timestamp, the requesting service identifier, the audio source reference, and the redaction configuration applied. Retain API access logs for a minimum of six years in your own compliant logging infrastructure, consistent with HIPAA's six-year documentation retention standard under 45 CFR §164.316(b)(2).
Speech-to-text vendors processing clinical audio typically need a combination of independently audited certifications and documented compliance assessments to meet enterprise procurement requirements:
- SOC 2 Type II: Verifies that security controls operated effectively over a defined audit period, not just at a point in time.
- ISO 27001: Confirms a certified information security management system with continuous improvement requirements.
- Third-party HIPAA risk assessment: Unlike SOC 2 or ISO 27001, HIPAA has no official government certification body. Look for a third-party risk assessment or readiness report confirming the vendor's controls have been evaluated against the HIPAA Security Rule by an independent assessor.
- GDPR compliance: Required for any vendor processing audio from EU-based patients or healthcare facilities.
- HDS (Hébergeur de Données de Santé): France's mandatory framework for hosting personal health and patient data, one of the strictest health data standards in Europe. Relevant for French and EU-based healthcare organizations where HDS certification is a hard procurement requirement for clinical audio workflows.
Vendor due diligence: 5 essential HIPAA questions
Use these five questions in every vendor conversation. For each, the answer should appear in the contract and the API documentation, not in a verbal assurance.
- "Will you sign a BAA during our pilot phase, or only for annual contracts?" Some vendors tie BAA execution to contract tier or commercial commitment. Ask explicitly whether a BAA is available during your evaluation phase before routing any clinical audio through a new vendor. Contact our team to discuss BAA execution for Growth and Enterprise tiers before your evaluation begins.
- "What is your default data retention policy, and do you support zero-data retention?" Ask for this in writing and verify it against the vendor's DPA. Default retention policies that store audio for debugging purposes are incompatible with zero-data retention requirements for clinical audio. Our DPA explicitly prohibits using customer audio for model training on Growth and Enterprise plans and supports immediate post-processing deletion.
- "Which of the 18 HIPAA identifiers does your automated redaction cover, and what is its accuracy rate?" Our PII redaction API covers the highest-risk PHI categories including names, dates, phone numbers, geographic data, and account numbers, with modern clinical NER models detecting the highest-risk identifiers reliably but never at 100% recall, depending on entity type and audio conditions. Zero-data retention addresses the residual risk: if no unredacted audio remains on the vendor's servers after processing, a missed entity in the transcript does not create a persistent PHI exposure.
- "Do you process audio in the same geographic region where it is stored?" Cross-border processing without explicit consent can create compliance complications under both HIPAA and GDPR for EU-based healthcare organizations. We offer EU-west and US-west regions with audio processed and stored within the selected region, configurable at the API request level.
- "Is our audio data completely isolated from your model training pipelines?" On our Growth and Enterprise plans, the DPA explicitly states customer data is never used for model training. This is verifiable in the contract language before you sign.
The BAA must also specify a breach notification window no later than 60 calendar days as required by HIPAA. Verify that the vendor's definition of "breach" aligns with HHS guidance, covering unauthorized access and not only external attacks, and that notification includes sufficient detail for the covered entity to begin its own breach response.
Evaluating vendors for HIPAA-compliant STT
Protecting PHI in speech API pipelines
Use this checklist when evaluating any speech-to-text vendor for clinical audio:
- BAA availability: Vendor signs BAA on the plan tier you intend to use in production, including during evaluation.
- Encryption: In-transit and at-rest encryption confirmed in the SOC 2 report.
- Deployment region: EU-west or US-west regional isolation configurable at the request level, no cross-border processing by default.
- Redaction: Automated PHI redaction covering the highest-risk Safe Harbor identifiers, explicitly enabled per-request, not active by default.
- Model training isolation: DPA explicitly prohibits using customer audio for training on the plan tier in use, with no opt-out action required.
- Certifications: SOC 2 Type II and ISO 27001 independently audited and available on request. Third-party HIPAA risk assessment and GDPR compliance documentation also available through our compliance hub. We hold all certifications listed above.
Ensuring HIPAA compliance during testing
To avoid routing real patient data before a BAA is in place, consider using audio that does not contain PHI during evaluation. Synthetic clinical datasets and pre-redacted recordings are two approaches teams use to benchmark accuracy without exposing patient information. Synthetic audio should replicate the acoustic conditions of your production environment: background noise, multiple speakers, accented speech, and domain-specific terminology. For a blind accuracy comparison on your own audio without exposing PHI, upload non-PHI test audio to our STT comparison tool. It runs a blind evaluation across providers so you can assess accuracy on your specific audio conditions rather than taking any vendor's benchmark at face value.
For noisy conversational and business audio in English and core European languages, our Solaria-3 model achieves 9.6% WER on real customer audio, ahead of AssemblyAI, ElevenLabs, Deepgram, Mistral, and Speechmatics, and 6.4% WER on Earnings22 financial calls, the only model in that benchmark under 7%. For use cases requiring broad multilingual coverage, real-time streaming, or non-European languages, Solaria-1 covers 100+ supported languages. For multi-speaker encounter recordings, speaker diarization powered by pyannoteAI's Precision-2 model is optimized for async workflows, where the full recording is analyzed before generating speaker-attributed output.
For teams considering self-hosted open-source models as an alternative: self-hosted setups consistently underperform managed APIs on noisy conversational audio in production, while adding substantial DevOps overhead for scaling and maintenance. For most teams, the total cost of ownership favors a managed API once GPU infrastructure, scaling engineering, and the accuracy gap on noisy conversational audio are accounted for.
For clinical audio cost modeling with all audio intelligence features included:
Table: Cost model for clinical transcription at scale (async, all features included)
| Monthly volume (hours) |
Starter ($0.61/hr async) |
Growth (volume-based pricing) |
Enterprise (custom) |
| 100 hours |
$61.00 |
Contact for volume pricing |
Custom SLA and hosting |
| 1,000 hours |
$610.00 |
Contact for volume pricing |
Custom SLA and hosting |
| 10,000 hours |
$6,100.00 |
As low as $2,000.00 ($0.20/hr with upfront commitment) |
Custom SLA and hosting |
Diarization, PHI redaction, translation, and named entity recognition are included in the Growth base rate. Deepgram charges separately for features like speaker diarization and redaction, and AssemblyAI's audio intelligence add-ons stack on top of the base transcription rate per hour, pushing the effective fully-featured price well above the headline rate. At 1,000 hours per month with a full feature set, the effective price difference compounds significantly against per-feature pricing models.
Table: Deployment model decision framework
| Deployment model |
Latency |
Data residency |
Implementation effort |
Security profile |
| Cloud API (Gladia) |
~300ms real-time / processing time of <60s per audio hour async |
Configurable (EU-west or US-west) |
Low (sub-24-hour integration) |
SOC 2 Type II, ISO 27001, HIPAA-eligible, BAA signed |
| On-device / offline |
Dependent on local hardware |
Local only |
Typically higher (infrastructure setup and maintenance) |
No external transit, local security controls required |
The vendor selection question most product leaders frame incorrectly is "is this vendor HIPAA compliant?" The correct question is "does this vendor sign BAAs on the tier I need, isolate my audio from model training by default, and give me programmatic control over redaction and data residency?" Those answers are in the contract and the API documentation, not the security badge on the marketing page.
For clinical audio workflows, Growth and Enterprise plans include the BAA, model training isolation, and zero-data retention configuration this article covers. Start with €50 in free credits and have your integration in production in less than a day.
FAQs
Do I need a BAA for every speech-to-text vendor I use?
Yes. Any third-party API that creates, receives, maintains, or transmits PHI on your behalf must sign a BAA before you route clinical audio through it. Processing PHI without a signed BAA is an unauthorized disclosure under HIPAA, and civil penalties apply regardless of whether an actual data breach occurs.
What is the difference between HIPAA-eligible and HIPAA-compliant for an STT API?
A speech-to-text vendor is HIPAA-eligible when it holds the relevant certifications and is willing to sign a BAA under a shared responsibility model. Your pipeline approaches HIPAA-compliant status when you have signed that BAA and implemented appropriate safeguards: PHI redaction configured on every request, a plan tier that prohibits model training on customer audio, and audio routed to the correct regional infrastructure. These steps address the vendor and configuration layers of HIPAA. Consult your compliance team to verify your complete posture.
Does automated PHI redaction fully replace zero-data retention?
No. Automated redaction detects the highest-risk identifiers reliably but never at 100% recall, meaning a small percentage of PHI entities may remain unredacted in the transcript. Zero-data retention eliminates the risk of persistent PHI exposure on the vendor's servers by ensuring no audio or transcript remains after processing completes. Together, these controls strengthen your HIPAA compliance posture.
Can I use the Starter plan for clinical audio if I enable redaction?
No. On the Starter plan, customer audio can be used for model training by default, which creates a compliance risk for PHI under HIPAA. Clinical audio should be routed through Growth or Enterprise plans, where customer audio is never used for model training and no opt-out action is required.
Is speaker diarization available for real-time clinical transcription?
Diarization in our API is optimized for async workflows, where the full recording is analyzed before generating speaker-attributed output. For live clinical encounters where speaker attribution is required, record the audio in real-time and submit the completed recording through an async transcription request with diarization enabled. Diarization analyzes the full recording before generating output, which is what produces accurate speaker attribution.
Which Gladia model should we use for English-language noisy or conversational audio?
Solaria-3 is the stronger choice for noisy conversational and business audio in English and core European languages. Use Solaria-1 for real-time streaming or languages outside the core European set.
Key terms glossary
Business Associate Agreement (BAA): A legally binding contract establishing HIPAA-compliant data handling responsibilities between a covered entity and a service provider. It must be signed before any PHI is transmitted to the vendor.
Protected Health Information (PHI): Any individually identifiable health data, including patient names, medical histories, and clinical audio recordings, protected under HIPAA. Both raw audio and text transcripts containing patient information are classified as PHI.
Zero-data retention (ZDR): A configuration where the API provider deletes all audio files and transcripts immediately after processing, leaving no data on their servers. ZDR works alongside automated redaction to strengthen HIPAA compliance for clinical audio pipelines.
Word Error Rate (WER): The standard metric for transcription accuracy, calculated by comparing the number of substitution, deletion, and insertion errors in the API output against a human-verified reference transcript.
Diarization Error Rate (DER): The metric measuring speaker attribution accuracy, calculated as the fraction of time that is not attributed correctly to a speaker or non-speech across a multi-speaker recording. DER differs from Word Diarization Error Rate (WDER), which measures the fraction of correctly recognized words with incorrect speaker tags.
Safe Harbor de-identification: The HIPAA standard requiring removal of all 18 defined PHI identifiers from health data before it can be considered de-identified. Automated NER identifies these identifiers in transcripts and replaces them with structured placeholders.
