EU AI Act and Hiring: Classification, Deadlines, and Duties

Recruitment and candidate-evaluation AI is among the uses listed in Annex III of the AI Act. Classification depends on the particular system and intended purpose, including the Article 6 rules and limited exceptions. An ATS having an AI feature does not make every function of that product high-risk.

Start by identifying what each system does and the roles of the employer and provider. The relevant obligations have different scopes and application dates.

This article is general information, not legal advice. Talk to employment counsel and your data protection officer about your specific situation.

Your hiring AI is now “high-risk.” What that actually means

Under the EU AI Act, an AI system used “for the recruitment or selection of natural persons” is classified as high-risk. That includes tools that place targeted job ads, analyze and filter applications, and evaluate or rank candidates. The same Annex III category (point 4(b)) covers AI used for promotion, termination, task allocation, and performance monitoring once someone is hired.

The single biggest misconception is that high-risk means prohibited. It does not. The Act has three tiers: a small set of prohibited practices, a larger band of high-risk systems, and everything else. Recruitment AI sits in the high-risk band, which means it is legal to use, but only if it meets a requirements stack and you, the employer, take on use-side duties.

Only a narrow set of hiring-adjacent practices are outright banned, and they have been banned since 2 February 2025. The most relevant for HR is emotion recognition in the workplace, which the Act prohibits except for narrow medical or safety reasons. If a vendor sells you an interview tool that infers a candidate’s emotional state from their face or voice, that is not a high-risk system you can manage with controls. It is a prohibited practice, full stop.

So the practical question is not “can I use AI in hiring?” It is “can I prove my AI use meets the high-risk requirements?”

When the Rules Apply

Update, September 6, 2026: the AI Omnibus entered into force on July 27, 2026. Annex III high-risk obligations apply from December 2, 2027, replacing the original August 2, 2026 date. This is an adopted change, not a pending proposal. See the European Commission timeline update.

This deferral does not suspend GDPR, employment discrimination law, prohibited-practice rules already in application, or transparency requirements on their own schedules. Check the relevant requirement rather than treating December 2027 as the only date that matters.

Are you the provider or the deployer?

The EU AI Act splits responsibility between two roles, and knowing which one you are is the first thing to settle. If you hire, you are almost certainly the deployer.

The provider is the entity that develops the AI system or has it developed and places it on the market under its own name. For hiring, that is your ATS vendor or the maker of your AI screening tool. Providers carry the heavy compliance burden: conformity assessment, CE marking, technical documentation, and registration in the EU database.

The deployer is the entity that uses the system under its own authority, in the course of its professional activity. That is you, the employer. Your obligations are different but very real, and they live in Article 26.

There is one trap worth naming. A deployer can become a provider, inheriting the full provider burden, if it substantially modifies a high-risk system or uses it for a purpose the provider did not intend. Fine-tune a screening model on your own data, or wire a general-purpose AI into an auto-reject workflow it was never sold for, and you may have promoted yourself into the role with the bigger obligations. Buy tools built for the job rather than improvising one.

The obligations every EU-touching hiring team must meet

Article 26 and the surrounding requirements translate into a concrete checklist. Think of these as product requirements you can hold a vendor to, not abstract legal principles.

Effective Human Oversight

Article 14 requires high-risk systems to be designed so humans can effectively oversee them, and Article 26(2) requires deployers to assign oversight to natural persons who are competent, trained, and empowered to do it. In hiring terms: a person must be able to understand the AI’s output, interpret it correctly, decide not to use it, and override it.

The pattern this targets is the auto-reject pipeline that discards résumés before any human looks. If your tool screens out candidates and nobody with authority reviews or can reverse those decisions, you do not have human oversight. You have a black box with a rubber stamp.

Bias testing and data governance

Article 10 requires that training, validation, and testing data be relevant, representative, and examined for bias. For recruitment, this is the heart of the discrimination risk. A model trained on a decade of historically skewed hiring data will reproduce that skew at scale. You should be able to ask a vendor how their system was tested for disparate impact and get a real answer.

Automatic event logging

Article 12 requires high-risk systems to technically allow the automatic recording of events (logs) across the system’s lifetime, sufficient to identify risk situations and support post-market monitoring. This is a design requirement on the system itself. If a tool cannot produce a record of what it did and why, it cannot meet Article 12.

Six-month log retention

Article 26(6) puts the retention duty on you: deployers must keep the automatically generated logs for at least six months, unless applicable Union or national law provides otherwise. This concerns logs under the deployer’s control, not indefinite retention of every recruitment document. Six months is a floor, not a ceiling. The practical test is whether, half a year after a hiring decision, you can pull up the record of how it was made.

Candidate and worker transparency

Two duties apply. Article 26(7) requires employers to inform workers’ representatives and affected workers before deployment of a high-risk system in the workplace. Article 26(11) requires informing individuals who are subject to the system’s decisions. Article 50 adds transparency duties about AI interaction more broadly. In short: candidates and staff have a right to know AI is in the loop.

