UK AI Code of Practice 2026: What SI 2026/425 Changes

Three things builders need to know now

Before the detail: three plain facts that matter right now, regardless of where your company is based.

• SI 2026/425 is enacted. The Data Protection Act 2018 (Code of Practice on Artificial Intelligence and Automated Decision-Making) Regulations 2026 are on the statute book. This is not a proposal or a consultation — it is law.
• The ICO must now publish a formal code. SI 2026/425 places a legal obligation on the Information Commissioner's Office to issue a code of practice covering AI and automated decision-making (ADM) under UK GDPR. The code has not yet been published; it is being developed. When it arrives, it will carry statutory weight.
• The EU AI Act's August 2026 high-risk deadline is a separate, concurrent obligation. If you sell into both the UK and EU markets, you are navigating two regulatory clocks simultaneously. They are not duplicative — they are additive. A builder in Bengaluru or Mumbai with UK and EU customers must track both. See our EU AI Act August 2026 deadline guide for the EU side of that picture.

What SI 2026/425 actually requires

The full title is the Data Protection Act 2018 (Code of Practice on Artificial Intelligence and Automated Decision-Making) Regulations 2026. That mouthful tells you the mechanism: it amends the Data Protection Act 2018 (DPA 2018) to insert a statutory duty for the ICO to prepare and issue a code of practice on AI and automated decision-making.

The DPA 2018 already gives the ICO power to produce statutory codes; existing examples include the Children's Code and the Data Sharing Code. SI 2026/425 follows the same legislative pattern: Parliament is not itself writing the substantive rules — it is directing the regulator to do so, within a framework set by UK GDPR and the DPA 2018.

Automated decision-making under UK GDPR echoes Article 22 of EU GDPR: individuals have rights in relation to decisions made solely by automated means that produce legal or similarly significant effects about them. Those rights — including the right to human review, the right to explanation, and the right to object — are already live under UK GDPR. What SI 2026/425 adds is a requirement for the ICO to codify how organisations should meet those obligations in the context of AI systems specifically.

In practical terms, the code will likely address how organisations should document their ADM systems, how they should communicate automated decisions to individuals, what constitutes adequate human review, and how bias and explainability requirements apply in AI-specific contexts. None of that is currently consolidated in one place — the code is intended to fill that gap.

UK vs EU: diverging regulatory philosophies

The UK and EU have made a conscious policy choice to approach AI regulation differently. Understanding that divergence matters for builders who serve both markets — you cannot assume that compliance with one regime automatically satisfies the other.

The EU's approach is centralised and risk-tiered: a single horizontal regulation (the EU AI Act) classifies AI systems by risk level and applies a uniform set of obligations regardless of sector. The regime is administered by a central AI Office alongside national authorities. For high-risk systems under Annex III, the Act prescribes specific documentation, conformity-assessment and registration requirements.

The UK's approach is sector-led and regulator-distributed. Rather than a single AI law, the UK relies on existing regulators — the ICO for data protection and ADM, the FCA for financial services AI, the CMA for competition dimensions of AI, and the MHRA for AI as a medical device — each issuing guidance or, as with SI 2026/425, statutory codes within their existing remit. The Frontier AI Bill, which is separate ongoing legislation focused primarily on the largest model providers, is not the UK equivalent of the EU AI Act; it addresses a narrower set of concerns at the frontier of capability.

For a UK-primary builder the practical upshot is this: the UK regime is more familiar territory (it builds on GDPR concepts you already know), but it is also less predictable right now because the ICO code has not yet been finalised. The EU regime is more prescriptive, but the obligations are already published. Builders serving both markets should treat them as parallel workstreams, not a single combined project.

Which products are affected

The scope of SI 2026/425 and the forthcoming ICO code is tied to the concept of automated decision-making with legal or similarly significant effects under UK GDPR. Translated into product categories, that means the following are firmly in scope.

• Hiring and recruitment tools: any system that screens, scores or ranks job candidates automatically, or that recommends who to interview or reject, where that output has a material effect on employment prospects.
• Credit and financial assessment: automated lending decisions, credit-scoring models, insurance premium calculation systems, and affordability assessments — all areas where the FCA is also actively watching.
• Healthcare triage and clinical decision support: systems that influence treatment recommendations or allocate care resources, particularly where individual patient outcomes follow automatically from model outputs.
• Education: automated grading, admissions-screening tools, and adaptive systems that track or rank student performance in ways that produce official records or affect academic outcomes.
• Content moderation at scale: systems that make binding decisions about whether user-generated content is removed or accounts are suspended, particularly where appeals processes are limited or absent.
• Benefit and service eligibility: any system used in the public or regulated private sector that determines whether an individual qualifies for a service, support payment, or entitlement.

Conversely, a general-purpose AI assistant, a recommendation engine for non-consequential content, or an internal productivity tool that does not make decisions about individuals does not, on those facts alone, trigger the ADM obligations. The test is whether the system produces a decision — or a decision-ready output — about a specific individual that has significant real-world consequences for them.

For Indian builders with UK customers: if your product is used by UK employers to screen candidates, by UK lenders to assess credit, or by UK healthcare providers to triage patients, your system is in scope. UK GDPR has explicit extraterritorial reach; the ICO can and does take enforcement action against non-UK controllers processing UK personal data in breach of the regime.

What the ICO code will likely cover

