12 August 2026

What the New EU Timeline Really Means for AI-Assisted Hiring

Share X in f

Priya Ellison 12 August 2026

The EU’s 2026 Digital Omnibus gave employers and hiring-technology providers more time to prepare for the main requirements governing high-risk AI. It did not remove recruitment or employment systems from the EU AI Act’s risk-based framework.

For qualifying stand-alone systems covered by Annex III—potentially including CV-ranking tools, automated shortlisting systems and interview scorers—the bulk of the relevant Chapter III regime now applies from 2 December 2027. That is an extension, not permission to stop compliance work. Prohibited practices, AI-literacy measures, some transparency requirements and other bodies of law may matter earlier.

The practical task is not to label every HR tool “high-risk” or “safe.” It is to determine what each system does, how it influences employment decisions and whether the organization acts as a provider, a deployer or both.

Updated 12 August 2026. This is a high-level compliance overview, not an article-by-article legal checklist. Questions involving classification exemptions, notices, information rights, assessment triggers, retention periods, legacy systems or exact responsibility allocation require verification against the operative legislation and the facts of the deployment.

The short answer: the Omnibus delayed hiring-AI rules, not the framework

The Digital Omnibus on AI became Regulation (EU) 2026/1744. It was adopted on 8 July 2026, published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. Its stated purpose is to simplify implementation while maintaining protections for health, safety and fundamental rights, rather than dismantling the framework. Those dates and the enacted amendments appear in the Official Journal text of Regulation (EU) 2026/1744.

Four kinds of date are easy to confuse:

Adoption is when the legislative act is formally made.
Publication places the final act in the Official Journal.
Entry into force makes the amending regulation legally effective.
Application dates determine when particular requirements must be followed.

The Omnibus was therefore in force on 27 July 2026 even though the bulk of the deferred Chapter III obligations for qualifying stand-alone Annex III high-risk systems will not apply until 2 December 2027.

A separate date—2 August 2028—applies to high-risk AI associated with regulated products covered through Annex I, such as certain AI embedded in machinery or other physical products. It is not the ordinary deadline for stand-alone recruitment software. The European Commission’s summary of the enacted AI Omnibus confirms the split between Annex III systems and AI embedded in Annex I products.

The timeline at a glance

Date	What it means for hiring and workplace AI
2 February 2025	Initial prohibited-practice and AI-literacy provisions began applying. Workplace emotion recognition can already be prohibited, subject to narrow medical or safety exceptions.
24 July 2026	Regulation (EU) 2026/1744 was published in the Official Journal.
27 July 2026	The Digital Omnibus on AI entered into force across the EU.
2 December 2027	The bulk of the deferred Chapter III regime applies to qualifying stand-alone Annex III high-risk systems, including covered employment systems.
2 August 2028	The separate high-risk regime applies to systems associated with Annex I regulated products.

The change is best understood as a targeted timetable extension accompanied by implementation simplifications. Employment remains within the high-risk architecture, and organizations still need to classify systems, allocate responsibilities and prepare controls.

For legal decisions, begin with the Omnibus and the operative AI Act. The EUR-Lex page for Regulation (EU) 2024/1689 is the base-act page and indicates that the Act has been amended; readers should use EUR-Lex’s consolidation tools to access the version incorporating the 2026 changes. The operative provisions control over recitals, summaries, draft guidance and commentary written before enactment.

Which recruitment and employment systems can still be high-risk?

Employment remains one of the areas covered by Annex III. Supported examples include AI used for targeted job advertising, recruitment, CV sorting, application analysis or filtering, candidate evaluation and selection. The framework can also cover uses affecting promotion, termination, task allocation based on individual behaviour or characteristics, and monitoring or evaluation of worker performance.

Classification should occur at the level of a system’s intended purpose and function, rather than by placing one label over an entire applicant-tracking system, HR platform or technology stack. Commission materials confirm that employment remains a high-risk area, but classification still requires analysis of the particular system.

A platform may contain components with different classifications. Its interview scheduler could be administrative, while a separate model ranking interview answers could be high-risk. Similarly, a chatbot that only reports an application’s status presents a different question from one that asks screening questions, infers suitability and determines who advances.

