EU AI Act for Recruitment and Hiring AI: What Developers Need

Why recruitment AI is high-risk

Annex III of the EU AI Act (Regulation (EU) 2024/1689) lists eight domains where AI systems are considered high-risk by their intended purpose. Category 4, “Employment, workers’ management and access to self-employment” covers the full hiring pipeline: job advertisement targeting, application screening and filtering, candidate evaluation, and interview assessment.

The model type alone does not settle classification. Intended purpose is central, but the complete Article 6 test and Annex III wording still apply. Recruitment-related code is evidence to review, not a legal conclusion by itself.

Regulation (EU) 2026/1744, in force since 27 July 2026, sets 2 December 2027 for Annex III high-risk provisions. Whether a recruitment system follows that path depends on the Article 6 test, intended purpose, and the Annex III wording; a code pattern alone does not decide it.

One thing that is already enforceable: Article 5 prohibitions, in force since 2 February 2025. If your recruitment tool uses subliminal manipulation, exploits vulnerabilities, or implements social scoring, that is banned now, not in 2027.

Code patterns associated with the high-risk path

Regula scans source code for patterns associated with Annex III use cases. In recruitment software, the patterns it looks for include:

• cv_screen, resume_filter, candidate_rank, hiring_decision
• ML model calls (sklearn, transformers, torch) combined with employment-related variable names
• Functions like score_resume(), classify_resume(), rank_candidates()
• Prompt templates that embed hiring instructions (e.g. “score these resumes”, “rank candidates by fit”)
• Automated decision outputs that feed into application accept/reject flows

Here is what the scan looks like on the bundled example project:

$ regula check examples/cv-screening-app --scope all --domain employment

Regula Scan: examples/cv-screening-app
============================================================

Decision: insufficient_information
Jurisdiction: eu
Rule resolution: unresolved
Facts needed to resolve the next decision: 2
  - is_ai_system: Does the subject meet the governing law's definition of an AI system or regulated automated technology?
  - jurisdiction_in_scope: Does this jurisdiction's territorial and operator scope apply?

Detector observations (not legal facts):

  Detector summary: ANNEX III OR SECURITY PATTERNS
  The scanner found patterns relevant to Annex III or security review.
  Resolve the facts listed above before attaching Article 9 to 15 duties.

  Files scanned:      1
  High-risk:          1
  BLOCK tier:         0
  WARN tier:          0
  INFO tier:          1

  HIGH-RISK INDICATORS:
    [INFO] [ 43] app.py — Employment and workers management [plan]
============================================================

Read the two halves separately. The decision block says insufficient_information: the tool has not concluded that the Act applies, and it names the two facts a person still has to establish before any Article 9 to 15 duty can be attached. The detector block is evidence for that person, not a finding of law, which is why it is labelled "not legal facts".

The number in brackets is a detector priority, not a probability and not a compliance score. 63 places this finding in the WARN band (50 to 79). It counts how many patterns matched, so a deliberately small example scores lower than a production hiring tool with named entity extraction on CVs, interview scoring pipelines and applicant tracking integrations. Earlier versions of this page labelled it a confidence percentage, which invited reading a pattern count as a likelihood; the tool no longer emits that wording.

The --domain employment flag activates employment-specific patterns that might not fire under the default scan. If you know your system is used for hiring, pass this flag.

Articles 9-15: what they actually require

If contextual review establishes that the system is high-risk, Articles 9 through 15 define core requirements. Here is a developer-oriented reading of each one.

Article 9: Risk management system

You need a documented process for identifying and mitigating risks throughout the system lifecycle. For recruitment AI, this means documenting known biases in your training data, testing for discrimination across demographic groups, and defining what happens when the system gets it wrong. This is not a one-off document. It is a living system with identified risks, mitigations, owners, and review cycles.

Article 10: Data governance

Training, validation, and testing data must be relevant, representative, and as free from errors as practicable. For hiring tools, the question is pointed: does your training data reflect the demographics of the candidate pool? If you trained on historical hiring decisions that were themselves biased, Article 10 requires you to identify and address that. You also need documented data management practices covering collection, labelling, cleaning, and enrichment.

Article 11: Technical documentation (Annex IV)

You must produce technical documentation following the Annex IV template before the system is placed on the market. This covers the system description, intended purpose, hardware and software requirements, design choices, training methodology, validation results, and risk management measures. It is thorough. Regula can generate a scaffold for this with regula docs ., but filling in the substance is your job.

Article 12: Record-keeping

