The ICO AI code of practice is now a live statutory project, not a finished rulebook. SI 2026/425 requires the Information Commissioner to prepare a code for AI and automated decision-making using personal data, with children's data included; boards should evidence compliance now.
As of 17 June 2026, the board position is precise: the code has been mandated, but the final code has not yet been published. The ICO's 29 May 2026 response to government places development of the AI code, agentic AI guidance and consumer support in its 2026/27 workplan. Its March 2026 strategy update says the draft automated decision-making guidance will inform parts of the AI and ADM code, and its guidance tracker puts final ADM guidance in winter 2026.
Key takeaways
- SI 2026/425 came into force on 12 May 2026 and requires the Information Commissioner to prepare a code covering good practice in personal-data processing for developing and using AI and automated decision-making.
- The code must include good-practice guidance on children's personal data, so boards with child-facing services should treat age-appropriate design and AI governance as the same control problem.
- The current operating material is still the ICO's AI and data protection guidance, AI risk toolkit and draft ADM guidance, all of which are being updated after the Data (Use and Access) Act 2025.
- The board task is not to wait for wording. It is to identify AI systems using personal data, classify any ADM, prove lawful basis and safeguards, and keep the evidence in a live risk register.
- ISO/IEC 42001 and the NIST AI RMF do not replace UK GDPR duties, but they give the board a management-system and risk-language structure for the evidence the ICO will expect.
What the ICO AI code of practice changes
The change is procedural first, but it will become practical. The 2026 Regulations require the Commissioner to prepare an appropriate code of practice on good practice in processing personal data under relevant data protection legislation in relation to developing and using AI, and automated decision-making. They also say the code must include good practice in processing children's personal data.
That is not the same as a new UK AI Act. The code sits inside the existing data protection regime: UK GDPR and the Data Protection Act 2018. The UK government's February 2024 AI regulation response kept the wider AI approach principles-based and regulator-led, with five cross-sector principles: safety, security and robustness; transparency and explainability; fairness; accountability and governance; and contestability and redress.
For boards, the code matters because the ICO is the regulator wherever AI processes personal data. The ICO's own AI and data protection guidance says the current guidance is not a statutory code, but that it explains the ICO's interpretation of data protection law and the organisational and technical measures it expects. The statutory code will put a formal code-making process around that subject matter.
Who this applies to
This applies to UK organisations that develop, buy or use AI systems processing personal data. The ICO's current ADM guidance is aimed at organisations planning to carry out automated decision-making, including in-house systems and vendor tools, and specifically addresses data protection officers, compliance professionals and technical leads who oversee use or procurement of ADM systems.
The code is not limited to recruitment or financial services. The ICO's March 2026 strategy update names central government ADM, recruitment ADM, foundation model developers and police facial recognition as focus areas for 2025/26, while the May 2026 workplan says 2026/27 will include the AI code, agentic AI guidance and support for consumers in a more personalised AI landscape. If EU exposure is possible, run the same inventory through our EU AI Act risk tiers guide as a separate classification exercise.
The practical threshold is personal data. If the AI never processes information relating to an identified or identifiable person, this code is unlikely to be the lead instrument. If the system classifies tenants, screens candidates, prices insurance, scores customers, assesses service eligibility, analyses children, monitors staff, generates profiles or feeds a significant decision about a person, the board should assume the ICO evidence trail matters.
What the board needs to decide
The board does not need to draft the code before the ICO does. It needs to make six decisions that will survive the code's arrival.
- Which AI systems process personal data, including vendor features switched on inside existing products.
- Which systems meet the ICO's ADM definition: a decision based solely on automated processing, including profiling, with legal or similarly significant effect.
- Which lawful basis supports each system, and whether special category data or children's data changes the analysis.
- Which safeguards are operating before the decision is taken: information to the person, a route to make representations, a route to contest the decision and meaningful human intervention.
- Which systems need a data protection impact assessment, given the ICO's brief guidance treats solely automated decisions with legal or similarly significant effect as high risk.
- Which board committee receives the live evidence, and who has authority to stop a use case when the evidence is missing.
The Data (Use and Access) Act 2025 changed the automated-decision rules. The government factsheet says section 80 replaces Article 22 of the UK GDPR with new Articles 22A to 22D, creating a more permissive framework for significant solely automated decisions where safeguards are in place. That is why nominal human sign-off is no longer enough. The board should ask whether the person reviewing the decision can understand it, challenge it and change it.
Controls and evidence the ICO will expect
The ICO's AI risk toolkit is designed to help organisations reduce risks to individuals' rights and freedoms from their own AI systems. Its AI audit toolkit lists control areas such as governance and accountability, transparency, contracts and third parties, data minimisation, security, statistical accuracy, bias and human review. Turn those headings into evidence, not policy prose.
| Control | Evidence the board should ask for | Owner |
|---|---|---|
| Personal-data AI inventory | System register showing purpose, data categories, affected people, supplier, model owner and current status | DPO and accountable executive |
| ADM classification | Recorded assessment of whether there is meaningful human involvement and whether the decision has legal or similarly significant effect | DPO, legal and process owner |
| Lawful basis and DPIA | Lawful-basis record, DPIA, special-category assessment and residual-risk decision | DPO and risk owner |
| Safeguards and rights | Privacy notice text, challenge route, human-intervention procedure and logs of representations, reviews and outcomes | Customer, HR or service owner |
| Data minimisation and security | Data map, feature-selection rationale, retention schedule, access controls and vendor security evidence | CTO or CISO |
| Children's data | Age-appropriate design assessment, child-risk review and board record of why the use is necessary | Safeguarding, product and DPO |
One ICO passage should be in the board pack: its security and minimisation chapter says AI can make known security risks harder to manage, and that organisations using AI to process personal data must assess and manage those implications carefully. It also says data minimisation requires the organisation to process only the personal data needed for the purpose, even where AI systems use large datasets.
Framework mapping for UK boards
The code will not arrive in isolation. A board can use the existing framework stack now, provided it keeps the hierarchy clear: law first, regulator guidance second, voluntary frameworks third.
| Framework or regime | What it gives the board | How it maps to the code work |
|---|---|---|
| UK GDPR and DUAA 2025 | Binding data protection duties, ADM definitions and safeguards | Decides lawful basis, individual rights, DPIA and human review evidence |
| ICO AI guidance and toolkit | Regulator interpretation and practical control areas | Sets the evidence vocabulary for governance, transparency, minimisation, security, fairness and human review |
| DSIT's five AI principles | Cross-sector regulatory lens for UK AI | Helps the board express why each control exists and which risk it addresses |
| ISO/IEC 42001 | A management-system structure for AI governance | Gives ownership, policy, risk assessment, operational controls, management review and improvement records; see the ISO 42001 checklist |
| NIST AI RMF | Govern, Map, Measure and Manage risk language | Helps teams classify risk, measure controls and manage residual risk across the AI lifecycle |
The NIST crosswalk between the AI RMF and ISO/IEC 42001 is useful because it shows how RMF activities can sit beside an AI management-system standard. NIST's AI RMF Core is useful because it breaks AI risk work into Govern, Map, Measure and Manage. Neither instrument satisfies UK GDPR by itself. Both help a board ask for the evidence in a consistent format.
The common mistakes are equally consistent. The first is treating the future code as a reason to pause; the ICO's current material already gives enough direction to start. The second is treating a human in the workflow as human intervention; the question is whether that person has competence, authority and time to change the result. The third is keeping the risk register apart from delivery evidence; the register should point to the DPIA, logs, notices, model changes and review outcomes.
Next step: turn the code into a live register
Start with the UK AI Regulation Tracker to keep the code, ADM guidance and DUAA dates visible in one board pack. Then use the AI Risk Register Generator to list the systems that process personal data and attach the controls above. If the board needs a baseline before assigning owners, the Board AI Scorecard is the shortest route. If the issue is material, regulated or already live, the AI governance diagnostic maps the evidence to UK GDPR, the ICO guidance, ISO/IEC 42001 and the NIST AI RMF.
The board minute should not say "we are monitoring the ICO." It should say which AI systems process personal data, which ones are ADM, which safeguards operate, what evidence proves that position, and who will update the board when the statutory code is published.
Sources: SI 2026/425 on the AI and ADM code; ICO response to government on safe AI-powered innovation, 29 May 2026; ICO AI and biometrics strategy update, March 2026; ICO plans for technology guidance; ICO consultation on draft ADM guidance; ICO automated decision-making guidance; ICO AI and data protection guidance; ICO AI and data protection risk toolkit; ICO AI audit toolkit; ICO security and data minimisation guidance for AI; GOV.UK DUAA factsheet; GOV.UK AI regulation response; NIST AI RMF to ISO/IEC 42001 crosswalk; NIST AI RMF Core.
