What GDPR actually requires for voice data
Voice recordings are personal data, and consent is not the only requirement. Here is what a defensible chain looks like in practice.
Voice data occupies an awkward position in data protection law. It is unambiguously personal data, because a recording can be linked to the person who made it. In most interpretations it is also biometric data when used for identification purposes, which puts it in a stricter category.
That combination means the compliance requirements for a voice dataset are heavier than for most text corpora, and buyers who assume otherwise tend to find out during legal review.
The lawful basis is the starting point
Under GDPR, processing personal data requires a lawful basis, and for voice data collected for AI training the realistic options are consent or legitimate interest.
Consent is the more defensible choice for most projects, but it has a specific meaning: it must be freely given, specific, informed, and unambiguous. A speaker who signed a general release without being told their voice would train a machine learning model has not given valid consent for that purpose.
What the consent record needs to say
The documentation that survives a legal review is specific about the purpose, not just the fact of recording.
- What the recording will be used for, described concretely enough that a layperson understands it.
- Who the data will be shared with, including whether it may leave the speaker's jurisdiction.
- How long it will be retained, and what happens at the end of that period.
- How the speaker can withdraw, and what happens to their data if they do.
- For children: guardian identity and authority, with the permitted use stated explicitly.
The transfer problem
If your speakers are in the EU and your training infrastructure is in the United States, you are making a restricted transfer, and that requires its own legal mechanism on top of the consent.
This is one of the more common gaps we see. A project collects consent correctly, then ships the data across an ocean without the transfer mechanism, and the compliance chain breaks at the point where it matters most.
Data subject rights have to be operable
A speaker can ask what you hold about them, ask for a copy, and ask for erasure. For a voice dataset distributed to buyers, that last one is genuinely difficult, and it is worth deciding how you will handle it before you sell the data rather than after.
Practical approaches include retaining a speaker identifier on every file so that records can be located, and contractual terms that require downstream recipients to comply with erasure requests.
What we do about it
For projects involving EU data subjects, consent documentation is built to satisfy these requirements and delivered with the dataset, and the transfer mechanism is addressed in the agreement rather than left implicit.
We also decline projects where the consent chain cannot be made sound — including anything involving recorded telephone calls, where the consent of the other party is typically absent.