AI Hiring Under the EU AI Act and GDPR: What's Actually Required

1. Why hiring AI is classified “high-risk”

Regulation (EU) 2024/1689, the AI Act, entered into force on August 1, 2024. It sorts AI systems by risk level: unacceptable risk (prohibited), high-risk (regulated), limited risk (transparency duties), and minimal risk (unregulated). Recruitment is not a gray area. It is named explicitly in the high-risk category.

The relevant text is Annex III, point 4 of the regulation — “Employment, workers management and access to self-employment.” It covers AI systems intended to be used:

• for the recruitment or selection of natural persons — in particular to place targeted job advertisements, to analyze and filter applications, and to evaluate candidates;
• to make decisions affecting the terms of work, promotion, or termination of a working relationship, to allocate tasks based on individual behavior or personal traits, or to monitor and evaluate the performance of people in such relationships.

In plain terms: CV screening, candidate scoring, profile-to-job matching, and automated evaluation all fall inside the perimeter. The legislator's reasoning is stated openly — these systems can directly affect a person's access to employment and livelihood, and they risk reproducing historical discrimination (gender, origin, age, disability). The full text, including Annex III, is on EUR-Lex (Regulation (EU) 2024/1689).

One useful nuance: Article 6(3) lets a system listed in Annex III escape the high-risk regime if it performs only a narrow procedural task with no material influence on the outcome — but the operator invoking that exception must document the assessment, and profiling of natural persons is always high-risk. In practice, for any tool that screens or scores candidates, the high-risk regime applies.

2. Who is in scope (including US companies)

The most common mistake outside the EU is to assume “we're not an EU company, so this doesn't apply.” It does. Article 2 of the AI Act defines a deliberately broad territorial scope. The regulation applies to:

• providers placing an AI system on the market or putting it into service in the EU, irrespective of where the provider is established;
• deployers of AI systems that have their place of establishment or are located within the EU; and, critically,
• providers and deployers established or located outside the EU, where the output produced by the system is used in the Union.

That third limb is the one builders need to internalize. If a US-based applicant tracking system, screening API, or matching model is used to evaluate candidates for roles in the EU — or its scores and rankings are consumed by a recruiter operating in the EU — the output is “used in the Union,” and the AI Act reaches the foreign provider and deployer. The mechanism is structurally similar to the GDPR's extraterritorial reach (Article 3 GDPR), which most teams already account for. The territorial scope is set out in Article 2 of the regulation.

3. The concrete AI Act obligations

A high-risk system isn't just “watched.” It must satisfy a specific list of requirements, carried mostly by the provider (who develops and places it on the market) but with duties also for the deployer (the recruiter or HR team using it). These are the obligations that structure any AI hiring project.

Transparency toward candidates

A person subject to a high-risk system that produces a decision concerning them must be informed clearly. Concretely: a candidate whose application is screened or scored by an AI tool must know it, understand the tool's role, and be able to obtain an explanation. This overlaps with the transparency the GDPR requires for automated processing.

Effective human oversight

Article 14 requires “effective” human oversight during use. Effective means a person able to understand the tool's limits, interpret its outputs, override them, and stop the system. A human who rubber-stamps whatever the tool proposes is not effective oversight. For recruitment this reduces to one rule: the tool proposes a ranking or score; a recruiter decides.

Technical documentation and risk management

The provider must maintain technical documentation describing the system's purpose, its training data, its limits, and its performance (Article 11), and run a continuous risk-management system across the lifecycle (Article 9). For a matching tool, that includes identifying possible biases, the tests run to detect them, and the mitigations chosen.

Data governance

Article 10 requires training, validation, and test datasets that are relevant, representative, and to the best extent possible free of errors. This is the heart of fighting algorithmic discrimination: a model trained on biased past hiring will reproduce those biases. Data governance is not a technical footnote — it is a legal obligation.

Logging and traceability

Article 12 requires automatic event logging throughout operation, so you can reconstruct what happened and detect drift. In recruitment, this is what lets you retrace, in case of a dispute, how an application was handled: what score, on what data, validated by whom.

On top of these come system registration, the conformity assessment and CE marking, the declaration of conformity, and — for deployers, in defined cases — a fundamental rights impact assessment (Article 27). The overarching logic: a high-risk system must be documentable, explainable, and controllable end to end. JAIKIN's longer technical breakdown of the regulation is in our AI Act white paper.

4. The enforcement timeline

The AI Act does not apply in one block. It phases in — and the Digital Omnibus political agreement of 6–7 May 2026 would push back the high-risk date that directly hits recruitment. That agreement is still provisional until it is published in the Official Journal; until then, the original dates stand.

Note: the Digital Omnibus postponements stem from a provisional political agreement of 6–7 May 2026 (confirmed by the Council on 13 May); it is not yet adopted or published in the EU Official Journal, with publication expected before 2 August 2026. Until then, the regulation's in-force text states the original dates, which apply as a matter of law.

Penalties are tiered under Article 99. Prohibited practices can draw fines up to €35 million or 7% of total worldwide annual turnover, whichever is higher. Non-compliance of a high-risk system with its obligations can draw up to €15 million or 3%. For SMEs and start-ups, the lower of the two amounts applies. The official timeline and Commission analysis are on the EU's regulatory framework for AI page. The operational read is simple: a team shipping AI hiring features in 2026 should build for compliance now rather than retrofit it under deadline pressure. The GDPR, meanwhile, already applies — there is no grace period there.

