Home / Compliance / EU AI Act
Compliance guide

The EU AI Act and hiring

If you use AI to screen, filter or evaluate candidates, you are operating a high-risk AI system under Annex III. Here is what that actually obliges you to do — and what it doesn't.

Regulation (EU) 2024/1689 ~12 min read

The EU AI Act is the first horizontal AI regulation anywhere, and recruitment sits close to the centre of it. Not as an afterthought or an edge case — hiring is named explicitly in the annex that defines high-risk systems, alongside things like critical infrastructure and access to education.

That is worth sitting with. The regulation's authors looked at the full landscape of AI applications and decided that software deciding who gets an interview belongs in the same tier of scrutiny as software running a power grid. Everything below follows from that judgement.

Why hiring AI is high-risk

Annex III, point 4 covers AI systems used in employment, worker management and access to self-employment. Within that, the recruitment-facing part catches systems used to place targeted job advertisements, to analyse and filter applications, and to evaluate candidates. If your tool ranks, scores, shortlists or screens applicants, you are inside point 4.

Being high-risk is not a prohibition. Prohibited practices live in Art 5 and are a different, shorter list. High-risk means permitted, subject to conditions — and the conditions are the substance of the regulation: risk management, data governance, documentation, logging, transparency, human oversight, accuracy.

One nuance worth knowing

Art 6(3) provides a narrow escape: an Annex III system may fall outside high-risk if it performs only a narrow procedural task, improves a prior human activity, or does not materially influence the outcome. A system that grades candidates is not a plausible candidate for that carve-out, and Art 6(3) explicitly excludes anything that profiles natural persons. Assume you are in scope.

The timeline — and what just changed

The AI Act applies in stages rather than all at once. The staging is the single most misunderstood part of the regulation, and as of mid-2026 it has just been rewritten.

  • 1 August 2024
    Entry into force

    The regulation is law. Almost none of it applies yet — the obligations switch on later.

  • 2 February 2025
    Prohibitions and AI literacy

    Art 5 prohibited practices bite. Art 4 requires that staff dealing with AI systems have a sufficient level of AI literacy — this one already applies to you.

  • 2 August 2025
    General-purpose AI model rules

    Obligations on GPAI model providers, plus governance and penalties provisions.

  • 2 December 2027 — moved from 2 August 2026
    Annex III high-risk obligations — including hiring

    The Digital Omnibus deferred the standalone Annex III high-risk regime by 16 months. Parliament endorsed it on 16 June 2026; the Council gave final approval on 29 June 2026. Notably, the originally proposed conditional trigger — obligations starting when harmonised standards were ready — was replaced with fixed dates.

  • 2 August 2028 — moved from 2 August 2027
    Annex I embedded systems

    AI embedded in products already covered by EU product-safety law.

A deferral is not a reprieve

It is tempting to read December 2027 as permission to stop thinking about this until 2027. That reading has two problems.

First, the AI Act is not the only regulation in the room. The GDPR applies now, it has applied since 2018, and for automated candidate screening it is in several respects the stricter instrument — see below. Nothing about the Omnibus touches it.

Second, the duties being deferred are architectural: logging, explainability, data governance, documented human oversight. They are not a compliance sprint you can run in the last quarter. A system that wasn't built to log its decisions cannot be made to have logged them retroactively.

Provider or deployer?

The AI Act splits duties between two roles, and almost every practical question turns on which one you are.

Provider
Develops the system, or has it developed, and places it on the market or puts it into service under its own name or trademark. A vendor selling assessment software is the provider. The heavy engineering duties — Arts 9 to 15, plus documentation and conformity assessment — sit here.
Deployer
Uses the system under its own authority. The employer running the assessment is the deployer. The duties are fewer but real, and they cannot be contracted away to the vendor.
You can become the provider without meaning to

Art 25 flips a deployer into a provider — inheriting the full provider obligation set — if you put your own name or trademark on the system, make a substantial modification to it, or modify its intended purpose. White-labelling an assessment tool under your employer brand is exactly the fact pattern Art 25 describes. Check this before you rebrand a vendor's product.

What the provider must build

This is the vendor's homework, not yours — but you should know what to ask for, because the deployer duties in the next section are impossible to discharge if the provider hasn't done these.