Right to explanation for rejected candidates

This is the one that surprises people. Article 86 gives any affected person subject to a decision made on the basis of a high-risk system’s output, where it produces legal or similarly significant effects, the right to “clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision taken.” A rejected candidate can ask how the AI factored into their rejection, and you have to be able to answer. “The algorithm said no” is not an answer.

DPIA and the GDPR overlap

The AI Act does not replace GDPR. It stacks on top. Automated decisions with significant effects already engage GDPR Article 22, and high-risk processing typically requires a Data Protection Impact Assessment. If you already run DPIAs for candidate data, extend them to cover the AI system. If you do not, that gap predates the AI Act and is worth closing now.

What the fines really are, and the EUR 35M hiring myth

The most common error in coverage of the AI Act is the fine figure. You will see “up to EUR 35 million or 7% of turnover” attached to hiring. For ordinary high-risk recruitment breaches, that is wrong.

Article 99 sets tiered penalties:

In each case the regulator takes whichever amount is higher. The EUR 35M / 7% tier is reserved for the prohibited practices, not for failing to keep your logs or skipping a candidate notice. The relevant exposure for non-compliant high-risk hiring is EUR 15 million or 3%.

There is relief built in for smaller companies. Article 99 caps SMEs and startups at the lower of the percentage or the fixed sum, rather than the higher. The exposure is real, but it scales with your size rather than wiping out a seed-stage company over a paperwork miss.

The legacy ATS problem: auto-screeners that reject before a human looks

The archetypal high-risk-without-the-controls scenario is the legacy ATS that auto-rejects on keyword matches or knockout questions before a human sees the candidate. It combines three things the Act targets at once: an automated decision, no human oversight, and no explanation.

This is not hypothetical. The same design pattern is at the center of US litigation. In Mobley v. Workday, a federal court allowed discrimination claims to proceed against an AI hiring vendor as an “agent” of the employers using it, over exactly this kind of automated screen. The EU AI Act and US courts are converging on the same conclusion from different directions: opaque, human-free auto-rejection is the risk, not AI in hiring as such. (We covered the US side in what the Workday AI hiring lawsuit means for every ATS.)

If your current tool cannot tell you which candidates it auto-rejected, why, and who could have overridden it, you are running the fact pattern both the EU regulator and US plaintiffs’ lawyers are looking for.

EU AI Act vs NYC Local Law 144

US teams often ask how this compares to the rule they already know. New York City’s Local Law 144 has required, since 2023, annual independent bias audits of automated employment decision tools, plus candidate notice. It is a useful reference point, but the EU regime is far broader.

Local Law 144 is a bias-audit law. The EU AI Act is a whole-lifecycle governance regime with penalties two orders of magnitude larger. If you built your process around Local Law 144, treat it as a starting point, not a finish line.

Your EU AI Act hiring compliance checklist

Here is what an EU-touching hiring team should be able to do and prove. Copy it, hand it to your vendor, and check off what your current stack already covers.

1. Confirm your role. You are almost certainly the deployer. Do not accidentally become a provider by heavily modifying a tool or using it outside its intended purpose.
2. Map your AI. List every tool that screens, ranks, scores, or evaluates candidates. Each one is presumptively high-risk.
3. Establish effective oversight. Assign competent, trained, empowered people who can interpret, challenge, and intervene in the system. Separately assess whether automated decisions are permissible under GDPR Article 22.
4. Verify bias testing. Ask each vendor how their system was tested for disparate impact, and get it in writing (Art. 10).
5. Confirm event logging. The system must automatically record what it did per decision (Art. 12).
6. Retain logs at least six months. Account for applicable Union or national law and logs under your control (Art. 26(6)).
7. Notify workers and candidates. Inform worker representatives before deployment and individuals subject to decisions (Art. 26(7), (11), Art. 50).
8. Be ready to explain. For any rejected candidate, you must be able to produce a clear, meaningful account of how the AI factored in (Art. 86).
9. Run a DPIA. Cover the AI system in your data protection impact assessment and your GDPR Article 22 analysis.
10. Calendar the date. Plan for the high-risk obligations to bite on 2 December 2027, with prohibited-practice bans already in force since February 2025.

What to Check in Kit

Kit stores evaluation criteria, reviews, rejection reasons, and stage history. These records can help reconstruct a hiring process, but they are not by themselves evidence of conformity with Articles 12 or 86.

Check automated actions. Stage conditions and voting can trigger transitions, and authorized AI tools can perform operations on applications. An action attributed to a user account does not prove a person independently reviewed each case. Kit does not guarantee a separate manual approval before every state change.

Establish retention rules. Database records are not immutable archives, and data deletion, permissions, and export scope matter. Do not infer a guaranteed six-month retention period merely from a visible timeline.

Your organisation must establish its deployment policies, oversight, notices, and required assessments. Using Kit is not an AI Act conformity certificate.

Start a free trial to inspect a sample application, or read how Kit represents hiring stages.