AI can prepare the right-to-work file; the employer must complete the check

The October change is narrower than “digital ID becomes mandatory”

The operational change is about a prescribed checking route and the evidence needed for an employer's statutory excuse. The Office for Digital Identities and Attributes said on September 3 that, from October 1, 2026, employers choosing a digital verification service for a right-to-work check must use a service certified and registered against the DVS trust framework and the relevant right-to-work supplementary code.

The digital route itself remains optional. The Home Office's September 11 draft employer guide describes three routes: a manual document-based check, a Home Office online check, and a check using a registered right-to-work digital verification service provider. The route depends on the person's circumstances and, where appropriate, preference. The draft anti-discrimination code says employers should apply checks consistently and should not treat people less favourably because of the route they use.

A DVS does not absorb the employer's responsibility. The draft guide says the employer remains responsible for ensuring the prescribed requirements are met. The employer must know which registered provider performed the service, keep the required result, satisfy itself that the photo and biographic output relate to the person presenting for work, review any work restrictions, and retain the right evidence.

The word “draft” matters. As of September 22, the October employer guide and discrimination code are published in draft form. HR should prepare now, but the go-live gate must re-check the final official documents, the live DVS register, and internal legal advice. This guide turns the current published direction into a readiness workflow; it is not a substitute for final guidance.

Design three routes, not one digital funnel

Do not let an AI router infer the route from nationality, appearance, name, accent, CV, or a scanned document. Present permitted options using approved employer policy and official guidance. Record the route the applicant uses. Where the person declines a digital route or cannot complete it, provide the applicable alternative rather than treating the failure as adverse evidence.

The DVS register is a live control, not a procurement document. The register lists services, legal providers, role types, supplementary codes, certification dates, and expiries. A provider may appear on the register without the right-to-work supplementary code on a particular service. Capture the exact service and provider entry used on the check date. If a recruitment or screening vendor sits in front, require it to name the certified and registered DVS actually performing the check.

Separate right-to-work checking from sponsorship. A candidate may disclose that sponsorship is needed, and the employer may have a separate sponsorship process, but the right-to-work check follows its prescribed evidence routes. The focused community scan found a current UKJobs discussion about late visa/sponsorship disclosure. That illustrates operational pressure, not a legal rule and not permission to screen people differently.

Build a field-level evidence ledger

A folder of screenshots is not a case record. The ledger should show what requirement was satisfied, by which official artifact, on what date, by which person, and what happens next. Use a pseudonymous case ID in AI tooling whenever the approved workflow does not require direct identifiers.

Reconcile the ledger before the start decision. Every required field should point to exactly one current artifact or an owned exception. Every exception needs a deadline and permitted next action. The case cannot become “complete” because a vendor API returned HTTP 200 or a model summarized the documents confidently.

def review_case(case, policy, dvs_register):
    require(case.policy_version == policy.approved_version)
    require(case.route in policy.permitted_routes)
    require(case.route_was_inferred is False)

    if case.route == "registered_dvs":
        entry = dvs_register.exact_service(case.dvs_service_id)
        require(entry.has_scope("Right to Work"))
        require(entry.valid_on(case.check_date))
        require(case.actual_provider == entry.legal_provider)

    require(case.official_result.complete)
    require(case.identity_match.completed_by_named_employer_reviewer)
    require(case.explicit_restrictions_checked_against_proposed_work)
    require(case.follow_up.owned_if_required)
    require(case.retention.approved)
    return "READY FOR HUMAN REVIEW"

AI may prepare and challenge the file, not create the conclusion

Useful AI work is administrative and evidential: compare the case against the route checklist; extract non-judgmental fields from an approved structured output; flag missing pages or conflicting IDs; draft an exception record; schedule the follow-up date supplied by the official result; and produce a reviewer-ready ledger.

Keep four decisions out of the model. First, do not let it infer immigration status or document validity. Second, do not let it decide which proof route a person should use. Third, do not let it resolve facial, biographic, or name mismatches. Fourth, do not let it make the employment decision or state that the employer has established a statutory excuse.

Use explicit vocabulary. The AI output can say missing official profile page, provider scope not evidenced, identity match pending, or restriction review incomplete. Avoid labels such as illegal, fraud, not eligible, or cleared. Those compress legal and human judgments into a model-generated status.

The best quality control is a two-state terminal output: READY FOR HUMAN REVIEW or NOT READY. A named reviewer then reads the official result and records the employer conclusion in the authorized system. Keep the AI draft and employer decision as separate fields with separate identities and timestamps.

Worked exception: the DVS cannot complete the face match

