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 — and 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 add to it, 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 gives any person affected by a decision taken on the basis of the output of an Annex III high-risk system — with the sole exception of point 2, critical infrastructure — the right to obtain from the deployer a clear and meaningful explanation of the role the AI system played in the decision and the main elements of the decision taken. Employment is point 4, so it is squarely covered.

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 to know whether the system actually influenced the outcome, which requires a per-candidate record rather than a system-level description. If a human reviewer made the call after seeing an AI score, the score influenced the decision and the explanation has to say so.
• 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: The GLACIS Connection

Article 12 is where employment AI compliance becomes operationally complex—and where GLACIS provides critical value. The regulation requires:

"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." — EU AI Act, Article 12(1)

For employment AI, this means logging:

• Every candidate evaluation: Input data (resume, video, assessment responses), scoring criteria applied, and resulting recommendation
• Every rejection decision: Which candidates were filtered out, at which stage, and why
• Performance assessments: Data points analyzed, weighting applied, and conclusions reached
• Termination recommendations: Complete audit trail from input data to recommendation
• Human override events: When humans deviated from AI recommendations and why

Logs must be tamper-evident and retained appropriately. In employment contexts, this often means years—discrimination claims can be filed long after the decision occurred.

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—come asking questions about your employment AI, you’ll need evidence that your controls actually work. Documentation alone isn’t sufficient.

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—complete audit trails for specific candidates or employees
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 execution evidence is critical. A policy stating "humans review all AI recommendations" means nothing without logs proving that review actually occurred.

Implementation Checklist

Frequently Asked Questions

References