A February 2026 class action against Microsoft Teams alleges that live transcription performs speaker diarization and collects voiceprints without BIPA-compliant notice or written consent. I've integrated diarization into meeting bots, call analytics pipelines, and voice agents for the past three years. The accuracy benchmarks are easy to find. Vendor docs rarely explain what happens to the voice embeddings your API call creates.
If you're routing audio through a third-party STT API with diarize=true, you're not just getting speaker labels. You're often creating biometric data that outlives the transcript. Here's how I evaluate diarization providers when privacy requirements are real, not just a checkbox on a sales deck.
What speaker diarization does (and why the feature flag matters)
Speaker diarization answers one question: who spoke when? It takes a single audio stream and segments it into time-stamped blocks labeled Speaker 1, Speaker 2, and so on. Transcription tells you what was said. Diarization tells you who said it.
That distinction matters because diarization isn't a metadata toggle you slap onto a transcript. To separate speakers, the system analyzes vocal characteristics: pitch, timbre, cadence, formant patterns. Those characteristics are unique enough to function as a voiceprint. AssemblyAI bundles diarization into its speech-to-text API. Deepgram exposes it as a parameter on batch and streaming requests. AWS Transcribe and Google Cloud Speech-to-Text have speaker separation in their enterprise tiers.
I've seen teams treat diarize=true like enabling timestamps. It's closer to turning on facial recognition. The output looks harmless ("Speaker 1: Let's review the contract"), but the processing underneath creates biometric identifiers that regulators now treat as sensitive personal data.
The privacy problem: diarization creates biometric voiceprints
Illinois BIPA defines a voiceprint as biometric information. Courts and plaintiffs in 2025–2026 are applying that definition to SaaS transcription tools, not just hardware scanners. The Microsoft Teams case cited in Lexology's analysis argues that live diarization collects voiceprints without the written notice, explicit consent, and published retention schedule BIPA requires.
Three implications hit developers directly.
First, single-host consent isn't enough. If your meeting bot diarizes a call with five participants, you need a consent framework that covers every voice in the room, not just the person who clicked "record."
Second, subprocessor liability is real. Your architecture is your vendor's architecture. If Deepgram retains audio samples for model training or AWS Chime SDK stores voice embeddings for up to three years, that retention policy becomes yours when a plaintiff's lawyer reads your privacy policy.
Third, the gap between "we have diarization" and "we handle voiceprints responsibly" is where most products fail. Vendor docs emphasize word error rate and streaming latency. They rarely lead with what happens to the embeddings after your API call returns.
Cloud diarization APIs compared: accuracy, retention, and training policies
I've benchmarked six cloud providers and two privacy-focused alternatives on identical multi-speaker audio. Accuracy varies, but the privacy posture varies more than the accuracy numbers suggest.
AssemblyAI delivers strong diarization accuracy on meeting audio and supports real-time streaming. Their data retention policy allows model training on submitted audio by default, with an opt-out available through the dashboard. Audio retention depends on your plan tier.
Deepgram matches AssemblyAI on speed for streaming workloads. Their privacy FAQ notes they retain a sample of submitted audio for model training unless you negotiate different terms in your contract. Diarization quality is competitive, but the training default is the dealbreaker for healthcare and legal clients I've worked with.
AWS Transcribe and Chime SDK Voice Analytics fit neatly into AWS-native stacks. The Chime SDK retains voice embeddings for up to three years for voice analytics features. That's a long time for biometric data you may not know you're storing.
Google Cloud Speech-to-Text has speaker diarization on batch requests with solid accuracy on clean audio. Data handling follows Google Cloud's standard terms. Your audio processes on shared infrastructure with configurable retention through your GCP project settings.
Gladia positions itself on privacy, with no training on customer data by default. Diarization is available, and their AssemblyAI vs Deepgram comparison includes a privacy ratings table. Useful as a starting point, though I'd verify every claim against primary sources.
pyannoteAI (hosted) offers the shortest retention window I've found among cloud options: 24-hour output retention and 48-hour media retention. Accuracy with their Precision-2 model is competitive with the major cloud APIs.
Querious takes a different approach entirely. Their BIPA policy states voiceprints are processed only in volatile memory and destroyed within 60 seconds of a session ending. That's the benchmark I use when clients ask what "ephemeral" should mean.
Data retention side-by-side (comparison table)
| Provider | Audio retention | Transcript/embedding retention | Trains on customer data? | On-prem available | BIPA-relevant notes |
|---|---|---|---|---|---|
| AssemblyAI | Plan-dependent; see docs | Transcripts stored per account settings | Yes, by default (opt-out available) | No | Voiceprint creation likely; verify consent flow |
| Deepgram | Sample retained for training | Stored per account/contract | Yes, sample retained | No | Contract terms govern training opt-out |
| AWS Chime SDK | Per AWS data policies | Voice embeddings up to 3 years | Per AWS service terms | Partial (VPC deployment) | Long embedding retention is a red flag |
| Google Cloud STT | Configurable via GCP | Per project settings | No for API audio by default | No | Shared infrastructure; check DPA |
| Gladia | Short-term processing | Per account settings | No by default | No | Verify current policy before production |
| pyannoteAI (hosted) | 48 hours | 24 hours (output) | Check current terms | Community model self-hosted | Shortest cloud retention window |
| Querious | Session only | 60 seconds (voiceprints) | No | No | Ephemeral voiceprint processing |
Source links: AssemblyAI retention, Deepgram privacy FAQ, AWS Chime SDK retention, pyannoteAI retention, Querious BIPA policy.
When self-hosted diarization is the safer choice
For teams with strict GDPR, HIPAA, or data sovereignty requirements, self-hosted diarization removes the subprocessor question entirely.
pyannote.audio Community-1 runs fully offline. I've deployed it on a single GPU instance processing call center audio where no byte could leave the VPC. Accuracy on clean two-speaker audio is within a few percentage points of cloud APIs. Noisy conference rooms with overlapping speech are where cloud models with larger training sets still win.
The hybrid pipeline I use most often pairs OpenAI Whisper or a private STT API like Privocio for transcription with pyannote for speaker segmentation. You get speaker labels without sending audio to a diarization-specific cloud endpoint. Our private speech-to-text guide covers the self-hosted deployment path in detail.
Trade-offs are real. You own GPU ops, model updates, and accuracy tuning. There's no SLA to call when diarization fails on a heavy-accent speaker. For regulated industries, that trade-off usually favors control over convenience.
How to add speaker labels without creating a compliance liability
I've helped three SaaS teams retrofit diarization into existing transcription pipelines. The technical integration takes a weekend. The compliance work takes longer if you skip it upfront.
Opt out of model training wherever the vendor allows it. AssemblyAI's dashboard has a training opt-out toggle. Deepgram requires contract-level terms for full training exclusion. Don't assume the default API terms protect you.
Configure minimum retention TTLs. If your product doesn't need stored embeddings, don't store them. I've audited codebases where diarization responses were cached in Redis for 30 days "just in case." Thirty days of biometric data in a cache nobody reviewed.
Use EU data residency where available. Several providers offer regional processing. It doesn't solve BIPA for Illinois users, but it matters for GDPR data residency requirements.
Document subprocessors in your privacy policy. If your STT vendor diarizes audio, that vendor's retention policy is your retention policy in the eyes of regulators. Link to their DPA and retention docs directly.
Prefer ephemeral processing for sensitive workloads. If you only need speaker labels for a live session, process in memory and discard embeddings after the session ends. Don't persist voiceprints you won't use.
A developer's privacy checklist before you flip diarize=true
Before enabling diarization in production, I run through this list with every client:
- Does your privacy policy disclose voiceprint collection and link to a retention schedule?
- Do you have written consent from all speakers, not just the meeting host?
- Have you reviewed your STT vendor's subprocessor list and data processing agreement?
- Did you opt out of model training on customer audio?
- Are voice embeddings stored anywhere (database, cache, logs, analytics pipeline)?
- What's the retention TTL for audio, transcripts, and embeddings at each processing layer?
- Do Illinois users trigger additional BIPA obligations in your consent flow?
- Can you delete all voice-derived data on user request within your stated timeframe?
- Is there an on-prem or VPC deployment option if cloud retention is unacceptable?
- Have legal counsel reviewed whether diarization alone triggers biometric consent requirements in your target jurisdictions?
If you can't answer at least eight of these confidently, you're not ready for production diarization, regardless of how good the accuracy benchmarks look.
Frequently asked questions
Does speaker diarization create a voiceprint under BIPA?
Yes, in most implementations. Diarization analyzes unique vocal characteristics to separate speakers. Illinois courts and recent litigation treat that analysis as voiceprint collection under BIPA. The February 2026 Microsoft Teams case is the most visible example, but the principle applies to any SaaS product routing audio through a diarization-enabled API.
Which diarization API has the shortest data retention?
Among cloud providers I've audited, pyannoteAI has the shortest window at 24-hour output retention and 48-hour media retention. Querious goes further with 60-second ephemeral voiceprint destruction. Self-hosted pyannote.audio gives you full control. Retention is whatever you configure locally.
Can I use cloud diarization for HIPAA workloads?
Only with a signed Business Associate Agreement and a vendor whose retention and training policies meet your compliance requirements. Most general-purpose STT APIs with diarization don't offer HIPAA-ready defaults. I've seen healthcare teams use cloud transcription without diarization (lower biometric risk) or self-hosted pyannote inside a HIPAA-compliant VPC. Our HIPAA transcription guide covers the BAA and deployment requirements.
Is self-hosted pyannote production-ready in 2026?
For two-to-four speaker scenarios on reasonably clean audio, yes. I've run Community-1 in production for call analytics and internal meeting tools. It struggles with noisy overlap and large speaker counts (10+ in a conference room). For those cases, cloud APIs with better training data still win on accuracy, but you pay the privacy cost.
Do I need separate consent for diarization vs transcription?
In jurisdictions with biometric privacy laws, likely yes. Transcription converts speech to text. Diarization creates a voiceprint to identify the speaker. Those are different data processing activities under GDPR and BIPA. Your consent flow should distinguish between them, and your privacy policy should describe each separately.
Conclusion: privacy-first speaker labels
Speaker diarization is a genuinely useful feature for meeting transcription, call analytics, and voice agents. It's also a biometric data pipeline that most vendor docs don't describe honestly. Before you flip diarize=true, audit what happens to voice embeddings after the API response, not just the word error rate on the benchmark page.
For teams that need speaker labels without long-lived voiceprints, self-hosted pyannote or ephemeral providers like Querious are the paths I've seen work in production. For everything else, run the checklist above and get legal review before shipping.
If you want transcription infrastructure where your audio stays under your control, Privocio's private speech-to-text API processes audio without training on customer data, with self-hosted deployment for full data sovereignty. Start with our free tier, 3 hours every 4 weeks, and compare the privacy posture against any diarization-enabled cloud API you're evaluating.
Image credits: Cover image sourced from Unsplash (Unsplash License).