A remote candidate chooses the digital route. The screening vendor returns a report with the candidate's document details but a low-confidence face comparison. Its dashboard labels the case “refer.” A generic AI assistant might turn that into “identity failed” and suggest withdrawing the offer. That would collapse a technical exception into an employment decision.

The controlled workflow first identifies the actual DVS behind the screening vendor and verifies its right-to-work registration for the check date. It records the “refer” output exactly, marks the employer identity match incomplete, and opens an exception. The applicant receives the approved correction or alternative-route process. No adverse inference is made from image quality or inability to use the digital route.

If an official online service or share-code flow is unavailable, use the current official fallback described in the employer guide, including Employer Checking Service where applicable. Do not have AI invent a workaround or treat a technical outage as evidence about the person.

Fairness, accessibility, and privacy are part of the check

The Home Office equality impact assessment identifies potential barriers involving age, disability, race, document access, and digital participation. Its mitigations include keeping the DVS route optional, providing other prescribed routes, applying anti-discrimination guidance, and supporting accessible formats. Translate those policy statements into testable workflow controls.

1. Consistency: use the same stage and approved process for every applicant in the comparison group.
2. Choice: record that an alternative route was available where current guidance permits it.
3. Accessibility: give a correction or assisted path when technology, disability, image quality, or document access blocks the digital route.
4. No proxy inference: do not use name, address, accent, nationality, or appearance to predict which check or immigration status applies.
5. Correction: preserve a route for inaccurate Home Office account details, poor photos, or name differences.
6. Minimization: send only approved fields to AI; do not copy biometric templates, source images, or complete identity files into general chat tools.
7. Retention: retain the evidence required by current guidance and policy, then securely destroy it on schedule.

HR should conduct a data-protection review of the actual DVS, screening intermediary, AI tool, storage location, and support process. A vendor's certification for identity services does not automatically approve every downstream AI use of the data.

Failure modes to remove before October

Run an October readiness plan

Days 1-3: legal/compliance freezes the current official source set: supplementary code 1.1, draft employer guide, draft discrimination code, live DVS register, online check and ECS instructions, equality assessment, and internal retention rules. Record what is final and what remains draft.

Days 4-7: procurement and HR map every vendor in the chain. For each DVS service, record legal provider, register entry, right-to-work scope, certification and expiry, contract, processor/subprocessor path, incident contact, data fields, and service continuity. Remove any workflow that cannot identify the actual performing DVS.

Days 8-12: test all three routes plus exceptions. Use synthetic cases for a complete DVS output, Home Office online result, manual check, poor photo, name difference, expired share code, service outage, missing restriction, time-limited follow-up, applicant requesting another route, and intermediary-provider mismatch.

Days 13-16: validate AI boundaries. Seed a CV with nationality clues, conflicting names, a vendor “pass” label, incomplete output, and unapproved biometric data. Confirm the workflow refuses inference, preserves exact source labels, flags missing evidence, and stops at human review.

Final go-live gate: re-check final GOV.UK guidance and the live DVS register. Legal/compliance approves policy interpretation; privacy/security approves data flow and retention; vendor management approves provider chain; HR operations signs the route checklist; a named owner rehearses ECS and alternate-route handling. Publish only the approved version and archive the superseded one.

Measure missing evidence per route, provider-register mismatches, identity-match exceptions, alternate-route requests, technical-failure resolution time, follow-up ownership, over-retained data, reviewer rework, and inconsistent treatment by stage. Do not optimize only for onboarding speed.

For the broader day-one join across identity, payroll, device, access, and learning, use the new-hire readiness reconciliation workflow. This page covers the prescribed right-to-work evidence boundary that must be complete before the case moves forward.

FAQ

Can a recruitment agency perform the check for us?

The draft guide distinguishes prescribed DVS checks from other third-party activity and requires transparency where an intermediary procures the DVS. Confirm the current official rule for your arrangement and identify the actual certified and registered service. The employer should not assume that outsourcing removes responsibility.

Can we keep using our current DVS after October 1?

Verify the exact service on the live statutory register, including right-to-work supplementary-code scope and validity on the check date. A company may offer multiple services with different roles or scopes. Re-check the final guidance and contract before go-live.

May AI compare the candidate's face with the DVS photo?

Do not route biometric comparison through a general AI tool. The draft guide assigns digital facial-recognition functions to registered providers and still requires the employer's prescribed identity step. Use only approved systems, data flows, and human procedures.

How long should evidence be retained?

The September draft guide says the relevant profile evidence should be retained securely for employment and two years afterward, then securely destroyed. Confirm the final route-specific guidance and your approved records policy before implementation.