Article 10 Data Governance for HR Tech AI — EU AI Act
How Article 10 of the EU AI Act applies to HR technology: data governance, bias examination, Article 4a, provider and employer roles, dates and fines.
Providers of high-risk HR-technology AI must use quality data sets for training, validation and testing (Article 10).
HR technology is not a category in the Act. Systems in Annex III point 4 (employment and workers’ management), for example CV filters, are high-risk (Article 6(2)). An exception exists (Article 6(3)). The rules apply from 2 December 2027 (Article 113(c)(i)). Fines reach EUR 15 million or, for an undertaking, 3% of worldwide annual turnover, whichever is higher (Article 99(4)). Next step: record where each data set comes from and how you checked it for bias.
Article 10 has no HR-specific rule: the same data rules apply to every high-risk system
The Act sets no minimum data size, no quota and no list of protected groups. It sets quality criteria and governance practices.
Data governance practices
The practices must fit the intended purpose. They cover design choices, data collection and the origin of data, and for personal data the original purpose of collection. They cover data preparation, such as annotation, labelling, cleaning, updating, enrichment and aggregation. They also cover the assumptions about what the data measure and represent, and an assessment of the availability, quantity and suitability of the data sets (Article 10(2)(a) to (e)).
Bias examination and measures
The practices also cover the examination of biases likely to affect health and safety, harm fundamental rights or lead to prohibited discrimination. They include measures to detect, prevent and mitigate those biases, and the identification of data gaps that prevent compliance (Article 10(2)(f) to (h)).
Quality of the data sets
Data sets must be relevant, sufficiently representative and, to the best extent possible, free of errors and complete in view of the intended purpose. They need appropriate statistical properties, including, where applicable, as regards the persons or groups of persons in relation to whom the system is intended to be used (Article 10(3)).
The setting of use
Data sets must take into account, to the extent the intended purpose requires, the characteristics particular to the geographical, contextual, behavioural or functional setting of use (Article 10(4)).
Systems without model training
For high-risk systems that do not train AI models, Article 10(2) to (4) and Article 4a(1) apply only to the testing data sets (Article 10(6)).
HR technology can be high-risk through Annex III point 4
The Act has no category called HR technology. What counts is the use listed in Annex III point 4, “Employment, workers’ management and access to self-employment”.
Point 4(a): recruitment and selection
AI systems intended to be used for the recruitment or selection of natural persons, in particular to place targeted job advertisements, to analyse and filter job applications, and to evaluate candidates.
Point 4(b): work-related relationships
AI systems intended to be used to make decisions affecting terms of work-related relationships, the promotion or termination of work-related contractual relationships, to allocate tasks based on individual behaviour or personal traits or characteristics, or to monitor and evaluate the performance and behaviour of persons in such relationships.
An exception exists, and it never covers profiling
An Annex III system is not high-risk if it does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons, including by not materially influencing the outcome of decision making. The derogation applies only where any one of the four conditions in Article 6(3), points (a) to (d), is fulfilled. A system that performs profiling of natural persons is always high-risk. A provider that considers its system not high-risk must document the assessment before placing it on the market or putting it into service (Article 6(4)). The Commission was to provide guidelines with practical examples by 2 February 2026 (Article 6(5)).
The software developer is the provider, the employer using it is a deployer
The provider is the natural or legal person, public authority, agency or other body that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark (Article 3, point 3). Providers of high-risk systems must ensure that the systems comply with the requirements of Section 2, Articles 8 to 15 (Article 16(a)). A deployer is a natural or legal person, public authority, agency or other body using an AI system under its authority, except in the course of a personal non-professional activity (Article 3, point 4). An employer that uses an HR system is a deployer with the duties of Article 26. A deployer becomes a provider if it puts its name or trademark on a high-risk system already on the market, makes a substantial modification to it, or changes the intended purpose of a system so that it becomes high-risk (Article 25(1)).
Dates, older systems and what the Act excludes
The requirements for Annex III systems apply from 2 December 2027 (Article 113(c)(i)). A high-risk system placed on the market or put into service before that date is covered only if it is subject to significant changes in its design as from that date. In any case, providers and deployers of high-risk systems intended to be used by public authorities must take the necessary steps to comply by 2 August 2030 (Article 111(2)). The Act does not apply to areas outside the scope of Union law (Article 2(3)), to AI systems or AI models, including their output, specifically developed and put into service for the sole purpose of scientific research and development (Article 2(6)), or to research, testing or development before a system is placed on the market or put into service; testing in real-world conditions is not excluded (Article 2(8)). It does not apply to obligations of deployers who are natural persons using AI systems in the course of a purely personal non-professional activity (Article 2(10)). AI systems under free and open-source licences are outside it unless placed on the market or put into service as high-risk systems or as systems under Article 5 or 50 (Article 2(12)).
Article 4a allows special categories of data for bias detection, under conditions
Providers of high-risk systems may exceptionally process special categories of personal data to the extent strictly necessary for bias detection and correction under Article 10(2), points (f) and (g), if all conditions of Article 4a(1) are met, for example that other data, including synthetic or anonymised data, cannot achieve the aim. Deployers of high-risk systems may do so under Article 4a(2), on the same conditions and safeguards. Article 4a(2) does not create any obligation to conduct such bias detection and correction. The GDPR continues to apply alongside it (Article 2(7)).
Employers: input data they control
To the extent the deployer exercises control over the input data, it must ensure that the input data is relevant and sufficiently representative in view of the intended purpose of the high-risk system (Article 26(4)).
What the Act leaves open
No quota, no list of protected characteristics, no fairness metric
The Act sets no quota and no demographic-parity rule, and Article 10 lists no protected characteristics; it refers to discrimination prohibited under Union law (Article 10(2)(f)). Other provisions name sensitive traits for their own purposes (Article 5(1)(g), Annex III point 1(b)). The provider decides how to examine and measure bias for its intended purpose.
A presumption exists for Article 10(4)
High-risk systems that have been trained and tested on data reflecting the specific geographical, behavioural, contextual or functional setting within which they are intended to be used are presumed to comply with the relevant requirements of Article 10(4) (Article 42(1)).
The Act names no standard; harmonised standards and guidelines exist
The Act itself names no standard for data quality. It asks for the generally acknowledged state of the art to be taken into account (Article 8(1)). High-risk systems in conformity with harmonised standards whose references are published in the Official Journal are presumed to conform with the Section 2 requirements those standards cover (Article 40(1)). The Commission is to develop guidelines on the application of the requirements in Articles 8 to 15 (Article 96(1)(a)). Any other standard a provider uses is a voluntary design choice.
Example: data governance for a CV-screening tool
These are examples, not requirements.
Example: representativeness (Article 10(3))
The provider of a CV-screening tool checks whether its training, validation and testing data contain the applicant groups the tool is intended for, and records any gap (Article 10(2)(h)).
Example: feedback loops (Article 10(2)(f))
A ranking tool trained on past hiring decisions may repeat past patterns. The provider examines this, especially where the tool’s outputs influence the data it later learns from.
Common questions: quotas, special categories of data, dates and fines
Does Article 10 require a balanced or quota-based data set?
No. The Act sets no quota. Data sets must be relevant, sufficiently representative and, to the best extent possible, free of errors and complete in view of the intended purpose, with appropriate statistical properties, including, where applicable, as regards the persons or groups of persons for whom the system is intended (Article 10(3)). They must take into account, to the extent required by the intended purpose, the characteristics particular to the setting of use (Article 10(4)).
May I use special categories of personal data to test for bias?
Article 4a(1) allows providers of high-risk systems to process special categories of personal data exceptionally, in addition to the GDPR, to the extent strictly necessary for bias detection and correction and only if all of its conditions (a) to (f) are met. They include that other data, including synthetic or anonymised data, cannot achieve the aim, that the data are not transmitted to other parties, and that they are deleted once the bias is corrected or the retention period ends. Deployers of high-risk systems may do so under Article 4a(2). Article 4a(2) does not create any obligation to conduct such bias detection and correction.
When do the Article 10 rules apply to HR technology?
The requirements for Annex III systems apply from 2 December 2027 (Article 113(c)(i)). A high-risk system placed on the market or put into service before that date is covered only if it is subject to significant changes in its design as from that date. In any case, providers and deployers of high-risk systems intended to be used by public authorities must take the necessary steps to comply by 2 August 2030 (Article 111(2)).
What are the fines, and are they lower for small companies?
Article 16 sets the provider duties, which include compliance with the requirements of Articles 9 to 15. Breaches are fined up to EUR 15 million or, for an undertaking, 3% of worldwide annual turnover, whichever is higher (Article 99(4)). For SMEs, including start-ups, and small mid-cap enterprises (Article 3(14b)), each fine is up to the lower of the two amounts (Article 99(6) and (6a)). The turnover percentage applies if the offender is an undertaking (Article 99(4)). Each Member State lays down to what extent administrative fines may be imposed on public authorities and bodies established in that Member State (Article 99(8)).
Read next: the article for all sectors, the HR technology overview and related guides
Article 10: Data Governance for High-Risk AI
The article as the Act states it, for all sectors.
EU AI Act Compliance for HR Tech
How the Act reaches AI for recruitment, selection and workers’ management.
Article 9 Risk Management for HR Tech AI — EU AI Act
Risk management across the lifecycle for HR technology.
Article 13 Transparency for HR Tech AI — EU AI Act
Instructions for use for HR technology, and who informs candidates and workers.
Scanara prepares evidence from your repositories
Scanara reads your connected GitHub repositories and runs rule-based scans for standard AI and machine-learning patterns. It can miss non-standard code. Separately, it generates draft documentation from templates and your assessment answers as evidence for your compliance work. You make the classification decisions.