Fireflies, voiceprints, and BIPA: why biometric meeting data is the next privacy front

In December 2025, Cruz v. Fireflies.AI Corp. was filed in the Northern District of Illinois. The complaint is short, technical and aimed straight at one feature: Fireflies' "Speaker Recognition", which generates voiceprints of every meeting participant and uses them to label transcripts.

The legal hook is the Illinois Biometric Information Privacy Act (BIPA), which has the rare distinction among US privacy laws of providing a private right of action with statutory damages of $1,000 per negligent violation and $5,000 per intentional one. That math gets large quickly when "every meeting participant" is the plaintiff class.

For European teams reading this from Brussels or Antwerp, BIPA is not directly applicable. But the case names something that GDPR has been quietly applying to since 2018 and that most meeting tools have not surfaced clearly: voiceprints are biometric data, and biometric data sits in a stricter regulatory category than transcripts.

This post is about what voiceprints actually are, why meeting tools build them, what GDPR Article 9 says about them, and how to evaluate a meeting recorder once you start asking the biometric question seriously.

What a voiceprint actually is

A voiceprint is a numerical representation of a person's voice that uniquely identifies them. Modern voiceprints are usually a vector of a few hundred floating-point numbers, generated by passing audio through a trained model (an x-vector or d-vector network, typically). Two recordings of the same speaker map to similar vectors; two recordings of different speakers map to dissimilar ones.

That property is what makes "speaker recognition" possible in meeting tools. Once a tool has a voiceprint for each participant, it can label transcripts ("Alice said: ...", "Bob said: ...") without anyone manually tagging speakers.

The Fireflies complaint alleges Fireflies builds these voiceprints automatically, including for participants who never created a Fireflies account, never agreed to its terms of service, and never gave written consent. Under BIPA, that combination is a per-violation problem if it can be proven.

The technical detail that matters: a voiceprint is not just "a transcript snippet". It is data that uniquely identifies a person, in a way that survives anonymisation of other fields, and that can be matched against future recordings (yours or anyone else's) without the person's involvement. Once the voiceprint exists, the person's voice is enrolled in a database whether they know it or not.

What GDPR says about this in Europe

GDPR Article 9 prohibits processing of "biometric data for the purpose of uniquely identifying a natural person" except under narrow conditions: explicit consent, employment law, vital interests, public interest, legal claims, or other specific bases listed in Article 9(2).

A voiceprint built for speaker recognition fits squarely in that prohibition. It is biometric data, used for unique identification. The processing requires an Article 9 basis on top of the Article 6 basis you would already need for any personal data.

In practice, "explicit consent" is the only realistic Article 9 ground for a meeting tool. That means each participant must give specific, informed, freely-given, opt-in consent to having their voiceprint generated and stored. Tucking it into a meeting invite footer does not meet that bar; the Belgian DPA and several other supervisory authorities have been explicit about this in recent guidance.

Most of the cloud meeting tools that offer speaker recognition have not built that explicit-consent flow. They rely on the meeting host's account-level consent and assume it covers all participants. If a Belgian regulator decides to test that assumption, the architecture will not survive.

Why meeting tools build voiceprints in the first place

It is not because users asked for them. It is because, before voiceprints, speaker labels in transcripts had to come from somewhere else, and the alternatives were worse:

• Manual tagging. Asks too much of the user.
• Channel separation. Only works in calls where each participant has their own audio track.
• Speaker diarisation without identification. Labels "Speaker 1", "Speaker 2", etc., but does not say who they are. Useful, but less polished than named labels.

Voiceprints solve the problem cleanly from a product perspective. They do it by capturing biometric data, which until 2025 most users were not asking about.

The Fireflies case will probably push the category toward one of two paths:

1. Add a real, per-participant, opt-in consent flow before generating any voiceprint. Net effect: most participants will not opt in, and transcripts will fall back to "Speaker 1, 2, 3" labels.
2. Stop generating voiceprints altogether. Use diarisation without identification, and let users (or AI) link names to speaker numbers if they want.

Both are reasonable. Both make the product slightly less magical. Neither is what the current generation of cloud meeting tools is shipping by default.

The local-recording angle, again

If you have read our other posts, you can see where this goes.

When meetings are recorded on the user's own Mac, with audio that never leaves the device, the question of "is the vendor storing voiceprints of meeting participants" simply does not arise. There is no vendor in the audio path. Whatever speaker labelling is done, is done locally with whatever audio is on the local disk.

In MeetMemo specifically, we do not currently generate voiceprints at all. Our chunker labels speaker turns from WhisperKit's segment boundaries, not from biometric identity. When WhisperKit ships diarisation in a future version, we will adopt it locally. We will not at any point build a voiceprint database on a server, because we do not have a server in the audio path.

That is not a difficult engineering choice for us; it falls out of the architecture. But it is a meaningful product difference for any team that would rather not have its participants' voices enrolled in a third-party database without their explicit consent.

What teams should do today

Three concrete actions that are easy to take this quarter:

1. Audit your current meeting tools for "Speaker Recognition" or "Voice ID" features. If any of them are enabled by default and you are recording calls with external participants (clients, candidates, partners), turn them off. Document the change.

2. Update your meeting-invite language. If a tool is generating voiceprints, your invite footer should say so explicitly and link to a per-participant consent flow. Generic "this meeting may be recorded" language probably does not cover biometric processing under GDPR Article 9.

3. Reconsider tools whose architecture forces voiceprint generation server-side. If the only way to get speaker-labelled transcripts is to ship audio to a vendor that generates voiceprints, you have a structural problem. Local-recording tools that diarise on-device avoid it. We are biased here, but the bias is downstream of the architecture, not upstream.

The Fireflies BIPA case will play out over months. The motion practice will produce interesting law. Meanwhile, the biometric question will quietly become a standard line item in any meeting-tool RFP starting Q1 2026.

If you want a Mac meeting recorder that records on your device, transcribes on the Neural Engine, summarises locally and keeps no biometric data anywhere we can reach, download MeetMemo. Free until you record more than three meetings per month. Your voice never enrolls in anything.