Is hiring and employment AI high-risk under the EU AI Act?

Annex III Employment Category Explained

The EU AI Act creates a risk-based classification system. Annex III exhaustively lists high-risk use cases requiring full compliance with Articles 8-15. Employment is Category 4:

The language is deliberately broad. The regulation doesn’t just cover final hiring decisions. It covers any AI system involved in the employment lifecycle from job advertisement through termination.

Full Scope of Covered Employment AI

Many organizations underestimate the breadth of employment AI subject to high-risk requirements. The following systems are explicitly covered:

Recruitment and Hiring

Workforce Management

Key Determining Factors

Not every HR software tool is automatically high-risk. The classification depends on whether the AI system:

1. Makes or materially influences employment decisions: filtering candidates, scoring performance, recommending actions
2. Processes personal data to evaluate individuals: analyzing behavior, traits, or characteristics
3. Affects employment relationship terms: compensation, scheduling, task assignment, contractual status

Examples that ARE high-risk:

• AI resume screener that auto-rejects 80% of applications
• Video interview platform that scores candidates on communication skills
• Performance analytics dashboard that identifies “underperformers”
• Algorithmic scheduling that assigns shifts based on predicted efficiency

Examples that may NOT be high-risk:

• Simple keyword search in job boards (no ranking/filtering of candidates)
• Calendar scheduling tool (no performance-based allocation)
• Expense reporting automation (not evaluating individual behavior)

When uncertain, classify conservatively. Regulators may disagree with narrow interpretations, and the penalty asymmetry favors over-compliance.

The hiring funnel, stage by stage

Employers ask whether the EU AI Act applies to hiring and get a yes, which is accurate and not very actionable, because a recruitment process is six or seven distinct systems rather than one. The table below walks a standard funnel and marks what actually attaches at each stage. Two stages that many teams assume are safe are not.

The derogation is the part worth reading carefully. Article 6(3) lets a system named in Annex III escape high-risk treatment where it performs a narrow procedural task, improves the result of a previously completed human activity, or does only preparatory work, and does not pose a significant risk of harm. Employers reach for it often. It rarely holds in recruitment, because the same provision states that a system always counts as high-risk where it performs profiling of natural persons. Scoring, ranking, or matching candidates is profiling. A CV parser that only extracts fields into a form may genuinely qualify. The moment it orders candidates, it does not.

Two practical consequences follow. Sourcing is in scope, so an organization that has audited its screening tool and left its advertising platform unexamined has assessed the second half of its exposure and not the first. And a funnel assembled from four vendors is four separate provider relationships, each owing documentation, with the employer sitting as deployer across all of them and carrying the duties in the next section for each.

What an employer owes candidates and workers: Articles 26 and 86

Most coverage of high-risk employment AI concentrates on Articles 9 to 15, which bind the provider that builds the system. An employer buying a hiring tool is usually a deployer, and the deployer obligations sit elsewhere in the Regulation. Two are routinely missed, and both are owed directly to people rather than to a regulator.

Article 26(7): tell the workforce before you switch it on

Before putting a high-risk AI system into service at the workplace, a deployer who is an employer must inform workers’ representatives and the affected workers that they will be subject to it. The obligation runs ahead of deployment rather than alongside it, and it is independent of whether any works council or co-determination process applies under national law. Those processes add to the obligation, as the German and French sections below describe. They do not substitute for it.

The other Article 26 duties frame the same relationship. Deployers must use the system in accordance with the provider’s instructions for use, assign human oversight to people with the competence, training and authority to exercise it, monitor operation and inform the provider of risks or serious incidents, and keep the logs the system generates for a period appropriate to its purpose and in any event at least six months. That last duty is why the Article 12 logging discussed below is a deployer problem as well as a provider one: the employer has to hold the records, not merely rely on the vendor holding them.

Article 86: the rejected candidate can ask why

Article 86 can give an affected person a right to a clear and meaningful explanation where a deployer’s decision is taken on the basis of an Annex III high-risk system’s output (other than point 2), produces legal effects or similarly significantly affects the person, and is considered by that person to adversely affect health, safety or fundamental rights. Employment systems can fall within that rule, but not every interaction or recommendation automatically does.

Read plainly, that means a rejected candidate can write to the employer and ask what part the AI played in rejecting them, and the employer owes an answer. Not the vendor. The employer. Three things follow that are worth deciding before the first request arrives rather than after.

• The answer has to be specific to that person’s application. A description of how the tool works in general is not an explanation of the role it played in this decision.
• The employer needs enough evidence to determine whether the statutory trigger is met and, if so, explain the AI system’s role and the main elements of the decision. A per-candidate record may be a useful design choice, but Article 12 does not prescribe one universal employment record.
• The obligation cannot be contracted away to the vendor. It can be contractually supported, and a procurement process that does not ask how the vendor will supply the underlying detail leaves the employer answering alone.

