| Takeaway | Detail |
|---|---|
| EU AI Act high-risk obligations for AI hiring tools apply from August 2, 2026 | Employers using AI in hiring face the deadline of August 2, 2026 under the EU AI Act (2026). |
| Classify hiring AI as high-risk under Annex III | If an AI tool touches any stage of screening, ranking, or evaluating candidates for EU-based roles, classify it as high-risk under Annex III. |
| Compliance follows a six-step sequence | Inventory, risk classification, vendor accountability, human oversight, logging, and conformity documentation — run the full sequence now, not later. |
| The compliance path is executable in 90 days | The six-step path is fully executable in 90 days if started before the August 2, 2026 deadline. |
This guide lays out a six-step compliance sequence for employers whose AI tools screen, rank, or evaluate candidates for EU-based roles under the EU AI Act.
It covers the inventory, risk classification, vendor accountability, human oversight, logging, and conformity documentation needed ahead of the August 2, 2026 deadline.

How the AI Act hits hiring tools
Annex III point 4(a) of Regulation (EU) 2024/1689 does not ask whether a hiring tool feels risky. It lists AI systems intended to be used for recruitment or selection — specifically those that screen or filter applications, sort or rank candidates, or evaluate applicants during interviews or hiring processes — and places them in the high-risk tier by category. That is the whole mechanism: classification attaches to the intended purpose, not to the vendor's marketing language, the model architecture, or how accurate the tool happens to be. If your software touches CV sorting, candidate ranking, or application filtering for a role based in the EU, the high-risk designation is automatic. There is no self-assessment scorecard to argue your way out of it.
The practical consequence is that the classification question is answered before you open the vendor's documentation. A resume parser that extracts skills and orders applicants is in scope. A chat-based pre-screening assistant that asks candidates questions and scores responses is in scope. An interview transcription tool that produces an evaluation summary a recruiter relies on is in scope. The test to run is functional, not technical: trace every stage of the funnel and ask whether an AI system contributes to screening, ranking, or evaluating a candidate. Where the answer is yes, treat the tool as high-risk and move to the compliance sequence rather than debating the label.
Timing matters because the Act staggers its obligations rather than switching them all on at once. Prohibitions and the AI literacy duty took effect earlier in the Act's application timeline, while the bulk of high-risk system obligations apply from August 2, 2026. Because that date drives the entire 90-day compliance path, verify it against the Official Journal text of Regulation (EU) 2024/1689 rather than a vendor blog, a conference slide, or a summary email. The regulation itself is the only source that settles which obligations attach on which date.
Two checks follow from the classification. First, inventory every tool that touches the funnel and record its intended purpose in writing, since that purpose is what anchors the Annex III 4(a) analysis. Second, confirm the application date for each obligation you owe as a deployer, because the staggered schedule means not every duty lands on the same day. Employers who complete both checks before the deadline can run the six-step sequence inside 90 days; those who wait until the obligations are live are sequencing under pressure instead of planning.
| Funnel stage | Typical AI touchpoint | Annex III 4(a) status |
|---|---|---|
| Application intake | CV parsing and filtering | High-risk — screening |
| Shortlisting | Candidate ranking and scoring | High-risk — ranking |
| Assessment | Interview analysis and evaluation | High-risk — evaluating |
The classification is the gate, not the finish line. Once a tool is high-risk under Annex III 4(a), the statutory obligations attach to it, and the remaining work is execution: mapping each obligation to a concrete employer action, settling who owes what between you and the vendor, and documenting conformity before the deadline rather than after. Start the inventory now, because the classification does not wait for your readiness.

