What GDPR actually requires for voice data

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. If the data crosses a border, the agreement states how it may be moved, not left unsaid.

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.

When voice becomes a special category

Voice recordings are personal data. Whether they are also special category data depends on what they are used for, and the test is narrower than most teams assume.

The special category is triggered when voice is processed for the purpose of uniquely identifying a person. Speech data collected to train a recognition model is not, by itself, biometric processing, because the model is learning general acoustic patterns rather than a template for a specific individual. The same recording used to build a speaker verification system is, because identification is the purpose.

The practical consequence is that the classification follows the use, not the file. A corpus that is ordinary personal data in one project can become special category in the next, and the consent obtained for the first purpose does not automatically cover the second. This is worth writing into the specification as an explicit statement of purpose, because it determines which legal basis is available and how heavy the compliance work will be.

What to ask a supplier before you sign

The questions that surface a compliance gap while there is still time to walk away:

• What is the stated purpose in the consent form, and does it name machine learning training rather than recording in general?
• Where were the speakers located, and if any were in the EU or UK, what transfer mechanism covers the movement of their data?
• How is a specific speaker located in the delivered corpus, so that an access or erasure request can actually be fulfilled?
• What happens contractually when a speaker withdraws after the dataset has shipped to a downstream recipient?
• Are there any speakers whose consent covers recording but not commercial licensing?
• For any dataset that was not collected by the supplier, what is the documented chain from the original speaker to the current holder?