A product lead at a UK recruitment technology company said something during a scoping call that has stuck: "We are not an AI company. We are a hiring platform that uses some machine learning for ranking."
That sentence is how most of this sector arrived at its current position. The distinction feels meaningful internally, where AI is one feature among many. It carries no weight at all in the regulation, in an employment tribunal, or in an enterprise procurement questionnaire.
Named in the regulation
Employment, worker management, and access to self-employment are explicitly listed among the high-risk categories in Annex III of the EU AI Act. This is not an inference from general principles or a reading of intent. The category is named.
Most recruitment and HR technology firms discovered this after the product was built, and a meaningful number still do not know it applies to them, for the reason the product lead gave. They think of themselves as software companies with a feature, rather than as providers of an AI system in a named high-risk category. The regulation does not make that distinction, and neither do the buyers who have read it.
The date has moved, the category has not. The original timetable set 2 August 2026 as the application date for high-risk obligations. The Digital Omnibus on AI, proposed by the European Commission in November 2025, amended this. Political agreement was reached on 7 May 2026, the European Parliament endorsed it on 16 June, and the Council gave final approval on 29 June 2026. Annex III standalone obligations, which include employment and worker management, now apply from 2 December 2027. The transparency obligations under Article 50 were not deferred and apply from 2 August 2026 as originally scheduled.
The obligations themselves are unchanged in substance. A provider or deployer still needs a risk management system, data governance documentation, technical documentation, human oversight procedures, and a fundamental rights impact assessment where required. Building that retrospectively inside a hiring platform already running in production is materially harder than building it in from the start.
What counts as employment AI
The category is broader than most firms assume, and it captures tools that rank, score, or prioritise rather than decide.
CV screening, parsing, and ranking. Candidate matching and sourcing, including outbound tools that decide who is shown a role. Video and asynchronous interview analysis. Assessment scoring, psychometrics, and skills inference. Promotion, allocation, and performance evaluation tooling. Task allocation and workforce management, including shift and route assignment. Monitoring and productivity analytics.
The common argument against inclusion is that the tool only suggests and a human decides. That argument is weaker than it feels. A ranking that determines which twenty of four hundred applications a recruiter reads has decided the outcome for three hundred and eighty people, and the human review at the top of the list does not reach them. Any inventory that classifies ranking as low impact because a human is nominally in the loop will not hold up under scrutiny.
UK exposure without the EU AI Act
A UK firm with no EU market presence is not therefore unexposed. The Equality Act 2010 creates liability for indirect discrimination where a provision, criterion, or practice puts people sharing a protected characteristic at a particular disadvantage and cannot be objectively justified. Nothing in that turns on whether a human or a model applied the criterion.
A screening tool that systematically disadvantages a protected group creates legal exposure for the employer deploying it and commercial exposure for the vendor supplying it. The employer is the respondent in the claim. The vendor is the party the employer turns to immediately afterwards, both for an explanation and, depending on the contract, for a contribution.
The ICO published its AI tools in recruitment audit outcomes report on 6 November 2024, following consensual audits conducted between August 2023 and May 2024. It found tools inferring gender and ethnicity from candidate names, and tools allowing recruiters to filter out applicants with protected characteristics. Nearly 300 recommendations were issued and accepted, collated into seven key recommendations. It followed DSIT's Responsible AI in Recruitment guide of March 2024.
The practical reality underneath all of it: an employment tribunal will ask how the tool worked, what it was trained on, and who checked it. "It is proprietary" is not an answer that improves the position.
The provider and deployer split
The EU AI Act distinguishes the provider, which develops and places the system on the market, from the deployer, which uses it. An HR technology vendor is typically the provider. The employer using the tool is typically the deployer. Obligations differ: providers carry the heavier burden on risk management, data governance, technical documentation, and conformity, while deployers carry obligations around use in accordance with instructions, human oversight, input data, and informing affected workers.
This split matters commercially in HR technology more than almost anywhere else, because the deployers are large employers with procurement functions and legal teams. A deployer under obligation cannot meet it without information from the provider. So the requirement travels up the supply chain through contract terms and questionnaires, and it arrives at the vendor whether or not the vendor considers itself in scope.
The commercial pressure therefore lands on the vendor either way. Understanding your role determines your obligations. It does not determine who gets asked.
What buyers are starting to ask
Enterprise HR buyers, particularly those with EU operations or works councils, are adding AI governance sections to procurement. The questions are consistent enough to prepare for:
What data was the model trained on, and does it reflect our applicant population. How is bias tested, against which characteristics, using which metrics, and how often. What human oversight does our configuration require, and what happens if we turn it off. What documentation can you provide for our own compliance file, and will you keep it current. What happens when you retrain the model, and how are we told.
A vendor that cannot answer these loses deals to one that can, and it happens well before any regulator is involved. That is the near-term commercial case, and it is usually more persuasive to a board than the regulatory one because the loss is measurable this quarter.
What ISO 42001 evidences for an HR tech vendor
An AI system inventory with documented purpose, affected parties, and the decisions the system influences. Impact assessment covering the individuals subject to the outcomes, which in this sector means candidates and employees rather than customers. Bias testing methodology with documented results tracked over time rather than a single validation snapshot. Training data governance and lineage, including what the data represents and what it does not. Human oversight design, specified to the level of what the deployer must configure and what the product enforces. Transparency documentation the deployer can lift into its own compliance file. Third party model governance where a foundation model sits underneath the product and its behaviour can change without your involvement.
State the limit clearly. ISO 42001 certification is not regulatory compliance. It does not discharge EU AI Act obligations, it is not a defence to an Equality Act claim, and no regulator requires it. What it does is produce, in an auditable and independently checked form, most of the evidence those regimes and those buyers ask for.
The bias testing problem
This is where most HR technology firms are weakest, and it is worth being specific.
The common pattern: bias was tested once, at build, against whichever protected characteristics the team happened to have data for, using a metric chosen by whoever ran the test, with the result recorded in a document that has not been opened since. That is a validation artefact. It is not a governance process, and it will not survive a serious question.
A defensible approach has five parts. Defined characteristics, chosen deliberately and with a documented rationale for what is tested and what cannot be, given the data lawfully available. Defined metrics, chosen for the decision type, with the reasoning recorded, because different fairness metrics conflict and picking one is a judgement that has to be owned. Defined cadence, tied to retraining and to elapsed time, so a stable model is still checked. Documented results, retained, so the trend is visible rather than only the latest figure. And a defined route from a failed test to a remediation decision, with a named owner and an authority to withhold release.
That last part is the one that is almost always missing. A bias test with no defined threshold for action is documentation rather than governance. It records a number. It does not commit anyone to doing anything about it, and a buyer's legal team will spot that in a single follow-up question.
Sequencing for an HR tech vendor
Establish role and classification first, because the answer determines the obligation set and the size of everything after it. Provider or deployer, in scope or out, high-risk or not, per product and per market.
Build the management system next, prioritised by the classification rather than by the order of the Annex.
Produce the deployer-facing documentation as a distinct, deliberate output rather than a by-product. This is the piece that converts into pipeline: a pack the buyer's compliance function can use directly, kept current, shipped with the product. Vendors that treat it as an internal document with the logo changed can be identified immediately, and are.
Certification last, when the commercial case supports it. In this sector the case tends to arrive earlier than in others, because the buyers are large, the category is named in the regulation, and the alternative to evidence is argument.
An AI governance readiness assessment establishes your classification, your role as provider or deployer, and the gap against both regulatory expectations and what your buyers are already asking. Book a scoping call.