AI Assurance Institute Logo AI Assurance Institute

What Companies Should Do to Reduce the Risk of Legal Action

AI in Recruitment


AI Risk Management

Article 5 of 6

AI recruitment tools are not unlawful. Using them without control is what creates trouble. The iTutorGroup settlement showed how quickly hard filters based on protected characteristics become enforcement cases. Mobley v. Workday shows that ranking and screening systems can draw both employers and vendors into discrimination litigation. The practical response is not to abandon technology. It is to govern it.

1. Know which tools you use and what they decide

Build an inventory of AI and automated tools in hiring: sourcing, CV screening, ranking, assessments, video analysis, chatbots and interview scheduling. For each tool, record:

If leadership cannot name the systems that decide who reaches a human recruiter, the organisation does not control its hiring risk.

2. Keep humans in meaningful control of high-impact decisions

Automated screening should not be an invisible wall. Define points where a qualified human reviews edge cases, overrides scores, or samples rejected candidates. "Human in the loop" only helps if the human has authority, information and time to intervene. Rubber-stamping a ranked list is not oversight.

3. Test for discriminatory outcomes

Do not assume a vendor's marketing claims are enough. Where legally permitted, monitor selection rates and progression by relevant groups, and investigate significant disparities. Ask vendors for bias testing methodology, scope and limitations. Document what was tested, when, and what changed as a result. In a dispute, "we never looked" is a weak position.

4. Avoid hard filters tied to protected characteristics

Age cut-offs, proxies that effectively encode age, disability-related exclusions, or criteria that unnecessarily disadvantage protected groups are high-risk. iTutorGroup is the simple version of this problem. Review rules, knockout questions and model features for the same effect even when the characteristic is not named directly.

5. Demand job-relatedness and evidence

Selection criteria should relate to the role. If a model favours certain career paths, schools or CV wording, the organisation should be able to explain why that predicts job performance. Where it cannot, narrow the automation or move candidates to human review sooner.

6. Manage vendors as part of the hiring process

Contracts should cover:

Vendors may face increasing direct exposure, as arguments in Mobley illustrate. Employers still choose the tool and often control how it is deployed. Due diligence and clear allocation of responsibilities are essential.

7. Keep records that explain the process

Retain configuration history, versions of models or rules used, job criteria, recruiter overrides, and reasons for major process changes. If a candidate or regulator asks why someone was rejected at the automated stage, the organisation needs an answer grounded in records, not reconstruction from memory.

8. Be transparent with candidates where required - and sensible even where not

Tell candidates when automated systems play a significant role in screening or assessment, and provide a route to ask questions or request human review where appropriate. Transparency will not eliminate all claims, but opacity increases suspicion and weakens trust with regulators and courts.

9. Train recruiters and hiring managers

People using AI outputs need to understand limitations, prohibited criteria, and when to challenge a score. Technology risk becomes people risk when staff treat model output as neutral truth.

10. Connect hiring AI to wider governance

Recruitment systems process personal information, affect access to work, and can trigger discrimination and regulatory scrutiny. They belong in the organisation's privacy, risk and AI governance processes - including impact assessment, security, retention and board-level visibility of material risk - not only in HR operations.

11. Meet the GDPR duties that sit on the same process

Every tool in the inventory that uses CVs, scores, video or similar material is processing personal data. The employer is normally the controller. Name a lawful basis for each purpose. Screening for a stated vacancy is not the same as building a standing talent pool or allowing a vendor to train models on candidate data.

If a score auto-rejects a person, or if a human only rubber-stamps the ranked list, treat that as a candidate for Article 22. Give the person a route to human intervention, to express their view, and to contest the outcome. Video analysis of faces, voice profiling, or inference of health or disability can engage Article 9 and needs a specific ground.

Complete a data protection impact assessment under Article 35 where people are evaluated systematically at scale and access to work is at stake. The DPIA should describe the actual signals and thresholds, not only the product name. Put processor terms in the vendor contract so the supplier may only process on documented instructions, including whether it may train or improve models.

12. Be able to answer an access request

Article 15 is often how a claim starts. A candidate can ask for their file, their score or rank, and, where Article 22 is engaged, meaningful information about the logic involved. "The model decided" is not an answer. Build a process that can retrieve, within the statutory time, the application record, the version of the tool used, the score, recruiter overrides, and a usable explanation of what the system was predicting.

The vendor must assist under Article 28. If the contract leaves the employer unable to obtain that material, fix the contract before the first request arrives. Trade-secret limits can restrict model detail. They do not cancel the candidate's right to their own data.

13. Treat high-risk recruitment use as an AI Act duty

Annex III treats many recruitment and selection systems as high-risk. Decide whether the organisation is the provider, the deployer, or both. Article 25 can treat a deployer as a provider if it puts its name on the system, substantially modifies it, or changes the intended purpose.

Deployers have Article 26 duties: follow the instructions for use, assign competent human oversight, monitor operation, and keep logs under their control. Points 2, 7 and 9 above are how those duties look in a hiring team. They are not optional extras once the use is high-risk.

Article 27 requires a fundamental rights impact assessment before first use for specified deployers of Annex III systems: bodies governed by public law, private entities providing public services, and deployers of the credit and insurance systems in Annex III, points 5(b) and 5(c). A private employer is not automatically inside Article 27. Public employers, and private bodies delivering public services, often are. Where a FRIA is required, complete it before first use and keep it with the DPIA and the hiring-tool inventory. Where it is not required, equality law and the GDPR still require the organisation to know who the ranking system filters out.

The standard to aim for

A defensible approach is easy to state and harder to operationalise: know the tools, understand what they optimise for, test their effects, keep humans able to intervene, document decisions, and hold vendors to evidence rather than assurances.

That will not make every unsuccessful candidate satisfied. It will make it much harder to argue that the organisation deployed a black box and hoped for the best. In the current enforcement and litigation climate, that difference matters.