The following matrix is a preliminary screening tool, not a complete statement of the legal test. References to influence describe a practical factor to investigate; they do not replace the operative classification rules or system-specific legal analysis.

A function-based classification matrix

Function	Illustrative use	Preliminary view	What to examine
Candidate ranking	Scores CVs and determines the order in which recruiters review applicants	Strong high-risk candidate	Whether ranking changes who receives meaningful consideration or advances
Automated shortlisting	Selects a subset of applicants for interview	Likely high-risk	Selection criteria, exclusions, recruiter discretion and actual workflow effect
Interview scoring	Scores spoken or written answers to determine who proceeds	Likely high-risk	What is measured, how scores are used and whether low scores effectively remove candidates
Application filtering	Rejects or deprioritizes applications against model-generated criteria	Potentially high-risk	Whether the function evaluates applicants and affects access to employment
Targeted job advertising	Uses AI to decide who receives employment advertisements	Potentially high-risk	Intended purpose, targeting logic and effect on access to opportunities
Candidate sourcing	Produces or ranks shortlists from CV databases or other sources	Potentially high-risk	Whether it retrieves records or evaluates and ranks people
Promotion or termination support	Recommends who should be promoted, disciplined or dismissed	Potentially high-risk	How closely the output is connected to the employment decision
Task allocation	Assigns work using personal behaviour or characteristics	Potentially high-risk	Inputs, purpose, worker effects and decision influence
Performance monitoring	Evaluates or predicts worker performance	Potentially high-risk	Whether individuals are evaluated and how management uses the output
Interview scheduling	Offers available calendar slots without evaluating applicants	May fall outside Annex III	Whether it is genuinely administrative and contains no hidden prioritization
Status chatbot	Reports whether an application is received, pending or closed	May fall outside Annex III	Whether it only retrieves information or also screens, profiles or scores users

Draft Commission materials are intended to help providers and deployers classify systems. As of the publication status supplied for this article, they were non-binding, non-exhaustive and subject to change. The Commission’s high-risk classification guidance page expressly describes the materials as draft and the examples as non-exhaustive.

Three distinctions matter in borderline cases.

First, use by HR is not enough. A tool does not become high-risk merely because a recruiter opens it or because it connects to an HR platform. Its intended purpose, operation and relationship to a covered decision are central.

Second, the label “assistant” does not settle the issue. A CV “assistant” that determines who enters a shortlist may influence selection even if a recruiter can theoretically reverse it. A tool that only reformats recruiter notes without evaluating a candidate presents a different case.

Third, human approval is not an automatic classification exemption. A recruiter’s final click does not change the purpose for which the system was designed. Human involvement is better treated as a compliance safeguard whose quality must be tested: Can the reviewer understand the output, identify mistakes, disregard the recommendation and intervene effectively?

The AI Act contains possible treatment for certain narrow procedural, preparatory or otherwise limited functions, but Article 6(3) analysis is fact-specific. Organizations should not assume that calling a function “administrative” or adding a human approval screen prevents high-risk classification. Any reliance on that provision should be checked against the operative text and documented with qualified legal advice.

What applies now, and what waits until 2 December 2027?

The date 2 December 2027 is not a universal starting point for every rule that can affect AI-assisted hiring. It applies to the bulk of the deferred Chapter III regime for systems that qualify as stand-alone Annex III high-risk AI.

A practical compliance calendar should separate three categories.

1. Practices already prohibited

Workplace emotion-recognition AI has been prohibited since 2 February 2025, subject to narrow medical or safety exceptions. Employers should not wait until December 2027 to investigate products that claim to infer candidates’ or workers’ emotions from biometric data. The Commission’s AI Act overview identifies workplace emotion recognition as a prohibited practice and summarizes the principal controls for high-risk systems.

Product descriptions require scrutiny. Terms such as “engagement,” “sentiment,” “attentiveness,” “personality signal” or “cultural fit” do not determine the legal classification. Procurement teams should establish what data the product processes, what inference it claims to make and how the result is used.

2. Organizational and transparency duties that may apply earlier

