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 classification is broad. It does not matter whether your system uses a logistic regression or a large language model. What matters is the intended purpose. If the software is designed to influence who gets hired, shortlisted, or rejected, it falls here.

The Digital Omnibus (provisional agreement 7 May 2026, approved by European Parliament on 16 June 2026) defers the compliance deadline for Annex III high-risk systems to 2 December 2027. The Council approved it on 29 June 2026; publication in the Official Journal is expected before 2 August 2026. Until then, the original deadline of 2 August 2026 technically remains in force.

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 that trigger high-risk classification

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
============================================================

  Verdict: HIGH-RISK
  Your project is classified as high-risk under EU AI Act Annex III.
  You must comply with Articles 9-15 before the enforcement deadline.
  Files scanned:      1
  High-risk:          1
  INFO tier:          1

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

  Questions for human review (1):
    ? app.py:1 — Annex III, Category 4
      Employment and workers management (confidence: 43%)
============================================================

The confidence score of 43% tells you how many indicators matched. In this case the example is deliberately small, so the score is low. A production hiring tool with richer patterns (named entity extraction on CVs, interview scoring pipelines, applicant tracking integrations) will score higher.

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

Once your system is classified as high-risk, seven articles define what you need to do. 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 whether Regula detects high-risk patterns and which Annex III category they fall under. The output above shows it: Verdict HIGH-RISK, Annex III Category 4.

Step 2: Gap analysis against Articles 9-15

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

EU AI Act Compliance Gap Assessment: cv-screening-app
Highest risk tier: high_risk
Overall score:     29%

Article 9   Risk Management                     [ 60%] MODERATE
  Gap: Risk documentation lacks structured mitigations

Article 10  Data Governance                     [ 30%] PARTIAL
  Gap: No bias detection or fairness checking libraries found

Article 11  Technical Documentation             [  0%] NOT FOUND
  Gap: No Annex IV technical documentation found

Article 12  Record-Keeping                      [ 30%] PARTIAL
  Gap: No structured or auditable logging format detected

Article 13  Transparency                        [  0%] NOT FOUND
  Gap: No user-facing AI disclosure found in code

Article 14  Human Oversight                     [ 45%] PARTIAL
  Gap: No evidence that AI outputs are reviewed before action

Article 15  Accuracy, Robustness, Cybersecurity [ 40%] PARTIAL
  Gap: No test files found

The gap report shows you exactly where your project falls short, article by article. A 29% overall score is typical for a project that has not started compliance work yet.

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 gap between 29% and compliant 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 caveat: All dates referencing the Digital Omnibus are based on the provisional political agreement of 7 May 2026, approved by the European Parliament on 16 June 2026. The Council approved it on 29 June 2026; publication in the Official Journal is expected before 2 August 2026. Until OJ publication, the original EU AI Act deadlines technically remain in force.

Last verified: 25 June 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.