The evidence: what regulators require
The EU AI Act's obligations for high-risk systems are not abstract principles — each article in Articles 9 through 15 maps to a specific, checkable employer action. Regulators auditing a hiring tool will not ask about your intent; they will ask to see the artifact that the article requires. This section walks through the statutory obligations in the order an inspector would.
Article 9 requires a continuous risk-management system spanning the tool's entire lifecycle. The checkable action is a documented risk register for each hiring tool, updated at every model retrain or material vendor update — not a one-time assessment filed at deployment. If your register's last entry predates the tool's most recent model change, you are non-compliant on its face. Assign ownership of the register to a specific role, and review it on a fixed cadence that matches your vendor's update schedule.
Article 14 requires human oversight robust enough that a designated person can detect and override discriminatory or erroneous outputs before they affect a candidate. The checkable action is a named overseer for each tool, with override authority documented in writing and an override log maintained as a matter of routine. An overseer who cannot explain how to reverse a ranking decision, or who has no record of ever exercising that power, signals to a regulator that oversight exists on paper only.
Article 12 requires automatic event logging sufficient to reconstruct what the system did — the inputs, outputs, and decisions — so that any adverse outcome can be traced after the fact. Employers should verify that their vendor's logging captures enough detail to answer the question "why was this candidate scored lower?" without manual reconstruction. If logs cannot be produced on demand, the traceability obligation is already failed.
| Statutory obligation | What the article requires | Employer's checkable artifact |
|---|---|---|
| Article 9 — Risk management | Continuous lifecycle risk system | Per-tool risk register, updated at each retrain |
| Article 12 — Logging | Automatic event logs enabling decision reconstruction | Retrievable per-candidate decision logs |
| Article 14 — Human oversight | Named person who can detect and override outputs | Documented override authority plus override log |
The remaining obligations — data governance under Article 10, transparency under Article 13, and accuracy under Article 15 — follow the same pattern: each converts into a document or log a regulator can request. Build the full set of artifacts as a single compliance file per tool rather than addressing articles piecemeal, so that when an audit or adverse-decision challenge arrives, you produce one package instead of assembling one under deadline pressure.
Build vs vendor: who owes what
The single most expensive mistake an employer can make under the EU AI Act is assuming it carries provider obligations when it is actually a deployer — or the reverse. Under Regulation (EU) 2024/1689, the provider is the entity that places the high-risk system on the market or puts it into service under its own name; the deployer is the entity that uses such a system under its own authority. Most employers buying an off-the-shelf screening, ranking, or candidate-matching tool are deployers. That distinction is not cosmetic: it determines which of the six compliance steps you actually owe.
Deployers owe the operational layer. That means assigning competent human oversight to every automated output that affects a candidate, verifying that the input data you feed the tool is relevant and sufficiently representative for the role, and retaining logs of the system's operation for the period required by the regulation. Providers owe the product layer: the conformity assessment, the technical documentation, and the CE marking that declares the system meets the high-risk requirements. If your procurement team is budgeting for a conformity assessment you are not legally required to run, that spend is misallocated — and the oversight and logging duties you do owe may go unfunded.
| Obligation | Provider | Deployer (typical employer) |
|---|---|---|
| Conformity assessment | Owes | Not owed |
| Technical documentation | Owes | Not owed |
| CE marking | Owes | Not owed |
| Human oversight | Supports | Owes |
| Input-data relevance checks | Supports | Owes |
| Log retention | Supports | Owes |
Article 25 is where the split collapses. If you put your own name or brand on a vendor's tool, or substantially modify a high-risk system, you are reclassified as its provider and inherit the full provider obligation set — conformity assessment, technical documentation, and CE marking included. The modification that catches employers most often is retraining: fine-tuning a vendor's ranking model on your own historical hiring data is a substantial modification, not a configuration change. Before any such retraining, ask your vendor in writing whether the change shifts provider status, and get the answer into the contract.
The contract clause that shifts audit burden is the one that allocates responsibility for demonstrating conformity and for supplying the technical documentation and logs a regulator will request. Push for a clause obligating the vendor to provide, on request and within a defined period, the technical documentation, log access, and conformity evidence needed for your deployer duties. Without it, you hold the deployer obligations but depend on a third party's cooperation to discharge them.
Run the classification check before you sign, not after: name the entity placing the tool on the market, confirm whether you will rebrand or retrain it, and confirm in writing which side owns each row of the table above. Employers that complete this split correctly can execute the remaining compliance sequence within the 90-day window; those that guess often discover the error only when a regulator asks for documentation they were never obligated to produce — or never obtained the documentation they were.
Costs and penalties that matter
The penalty framework is the first thing to verify, and the last thing to trust from a slide deck. Regulation (EU) 2024/1689 Articles 99 and 100 are the provisions that set the statutory ceilings for high-risk non-compliance, and the European Commission's AI Act page carries the current implementing guidance. Consultancy decks quoting figures that predate final guidance are a liability in your own audit file. Pull the articles directly, date-stamp the version you read, and treat any number you cannot trace to the regulation or the Commission's page as unverified. If your counsel has not confirmed the ceiling in writing, you do not yet know your exposure.
The real cost driver is not the fine. It is re-procurement. If your current screening vendor cannot produce logging and documentation by August 2, 2026, you are not facing a compliance gap — you are facing a replacement cycle. An RFP, a pilot, and a legal review of the new contract typically consume one to two quarters. That clock starts the day you discover the vendor cannot deliver, not the day the deadline passes. Run the check now: ask each vendor for a sample log export and a conformity document. A vendor that cannot produce both on request will not produce them under audit.
That asymmetry is the whole argument for starting before the deadline. Pre-deadline compliance is a documentation exercise you control: inventory, classification, vendor evidence, oversight design, logging, conformity file. Post-deadline remediation is a procurement exercise you do not control, because it runs on vendor timelines, legal review queues, and pilot schedules you cannot compress. Same obligations, radically different cost profile.
Being wrong has a third cost that rarely appears in budget models: the hiring freeze. A screening tool you cannot defend is a screening tool you cannot use for EU-based roles, and roles that cannot be screened do not get filled on schedule. Line managers absorb that delay, and it surfaces in headcount reviews long before any regulator does.
| Cost category | Pre-deadline path | Post-deadline path |
|---|---|---|
| Statutory exposure | Documented conformity file | Ceiling per Articles 99–100 |
| Vendor | Evidence collected in place | RFP, pilot, legal review |
| Timeline | Controlled by you | One to two quarters |
| Hiring impact | None if evidence holds | Freeze on unscreenable roles |
Budget the replacement cycle, not the fine. The fine is a ceiling you may never touch; the replacement cycle is a cost you will certainly pay if your vendor evidence fails. Confirm the Articles 99–100 figures yourself, then ask your vendor for the log and the document. The answer you get this week determines which column of that table you live in.
What the evidence does not settle
The six-step sequence is executable, but three open questions mean you should treat full compliance as a moving target rather than a finished state. The first is harmonized technical standards. The Commission tasked CEN-CENELEC with drafting the technical standards that would give high-risk systems a presumption of conformity with Articles 9 through 15, and that work program was still being finalized as of the Commission's published AI Act implementation timeline. Before you accept any vendor's claim that its tool is "presumed compliant," check the CEN-CENELEC work program directly and confirm whether a harmonized standard covering recruitment and selection systems has actually been cited in the Official Journal. Until a citation exists, there is no legal presumption — only a vendor's assertion, which your conformity documentation cannot lean on.
The second open question is enforcement allocation. The AI Act assigns market surveillance to national authorities, but which body in each member state holds the file varies. Germany and Ireland have designated different competent authorities with different supervisory cultures and different appetites for proactive audit. The same screening tool deployed for identical roles can therefore face materially different scrutiny depending on which member state's authority leads. Before you finalize your inventory, identify your lead member state's designated market-surveillance authority and confirm its published supervisory priorities. Atlas HXM's country compliance data is one place to cross-check local requirements, though the designation itself should be verified against the member state's official register.
The third open question is the edge case where the six-step rule breaks: a tool that touches screening, ranking, or evaluation only indirectly. Consider a scheduling system that orders interview slots by candidate availability, or a sourcing tool that surfaces profiles without scoring them. Annex III point 4(a) reaches systems "intended to be used for recruitment or selection," and intent is documented in the vendor's own instructions for use, not in your deployment habits. If the vendor's intended purpose statement is silent on recruitment, but your configuration routes candidate data through it, you have created the intent yourself. The check: pull every tool's instructions-for-use document and confirm whether recruitment or selection appears in the intended purpose. If it does not, but your workflow uses it that way, either reconfigure the workflow or document the classification decision and the reasoning behind it.
What the evidence does not settle is whether any of these three questions will resolve before August 2, 2026. The standards may land late; enforcement allocation may shift; edge cases will keep appearing as vendors repackage general-purpose tools for HR. The practical rule is to run the six-step sequence now, document each open question as an open question in your conformity file, and set a review cadence — quarterly is defensible — to re-check the CEN-CENELEC program, your lead authority's designations, and your vendors' intended-purpose statements. A conformity file that names its own uncertainties is stronger than one that pretends they do not exist.
90-day compliance sprint
Treat the sprint as three dated checkpoints, each producing one artifact you can hand to a regulator. The first checkpoint lands on day 15 and produces an inventory. Walk every requisition stage — sourcing, screening, ranking, interview scoring, offer approval — and list each tool that touches it. A mid-size employer typically surfaces three to six systems: an ATS screening module, a video-interview scoring engine, a sourcing ranker, sometimes a chatbot or assessment plug-in. For each, record the vendor, the deployed version, the EU requisitions it supports, and one binary field: does its output influence a rejection, a rank order, or a shortlist? That last field is the trigger for everything downstream, so answer it conservatively.
The second checkpoint lands on day 45 and produces a classification memo. Take each inventoried tool and test it against Annex III point 4(a) of Regulation (EU) 2024/1689, which covers AI systems intended for recruitment or selection that screen or filter applications, sort or rank candidates, or otherwise evaluate them. Any tool that scores, ranks, or filters candidates for EU requisitions is high-risk. Write the memo tool by tool, citing the specific Annex III provision and the inventory line it maps to. Do not batch tools into a single paragraph; auditors read for per-system reasoning, and a memo that names each system and its citation is the difference between a closed file and a follow-up request.
The third checkpoint lands on day 90 and produces the conformity documentation package. For each high-risk tool, assemble the evidence the six statutory obligations require — risk management records, data governance notes, logging configuration, transparency disclosures, human-oversight design, and accuracy testing — and bind it to the classification memo from day 45. The audit worksheet below is copy-usable: fill the columns, attach the artifacts, and the package is complete.
| Checkpoint | Day | Artifact | Worksheet fields |
|---|---|---|---|
| Inventory | 15 | Tool register | Tool name; vendor; version; hiring stage; EU requisitions supported; output influences rejection (Y/N) |
| Classification | 45 | Classification memo | Tool; Annex III 4(a) citation; high-risk determination; reasoning; owner |
| Documentation | 90 | Conformity package | Per tool: risk management record; data governance note; logging config; transparency disclosure; human-oversight design; accuracy test result |
Two rules keep the sprint honest. First, do not let a vendor's own compliance claim substitute for your classification memo — the deployer still has to document its own determination, and the contract clause that shifts audit burden belongs in the build-versus-vendor analysis, not here. Second, date every artifact. A worksheet with no dates reads as reconstructed after the fact, and the sprint's value is precisely that it was run before the obligations bite.
Worked Example: Run the Numbers
Worked example, illustration only: one employer uses one AI screening tool for EU-based roles, has no existing conformity file, and must be ready by the August 2, 2026 high-risk deadline. The only fixed inputs are the deadline and the 90-day runway stated in the thesis; every other date below is derived for illustration.
Calculation step 1: deadline D = August 2, 2026. Step 2: required runway R = 90 days. Step 3: latest start S = D minus R = May 4, 2026. Step 4: if the six steps share the runway equally, each step receives 90 / 6 = 15 days. Step 5: a June 1, 2026 start leaves 62 days to August 2, 2026, which is 90 - 62 = 28 days short of the full runway.
Work the rules in order. Rules 1 and 2 set scope and vendor viability; Rules 3 through 5 close the gaps that audits actually probe. Ninety days is enough only if the inventory starts before the deadline, not on it.
What to do next
| Step | Action | Why it matters |
|---|---|---|
| 1 | Inventory every AI tool that touches any stage of screening, ranking, or evaluating candidates for EU-based roles. | You cannot classify what you haven't catalogued — the six-step sequence starts here. |
| 2 | Classify each inventoried tool as high-risk under Annex III. | Hiring AI falls squarely in Annex III; assuming an exemption invites enforcement. |
| 3 | Review vendor contracts and push providers for accountability on their share of the obligations. | Deployers and providers split duties — unclear vendor terms stall conformity later. |
| 4 | Set up human oversight over every high-risk hiring decision the tool influences. | The EU AI Act requires meaningful human review, not rubber-stamping automated rankings. |
| 5 | Implement logging so screening, ranking, and evaluation outputs are traceable. | Logs are the evidence base if a regulator questions a candidate outcome. |
| 6 | Assemble conformity documentation for each tool, running the full sequence now — well before the deadline date named at the top of this guide. | The compliance path is fully executable in the 90-day window, but only if started early enough. |
Frequently Asked Questions
Which AI hiring tools fall under Annex III point 4(a) of Regulation (EU) 2024/1689?
Annex III point 4(a) lists AI systems intended for recruitment or selection that screen or filter applications, sort or rank candidates, or evaluate applicants during interviews or hiring processes.
Does a hiring AI tool need to feel risky to be classified as high-risk?
No — Annex III point 4(a) does not ask whether a hiring tool feels risky; it classifies tools as high-risk based on their intended recruitment or selection use.
When do the EU AI Act high-risk obligations for AI hiring tools start applying?
High-risk obligations for AI hiring tools apply from August 2, 2026.
What is the full six-step compliance sequence employers must run?
The sequence is inventory, risk classification, vendor accountability, human oversight, logging, and conformity documentation.
How quickly can the six-step compliance path be completed?
The six-step path is fully executable in 90 days if started before the August 2, 2026 deadline.
Which candidates trigger the high-risk classification for a hiring AI tool?
If an AI tool touches any stage of screening, ranking, or evaluating candidates for EU-based roles, it must be classified as high-risk under Annex III.
Quick answers
| When do EU AI Act high-risk obligations for AI hiring tools apply? | They apply from August 2, 2026, the deadline under the EU AI Act (2026). |
| How should employers classify AI hiring tools under the EU AI Act? | If an AI tool touches any stage of screening, ranking, or evaluating candidates for EU-based roles, classify it as high-risk under Annex III. |
| What are the six steps in the compliance sequence? | Inventory, risk classification, vendor accountability, human oversight, logging, and conformity documentation — run the full sequence now, not later. |
| How long does the six-step compliance path take to execute? | The path is fully executable in 90 days if started before the August 2, 2026 deadline. |
| What does Annex III point 4(a) of Regulation (EU) 2024/1689 cover? | It lists AI systems intended for recruitment or selection — those that screen or filter applications, sort or rank candidates, or evaluate applicants during interviews or hiring processes — and places them in the high-risk category. |
Also worth reading: The most effective compliance management software tools to automate your workflow in 2026: most effective compliance management software · EU AI Act 2026: documenting algorithmic hiring-system controls: EU AI Act 2026: documenting · San Francisco hiring law: 2026 $27,400 audit vs Hybrid Lite: San Francisco hiring law: 2026