The Omnibus amended the AI-literacy approach rather than eliminating it. Providers and deployers are expected to support sufficient, context-sensitive literacy among relevant personnel. Organizations should not treat this as a duty beginning only in December 2027.

Some Article 50 transparency requirements also remained on an earlier timetable. Whether a chatbot, synthetic-content feature or other hiring tool triggers a particular requirement depends on the system and its use. Because the applicable actor, trigger and timing can differ, organizations should check the operative provision rather than assume all transparency requirements were deferred with Chapter III.

Other legal regimes continue independently. Depending on the deployment, GDPR, national data-protection law, employment and equality law, anti-discrimination rules, collective agreements, works-council rights and worker-consultation requirements may apply before the deferred AI Act date. The Omnibus does not displace those regimes.

3. The deferred high-risk Chapter III regime

For qualifying Annex III employment systems, the deferred regime includes statutory control categories such as risk management, data governance, technical documentation, logging, information for deployers, human oversight, accuracy, robustness, cybersecurity, conformity processes, operational monitoring and incident handling. The precise content and allocation depend on the organization’s role and the operative provisions.

Myth versus reality

Myth: The Omnibus repealed the EU rules for hiring AI. Reality: It extended the implementation timetable while retaining employment within the high-risk framework.

Myth: Every tool used by an HR department is high-risk. Reality: Classification depends on intended purpose and function. A candidate-ranking model and a calendar scheduler do not necessarily receive the same treatment.

Myth: No preparation is required before December 2027. Reality: Prohibitions and other duties can apply earlier, while classification, contracting, documentation and oversight require lead time.

The safest planning assumption is not that every hiring system is high-risk. It is that every material AI use in a hiring or employment workflow deserves enough investigation to support a documented classification.

Provider versus deployer: who is responsible in a hiring workflow?

In practical terms, a provider develops an AI system—or has it developed—and places it on the market or puts it into service under its name or trademark. A deployer uses an AI system under its authority. These are role-based concepts, and their exact application should be checked against the Act’s definitions.

In a common hiring workflow, a software vendor may be the provider while an employer or staffing company is the deployer. That distinction remains important even when the vendor hosts the model, controls updates and supplies the interface.

Buying a third-party product does not transfer all responsibility away from the customer. A deployer still makes choices about configuration, input data, operating context, human oversight, monitoring and how outputs affect people. A staffing firm may therefore be a deployer when it uses a vendor-built tool to screen or rank candidates for clients.

Different controls for different roles

Provider-focused statutory categories generally concern the design and lifecycle of a high-risk system, including:

risk management;
data and data-governance requirements;
technical documentation;
appropriate logging capabilities;
instructions and information for deployers;
accuracy, robustness and cybersecurity;
conformity assessment and registration where applicable;
corrective action and post-market monitoring; and
cooperation concerning serious risks or incidents.

Deployer-focused controls generally concern operation in the workplace, including:

using the system according to provider instructions;
assigning competent people to human oversight;
monitoring operation and responding to warning signs;
addressing input data under the deployer’s control;
retaining and accessing logs under its control as required; and
escalating risks, malfunctions or incidents.

These are high-level categories, not complete legal checklists. Exact duties, retention periods and incident thresholds must be checked against the operative text. Provider and deployer obligations should not be treated as identical.

Responsibility across a three-party hiring arrangement

The following table is a practical allocation aid. “Usually” indicates a preliminary role-based view, not an automatic legal conclusion.

Issue	Technology vendor	Staffing agency	End employer
Define the marketed intended purpose	Usually provider-led	Review and avoid unapproved repurposing	Review intended use and procurement fit
Classify the supplied system	Usually provider-led	Conduct deployment analysis	Conduct deployment analysis
Configure screening criteria	Supply appropriate controls	May configure or operate	May direct or approve criteria
Supply technical materials and instructions	Usually provider-led	Obtain and follow relevant materials	Obtain materials where it deploys or controls use
Human oversight	Enable effective oversight	Assign competent reviewers for its use	Assign competent reviewers for its use
Input data	Address design-related controls	Address data under its control	Address data under its control
Logs	Enable appropriate logging	Secure practical access where required	Secure practical access where required
Candidate or worker communications	Supply necessary product information	Depends on trigger and workflow	Depends on trigger and workflow
Monitoring and escalation	Conduct provider-side monitoring and response	Monitor deployment and notify relevant parties	Monitor deployment and notify relevant parties
Allocation between agency and employer	Contractual cooperation required	Shared or unresolved—legal review	Shared or unresolved—legal review

