Yes, AI that screens, ranks, or evaluates job candidates is "high-risk" under the EU AI Act. Annex III, point 4(a) names recruitment and selection systems explicitly, which triggers a stack of legal obligations: human oversight, bias-tested data, candidate transparency, automatic event logging, and a minimum six-month log retention. High-risk does not mean banned. It means permitted but heavily regulated, and if you hire EU candidates, you are largely the party on the hook. Breaches can cost up to EUR 15 million or 3% of global turnover, whichever is higher.

This guide cuts through the noise around dates and fines, both of which are widely misreported. It explains what the law actually requires, who carries the liability, what the real deadline is after the EU moved it, and what defensible hiring infrastructure looks like in practice.

> 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 does it apply? The August 2026 deadline that moved

The original deadline for high-risk obligations on standalone Annex III systems, including recruitment, was **2 August 2026**. That date is now wrong, and most articles citing it have not caught up.

On 19 November 2025, the European Commission published the **"Digital Omnibus on AI,"** which proposed deferring the high-risk compliance deadline for Annex III systems from 2 August 2026 to **2 December 2027**. The European Parliament's IMCO and LIBE committees supported the postponement in March 2026, and Parliament and Council reached a provisional political agreement on the package in May 2026.

As of mid-2026 the deferral is provisional. It is agreed in principle but not yet formally adopted and published in the Official Journal, with adoption expected ahead of the original August 2026 date. So the honest answer to "when does it apply?" has three parts:

- **2 February 2025:** prohibited practices (including workplace emotion recognition) are already in force. This is not the future. It is the past.
- **Largely on the original schedule:** the AI literacy obligation (Article 4) and certain transparency duties (Article 50) are not part of the high-risk deferral.
- **2 December 2027 (pending final adoption):** the full high-risk obligation stack for recruitment systems, the part everyone calls "the deadline."

Treat the extra time as a gift to build it right, not a reason to ignore it. The EU delayed its own flagship deadline partly because the technical standards were not ready, which tells you how much there is to get in order. Teams that wait until late 2027 to start will be retrofitting oversight and logging onto tools that were never designed for it.

## 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.

### Human oversight: no fully automated rejections

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 other law (such as GDPR) requires longer. 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.

<div class="blog-inline-cta">
  <p><strong>Want a hiring stack where these controls are default-on?</strong> Kit records an attributed, timestamped decision for every advance and rejection, keeps that history as durable data, and keeps a human in the loop on every state change.</p>
  <p><a href="/users/sign_up">Start your free trial</a></p>
</div>

## 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:

| Violation type | Maximum fine |
|---|---|
| Prohibited practices (e.g. workplace emotion recognition) | EUR 35M or 7% of global turnover |
| **High-risk obligation breaches (the hiring tier)** | **EUR 15M or 3% of global turnover** |
| Supplying incorrect or misleading information | EUR 7.5M or 1% of global turnover |

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](/blog/workday-ai-hiring-lawsuit-ats-liability).)

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.

| Dimension | NYC Local Law 144 | EU AI Act |
|---|---|---|
| Core duty | Annual independent bias audit + candidate notice | Full lifecycle: oversight, data governance, logging, transparency, explanation |
| Scope | Automated employment decision tools | All high-risk recruitment and selection AI |
| Explanation right | Notice that a tool is used | Right to a meaningful explanation of the decision (Art. 86) |
| Retention | Audit results published | Logs retained at least six months (Art. 26(6)) |
| Maximum penalty | Up to USD 1,500 per violation | EUR 15M or 3% of global turnover |

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. **Kill fully automated rejections.** Ensure a competent, trained, empowered human reviews and can override every reject-or-advance decision (Art. 14, 26(2)).
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.** Longer if GDPR or other law requires (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** (pending final adoption), with prohibited-practice bans already in force since February 2025.

## What compliant hiring infrastructure looks like, with Kit as the worked example

The cleanest way to meet these obligations is to use a hiring system where they are byproducts of normal use rather than features you bolt on. The right posture is simple to state: AI assists, humans decide, and the system records. [Kit](/) is built around exactly that division of labor.

**Human oversight is structural, not optional.** Every state-changing action on an application requires a human actor. Rejecting, advancing, deciding a review, and extending an offer are all attributed to a person. Even Kit's AI tools cannot rule a candidate out on their own; the AI rejection path requires a logged-in user, an authorization check, and explicit confirmation. There is no code path where AI silently rejects a candidate, which is the difference Articles 14 and 26(2) are looking for.

**The audit trail is automatic.** Kit models the pipeline as attributed stage-progress records, each paired with a decision that requires a written rationale and records who made it. The candidate timeline renders this as a human-readable event history. That is the "automatic recording of events over the lifetime" of Article 12, produced as a side effect of hiring rather than a separate logging project.

**Retention is the default, not a chore.** Because decisions and stage history are first-class database records rather than ephemeral logs that roll off, they persist well past the six-month floor in Article 26(6). The burden flips from "how do I keep logs for six months" to "I already have the full, queryable history."

**Provenance and explanation are built in.** Kit tags whether a signal came from AI or a human, so the system knows and can disclose which inputs were AI-derived, supporting the transparency duties in Articles 26(11) and 50. And because every decision carries an attributed actor plus a rationale, and reviews carry scores against named criteria, Kit can produce the "clear and meaningful explanation" Article 86 grants rejected candidates.

To be clear about scope: using Kit does not make you automatically compliant. You still own your DPIA, your worker notices, and the competence of the humans doing oversight. What Kit does is make the hard, easy-to-skip parts default-on, so the records and controls the AI Act expects already exist when a regulator, a candidate, or your board asks.

The EU AI Act did not make AI hiring illegal. It made undocumented, human-free AI hiring a liability. The teams that come out ahead are not the ones that rip AI out of recruiting. They are the ones that can show their work: who decided, on what basis, with what record. Build that now, while the deadline gives you room, rather than retrofitting it under pressure in late 2027.

Want to see what a defensible, human-in-the-loop hiring pipeline looks like? [Start a free trial](/users/sign_up) or read [what an AI-native ATS actually is](/blog/pipelines-as-code-hiring).