AI Bias in CV Screening: What Should Recruiters Check?

Where does bias in screening tools come from?

CV screening tools read a CV and score it against criteria set by the employer. Guidance from the UK Department for Science, Innovation and Technology (DSIT) explains that these tools are often trained on historical hiring data, so they can carry forward the bias of past decisions and may rely on proxy indicators unrelated to the job. ^[1]

Examples in the guidance include scoring employment gaps in ways that disadvantage parents, carers and disabled people, and comparing applicants with past “ideal” CVs in ways that reinforce the under-representation of some groups. ^[1] US Department of Justice guidance warns that selection tools can screen out people with disabilities even without any intent to discriminate, and that the employer remains responsible when using a tool developed by another company. ^[3]

In Gulf workplaces there is a third risk. NIST’s Generative AI Profile notes that language models may perform less well in non-English languages and certain dialects. ^[4] An Arabic CV may be read less accurately than its English equivalent, which is bias even if nobody intended it.

Start from the role criteria, not the tool

Before assessing the tool, write down what the role actually needs: the required qualification, the type and length of experience, the skills that can be evidenced, and the languages required and at what level. Any criterion you cannot link to a task in the job description deserves a second look. For each criterion, set the evidence a CV must show: a certificate, a job title, or a project described by its result.

The Department of Justice guidance stresses that a test should measure the skills the job requires, not unrelated sensory, manual or speaking abilities. ^[3] The same question applies to screening: does the tool measure competence, or how closely the CV resembles those of people hired before?

What to ask the vendor before you buy

DSIT guidance recommends that buyers ask suppliers for evidence behind their claims, such as impact and risk assessments and data protection impact assessments, and check how the system performs across groups through bias audits and performance testing. ^[1]

The findings of audits carried out by the UK Information Commissioner’s Office (ICO) on developers of recruitment tools between August 2023 and May 2024 show why these questions matter. Some tools inferred a candidate’s gender and ethnicity from their name instead of asking, some allowed recruiters to filter candidates by protected characteristics, some collected more data than necessary, and at least one provider had launched its tool without formal accuracy testing. ^[2] The audits also found contracts that were vague about each party’s data protection role, providers keeping candidate data indefinitely, and some reusing data they had collected for other purposes. ^[2]

So put in the contract: each party’s data protection role, the retention period for candidate data, a ban on using it for any other purpose, the vendor’s obligation to notify you before changing the model or version, and your right to see the results of periodic bias audits. Asking the questions before you buy is not enough unless the answers become written commitments.

How to run a useful comparison before go-live

Build a set of hypothetical CVs matched for experience and qualifications, then change one element the role does not need in each version:

• CV layout: one column or two, table or prose.
• CV language: Arabic, English or a mix of both.
• How the qualification is written: in full or abbreviated, or the university name in Arabic or English.
• A gap in the work history, with or without a stated reason.

Record the results in a simple table: the pair number, the element changed, each version’s score, the difference, and whether the difference changed the pass decision. Decide in advance what size of difference triggers investigation, so that differences are not explained away after they appear.

If the score changes when an element unrelated to the job changes, you have found a source of bias to fix before go-live. Also review a sample of CVs the tool rejected during the trial and look for candidates who should have passed. DSIT recommends piloting the system before deployment with a diverse range of users and testing its performance in your own environment. ^[1]

Collecting data on candidate groups for wider analysis needs a lawful basis in your country. The ICO audits found that data inferred from names was too imprecise to monitor bias and was often processed without a lawful basis. ^[2]

Reading quality: an overlooked source of bias

Before a tool scores a CV, it extracts fields: job title, employer, start and end dates, qualification. If it misreads a particular type of CV, everyone who uses that format is disadvantaged in the same way. Compare the extracted fields with the original CV in a sample that reflects the layouts you actually receive.

Hypothetical example

A hypothetical organisation trialled a tool to screen Arabic and English CVs for a customer service role. The review found that the tool read employment dates consistently in English layouts but misread Arabic layouts that set dates right to left in a table, so it calculated shorter experience than candidates actually had. The team went back to the original CVs, asked the vendor to fix the reading, added a manual review route for any CV with low extraction quality, and reran the trial with the same set before go-live.

Human review that actually corrects

A member of staff clicking “approve” on a ranked list is not review. The ICO audits noted that some human reviews were informal and carried out by untrained staff, and recommended that tool scores should not be used for automated decisions where the tool was not designed for that, and that candidates should have a way to challenge decisions. ^[2]

Let the reviewer see the evidence behind the score, not just the score. Tell applicants that the tool is used and how they will be assessed, and set up a clear procedure for requesting an adjustment that does not harm the chances of those who use it, as the Department of Justice guidance recommends. ^[3] After go-live, repeat performance testing and bias audits regularly, because model performance can drift over time. ^[1]

Stop automated screening if review reveals material errors you cannot control, if a new version of the tool arrives without a documented test, or if you cannot explain why a candidate was rejected.

Applying this in the Gulf

The sources cited here are American and British; they are examples of good practice, not laws in force in the Gulf. Check the labour rules in your country, such as those issued by the Ministry of Human Resources and Social Development (HRSD) in Saudi Arabia and the Ministry of Human Resources and Emiratisation (MoHRE) in the UAE, together with the personal data protection laws in force.

Where nationality is a legitimate criterion for the role under localisation programmes, make it an explicit, documented requirement applied by the team, not something the tool infers from a name or university. When buying, ask for documented testing and what changes between versions, and test the tool on the local languages and qualifications you actually receive, checking specifically that it does not give Arabic CVs lower scores than their English equivalents or read qualifications from local universities differently.

Conclusion

A screening tool is not fair simply because it is automated. Define the role criteria first, ask the vendor for evidence, test with matched CVs and Arabic layouts, and make sure human review can see the evidence and correct rejections.