Contracts should identify who performs each task, but contractual allocation does not necessarily alter a party’s statutory role. An agreement stating that the vendor “handles AI Act compliance” is not a substitute for analysing how the customer uses the product.

Role changes are possible. Rebranding a system, making a substantial modification or repurposing a product for a high-risk intended use may cause an employer, staffing agency or integrator to assume provider responsibilities. Routine configuration should not automatically be equated with substantial modification; the change, intended purpose and resulting system require fact-specific analysis. A legal briefing on provider, deployer and high-risk-system obligations discusses these distinctions and possible role changes.

The controls expected around high-risk hiring AI

The Act supplies statutory control categories, but organizations must turn them into working processes. The distinction between a legal requirement and a prudent implementation choice matters. The law establishes role-specific obligations; an organization decides how to operationalize them in its workflow.

Risk management

For providers, risk management is a lifecycle discipline rather than a one-time assessment. It connects foreseeable harms, testing, mitigations, changes and post-market evidence.

Deployers can contribute operational evidence: where recruiters misunderstand outputs, when candidate populations differ from expected conditions and whether recommendations produce recurring anomalies. Even when the provider owns the formal risk-management system, the deployer should have a route for reporting deployment risks.

A prudent implementation choice is to maintain a risk register for each significant hiring system. Record the affected decision, possible failure, affected population, detection method, mitigation, owner and escalation threshold.

Data quality and governance

Providers generally address design-level governance of training, validation and testing data where those datasets fall within the statutory requirements. Deployers are more likely to control local inputs, configurations and the context in which outputs are interpreted.

Employers should ask whether validation reflects the relevant language, occupation, candidate population and operating conditions. A general performance figure does not establish suitability for every role or deployment.

Documentation and information for deployers

Providers of high-risk systems have information obligations intended to support appropriate deployment. As a contractual and procurement matter, customers should secure usable access to:

the intended purpose and unsupported uses;
operating instructions and configuration constraints;
relevant performance and validation information;
known limitations and foreseeable failure modes;
the meaning and interpretation of outputs;
human-oversight features;
update and change notices;
relevant cybersecurity information;
log availability and export methods; and
incident-investigation and regulatory support.

The practical standard should be usability, not mere existence. A generic sales sheet or inaccessible compliance portal may not equip recruiters to oversee a model.

Logging and monitoring

A provider may need to design appropriate logging capabilities, while a deployer may need to retain and use logs under its control. Those responsibilities cannot work effectively if the customer cannot export records, connect them to a hiring decision or understand what an event means.

Before contracting, organizations should test whether the system records the model version, configuration, inputs, outputs, relevant timestamps, user actions and overrides to the extent necessary and lawful. Exact retention periods should be checked against the operative AI Act and other applicable law; this article does not prescribe a universal period.

Human oversight that works

Human oversight is an operational design question, not a checkbox. Reviewers need:

enough competence to understand the system’s purpose and limits;
access to evidence needed to question an output;
authority to disregard or override a recommendation;
sufficient time to conduct a real review;
awareness of automation bias; and
a clear escalation route for recurring or serious problems.

A nominal approval button is weak evidence of effective oversight. Organizations should test whether recruiters can identify deliberately inserted errors, explain why a recommendation is unsuitable, disregard it without penalty and document an intervention.

The Act should not be summarized as categorically forbidding every AI-assisted final hiring decision. But a human click should not be treated as automatic compliance.

Accuracy, robustness and cybersecurity

Providers generally bear design-level requirements concerning appropriate accuracy, robustness and cybersecurity. Deployers still affect real-world performance through configuration, input quality, access controls, integrations and update management.

Procurement teams should obtain performance limitations, not just headline claims. They should ask how the product behaves with missing information, unusual CV formats, language variation, integration failures, adversarial inputs and model drift.