ArticleRequirementWhat it means in a hiring context
Art 9 Risk management A continuous, iterative process across the whole lifecycle — not a one-off sign-off. Must consider reasonably foreseeable misuse, not just intended use.
Art 10 Data governance Training, validation and test data must be relevant, sufficiently representative and, as far as possible, error-free. Requires explicit examination for biases that could lead to discrimination.
Art 11 + Annex IV Technical documentation Drawn up before the system goes to market and kept current. Annex IV sets the minimum contents.
Art 12 Automatic logging The system must technically enable automatic recording of events over its lifetime, sufficient for traceability.
Art 13 Transparency & instructions for use Instructions must state accuracy levels and metrics, known limitations, performance regarding specific groups, and how to interpret the output.
Art 14 Human oversight by design Must be buildable into the workflow — including the ability to disregard, override or reverse the output, and to stop the system.
Art 15 Accuracy, robustness, cybersecurity Declared accuracy metrics. Systems that keep learning post-deployment must mitigate biased-output feedback loops.
Art 43(2) Conformity assessment For Annex III points 2–8 — which includes hiring — this is internal control under Annex VI. No notified body is involved.
Read Art 43(2) carefully before you rely on a CE mark

Hiring AI is self-assessed. There is no independent auditor in the loop, no notified body number on the declaration. A vendor's CE marking for an employment system attests that the vendor concluded it complies. That is not nothing — it is a legal statement with penalties attached — but it is not third-party verification, and you should not present it internally as though it were.

The bias-testing paradox, and the Act's answer to it

There is a genuine tension at the heart of fairness testing: to prove your system doesn't discriminate on race or ethnicity, you need data about race and ethnicity — which is precisely the special-category data Art 9 GDPR restricts. Testing for bias requires collecting what you are told to minimise.

Art 10(5) addresses this directly, permitting processing of special categories where strictly necessary for bias detection and correction — but it is a narrow gate with six cumulative conditions: no other data (including synthetic or anonymised) would work; state-of-the-art security and pseudonymisation; strict documented access control; the data must not be transmitted or otherwise accessed by other parties; deletion once the bias is corrected; and records justifying why it was strictly necessary. Miss one and the derogation doesn't apply.

What you must do as an employer

Art 26 is the deployer's list. It is short. It is also where most of the practical exposure sits, because these are the duties no vendor can perform for you.

ArticleYour obligation
Art 26(1)Use the system in accordance with the instructions for use. Deviating from documented intended use is itself a breach — and may trigger Art 25.
Art 26(2)Assign human oversight to natural persons with the necessary competence, training and authority — and give them support. A reviewer without authority to overturn the output does not satisfy this.
Art 26(4)Ensure input data is relevant and sufficiently representative, to the extent you control it.
Art 26(5)Monitor operation; inform the provider and market surveillance authority and suspend use where a risk arises.
Art 26(6)Keep the logs for at least six months, where they are under your control.
Art 26(7)Before putting a high-risk system into use at the workplace, inform workers' representatives and the affected workers that they will be subject to it.
Art 26(9)Use the Art 13 information to carry out your GDPR Art 35 DPIA.
Art 26(11)Inform natural persons that they are subject to the system's use when it informs decisions about them.
Six months is a floor, not a target

Art 26(6)'s six-month log retention is the AI Act's minimum. It is likely the wrong number for a hiring decision: discrimination claims have limitation periods measured in years, not months, and a log you deleted at month seven is a log you cannot produce at month eighteen when a claim lands. Set your retention against your litigation exposure, then check that number against GDPR minimisation — the two pull in opposite directions and the resolution is a documented, defensible decision rather than a default. More on retention here.

The candidate's right to an explanation

Art 86 gives any affected person subject to a decision taken on the basis of a high-risk Annex III system's output — where that decision produces legal effects or similarly significantly affects them adversely — the right to obtain from the deployer "clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision taken."

Read that carefully: the duty falls on you, the employer, not on your vendor. Only Annex III point 2 is carved out, and hiring is point 4 — squarely in scope. If a rejected candidate asks why, "the system scored you a C" is not an explanation of the role of the system or the main elements of the decision. You need to be able to answer, which means your vendor needs to have made answering possible.

What is not required of you

Compliance content has a strong incentive to imply that everything applies to everyone. Two widely-cited obligations probably do not apply to a private employer, and knowing that saves real money.

You almost certainly do not need a FRIA

The Fundamental Rights Impact Assessment (Art 27) is frequently described as a duty attached to high-risk deployment. It isn't. The trigger is the deployer's public character, not the Annex III category: Art 27(1) reaches bodies governed by public law, private entities providing public services, and deployers of Annex III points 5(b) and 5(c) — credit scoring and life/health insurance pricing. Employment (point 4) is not on that list.

A purely private-sector employer deploying a hiring tool has no Art 27 FRIA obligation. Your real obligation in that space is the GDPR Art 35 DPIA, which Art 26(9) points you at directly. Two caveats: if you provide public services (Recital 96 names education, healthcare, social services, housing, administration of justice), you may be caught; and where a FRIA is required, Art 27(4) lets it complement an existing DPIA rather than duplicate it.