The ICO code has not been published, so this section is necessarily forward-looking — based on the ICO's existing AI guidance, its public statements on ADM, and the pattern set by previous statutory codes. Do not treat this as a statement of what the code will definitively require; treat it as the planning baseline that makes the most sense given the public record.

The ICO has been publishing AI-specific guidance since 2020. Its Explaining Decisions Made with AI guidance, its accountability framework, and its audit methodology for algorithmic systems all signal the themes it considers important. Those themes translate into the following expected areas of focus.

• Transparency and explainability: organisations will almost certainly need to be able to explain, in plain language, how an automated decision about a specific individual was reached. The explanation must be meaningful — not a boilerplate statement about "using algorithms" — and must address the factors that were materially weighted in the specific case.
• Human oversight and meaningful review: the UK GDPR right to human review of automated decisions is already law. The code is expected to specify what constitutes genuine human involvement versus rubber-stamping, and to require that review processes are resourced and documented, not merely stated in a privacy notice.
• Bias and fairness testing: the ICO has been clear that algorithmic bias is a data protection issue, not just an ethics issue. Expect the code to require documented bias assessments, disaggregated performance metrics across protected characteristics, and remediation processes when bias is identified.
• Data subject rights for ADM: the code will likely clarify how organisations should handle data subject access requests that involve ADM logic, including what information must be disclosed about model inputs, outputs and the reasoning process — going beyond what a general DSAR currently requires.
• Accountability and record-keeping: documentation requirements for ADM systems — covering intended purpose, training data, model logic, performance benchmarks and known limitations — are a near-certainty. The ICO's existing audit framework points in that direction.

A compliance checklist for builders

You do not need to wait for the ICO code to be finalised before taking action. The obligations that SI 2026/425 builds on — UK GDPR's ADM rights — are already in force. Starting the groundwork now means that when the code is published, you will need to refine rather than rebuild. Here is an eight-point checklist for teams shipping ADM-affected products.

• Audit your ADM use. List every system, feature or workflow in your product that makes — or materially contributes to — automated decisions about individual UK data subjects. Include both fully automated decisions and automated decisions with nominal human sign-off (the ICO treats the latter as automated if the human adds no substantive review).
• Document data flows and model logic. For each ADM system, produce a written description covering: what data feeds in, how the model weights it, what decision or output is produced, and how that output is used downstream. This is the foundation of both DSAR responses and any future ICO audit.
• Build and test genuine human review. Ensure your product design includes a meaningful human-review step for significant ADM outputs. Document what that review entails, who performs it, what authority they have to override the model, and what training they receive. "A human can override the decision" is not sufficient if the interface or workflow makes override impractical.
• Run bias and fairness assessments. Disaggregate your model's outputs across relevant protected characteristics — age, sex, race or ethnicity, disability status as appropriate to your use case. Document the methodology, the results and any remediation steps taken. Repeat this at each material model update.
• Prepare DSAR responses for ADM. When a UK data subject submits a data subject access request, your response must be capable of addressing ADM-related questions: what data was used, what decision was reached, and on what basis. Draft and test a response template specifically for ADM DSARs before you receive one.
• Update your privacy notice and communications. Privacy notices must inform individuals when significant decisions are being made by automated means, describe the logic involved in meaningful terms, and explain their right to request human review and to object. Generic AI disclosure language does not meet this standard.
• Assign ADM accountability clearly. Name a single accountable owner for each ADM system — ideally a named individual with both technical and business authority. Ensure that person is aware of the current UK GDPR ADM obligations and is monitoring ICO publications for the forthcoming code.
• Watch ico.org.uk for the consultation draft. The ICO is obliged to consult before finalising the code. The consultation period is your primary opportunity to understand what specific requirements are coming and to shape them. Subscribe to ICO updates and assign someone to review the draft when it appears.

The UK regulatory landscape: where SI 2026/425 fits

It is worth briefly mapping where SI 2026/425 sits within the broader UK AI policy picture, because the landscape is more fragmented than most builders realise.

The UK Frontier AI Bill is separate ongoing legislation directed primarily at developers of the most capable frontier models — think the large-scale training runs that might pose systemic risks. It is not a product-level compliance framework and it does not replace or subsume SI 2026/425. Builders of downstream applications, integrations and sector-specific AI tools are not the primary target of the Frontier AI Bill; they are, however, directly in scope of the DPA 2018 and the forthcoming ICO code.

The FCA has published its own guidance on AI in regulated financial services, and is actively supervising algorithmic decision-making in credit, insurance and investment contexts. If your product sits in financial services, you face an additional layer of sector-specific oversight on top of the ICO code.

The CMA is examining AI in markets — specifically, whether AI-powered pricing, personalisation and recommendation systems create competition concerns. This is a third, distinct regulatory track that intersects with ADM in e-commerce and platform contexts.

The practical consequence for builders is that the UK's sector-led approach means multiple regulators may have a view on your product simultaneously. The ICO owns data protection and ADM; the FCA owns financial services AI; the CMA owns market-facing AI with competitive implications; the MHRA owns AI as a medical device. You need to map your product against all relevant regulators, not just the ICO.

For Indian builders with UK customers, this multi-regulator landscape is a particular operational challenge — there is no single UK AI compliance checklist that covers everything. The ICO code, when published, will be the most widely applicable instrument for ADM products, but it will not be the only one.