Incident handling and change management

As prudent implementation practice, an organization using a significant hiring system should define:

who can pause the tool;
who preserves relevant evidence;
who contacts the provider;
who assesses affected decisions;
who determines whether notification or remediation is required; and
who authorizes a return to service.

Updates deserve separate controls. A change to a model, data source, scoring logic or intended purpose can invalidate earlier testing or alter classification. Contracts should require meaningful notice of material changes and identify when revalidation is expected.

Vendor due-diligence checklist

Before acquiring or renewing an AI-enabled hiring product, ask:

What is the documented intended purpose?
Which functions use AI, and which use deterministic workflow rules?
Does the provider classify the system as high-risk, non-high-risk or subject to another treatment—and why?
Who acts as provider, deployer, importer, distributor or product manufacturer?
Does the proposed use remain within the stated intended purpose?
What training, validation and testing information can lawfully be supplied?
For which populations, languages, roles and conditions was the system validated?
What are the known limitations and failure modes?
Can the customer access, export and interpret relevant logs?
What human-oversight controls are built in?
Can reviewers override or disable recommendations?
How are material model and product updates communicated?
What cybersecurity information and assurance are available?
How will the vendor cooperate with incident investigations?
What support is available for regulators, audits and affected-person inquiries?
What happens to documentation and logs when the contract ends?

A strong contract supports compliance but cannot replace operational governance. Employers must still ensure that recruiters use the product consistently with its limitations and that oversight works in real decisions.

AI literacy, bias testing, and fundamental-rights assessments after the Omnibus

The Omnibus reframed AI literacy as an organizational, context-sensitive support duty. Providers and deployers are expected to support sufficient literacy among relevant people rather than guarantee that every individual reaches a fixed prescribed level.

That does not mean giving everyone the same introductory course:

Recruiters need to understand outputs, limitations, override procedures and escalation.
Procurement teams need to question intended purpose, classification, validation, logging and contractual cooperation.
System administrators need to manage permissions, configurations, updates and integrations.
Oversight personnel need deeper knowledge of failure modes, monitoring and intervention.
Incident responders need evidence-preservation and escalation processes.

As prudent evidence of implementation, organizations should document the measures offered, their intended audience, participation records, practical exercises and identified gaps.

Sensitive data and bias analysis

The Omnibus creates a potential route for processing special-category personal data for bias detection or correction, but only when strict necessity and safeguards are satisfied. It is neither unrestricted permission to collect sensitive candidate data nor a universal requirement to conduct bias correction.

Supported safeguards include:

testing and documenting whether other data could achieve the purpose;
recording why the processing is strictly necessary;
limiting access to authorized personnel;
applying appropriate security and pseudonymisation;
technically restricting reuse for other purposes;
limiting retention; and
deleting the data when it is no longer necessary.

Organizations must separately evaluate the applicable data-protection requirements. “Fairness testing” is not, by itself, blanket authorization to collect or reuse special-category data. A post-Omnibus legal analysis of AI literacy, sensitive-data safeguards and impact assessments explains the strict-necessity conditions and confirms that the provision does not create a general duty to conduct bias detection or correction.

DPIAs and fundamental-rights impact assessments

Existing work from a GDPR data-protection impact assessment may support an AI Act fundamental-rights impact assessment to the extent it addresses relevant issues. Reusing an accurate system description, data map, affected-population analysis or mitigation record can reduce duplication.

The assessments nevertheless remain legally distinct. They have different legal bases, triggers and required areas of analysis. Renaming a DPIA or attaching it to an AI-governance file does not necessarily satisfy an AI Act assessment requirement.

Organizations should determine whether a fundamental-rights impact assessment is triggered for the particular deployer and use case. It would be unsafe to say that every employer must complete the same assessment under identical conditions. The operative provisions, the organization’s status and any applicable final guidance should be checked before relying on a standard template.

What the rules mean for candidates and workers

The AI Act’s stated objectives include supporting trustworthy, human-centric AI while protecting health, safety and fundamental rights. Candidate screening and worker evaluation receive heightened scrutiny because their outputs can influence access to employment, continued work and workplace opportunities.

