Key Takeaways
- Annex III defines eight high-risk domains. Biometric identification, employment screening, and credit scoring face the strictest data quality obligations.
- Voice and speech AI falls under biometrics if used for remote identification or inferring sensitive attributes. Training data must reflect demographic and linguistic diversity.
- Article 10 requires training datasets to be relevant, representative, error-free, and complete. These are legal standards, not engineering suggestions.
- Full high-risk obligations including conformity assessments apply from August 2, 2027. Data governance work must start now.
- A compliant procurement spec asks vendors for bias audit methodology, speaker demographic breakdowns, consent documentation, and chain-of-custody records.
- YPAI's human-verified, consent-documented speech data collection is designed to satisfy Annex III data quality requirements.
The EU AI Act Article 10 data governance requirements covered in our earlier guide apply to any high-risk AI system. But which systems are actually high-risk? That is where most compliance efforts stall.
Annex III of the EU AI Act answers that question directly. It lists eight domains of high-risk AI applications. If your system falls into one of these categories, Article 10 data quality obligations are not optional. They are legal requirements.
This guide focuses on what Annex III means for training data procurement, with particular attention to the categories most relevant to voice, speech, and language AI.
The Eight Annex III Categories
Annex III organizes high-risk AI into eight domains:
- Biometric identification and categorization - Remote identification of individuals; categorization that infers sensitive attributes
- Critical infrastructure - AI managing roads, water, gas, heating, and electricity networks
- Education and vocational training - Automated assessment of learners; systems determining access to education
- Employment and worker management - Recruitment screening, task allocation, performance monitoring, termination decisions
- Essential private and public services - Credit scoring, insurance risk assessment, emergency services dispatch
- Law enforcement - Polygraph tools, crime prediction, evidence evaluation, profiling
- Migration, asylum, and border control - Risk assessment of individuals, document verification, application processing
- Administration of justice and democratic processes - AI assisting courts; systems influencing elections
Not every AI system in these sectors is automatically high-risk. Article 6(3) allows providers to self-classify as non-high-risk if the system performs a narrow procedural task with no meaningful impact on decision outcomes. But that exemption is narrow. If your system influences a decision about a person, the default assumption is high-risk.
Biometrics: Where Voice AI Gets Caught
Category 1 is the most relevant for voice and speech AI companies. Two subcategories apply.
Remote biometric identification
A system is high-risk if it identifies individuals from biometric data at a distance and without their active cooperation. Speaker identification systems, voice-print verification used for access control, and voice-based authentication in asynchronous contexts all fall here.
Article 10 data quality requirements for biometric identification are stringent. Training data must reflect the demographic diversity of the intended user population. A voice identification system trained primarily on male voices from a narrow age range will fail the representativeness test. The regulation does not specify exact demographic ratios, but the standard is whether a regulator could reasonably conclude the data reflects the real-world population the system will encounter.
Biometric categorization inferring sensitive attributes
This covers AI that infers race, political opinion, religious belief, or sexual orientation from biometric data. Article 5(1)(g) prohibits most real-time biometric categorization for mass surveillance. But there is a specific exemption in the regulation: training data vendors may use categorization tools to label datasets for the purpose of promoting demographic representativeness and reducing bias.
This matters for speech data collection. A provider assembling a multilingual European corpus can lawfully classify speakers by demographic group to ensure balanced representation. The purpose must be dataset quality, not end-user surveillance.
Employment AI: The Screening Data Problem
Category 4 covers AI used in recruitment, task assignment, performance evaluation, and termination decisions. This is the second highest-risk category for organizations using voice or language AI.
Automated CV screening, spoken interview analysis tools, and voice-based assessment platforms all fall here. The Article 10 requirements for employment AI carry specific implications.
Bias in historical hiring data
Employment AI trained on historical hiring data inherits the biases of past decisions. If a company systematically hired fewer women for engineering roles, a model trained on those outcomes will learn to de-prioritize female candidates. This is the failure mode Article 10 is designed to prevent.
Providers must examine training data “in view of possible biases that are likely to affect health or safety or lead to discrimination.” For employment AI, this means demographic parity analysis across protected characteristics before training begins, not as an afterthought.
Representativeness for global workforces
A recruitment AI trained on data from one country may perform poorly and discriminate against candidates from other regions. Article 10(4) requires that training data account for “the specific geographical, behavioural or functional setting within which the high-risk AI system is intended to be used.” An employment AI deployed across EU member states must be trained on data representing linguistic and cultural diversity across those markets.
What Article 10 Requires in Practice
The regulation sets four data quality standards that apply across all Annex III categories.
Relevant. Training data must match the intended deployment context. A voice AI system for Nordic markets should be trained on Nordic language varieties, not general English or standardized European speech.
Sufficiently representative. The data must reflect real-world variability. For speech AI, this means balancing speakers across age, gender, accent, dialect, education level, and recording environment. For employment AI, it means balanced representation across protected characteristics.
Free of errors. Data sourced from unreliable providers, scraped without consent, or containing labeling errors fails this standard. Article 10 explicitly requires data governance practices that catch and correct errors before training.
Complete. The dataset must be adequate for the system’s purpose. A corpus that excludes elderly speakers from a system designed for all age groups is incomplete for that purpose, regardless of its total size.
A Procurement Checklist for Annex III Training Data
When buying training data for a high-risk AI system, these are the questions your procurement spec must address.
Provenance and consent
- Can the vendor provide chain-of-custody documentation for every dataset element?
- Were data subjects informed about AI training as a use case at the point of consent?
- Does consent documentation survive a GDPR data subject access request?
Demographic coverage
- What is the breakdown of speakers (or subjects) by age, gender, and region?
- Does the dataset cover the geographic scope of your intended deployment?
- Has underrepresentation in any demographic group been documented and quantified?
Bias examination
- Has the vendor run bias audits using recognized fairness metrics?
- Are bias audit reports available for review before purchase?
- What was the inter-annotator agreement on sensitive labels?
Technical documentation
- Does the vendor provide a datasheet specifying collection methodology, preprocessing steps, and known limitations?
- Is there version control on the dataset so you can reproduce the exact training conditions?
- Can you receive a sample for independent quality testing before full delivery?
Ongoing obligations
- What is the vendor’s process for handling data deletion requests from individuals in the corpus?
- How will you be notified if the dataset is found to contain errors after delivery?
A vendor who cannot answer these questions should not be supplying data for a high-risk AI system.
How YPAI Addresses Annex III Requirements
YPAI collects European speech data through structured, human-verified processes designed around the data quality standards in Article 10.
Every speaker in a YPAI corpus provides informed consent that covers AI training as an explicit use case. Demographic breakdowns are documented before collection begins and tracked throughout. Quality control is human-verified at the recording level, not just aggregate statistics. Documentation includes collection methodology, preprocessing decisions, and known limitations in a datasheet format.
For biometric category use cases, YPAI’s consent framework and demographic documentation are designed to survive regulatory scrutiny. For employment AI use cases involving voice analysis, YPAI’s speaker diversity across EEA languages and accents supports the representativeness standard.
Organizations building Annex III systems can request YPAI’s data documentation package to assess fit before procurement.
YPAI Speech Data: Key Specifications
| Specification | Value |
|---|---|
| Verified EEA contributors | 20,000 |
| EU dialects covered | 50+ (demographic breakdowns documented per corpus) |
| Transcription IAA threshold | ≥ 0.80 Cohen’s kappa per batch |
| Data residency | EEA-only — no US sub-processors for raw audio |
| Synthetic data | None — 100% human-recorded |
| Consent standard | Explicit, purpose-specific, names AI training (GDPR Art. 6/9) |
| Erasure mechanism | Speaker-level IDs in all delivered datasets |
| Regulatory supervision | Datatilsynet (Norwegian data protection authority) |
| EU AI Act Article 10 docs | Available on request before contract signature |
Timeline and What to Do Now
Full Annex III high-risk obligations, including conformity assessments and CE marking for applicable systems, apply from August 2, 2027. That is the hard deadline.
But data governance cannot be retrofitted. Building a compliant training dataset takes planning, and documenting provenance after the fact is practically impossible. The organizations that begin in 2025 and 2026 will be positioned for compliance. Those that wait until 2027 will be scrambling.
Start by classifying your system against the Annex III categories. If you fall into any of the eight domains, audit your current training data against the four Article 10 standards. Identify the gaps. Then procurement becomes a specification problem, not a compliance emergency.
Related YPAI resources
- EU AI Act Article 10: Data Governance Checklist
- GDPR-compliant speech data collection in Europe - lawful basis, consent documentation, and vendor checklist for voice data under GDPR
- CTOs guide to sovereign AI architecture and costs - how AI Act compliance fits into the broader sovereign AI infrastructure decision
- EU AI Act compliant training data
- AI Act risk classification
- GDPR compliant speech data
- Consent framework
- Technical specifications
Sources:
