Compliance · July 18, 2026 · 9 min read

EU AI Act and hiring: what high-risk means for you

The EU AI Act classes hiring AI as high-risk, with duties on documentation, human oversight, logging and transparency. What that means for your assessments.

← Part of Compliance-First Hiring AI: LL144 and the EU AI Act

If you assess candidates who live in the European Union, the EU AI Act puts your hiring software in its high-risk tier — the same regulatory bracket as medical devices and credit scoring — and the duties reach any employer that hires EU candidates, wherever that employer is based. This matters because high-risk classification is not a badge you argue your way out of; it is assigned by what the system does, and it brings documentation, human oversight, logging and transparency obligations that a policy PDF cannot satisfy. This guide is written for the hiring manager or talent leader who has to make an AI-native skills assessment platform defensible before those duties bite on 2 December 2027, and it is a deep dive from our wider guide to compliance-first hiring AI.

Why hiring is high-risk by definition

The Act takes a risk-tiered approach. Most software sits in a minimal-risk band with few obligations; a narrow set of practices is prohibited outright; and in between sits the high-risk tier, where the real compliance work lives. Employment falls squarely in that middle band. Annex III, Area 4 — 'employment, workers management and access to self-employment' — explicitly names AI used to recruit, screen, filter and evaluate candidates, and to make or support decisions on promotion, termination and task allocation.

The consequence is blunt: if your tool influences who gets hired, it is high-risk by classification, not by argument. There is no accuracy threshold that lets a vendor opt out, and no 'we only assist the recruiter' framing that moves the tool into a lighter tier. A confident model score that a recruiter leans on is exactly the scenario the Annex is written for. This is why the safest posture treats compliance as an architecture decision made early, in the same spirit as reducing bias in hiring — something you build in, not bolt on.

The core obligations, in plain terms

The high-risk requirements read like a systems checklist rather than a legal abstraction. They cover the whole lifecycle of the system, and each one maps to something you can point at in a working assessment process.

• Risk management across the system's lifecycle — a live process, not a one-off sign-off
• Data governance — training, validation and testing data managed for relevance, representativeness and error handling
• Technical documentation and automatic record-keeping (logging) that let others reconstruct what happened
• Human oversight that is meaningful — a person who can understand, monitor and override the output
• Transparency and information to deployers, so the people running the tool know its limits
• Accuracy, robustness and cybersecurity appropriate to the intended purpose

Read as a group, these obligations reward a design where evidence is generated as a by-product of normal use. If the only way to prove human oversight is a signed policy nobody can show was followed, the paperwork becomes a scramble. If every candidate's AI-generated candidate evaluation leaves a reviewable record and every reviewer decision is logged, most of the documentation writes itself.

Human oversight as a feature, not a policy

Article 14 is unusually specific about what oversight means. The people responsible must be able to understand the system's capabilities and limits, monitor it for signs of anomaly or malfunction, correctly interpret its output, and — critically — stay alert to automation bias, the human pull to over-trust a confident machine. They must retain the power to disregard the output, override it, or decide not to use the system at all in a given case.

That standard is hard to satisfy with a policy document and easy to satisfy with the right workflow. A recruiter review queue where a person approves, edits or rejects each result — with every action timestamped and attributed — is Article 14 made concrete. Oversight you can evidence beats oversight you merely assert. The distinction matters most when a rejected candidate asks how the decision was made, or when a regulator asks the same question two years later.

Automation bias is the failure mode to design against

The Act names automation bias because it is the predictable way human oversight collapses in practice. A reviewer facing a hundred candidates and a confident score will drift toward rubber-stamping. The countermeasures are structural: surface the reasoning behind a result rather than a bare number, make the reviewer record a judgement rather than click 'accept', and calibrate the workload so oversight is realistic. The same discipline underpins structured, defensible evaluation generally — consistency of process is what makes a decision reviewable.

Transparency to the people being assessed

High-risk classification also carries transparency duties that face the candidate, not just the auditor. People interacting with an AI system in a high-risk context need to be informed that this is happening, in a way they can actually understand, and deployers must give the affected person the information they need to grasp how the system fits into a decision about them. For hiring, that means telling candidates plainly that AI is used in the assessment, what it evaluates, and that a human reviews the result before it counts.

Transparency is cheap to build in and expensive to retrofit. A short, honest notice at the point a candidate starts an assessment satisfies the spirit of the requirement and, in our experience, improves completion rates rather than harming them — people are more willing to be assessed by a machine when they are told a person stands behind the decision. Vague or buried disclosures do the opposite and invite exactly the complaint the rule is designed to prevent. The same candour underpins a strong candidate experience — transparency and trust move in the same direction.

Provider versus deployer: who owes what