For candidates, an important distinction is often between a tool that organizes information and one that evaluates them. A calendar function may reduce administrative work. A ranking model can change who is seen first, who reaches interview or which applications receive meaningful review.

High-risk governance is intended to make influential systems more accountable through documented operation, appropriate information, monitoring, oversight and routes for intervention. It does not guarantee that every AI-supported decision will be correct, but it is designed to reduce reliance on invisible or unreviewable scoring.

Secondary legal analysis identifies workplace-information duties involving affected workers and worker representatives, as well as a qualified ability to request information concerning certain decisions based on high-risk AI outputs. The recipients, triggers, timing and required content should not be treated as universal without checking the operative text. A worker-representative provision does not automatically establish an identical notice for every job applicant, and a qualified information right should not be described as an unconditional right to an explanation for every AI-influenced outcome.

Employers should design communications around the actual legal trigger and audience. Depending on the applicable rule, useful information may include that AI is being used, the system’s purpose, how its output enters the decision process, where a person can raise a concern and how an appropriate human review can be requested.

The December 2027 deferral does not suspend GDPR rights, anti-discrimination protections, national employment law or collective-representation requirements. Candidates and workers may therefore have relevant protections before the deferred high-risk regime begins.

HRaizon describes its work as vendor-neutral educational content for candidates and HR professionals, as explained in its editorial mission.

This article is informational only and is not legal, HR or employment advice. Hiring laws vary and change, and applicability depends on the employer, system, role and jurisdiction. Readers should verify current requirements with qualified counsel, consistent with HRaizon’s terms and advisory limitations.

A phased preparation plan for employers, staffing firms, and vendors

The extension is most valuable when used as an implementation window. Waiting until late 2027 would compress system discovery, classification, contract negotiation, testing and staff preparation into the same period.

Phase 1—now: build the inventory

Inventory AI used across:

job advertising;
candidate sourcing;
CV parsing and screening;
matching and ranking;
application questions and chatbots;
assessments and interviews;
scheduling;
background or eligibility workflows;
onboarding;
promotion and performance analysis;
task allocation; and
worker monitoring.

Do not rely only on the main procurement system. AI functions may enter through add-ons, integrations, staffing suppliers, business-unit subscriptions, general-purpose models, browser tools or vendor updates.

For each system, record:

vendor and product;
system owner;
intended purpose;
actual use;
decisions influenced;
affected people;
inputs and outputs;
provider and deployer roles;
human intervention points;
vendor and integration dependencies;
available documentation;
log availability;
deployment countries; and
update history.

An inventory is not a classification. It is the evidence base for one.

Phase 2—classification and gap analysis

Place each use into a working category:

Potentially prohibited
Likely Annex III high-risk
Likely outside Annex III or lower risk
Unresolved

Document the reasoning rather than recording only the result. For an interview scheduler, note whether it merely offers available times or prioritizes candidates using inferred suitability. For a CV tool, record whether it extracts fields, applies human-set filters, predicts suitability, ranks applicants or determines who advances.

Any reliance on Article 6(3) treatment for procedural, preparatory or otherwise limited functions should be narrow and fact-specific. Administrative labeling alone does not avoid high-risk classification. Because the precise conditions and consequences require operative-text review, borderline cases should go to qualified counsel with the system description, workflow, screenshots, instructions and contract—not just the product name.

Maintain separate workstreams:

A provider workstream should address system design, data governance, technical documentation, risk management, applicable conformity processes, logging functionality, cybersecurity and post-market monitoring.
A deployer workstream should address instructed use, local configuration, input data, oversight, monitoring, practical log access, workplace processes and incident escalation.

An organization occupying both roles will need both workstreams.

Phase 3—implementation

Assign a named owner for each significant system and a central owner for the overall program. The responsible team should then:

establish human-oversight roles and authority;
create monitoring thresholds and review schedules;
define incident and risk-escalation workflows;
obtain missing instructions and validation material;
remediate vendor contracts;
test log access and export;
document role-specific AI-literacy measures;
plan performance and workflow testing;
integrate AI review into procurement and change management; and
establish reassessment triggers for updates or repurposing.