5. Provider vs. deployer: who does what

The AI Act splits responsibility between the provider (develops the system and places it on the market) and the deployer (uses it under its own authority). If you build a screening tool you ship to others, you are a provider. If you build it for your own hiring, you are typically both. Get this mapping right early — it determines what you must produce.

A trap to watch: under Article 25, a deployer can become a provider — for example by substantially modifying a high-risk system, or by putting its own name on it. Fine-tuning a screening model on your own hiring data, or rebranding a third-party tool, can shift the heavier obligations onto you. When the system is custom-built, these roles are clarified in the contract, which is one practical advantage over a black-box SaaS rental.

6. The GDPR overlap (and one note on France)

The AI Act does not replace the GDPR — it adds to it. Processing applications means processing personal data, often sensitive. The two regimes apply in parallel, on different but largely complementary angles, and they reinforce each other.

• Legal basis. Hiring usually relies on the recruiter's legitimate interest or pre-contractual measures. Consent is rarely the right basis in recruitment, since a candidate is not in a position to refuse freely. Whatever you pick must be identified and documented before processing.
• Minimization and relevance. Collect only what is necessary to assess professional competence. Data unrelated to the role — or attributes inferred by an algorithm without job relevance — should not be collected or used to score a candidate. A matching tool must rest on explicit job criteria, not on opaque correlations.
• Retention. A rejected candidate's data is not kept indefinitely. Set a defined lifetime per record type and an automated purge.
• Candidate rights. Access, rectification, erasure, objection all apply. Article 22 GDPR additionally restricts solely automated decisions producing legal or similarly significant effects: a candidate has the right not to be subject to one without human intervention, to obtain an explanation, and to contest it. One more reason to keep a human in the final decision loop.
• Impact assessment (DPIA). Large-scale processing involving profiling or automated evaluation of candidates generally triggers a data protection impact assessment. A DPIA overlaps heavily with the AI Act's risk management — do it once, satisfy both.

7. What this changes for matching, screening, and scoring

The principles above get concrete the moment you apply them to the three most common AI hiring use cases.

Profile-to-job matching

Matching a candidate to a role on job criteria (qualification, availability, location, experience) is legitimate — provided the criteria are explicit, justified by the role, and auditable. A matcher that leans on discriminatory proxies (a neighborhood, a first name, a gap in a CV) crosses into illegal territory. Good matching proposes an explainable ranking; it does not decide.

CV screening

Pre-ranking hundreds of applications to surface relevant profiles saves real time. But screening is still a high-risk task: it must rest on professional competence, log its decisions, and let the recruiter review, reorder, and reinstate a filtered-out profile. Screening doesn't eliminate — it prioritizes for a human.

Candidate scoring

Assigning a score is the most sensitive use, because it compresses a complex evaluation into one number. To stay compliant, a score must be decomposable (you must be able to say why it is high or low), rest on relevant criteria, and serve only as an aid — never an automatic cut-off. That is exactly the line drawn by Article 22 GDPR and Article 14 of the AI Act.

8. A 10-question vendor checklist

Whether you are buying an AI hiring tool or auditing one you built, these ten questions surface most of the compliance gaps. If a vendor cannot answer them in writing, treat that as a finding.

1. Provider or deployer? Does the contract state who is the AI Act provider and who is the deployer, and who is the GDPR controller for candidate data?
2. Technical documentation. Can you obtain the Article 11 documentation — purpose, training data sources, known limits, performance metrics?
3. Human oversight. How does the system support an Article 14 override — can a recruiter ignore, reorder, and reinstate a filtered candidate, and is that action logged?
4. No automated rejection. Is there any path where the system rejects a candidate with no human review? (There should not be.)
5. Explainability. For any given score or ranking, can the tool state the job-relevant reasons behind it — to the recruiter, and on request to the candidate?
6. Data quality & bias testing. What datasets trained the model, were they tested for representativeness (Article 10), and what bias tests run before and after deployment?
7. Logging. Are events logged automatically (Article 12), retained, and exportable for an audit or a candidate complaint?
8. Transparency. How are candidates informed that AI is involved, and what wording is provided for the job ad and privacy notice?
9. Data minimization & retention. Which fields are collected, is each one job-relevant, and is there a configurable retention period with automated purge?
10. Hosting & assessments. Where is the data hosted, are sub-processors disclosed, and do DPIA / fundamental rights impact assessment templates exist for the deployer?

Most of these map one-to-one onto specific articles, which is the point: a tool that was designed compliant can answer them directly, while a tool that bolted compliance on afterward usually cannot. This is the approach we apply across our AI automation projects.

9. FAQ

Where to go from here

AI hiring is not a place where you trade off compliance against effectiveness. Built well, a compliant tool — explainable, traceable, supervised — is simply a better tool: safer, more auditable, more defensible. The AI Act and the GDPR don't stop innovation; they set its rules. The teams that wire those rules in at design time will be ahead of the ones scrambling to retrofit under deadline pressure as the December 2027 high-risk date approaches.