The Act splits duties between two roles. A provider develops the AI system, or has it developed, and places it on the market under its own name. A deployer uses that system under its own authority — for a hiring tool, that is usually the employer. If you buy an assessment platform and run it on your candidates, you are a deployer; the vendor is the provider.

Providers carry the heaviest build-side load: risk management, data governance, technical documentation, logging, conformity assessment and post-market monitoring. Deployers have a lighter but real set of duties — use the system according to the provider's instructions, run human oversight in practice, keep the logs the system generates, and inform affected people where required. The comfortable position for a deployer is to pick a provider whose product already generates the records both roles need, so your obligations are satisfied by using the tool as intended rather than by bolting a compliance layer on top.

There is a practical reason to care which role you occupy beyond apportioning blame. Your evidence obligations differ, and so does what you can outsource. A deployer cannot delegate away human oversight — it is exercised by your people, on your candidates, whatever the vendor's product does. But a deployer can, and should, insist that the provider supplies the documentation, logging and instructions that make oversight and record-keeping feasible. If a vendor cannot show you how their tool generates the records you will need, that is a signal about how much of the compliance burden they are quietly leaving on your desk.

The clock: 2 December 2027

The high-risk obligations for Annex III systems now become enforceable on 2 December 2027. The Digital Omnibus regulation deferred them from the original 2 August 2026 date, an unconditional move that hands employers roughly sixteen extra months. That August 2026 date has not vanished — it is when the Article 50 transparency duties bite, covering disclosure that AI is involved and the labelling of AI-generated content, and when the EU AI Office begins enforcing obligations on general-purpose AI. The rules banning a small set of prohibited practices applied earlier still, from February 2025. Penalties for the most serious infringements reach into the tens of millions of euros or a share of global annual turnover, whichever is higher — deliberately large enough to matter to a global employer, not just a fine to be absorbed.

Treat the deferral as breathing room, not a reprieve. Sixteen months is enough time to build documentation, bias testing and human oversight properly rather than in a panic, but only if you start now — December 2027 is a hard date, and the transparency duties land in August 2026 regardless. The safe posture is the same for providers and deployers, and it is the same posture the New York City bias-audit rules and the emerging US state laws such as Colorado's AI Act already push toward: a human genuinely in the loop, and logs that prove it. Build for evidence generation and record-keeping now, and the through-line across every jurisdiction — keep a person accountable, keep a trail — means the same architecture answers most of the questions at once.

What defensible documentation actually looks like

The word 'documentation' does a lot of quiet work in the Act, and it is worth being concrete about what it demands. For a high-risk hiring system, the technical documentation is meant to let a competent third party understand what the system does, the data it was built on, how it performs, and what its known limitations are. Logging then captures what actually happened in use: which candidate was assessed when, what the system produced, and what the human reviewer did with it.

For a deployer, the honest test is simple: if a candidate complained to a regulator eighteen months from now, could you reconstruct their assessment end to end from records that already exist? If the answer requires guesswork, reconstruction from memory, or asking the vendor to dig something up, the documentation is not yet doing its job. The systems that pass this test are the ones where the record is a by-product of running the assessment, not a report someone has to remember to write. That is the same reason a rigorous AI-native hiring process keeps a reviewable trail for every result by default.

How the EU AI Act sits alongside GDPR

The AI Act does not replace data protection law; it layers on top of it. For a hiring team in Europe, GDPR still governs how you collect, store and delete candidate data, and the AI Act adds obligations about how the AI system itself is built, documented and overseen. The two overlap most visibly around human oversight: GDPR's Article 22 already restricts decisions based solely on automated processing, and the AI Act's Article 14 spells out what meaningful human control looks like. Meet one properly and you are most of the way to meeting the other.

The practical upshot is that you should not run two separate compliance projects. The candidate data you minimise under GDPR is the same data your AI system's data-governance obligations cover. The consent and notice you give under GDPR is where your AI transparency disclosure naturally lives. Treating them as one programme, rather than two, is the difference between a coherent process and a pile of overlapping paperwork. Our guide to GDPR for hiring walks through the data-protection half of the same picture.

What to do before the deadline

Start by mapping where AI touches your hiring funnel — sourcing, screening, evaluation, ranking — and mark each point as provider-supplied or built in-house, because your role determines your duties. Then confirm three things about each high-risk touchpoint: that a named person can override the output, that every decision is logged in a form you could hand to an auditor, and that candidates are told an AI system is involved where the Act requires it. If any of the three is missing, that is where the remediation work sits.

Finally, keep the record human-readable. The point of documentation is not to satisfy a filing requirement; it is to let a reviewer, an auditor or a rejected candidate reconstruct how a decision was reached. A compliance-first approach treats that reconstructability as the product, and the certificate of compliance as a side effect. See how oversight and logging work in practice in a live demo.