Testing should reflect the real workflow. It should determine whether recruiters understand outputs, detect unsuitable recommendations, intervene effectively and document departures from the system. It should also examine whether time pressure or interface design encourages rubber-stamping.

Track guidance and maintain a source hierarchy

The Commission classification materials available for this article were draft, non-binding and non-exhaustive. Organizations should monitor their finalization and reassess classifications when official guidance changes.

Maintain a legal-source register in this order:

Regulation (EU) 2026/1744;
the AI Act version consolidated to incorporate the Omnibus;
final Commission guidance and applicable regulator materials;
relevant national law and guidance; and
secondary commentary used for interpretation and implementation ideas.

For each source, record its publication date, legal status, relevant provision and the internal policies or classifications that depend on it. This reduces the risk of relying on a provisional client alert after final legislation has changed the position.

The next 90 days

Organizations do not need to complete an entire high-risk compliance program immediately. They should establish control over the work:

Appoint an accountable owner for hiring-AI governance.
Complete an initial system inventory, including tools used through staffing firms and integrations.
Identify and stop or escalate potentially prohibited functions, especially workplace emotion recognition.
Classify the highest-impact tools first, including automated shortlisting, CV ranking and interview scoring.
Contact vendors for intended-purpose statements, classification reasoning, instructions, validation information, limitations and log access.
Map provider and deployer roles across the vendor, staffing agency and end employer.
Schedule qualified legal review for prohibited, likely high-risk and unresolved deployments.

Frequently asked questions

Did the 2026 Omnibus remove AI hiring systems from the EU AI Act’s high-risk category?

No. Employment remains within the Annex III high-risk framework. Systems used for covered recruitment, application filtering, candidate evaluation, selection and other employment decisions can still qualify as high-risk.

The Omnibus changed implementation dates and some administrative requirements. It did not repeal the employment category or convert every recruitment system into a lower-risk system.

When do the main high-risk rules for qualifying recruitment AI apply?

The bulk of the deferred Chapter III regime for qualifying stand-alone Annex III systems applies from 2 December 2027. The separate 2 August 2028 date concerns high-risk AI associated with Annex I regulated products and is not the ordinary date for stand-alone recruitment software.

Other requirements may apply earlier, including prohibited-practice rules, AI-literacy measures and potentially relevant transparency obligations.

Is every AI tool used by an HR department high-risk?

No. Classification depends on the system’s intended purpose and function, not simply the department using it.

A tool that ranks CVs to determine who advances is a strong high-risk candidate. A calendar tool that only offers interview times may fall outside Annex III if it does not evaluate, profile, prioritize or otherwise influence candidate selection. Each function should be assessed separately.

Does using a third-party hiring platform remove an employer’s AI Act responsibilities?

No. The vendor may be the provider, but an employer or staffing agency can remain a deployer. Relevant deployer controls can include instructed use, competent human oversight, monitoring, management of input data under its control, access to required logs and escalation of risks or incidents.

Contracts should allocate cooperation and deliverables clearly, but they do not automatically transfer statutory responsibility. Rebranding, substantial modification or repurposing for a high-risk use may also cause a customer or integrator to assume provider responsibilities, subject to fact-specific analysis.

Can employers use sensitive personal data to test a hiring system for bias?

Potentially, but not freely. The post-Omnibus route is conditioned on strict necessity and safeguards such as testing whether other data would suffice, documenting necessity, restricting access and reuse, applying security and pseudonymisation, limiting retention and deleting data when it is no longer needed.

The provision does not create a universal obligation to conduct bias testing, and “bias testing” is not blanket authorization to collect special-category data. Employers should examine the AI Act, applicable data-protection law and deployment-specific risks before proceeding.

The useful takeaway is not that employers can ignore hiring AI until December 2027. The Omnibus created a longer implementation window while leaving the risk-based framework intact. Organizations should use that window to identify what each system does, document whether it influences employment decisions, distinguish provider from deployer roles, stop prohibited uses, strengthen oversight and vendor cooperation, and verify unresolved duties against the operative AI Act with qualified legal advice.