The EU AI Act and recruitment: a practical guide for UK and EU employers
Michael
Founder, KimonRecruit
Published
What the EU AI Act means for AI in hiring: who carries which duties, what the timeline really is, and how to prepare while the deadline is still in flux.

If you use AI anywhere in your hiring process, the EU AI Act probably has something to say about it. This guide explains what the Act treats as high-risk, who carries which obligations, what the timeline actually is right now, and what a sensible employer can do about all of it today. It is a practical orientation, not legal advice. For decisions about your specific situation, including how any of this applies to your own tools and jurisdictions, speak to your own qualified advisers.
We have written this as a hub. Each section answers one real question employers and recruiters ask, and several of those questions have their own dedicated, deeper article linked from this page. Read this first for the shape of the whole subject, then follow the links into the parts that matter most to you.
Is AI used in hiring high-risk under the EU AI Act?
In most realistic cases, yes. The EU AI Act takes a risk-based approach and reserves its heaviest obligations for a defined set of high-risk use cases listed in Annex III of the Regulation. Employment is on that list explicitly. AI systems intended to be used for the recruitment or selection of people, including to place targeted job advertisements, to analyse and filter applications, and to evaluate candidates, fall into the high-risk category.
That is not a stretched reading. A tool that scores, ranks, filters, shortlists or summarises candidates, where its output influences who progresses, is the kind of system the Annex is describing. The reasoning is straightforward. Hiring decisions shape people's livelihoods, and any group-level skew in an automated tool scales across every candidate it touches, quietly and at speed. That is exactly the harm the high-risk category exists to catch.
It is worth being concrete about how broad this is in a real recruitment stack. The obvious candidates are assessment-scoring engines and CV-ranking tools, but the category also reaches into features bundled inside products you may not think of as AI at all: a sourcing tool that surfaces "best-fit" profiles, an applicant-tracking system that auto-tags or auto-sorts applications, a chatbot that pre-screens candidates against criteria, and even job-advert targeting that decides who sees a vacancy. If the feature shapes who gets seen, scored or shortlisted, it is in scope for this analysis, whoever built it. The safest working assumption for an employer is that any AI touching the funnel is high-risk until someone qualified has confirmed otherwise.
There is a narrow set of conditions under which an Annex III system might not be treated as high-risk, for example where it performs a narrow procedural task and does not materially influence the outcome of a decision. These exemptions are narrow by design and a provider relying on one must document that assessment. For a tool that helps decide who gets hired, assume high-risk unless a qualified adviser has confirmed otherwise in writing.
We go into where the high-risk line falls, and the edge cases around it, in more depth in is hiring AI high-risk under the EU AI Act, explained.
When do the EU AI Act hiring rules actually apply?
This is the question where honesty matters most, because the answer is genuinely unsettled as we write this.
Here is what is confirmed. The EU AI Act entered into force in August 2024 and applies in stages. Prohibited practices, such as emotion recognition in the workplace, have applied since February 2025. General-purpose AI model obligations began in August 2025. The obligations attaching to the high-risk systems listed in Annex III, which include hiring and selection tools, are set in the Regulation to apply from 2 August 2026.
Here is what is in flux. On 7 May 2026 the EU reached a provisional political agreement, part of what has been reported as the Digital Omnibus simplification package, that would defer the application of obligations for stand-alone Annex III high-risk systems, the category that includes recruitment and selection AI, to 2 December 2027. As we publish, that agreement is provisional and not yet formally adopted. Until it is adopted and published in the Official Journal, the date that legally stands is 2 August 2026. A deferral could be confirmed, amended, or fall away.
So treat the timeline as a moving target. State plainly which date you are relying on and as of when. Do not build an internal programme, a customer commitment, or a marketing claim on a single date as though it were settled.
The practical conclusion is the same under either date: prepare now regardless. Vendor due diligence, designing real human oversight, writing candidate-facing transparency, and standing up outcome monitoring all take longer to do honestly than the gap to either deadline. An organisation that treats this as a design constraint rather than a date will be ready whichever way the timeline lands. The fuller version of this argument, with the dates set out side by side, is in the EU AI Act hiring deadline: what to do and when.
Timeline status, as at the publish date
Use this as a snapshot, not a settled fact. Confirm every row against the current consolidated Regulation before you rely on it, the dates in particular are subject to change pending the Digital Omnibus.
| Milestone | Status as we publish | Date |
|---|---|---|
| EU AI Act entered into force | Confirmed | August 2024 |
| Prohibited practices apply | Confirmed | 2 February 2025 |
| General-purpose AI obligations apply | Confirmed | 2 August 2025 |
| Annex III high-risk hiring obligations apply | Confirmed in the Regulation as it currently stands | 2 August 2026 |
| Provisional Digital Omnibus deferral of stand-alone Annex III | Provisional, not yet adopted | would move to 2 December 2027 |
Who carries which obligations, provider or deployer?
The Act splits responsibility between two roles. A provider builds and supplies the AI system, or has it built and puts it on the market under its own name. A deployer uses an AI system in the course of its activities. An employer running an AI hiring tool is, in almost every case, a deployer. That role carries its own legal duties, and you cannot contract them away to your vendor.
As a deployer of a high-risk hiring system you are expected, among other things, to:
- Use the system as instructed. Follow the provider's instructions for use, and assign human oversight to people who have the competence, training and authority to exercise it properly.
- Keep a human meaningfully in the loop. Oversight is not a tick-box. The person reviewing the AI output must be able to understand it, question it, and overrule it.
- Mind your input data. Where you control the input data, you are responsible for ensuring it is relevant and sufficiently representative for the system's intended purpose.
- Monitor and report. Watch how the system operates, and where you identify a serious risk or incident, inform the provider and the relevant authority. Keep the automatically generated logs that are under your control.
- Tell candidates. People subject to a high-risk AI system in a hiring decision must be informed that it is being used.
- Inform workers and their representatives before putting a high-risk AI system into service in the workplace.
Providers carry the heavier conformity burden: a risk-management system, data governance, technical documentation, logging by design, accuracy and robustness, human-oversight design, a quality-management system, conformity assessment, and post-market monitoring. When you evaluate a vendor you are, in effect, checking whether they can evidence that work, because their gaps become your operational and legal risk.
This split, and the grey area where an employer can drift into provider-like duties, for example by substantially modifying a system or putting its own name on it, deserves its own treatment. We cover it in provider vs deployer obligations for hiring AI.
What is a FRIA and do recruiters need one?
Certain deployers of high-risk systems are required to carry out a fundamental rights impact assessment, a FRIA, before putting the system into use. The assessment looks at the system's purpose, the categories of people affected, the specific risks of harm to their fundamental rights, the human-oversight measures in place, and what you will do if those risks materialise.
Whether a given private employer is strictly required to produce a FRIA depends on the deployer category and use case, and that is a question for your own adviser. Even where it is not strictly mandatory, a documented FRIA-style assessment is a sensible piece of evidence for a high-risk hiring tool, and it overlaps usefully with data-protection work you may already do. We provide a working structure in a fundamental rights impact assessment template for recruitment.
How is a FRIA different from a DPIA?
If you process personal data in a way likely to result in a high risk to individuals, data-protection law may already require a data protection impact assessment, a DPIA. Recruitment using AI will frequently meet that bar. The FRIA and the DPIA are different instruments with different legal homes, the AI Act and data-protection law respectively, but they overlap in practice. A DPIA centres on data-protection risk; a FRIA centres on the broader fundamental-rights risk of the AI system, including discrimination.
The point for a busy recruiter is not to do the same work twice. Map what each instrument needs, do the shared parts once, and record clearly which assessment covers which risk. We set out how the two fit together in DPIA vs FRIA in hiring: how they differ and overlap.
What does meaningful human oversight look like in hiring?
Human oversight is one of the load-bearing requirements, and it is the one most often reduced to theatre. A person nominally signing off a ranked list they never had the means to question is not oversight. The Act expects oversight by people who can actually understand the system's output, are alert to the risk of over-relying on it, can interpret it correctly, and can decide not to use it or to reverse its result.
In practice that means naming the people, training them, giving them the authority and the time to do it, and making sure the tool shows them evidence they can interrogate rather than a verdict they can only accept. A system that surfaces the reasoning behind a score, and lets the recruiter dig into it, makes oversight real; one that emits a number does not. Two failure modes are worth naming. The first is automation bias, the well-documented tendency to defer to a machine output simply because it is a machine output, which is why the Act expects the overseeing person to stay actively alert to over-reliance. The second is oversight on paper only, where a sign-off step exists in the workflow but the reviewer has neither the information nor the realistic time to disagree. Designing against both means budgeting time for review, giving reviewers the underlying evidence, and recording when and why a recommendation was overruled. We go into how to design and evidence this in human oversight requirements for AI in hiring.
This is also where good product design and good compliance meet. A platform built to support a decision, never to make it, keeps the human genuinely in charge by construction. There is no path that removes a candidate from a process without a person choosing to. You can see how we approach decision support across the platform on our features page.
What must you tell candidates about AI in hiring?
Transparency to the people affected is a deployer duty, and it is one candidates increasingly expect regardless of the law. Where a high-risk AI system is used in a decision that affects a person in a hiring context, that person should be told the system is being used, in clear terms, before or at the point it affects them. Quiet deployment is not an option, and a candidate may also have a right to an explanation of a decision that significantly affects them.
A good candidate notice says, in plain language, that AI is involved, what it does, what it does not do, who makes the final decision, and how to ask questions or request a human review. We walk through how to write one, with example wording, in writing an AI transparency notice for candidates.
How do you test a hiring AI for bias?
Bias testing is where the AI Act, equality law, and plain good practice all point the same way. For a high-risk hiring system you should be monitoring outcomes across protected groups, looking for adverse impact, and acting on what you find. A widely used starting screen is the four-fifths rule, which flags a possible adverse impact where the selection rate for one group falls below four-fifths of the rate for the most-selected group. It is a screening signal, not a verdict, and it has well-documented limitations, so it belongs inside a broader, documented methodology rather than on its own.
The right answer is to use a documented, citable methodology rather than a home-grown rule of thumb, because if an outcome is ever challenged it is the method and the records that carry weight. We cover what to measure, how often, and what to do with a flag in bias testing for AI hiring and the four-fifths rule, and you can see how continuous adverse-impact monitoring works in practice on our bias audit page.
Does the EU AI Act apply to UK employers, and how do UK rules differ?
Often, yes, the EU AI Act reaches UK companies. It can apply where you are hiring into EU member states, or where the output of your AI system is used in the EU, regardless of where your company sits, and any EU entities you operate are deployers in their own right.
UK-only hiring is still not a compliance holiday. The Equality Act 2010 applies to every stage of a hiring process, automated or not, and a discrimination claim does not require proof of intent, so a tool that produces worse outcomes for a protected group is a live exposure under UK law today. UK data-protection law also restricts solely automated decisions that have a significant effect, which a hiring outcome plainly can be, and the UK has been developing its own pro-innovation approach to AI rather than a single AI statute.
The differences, and what they mean for an organisation hiring across both, are set out in EU AI Act vs UK rules for AI in hiring.
What should you ask an AI hiring vendor?
When the duties land on you as the deployer, your vendor's evidence is your first line of defence. Before you buy or renew, ask for the documentation a compliant provider should already hold: technical documentation, the risk-management record, data-governance and bias-testing results, the instructions for use, the logging capability, and a clear statement of intended purpose and limitations. A provider that cannot produce these is asking you to carry their risk.
We have turned this into a usable due-diligence list in an EU AI Act vendor checklist for hiring AI. If you are weighing tools against each other, our compare page sets out how we think the trade-offs should be framed.
A practical checklist for the months ahead
This table is a starting programme for an SME between now and whichever enforcement date applies. Each row is a concrete action with a dated, sourced basis. Treat every regulatory basis as subject to confirmation against the current consolidated Regulation, the enforcement dates especially, pending the Digital Omnibus.
| # | Action | Why it matters | Dated, sourced basis |
|---|---|---|---|
| 1 | Inventory every AI tool that scores, ranks, filters or summarises candidates, including features inside tools you think of as "just an ATS" | You cannot govern what you have not listed | High-risk classification of recruitment and selection AI, Annex III, Regulation (EU) 2024/1689 |
| 2 | Ask each vendor for technical documentation, risk assessment, bias-testing results, instructions for use and logging capability | A provider's gaps become your deployer risk | Provider requirements, Articles 9 to 17 and Annex IV, Regulation (EU) 2024/1689 |
| 3 | Design real human oversight: name the people, train them, give them authority and time, and make sure the tool presents interrogable evidence | Oversight is a duty, not a sign-off ritual | Human oversight, Article 14, Regulation (EU) 2024/1689 |
| 4 | Write the candidate disclosure: what AI does, what it does not do, who decides, how to ask for a human review | Affected persons must be informed; some may have a right to an explanation | Transparency and explanation duties, Articles 26(11) and 86, Regulation (EU) 2024/1689 |
| 5 | Stand up group-level outcome monitoring, such as a four-fifths-rule screen inside a broader documented method | Catches adverse impact while it is a correction, not a claim | Four-fifths rule, EEOC 29 CFR 1607.4; data governance, Article 10, Regulation (EU) 2024/1689 |
| 6 | Keep records: logs, decisions, overrides and the reasons for them | If a decision is challenged, the contemporaneous record carries the weight | Deployer log-retention and record-keeping, Article 26, Regulation (EU) 2024/1689 |
| 7 | Decide whether you need a FRIA, and run a documented assessment where you do or where it is prudent | Evidence of fundamental-rights diligence for a high-risk tool | FRIA, Article 27, Regulation (EU) 2024/1689 |
| 8 | Confirm the deadline that applies to you, and record the date you relied on and as of when | The timeline is in flux pending the Digital Omnibus | 2 August 2026 in the current Regulation; provisional deferral to 2 December 2027, not yet adopted |
How KimonRecruit approaches all of this
We built KimonRecruit for these obligations rather than retrofitting them, because retrofitting is far harder than designing for them. The platform produces decision support, never an automated outcome: no code path takes a candidate out of a pipeline without a human recruiter making that call. Every assessment score is replayable from the prompt, model and version that produced it, so a decision can be explained later. An adverse-impact dashboard monitors outcomes across Equality Act 2010 characteristics continuously, and candidates are told how AI is used in their process.
None of that removes the deployer duties set out above. It does mean the evidence you need for them, the logs, explanations, oversight records and monitoring, is generated as you hire rather than assembled in a hurry when someone asks. You can read more on our features page, see how we frame the choice against other tools on compare, and look at outcome monitoring on bias audit.
The employers who will find the enforcement date uneventful, whichever date it turns out to be, are the ones who treated the Act as a design constraint rather than a deadline. There is still time to be one of them.
This guide is a practical orientation and is not legal advice. The regulatory position, in particular the application timeline, can change. Confirm how any of this applies to your tools and jurisdictions with your own qualified advisers before you act.
Found this useful? Share via email. · Read more →
