GDPR Consent for Voice Recording

Who it applies to

This applies to any project where the speaker is in the EU at the time of recording, regardless of where the company running the project is registered. It also applies to a buyer who never met the speakers, because the buyer relies on a consent it did not obtain and cannot cure.

The obligation sits with the controller, which in most voice projects is whoever decided to collect the data and why. A data supplier acting on instructions is usually a processor, and the buyer is usually a controller or a joint controller for its own training purposes. That allocation is worth writing down, because it determines who answers a withdrawal request two years later.

The scope of the problem is wider than commercial datasets. University corpora, community language projects and app-based collections frequently rely on a research consent that does not extend to commercial training, and buyers who assume a published corpus is clearable discover otherwise during diligence. The age of the corpus is a poor guide: older forms tend to be broader in appearance and narrower in the purposes they actually specify.

One category sits outside this analysis entirely. Where the recording captures a conversation, the other party is also a data subject, and their consent is generally absent. That is why call recordings are treated as unusable rather than as a documentation problem.

• Speakers recruited and recorded specifically for the dataset: the consent can be drafted correctly, so this is a documentation check.
• Existing corpora with research-era consents: usually requires re-consent, which is often impossible, so the dataset is not clearable.
• Recordings where a third party is audible: the missing consent belongs to someone who was never asked.

How to comply when you are buying data

The check is textual. You are not assessing whether the speakers were willing — you are assessing whether the document they signed reaches the thing you intend to do with the recording. A willing speaker and a valid consent are different facts, and only the second one survives a review.

For EU projects we build the consent documentation to these requirements and deliver it alongside the dataset, and we decline work where the consent cannot be drafted to cover the intended use. We are a sourcing company rather than a law firm, so the assessment of whether a given form is sufficient for your use case belongs with your counsel; our job is to make the form and the purpose statement legible and complete, and to say plainly when a form cannot be fixed rather than deliver a dataset with a defect in it.

• Read the consent form itself. Ask for the version that was actually signed, with its date, and check whether the form changed during the collection period — a corpus recorded across eighteen months can contain two different consents.
• Check that AI or machine learning training is named as a purpose in its own right. If the form says "research", "product development" or "improvement of services", assume it does not reach commercial training.
• Check that the consent is separate from the rest of the engagement. Payment terms, scheduling and confidentiality in the same declaration is the Article 7(2) problem, and it is visible in the document.
• Ask how withdrawal works and test the answer. If the supplier cannot explain how a withdrawal request would be actioned against files already delivered, the process does not exist.
• Confirm the onward-disclosure language. The speaker should have been told that the data may be shared with third parties and may leave their jurisdiction, or the redistribution to you was never covered.

How we handle consent and licensing →