You do not register in the EU database

Art 49(3) requires registration by deployers that are public authorities, Union bodies, or persons acting on their behalf. A private employer-deployer has no registration duty. Your provider registers itself and the system under Art 49(1); that entry is publicly accessible under Art 71(4) — which makes the EU database a genuinely useful due-diligence tool when evaluating a vendor.

Where GDPR bites harder

Art 2(7) of the AI Act is explicit that it does not affect the GDPR. The two regimes are cumulative. For automated candidate screening, the GDPR is in several respects the sharper instrument — and it is in force today, whatever the Omnibus does to the AI Act's dates.

Art 22 GDPR gives a data subject the right not to be subject to a decision based solely on automated processing which produces legal effects or similarly significantly affects them. Rejecting a job application qualifies. The exceptions are narrow: contract necessity, Union/Member State law, or explicit consent — and consent is notoriously fragile in an employment context because of the imbalance of power between employer and applicant.

SCHUFA (C-634/21) — why the score itself can be the decision

The CJEU held that a credit agency's automated production of a probability value is itself automated decision-making under Art 22(1) where a third party draws strongly on that value to decide whether to enter a contractual relationship.

Read across to hiring, that is a significant holding: if an employer leans heavily on a vendor's candidate score, the score can be the Art 22 decision — which puts the scoring vendor, not only the employer, inside the frame. It also means a human who merely rubber-stamps the model's output does not rescue you. "Not solely automated" requires meaningful human involvement, by someone with the authority and the information to reach a different conclusion.

And on explanations, Dun & Bradstreet Austria (C-203/22) is the one to know: "meaningful information about the logic involved" under Art 15(1)(h) requires explaining the procedure and principles actually applied, such that the data subject can exercise their Art 22(3) rights. A complex mathematical formula does not suffice, and neither does a step-by-step description of the algorithm. Trade secrecy is not a blanket exemption — the controller may have to disclose to the authority or court for a case-by-case balancing.

Our fuller GDPR guide covers legal basis, DPIAs, retention and candidate rights.

Penalties

€35M / 7%
Art 99(3) — breach of the Art 5 prohibitions. Whichever is higher.
€15M / 3%
Art 99(4) — including deployer breaches of Art 26. This is the tier that applies to an employer.
€7.5M / 1%
Art 99(5) — supplying incorrect, incomplete or misleading information to authorities or notified bodies.

Percentages are of total worldwide annual turnover for the preceding financial year. One useful asymmetry: under Art 99(6), for SMEs and start-ups the fine is capped at whichever of the percentage or the fixed amount is lower — the reverse of the general rule.

Where HireBeep fits

HireBeep is the provider; you are the deployer. Our side of that split is to make your side dischargeable — which is the whole reason the platform was built around compliance rather than having it added afterwards.

  • Transparency by default — every grade carries a plain-language rationale, so the Art 86 explanation you owe a candidate is something you already hold.
  • Human oversight built in — a reviewer who can see the reasoning and overturn the result, which is what Art 14(4)(d) and Art 26(2) actually ask for.
  • Record-keeping for every decision — every answer, grade and decision timestamped and exportable, so Art 26(6) is a setting rather than a project.
  • Full German localization — built for EU hiring rather than translated into it.
What this page is not

This is a technically-sourced explainer, not legal advice, and no vendor can make you compliant — the Art 26 duties are yours by law and no contract moves them. What a vendor can do is make them practical to meet. Judge us, and everyone else, on that.

Sources
  1. Regulation (EU) 2024/1689 (Artificial Intelligence Act), OJ L, 2024/1689 — EUR-Lex
  2. AI Act Explorer, per-article text — artificialintelligenceact.eu (Arts 9, 10, 12, 14, 26, 27, 43, 49, 86, 99, Annex III)
  3. European Commission, AI Act Service Desk — Art 27
  4. Council of the EU, press release, 29 June 2026 — final green light to simplify and streamline rules
  5. Gibson Dunn — EU AI Act Omnibus agreement: postponed high-risk deadlines
  6. Travers Smith — EU agrees to delay key AI Act compliance deadlines
  7. DLA Piper — The Digital AI Omnibus: proposed deferral of high-risk AI obligations
  8. CJEU, C-634/21 SCHUFA Holding (Scoring), 7 December 2023 — case note
  9. CJEU, C-203/22 Dun & Bradstreet Austria, 27 February 2025 — Bird & Bird analysis
  10. Regulation (EU) 2016/679 (GDPR), Art 22 — text

Assess with confidence under the AI Act

Transparency, human oversight and record-keeping — designed in from the first commit, not retrofitted before a deadline.