Recruiters see the evidence for each job criterion in every application, faster and more consistently. No candidate is rejected by a machine, no protected characteristic is guessed, and outcomes are tested for bias before and during use.
At a glance
An illustrative scenario. The numbers are typical examples, not a client case study. The cloud services and UK rules were checked on 9 November 2026.
A graduate scheme opens and 8,000 applications arrive in three weeks. Recruiters skim each CV for a minute or two. Some are read carefully in the morning and others in a hurry at six in the evening. Two recruiters reading the same CV often reach different views, and the reasons for a rejection are rarely written down. Good candidates are lost, and nobody can show whether the process treats everyone fairly.
Screening tools promise to fix this, and some make it worse. The ICO's audits of AI recruitment tools, reported in November 2024, found features that could filter out candidates by protected characteristic, tools that inferred gender from a candidate's name, and tools that collected far more data than they needed and kept it indefinitely. Models trained on who was hired in the past learn the past's biases. Video tools that claim to read emotion or personality from a face or voice rest on contested science, and in the EU, using AI to infer emotions at work is now banned.
The rules leave little room for shortcuts. The Equality Act 2010 applies to the arrangements an employer makes for deciding who to offer a job, including any tool it buys. Since 5 February 2026, automated decisions about people are allowed only with safeguards, and the ICO's March 2026 report found that many employers who thought they were using decision support were in fact making solely automated decisions. Candidates are entitled to be told about automated decisions and to contest them, and the employer has to be able to explain each outcome.
Agree these, and measure the baseline, before anything is built. Example targets are typical, not promises.
Pass rate at each stage, compared across groups using equality data candidates gave voluntarily. Any gap is investigated before the tool is used again.
ExampleNo unexplained gap, reviewed every campaign
How often recruiters agree with the evidence summary. Near 100% can mean they've stopped reading.
ExampleStable, with a sample re-read blind each week
Time to reach a decision with the evidence summary, against the baseline.
ExampleDown by around a third
How many candidates asked for a person to review, how quickly they were answered, and how often the outcome changed.
ExampleAnswered within 10 working days
Reasonable adjustment requests met before the candidate's next stage.
ExampleEvery request
Share of rejections with a reason written against the published criteria.
ExampleEvery rejection
Cross-sector rules are on the UK regulation map.
The employer is liable for the arrangements it uses to decide who gets a job, including a supplier's tool. A criterion or model that puts a group at a disadvantage is indirect discrimination unless it can be objectively justified. So every criterion is tied to the job, the tool is tested for adverse impact before use and monitored afterwards, and protected characteristics are never inferred.
Disabled candidates are entitled to reasonable adjustments at every stage, including to any automated step. Section 60 limits questions about health before a job offer. Adjustment requests go to a recruiter, never to the model, and health information never enters screening.
Rejecting a candidate is usually a significant decision. Solely automated decisions are now allowed with safeguards, but where special category data is involved, such as health or ethnicity, the strict limit remains. This design goes further than the law requires: a person with real authority makes every reject decision, and candidates can still make representations, contest the outcome and reach a person.
The ICO's recommendations: monitor for bias and accuracy, using real rather than inferred equality data; tell candidates how AI is used; collect the minimum data and keep it for a set period; do a DPIA early, ideally before procurement; agree controller and processor roles in a contract with written instructions; and state the lawful basis. The procurement questions it published are a good checklist for any supplier.
The ICO found many employers using what they called decision support were making solely automated decisions, because the human review was token. A reviewer must understand the tool's output and limits and be able to change the outcome. The ICO also warned that consent and contract are unlikely to be the right lawful basis for most recruitment processing.
Government guidance, written with input from the ICO and EHRC, on assurance before buying, during a pilot and in live use: impact assessments, bias audits, accessibility and adjustments, and performance testing. Use it as the plan for the pilot gate.
Screening and evaluating candidates is listed in Annex III, with high-risk duties from 2 December 2027 under the Digital Omnibus. Emotion recognition in the workplace has been prohibited since February 2025. Neither applies to UK-only hiring, but a design that already meets them travels well.
Showing AWSAzuresovereign / on-prem services. Switch with the toggle; every diagram and table on this page follows it.
01Channels
02Intake
03Intelligence
04Orchestration
05Systems of record
06People
| Layer | AWS | Azure | Sovereign / on-prem |
|---|---|---|---|
| Link to the applicant tracking systemThe applicant tracking system stays the record. Decisions are made and stored there, not in the AI layer. | API Gateway, EventBridge, plus your existing integration platform if you have one | API Management, Event Grid, plus your existing integration platform if you have one | Kong, Kafka, plus your existing integration platform if you have one |
| Hiding identifying detailsNames, photos, addresses, dates of birth, and clues such as graduation years or school names where they act as a proxy for age. | Amazon Comprehend PII detection, plus your own rules | Azure Language in Foundry Tools (PII detection), plus your own rules | Open-source PII detection (e.g. Presidio) |
| Evidence against criteriaBoth clouds offer a choice of models, including Claude. The output is quoted evidence per criterion, not a score or a ranking. | Amazon Bedrock | Microsoft Foundry | Open-weight models served with vLLM on your own GPUs, or IONOS AI Model Hub |
| Agent runtimeThe original Bedrock Agents closed to new customers on 30 July 2026; new builds use AgentCore. | Amazon Bedrock AgentCore | Foundry Agent Service | An open-source agent framework (e.g. LangGraph) on Kubernetes |
| Adverse impact testing and monitoringSageMaker Clarify closed to new customers on 30 July 2026. Use real equality data candidates gave, not inferred data. | Amazon SageMaker AI with Fairlearn (open source) | Azure Machine Learning with Fairlearn (open source) | MLflow and Fairlearn on Kubernetes |
| Equality monitoring dataOnly the fairness reviewer can join it to outcomes, and only in aggregate. | A separate, access-restricted store (S3 with its own KMS key) | A separate, access-restricted store (Blob Storage with its own Key Vault key) | A separate, access-restricted store (Ceph or IONOS S3 Object Storage) with its own keys |
| GuardrailsBlock output that comments on age, health, family, nationality or other protected characteristics. | Bedrock Guardrails | Foundry guardrails (Azure AI Content Safety) | Open-source guardrails (e.g. NeMo Guardrails, Llama Guard) |
| Video and assessmentsIf you record interviews, people watch them. Test any online assessment for adverse impact and offer an alternative. | No face, voice or emotion analysis | No face, voice or emotion analysis | No face, voice or emotion analysis |
| WorkflowThe rule that only a person can reject sits here, not in a prompt. | AWS Step Functions | Logic Apps or Durable Functions | Temporal, or n8n |
| Identity, keys, data protection | IAM Identity Center, KMS, Macie | Entra ID, Key Vault, Purview | Keycloak or your existing Active Directory; OpenBao or HashiCorp Vault; an HSM |
| Monitoring and auditLog the evidence shown, who decided, the decision and the reason, for every application. | CloudWatch, CloudTrail | Azure Monitor, Log Analytics | Prometheus, Grafana, OpenTelemetry |
| UK data residencyIONOS AI Model Hub runs in German data centres: EU, not UK, residency. | eu-west-2 (London) | UK South / UK West | Your own UK data centre, or a UK or EU provider |
On a phone, the table shows the platform you pick. Sovereign / on-prem means open, portable components you can run in your own data centre or with a UK or European provider; IONOS is shown as one example, and others exist. What sovereign cloud means →
Many organisations keep core systems and sensitive data on their own servers. This is how the same design works across both.
Stays on-prem
The applicant tracking system, the HR system and the equality monitoring data stay where they are. If your monitoring data is held on your own servers today, it can stay there, with the fairness tests run beside it.
Uses cloud AI
Hiding identifying details and finding evidence against criteria can run in a UK cloud region, or on your own GPUs with open-weight models if candidate data must not leave your estate. Only the redacted application and the criteria are sent.
How they connect
A private link (AWS Direct Connect or Azure ExpressRoute) and your API layer. Evidence summaries come back as events and are attached to the application in the applicant tracking system.
If the link drops
Recruiters screen exactly as they do today, in the applicant tracking system. Applications are marked as not yet summarised, and nothing is rejected or delayed by default.
What each agent may do through its tools, what it may not, and where a person signs off. The limits are enforced by the platform, not the prompt.
Screening assistant
Where a person signs offA recruiter decides every shortlist and every rejection, reads the source as well as the summary, and records the reason against the criteria. Candidate requests for review go to a different recruiter. Permissions are enforced by the platform's identity and policy controls, not by instructions in a prompt.
The applicant tracking system stays the record of every application and decision. The AI layer receives redacted applications through an API, adds a summary, and never writes a status. Rejection is an action only a recruiter's account can take.
Equality monitoring data flows on its own path, into a separate store with its own keys. The fairness tests join it to stage outcomes in aggregate, after decisions are made. It is never available to the assistant, the recruiter or the hiring manager.
If the AI is paused, recruitment carries on in the applicant tracking system as it does today. Switching it off is a single setting, and it should be used the moment a bias test fails.
Map today's screening, measure the baseline and current selection rates by group, write the criteria for the pilot roles, and complete the DPIA and equality impact assessment.
Gate · must be true to passDPIA and equality impact assessment signed off, criteria agreed, legal and DPO involved, candidate notice drafted.
Run the assistant on last year's anonymised applications for the pilot roles and compare evidence summaries with blind human reads, by group.
Gate · must be true to passNo unexplained adverse impact, and the fairness reviewer and DPO sign off.
One campaign, such as seasonal roles, with recruiters using the summaries and deciding every application, plus a blind sample re-read.
Gate · must be true to passSelection rates stable by group, review requests answered on time, and recruiters trust and check the summaries.
Add roles and campaigns one at a time, each with its own criteria and bias test.
Gate · must be true to passEach new role family passes the same bias-testing gate.
| Activity | Head of talent acquisition | HR director | D&I lead | Solutions architectI can fill this | Technical PMI can fill this | EngineersI can fill this | DPO & legal | SecurityI can fill this |
|---|---|---|---|---|---|---|---|---|
| Business case and benefits | Responsible | Accountable | Consulted | Consulted | Consulted | Informed | Consulted | Informed |
| Job criteria and candidate notice | Responsible | Accountable | Consulted | Informed | Informed | Informed | Consulted | Informed |
| DPIA and equality impact assessment | Consulted | Accountable | Responsible | Consulted | Informed | Informed | Responsible | Consulted |
| Target architecture | Consulted | Informed | Consulted | Accountable and Responsible | Consulted | Consulted | Consulted | Consulted |
| Bias testing and monitoring | Consulted | Accountable | Responsible | Consulted | Consulted | Responsible | Consulted | Informed |
| Build and integration | Informed | Informed | Informed | Accountable | Responsible | Responsible | Informed | Consulted |
| Go-live and stop decisions | Responsible | Accountable | Consulted | Consulted | Responsible | Informed | Consulted | Consulted |
R ResponsibleA AccountableC ConsultedI Informed· not involved
Option A
If there's no architect on the programme, I'd own the design end to end: the integration with your applicant tracking system, the redaction, the separate path for equality data, the bias testing and the gates. I'd report to your programme board, and I'd say plainly which parts of screening shouldn't be automated at all.
Option B
If your partner or your own team already has an architect, I'd take on the redaction, the evidence summaries and the fairness monitoring under their lead, and give them a second senior opinion on the rest, especially data protection and the supplier's claims.
Goes wrong
A model trained on past hires learns who used to be hired, and repeats it.
How the design avoids it
No ranking trained on past decisions. Evidence against criteria written for the job, and adverse impact tested before use.
Goes wrong
Recruiters approve the AI's view in seconds, so a 'human in the loop' is really a rubber stamp.
How the design avoids it
No score or verdict to approve, reasons recorded against criteria, and a weekly blind re-read of a sample.
Goes wrong
Proxies slip through: a graduation year, a postcode, a gap for caring, a name in an email address.
How the design avoids it
Redaction rules tested on real applications, and output guardrails that block comment on protected characteristics.
Goes wrong
The supplier's tool offers video or personality scoring, and someone switches it on.
How the design avoids it
Contract terms and configuration that rule it out, and a DPIA that names what's off.
Goes wrong
Bias is checked once at launch and never again.
How the design avoids it
Monitoring at every stage of every campaign, with a stop rule agreed in advance.
Changes already announced or under way that affect this design. More in the UK horizon scan.
Design against the draft now: meaningful human involvement, information for candidates, and a route to contest every decision.
Make sure no screening data, model or supplier list carries trade union membership or activity, which is special category data anyway.
If you hire in the EU, work out whether you're provider or deployer, and plan human oversight, logging and documentation now.
Keep monitoring data out of hiring and promotion decisions, so any new rules don't reach into screening.
Good answers are specific. Vague answers to any of these are worth following up.
Whether you need someone to lead the design or to support the architect you already have, let's talk it through.