The uncomfortable case is the one where a candidate asks and the employer cannot reconstruct what happened. The tool ran months ago, the model has been updated since, the logs rolled off, and nobody recorded which version scored this application or what it returned. That is not a documentation failure discovered at audit; it is a failure discovered in correspondence with a person who has a statutory right to an answer, and it is the practical reason Article 12 logging matters more in employment than in most other high-risk domains.

High-Risk Compliance Requirements (Articles 9-15)

Employment AI systems must satisfy the full suite of high-risk requirements. The EU AI Act mandates seven categories of obligations:

Article 12 Logging: What the Text Requires

Article 12 requires high-risk AI systems to technically allow automatic recording of events over the system lifecycle. The logging must support traceability appropriate to the intended purpose and record events relevant to specified risk, post-market-monitoring, and deployer-monitoring functions. Read the current consolidated regulation and assess the system in context.

“High-risk AI systems shall technically allow for the automatic recording of events (’logs’) over the lifetime of the system... ensuring a level of traceability of the AI system’s functioning throughout its lifecycle that is appropriate to the intended purpose of the system.” Source: EU AI Act, Article 12(1)

For employment AI, teams may decide that useful operational records include the following. These are design examples, not a verbatim Article 12 field list:

• Covered candidate evaluations: The configured stage, relevant input references, scoring or policy version, and reported recommendation
• Covered adverse outcomes: The stage, reported outcome, stated reason fields, and applicable human-review path
• Performance assessments: Data points analyzed, weighting applied, and conclusions reached
• Termination recommendations: The covered inputs, reported recommendation, model or policy version, and stated scope
• Human override events: When humans deviated from AI recommendations and why

Article 12 itself does not say that every log must be cryptographically tamper-evident. Providers and deployers have separate retention duties for automatically generated logs under their control, generally for at least six months unless other applicable law provides otherwise. Employment, privacy, and limitation-period rules may require different retention, so set the schedule with counsel.

Fairness, Bias, and Discrimination Requirements

The EU AI Act places extraordinary emphasis on preventing discrimination in employment AI. Article 10 requires:

For employment AI, this intersects with existing anti-discrimination frameworks:

• EU Employment Equality Directive (2000/78/EC): Prohibits discrimination based on religion, disability, age, or sexual orientation
• EU Racial Equality Directive (2000/43/EC): Prohibits discrimination based on racial or ethnic origin
• Gender Equality Directive (2006/54/EC): Prohibits discrimination based on sex
• GDPR Article 22: Right not to be subject to automated decisions with legal effects

Organizations must demonstrate they’ve tested for bias across protected characteristics and implemented mitigation measures. This requires:

1. Demographic analysis of training data representation
2. Disparate impact testing across protected groups
3. Ongoing monitoring for bias drift in production
4. Documentation of bias findings and remediation steps

Interaction with Employment Law

The EU AI Act doesn’t exist in isolation. Employment AI must also satisfy national employment laws, which often impose additional requirements:

Germany: Works Council Co-Determination

Under the Betriebsverfassungsgesetz (Works Constitution Act), works councils have mandatory co-determination rights over:

• Technical devices designed to monitor employee behavior or performance (§87(1)(6))
• Introduction and application of technical devices for data collection (§94)
• Selection guidelines for recruitment and termination (§95)

Deploying employment AI without works council consultation can result in injunctions, even if the system itself is EU AI Act compliant.

France: CNIL and Labor Code

The CNIL (data protection authority) has issued specific guidance on AI-assisted recruitment. The Labor Code requires informing employees of surveillance methods and consulting comités sociaux et économiques (CSE).

Netherlands: Employee Consent

Dutch data protection authority guidelines require explicit consent for AI-based profiling in employment contexts, beyond GDPR’s legitimate interest basis.

US Regulatory Comparison

While the EU AI Act represents the most comprehensive framework, US employers face a growing patchwork of employment AI regulations:

US multinational companies must increasingly manage compliance across both EU AI Act requirements and this fragmented US landscape.

Evidence Requirements for Regulators

When regulators or litigants ask about employment AI, policies, assessments, notices, testing, decision records, and operational evidence may answer different parts of the inquiry. A signed control record can support integrity review for covered fields; it does not by itself prove that the control worked or that the system complied.

Regulators may request:

1. Technical documentation per Annex IV: system architecture, training data details, validation results
2. Risk assessment records: identified risks, probability/severity estimates, mitigation measures
3. Bias audit results: disparate impact analysis across protected groups, remediation evidence
4. Decision logs: purpose-appropriate records for in-scope candidate or employee decisions, with known coverage gaps documented
5. Human oversight records: evidence that humans reviewed and could override AI decisions
6. Incident reports: any serious incidents reported per Article 73

The distinction between policy documentation and operational evidence is critical. A policy stating “humans review all AI recommendations” does not establish that review occurred. Assess authenticated reviewer actions, source and timing evidence, workflow coverage, and relevant exceptions together.

Implementation Checklist

Frequently Asked Questions

References