The system must automatically log its operations to a degree that allows traceability. For a recruitment AI, this means logging every candidate decision: which candidates were scored, what scores they received, what features contributed to the score, and what action was taken. Think structured audit logs, not just print statements.

Article 13: Transparency

Candidates must be told that AI is being used in their application process. This is not optional, and it is not buried-in-the-terms-of-service transparency. The obligation is to enable deployers (the companies using your tool) to interpret outputs and use the system appropriately. Your documentation needs to cover capabilities, limitations, and the degree of accuracy tested.

Article 14: Human oversight

A human must be able to understand, intervene in, and override the system. For recruitment, this means a person reviews AI-generated rankings or recommendations before they are acted on. A hiring system where the AI output is the final decision, with no human in the loop, does not meet Article 14. The human must have the competence and authority to override.

Article 15: Accuracy, robustness, and cybersecurity

The system must achieve appropriate levels of accuracy for its intended purpose, be resilient to errors and inconsistencies, and be secured against tampering. For hiring AI, the accuracy requirement includes testing for bias across protected characteristics: gender, ethnicity, age, disability. If your model performs differently for different demographic groups, that is an Article 15 problem.

What Regula covers and what it does not

Regula can	Regula cannot
Detect risk patterns in your code that indicate high-risk classification	Test for actual bias in your hiring data
Generate Annex IV documentation scaffolds	Conduct a Fundamental Rights Impact Assessment (FRIA)
Run a gap analysis against Articles 9-15	Implement operational risk management for you
Run bias benchmarks (CrowS-Pairs, BBQ) as a starting point	Replace bias testing on YOUR candidate data

On bias testing specifically: regula bias runs established academic benchmarks (CrowS-Pairs and BBQ) against language models to check for stereotypical associations. This is a useful directional signal. It is not a substitute for testing your model on your actual candidate data with your actual feature set. If your model is a logistic regression on structured features, CrowS-Pairs does not apply at all. Know what you are testing and what you are not.

Practical walkthrough

Here is a full workflow for scanning a recruitment AI project. We will use the bundled cv-screening-app example.

Step 1: Scan for risk indicators

$ regula check examples/cv-screening-app --domain employment --scope all

This tells you which Annex III category the detected patterns point at. The output above shows Annex III Category 4 as a candidate, alongside the facts that remain unresolved. It is not a determination that the system is high-risk.

Step 2: Gap analysis against Articles 9-15

$ regula gap --project examples/cv-screening-app

Decision: insufficient_information
Jurisdiction: eu
Rule resolution: unresolved
Facts needed to resolve the next decision: 2
  - is_ai_system: Does the subject meet the governing law's definition of an AI system or regulated automated technology?
  - jurisdiction_in_scope: Does this jurisdiction's territorial and operator scope apply?

Evidence scan:
Article evidence is attached only where the decision kernel resolved the corresponding obligation.
Article observations emitted: 0; held pending applicability: 8

Eight article observations are held, not emitted. That is the point of this command: until someone establishes that the subject is an AI system and that the jurisdiction applies, Regula will not attach Article 9 to 15 evidence to it. An earlier version of this page showed a percentage score per article. That output no longer exists, and it should not: a percentage against an article reads as a compliance measurement, which is a determination Regula does not make. Example source.

Step 3: Organisational conformity check

$ regula conform --organisational

This is an interactive questionnaire that walks through the organisational requirements: do you have a risk management process, data governance policy, human oversight procedures, and so on. It generates a conformity report you can include in your compliance file.

What you need to worry about and what you probably do not

Worry about: documentation gaps (Article 11 is the most common zero-score), logging (most hiring tools log nothing useful for Article 12), and transparency notices (Article 13 is rarely implemented in code).

Probably do not need to worry about yet: conformity assessment procedures (those come at deployment, not development), notified body involvement (Annex III systems use self-assessment unless they also fall under Annex I), or post-market monitoring systems (required, but you need a working system first).

Start now regardless of the deadline: the distance between a codebase with no documented data governance and one that could survive scrutiny is not closed in a sprint. Data governance and technical documentation take months to get right, and retrofitting logging into an existing system is harder than building it in from the start.

---

Omnibus status: The dates stated here come from Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force from 27 July 2026. The earlier provisional agreement is legislative history, not the current legal basis.

Last reviewed: 14 August 2026 · Author: Kuziva Muzondo · Sources: Regulation (EU) 2024/1689, Digital Omnibus provisional agreement (7 May 2026) · Not legal advice. Regula identifies risk indicators for developer review.