ICO AI Code of Practice: A Readiness Checklist

The statutory duty behind it

The Data (Use and Access) Act 2025, which received Royal Assent on 19 June 2025, reshaped several parts of the UK data protection regime and provided the mechanism for the Commissioner to be required, through secondary legislation, to prepare a statutory code of practice covering artificial intelligence and automated decision-making. The ICO has publicly committed to developing that code and to consulting on it. Confirm the current position on commencement and consultation timing before building a plan around specific dates, because the statutory instruments and the ICO's own programme have moved more than once.

The themes the ICO has signalled

Four themes recur in the ICO's public statements and in its existing AI material: transparency and explainability, bias and discrimination, rights and redress, and safeguards around decisions that affect people without meaningful human involvement. None of those themes is new to data protection practice. What changes is the expectation that a business can demonstrate, system by system, how each one has been addressed rather than asserting compliance at policy level.

What the code is not

The code is not a licensing regime, and it does not create product safety duties in the way the EU AI Act does for certain high-risk systems. It is also not limited to models a business builds itself. Scope follows personal data, which means a bought-in scoring tool, an API call to a third-party model and an internal fine-tuned classifier are all in scope if identifiable people are involved anywhere in the processing. That distinction matters because procurement teams frequently treat vendor tooling as the vendor's compliance problem, when the controller obligations sit with the buyer.

Why statutory status changes the bar

A statutory code is not the same thing as ordinary guidance. The Commissioner must have regard to it when exercising regulatory functions, and courts and tribunals can take it into account in proceedings. In practice, a documented departure from a statutory code becomes something a business has to justify rather than simply explain. Organisations that have already been through the Age Appropriate Design Code will recognise the shift in tone that follows.

The likely sequence is familiar: a call for views, a formal consultation on a draft, revision, laying before Parliament, then a transition window before enforcement expectations apply in full. The Age Appropriate Design Code offers the most useful timing precedent, having come into force on 2 September 2020 with a twelve month transition period before full conformance was expected. A similar runway would give most organisations enough time to fix design problems, provided the work starts while the draft is still in consultation.

The ICO has been consistent in saying that existing obligations already apply, so waiting for publication is not a defensible strategy. The best preview available is the material already on the ICO website: the guidance on AI and data protection, the work with the Alan Turing Institute on explaining decisions made with AI, and the AI and data protection risk toolkit. Anyone who has worked through the toolkit will find little in the signalled themes that comes as a surprise. For tracking changes without checking the ICO site every week, published consultation responses, the ICO's AI and biometrics workstream and statements from sector regulators such as the FCA and the EHRC are the more efficient signals.

The general restriction on solely automated decision-making has been reformed into a safeguards-based model for most processing that does not involve special category data. Significant decisions taken without meaningful human involvement are permitted, provided specific safeguards are in place: the person is informed that such a decision has been made, they can make representations, they can obtain human intervention, and they can contest the outcome. Special category data, including health data and data revealing ethnicity, remains tightly constrained, which is why occupational health triage and insurance underwriting need a materially different design from B2B lead scoring. Commencement of these reforms has been phased, so check what is in force on the date you are designing against.

Meaningful human involvement is where most implementations fail. A reviewer who sees a score and a recommended action, but not the inputs that produced them, is not exercising judgement. Neither is a reviewer whose performance is measured on throughput and who has no practical authority to overturn the system. The audit trail tends to tell the story without much interpretation: if the override rate across several thousand decisions sits at or near zero, the review step is decorative, and a complainant's representative will say so. Record what the reviewer saw, what they were empowered to change, and how often they changed it.

Marketing and growth stacks are the blind spot. These tools are usually bought on a departmental card, integrated in an afternoon, and never routed through the data protection review cycle, yet they make decisions about identifiable people every day.

Website chat agents and AI assistants that qualify, route or deprioritise enquiries before a human sees them. A B2B chat agent that silently filters out enquiries it judges low value is making a decision about a named individual, often with no record of what was discarded or why.

Lead scoring, propensity models and audience segmentation running inside marketing automation platforms, CRMs and ad platforms, frequently using vendor models the buyer cannot inspect.

Recruitment sifting and workforce tools, the category most commentators expect the code to press hardest on. A sifting tool that auto-rejects candidates below a score threshold needs the full safeguards route: notification that the decision was automated, the ability to make representations, human intervention and a route to contest the outcome.

AI visibility, brand monitoring and prompt-testing tools. Prompt-based tools process personal data more often than teams assume. If a prompt set contains customer names, job titles or verbatim complaint text, that is processing, and it needs a lawful basis, a retention rule and a clear answer on where the data is handled.

The inventory format does not need to be elaborate. Seven columns are usually enough: system, purpose, decision effect on the individual, data categories, vendor and processing location, human review point, and DPIA status. One named owner per system, not per department.

1. Run or refresh DPIAs wherever innovative technology, large-scale profiling or significant decisions are involved, and record the alternatives that were rejected alongside the design that was chosen. The rejected options are what demonstrate that a genuine assessment took place.

2. Write plain English explanations of each automated decision, covering the main factors that drive an outcome and their relative weight in ordinary language. A model architecture description is not an explanation, and neither is a link to a vendor white paper.

3. Design the contest and review route before launch. Specify who reviews, what evidence they see, what authority they hold to change the outcome, and the service level for responding.

4. Test for disparate outcomes across groups and keep the evidence, including the tests that showed no material difference. Bias and discrimination is expected to be a named code theme, and retrospective testing is far weaker than a dated series.

5. Tighten vendor due diligence: stated limitations, the training data position, sub-processors, retention periods, human review of prompts, and whether prompts or outputs leave the UK or EEA.

6. Set a review cadence. Quarterly for systems making significant decisions, annually for the rest, with a trigger for material model or vendor changes. A checklist completed once and filed is worth very little in a regulatory conversation two years later.

Treat the transition period as build time rather than waiting time. Retro-fitting explanation text, a contest route and outcome testing to a live system costs considerably more than designing them in before the draft code closes.

Organisations that already operate the NIST AI Risk Management Framework have a usable spine in its four functions: Govern, Map, Measure and Manage. Inventory and scoping work sits under Map, bias and outcome testing under Measure, human review and incident handling under Manage, and accountability, ownership and policy under Govern. The expected UK code themes can be hung off that structure rather than run as a parallel programme.

ISO/IEC 42001, published in December 2023, provides the management system layer and overlaps substantially on governance, competence and supplier control. EU AI Act obligations overlap on transparency and risk management for organisations in scope, although the Act's classification logic and conformity requirements are genuinely separate from UK data protection duties, and its implementation timetable has itself been the subject of proposed amendment. Preparing once beats preparing three times. One control library, multiple mappings, one owner per system, and a single evidence set that can be pointed at whichever framework is asking. Stating boundaries and limitations openly, including the decisions a system is not permitted to make, is increasingly expected by regulators and by enterprise buyers running their own supplier assessments.

Governance statements, AI disclosure pages and DPIA summaries are public content. Assistants such as ChatGPT, Gemini, Perplexity and Claude draw on that content when describing what a business does and how it handles data, which creates a second audience nobody planned for. Where the wording on the website says one thing, a partner directory listing says another and a press release implies a third, the answers those systems produce about a company's AI use and risk posture become contradictory. That is a compliance gap and a brand representation problem at the same time.

The fixes are unglamorous. Maintain one canonical governance page rather than three overlapping ones, use consistent entity naming across the site, directories, partner pages and coverage, date every update, and describe the same systems in the same terms wherever they appear. Clarity, consistency and verifiable trust signals matter here for the same reason they matter in enterprise AI search visibility work generally: they shape the view a model forms of an organisation. Periodic prompt testing is the only way to see the result, and a free AI visibility scan will show how assistants currently summarise a business, which is a reasonable starting point before commissioning anything larger. Where the summaries are wrong or inconsistent, the remedy is usually source correction rather than more content, and the AI visibility plans and pricing page sets out what a structured programme involves.

Preparation for the ICO AI code of practice and control of how AI systems describe a business are closer than they look. Both depend on an accurate inventory, consistent public statements and evidence that can be produced on request.

What is the ICO AI code of practice and who does it apply to?

It is a statutory code of practice on artificial intelligence and automated decision-making that the Information Commissioner has committed to preparing under the framework introduced by the Data (Use and Access) Act 2025. It is expected to apply to controllers and processors using AI where personal data is involved, regardless of whether the model was built in-house or bought in. Organisations using third-party tools for recruitment, customer decisions, personalisation or lead handling should assume they are in scope.

When is the ICO code of practice on AI and automated decision-making expected to take effect?

No confirmed enforcement date is available at the time of writing. The realistic sequence is consultation, a draft, parliamentary process and then a transition window, and the Age Appropriate Design Code provides a precedent of roughly twelve months between coming into force and full conformance expectations. Plan for a runway rather than a single deadline, and verify the current timetable on the ICO website.

Is the code legally binding, or is it guidance?

A statutory code is not a law in its own right, but it carries more weight than ordinary guidance. The Commissioner must have regard to it, and courts and tribunals can take it into account, so a departure from it needs to be justified and documented rather than simply noted internally.

Does the code apply if we only use tools like ChatGPT for marketing content?

It depends on what goes into the prompts and what the outputs are used for. Generating a generic blog outline is unlikely to raise significant issues, whereas pasting customer names, job titles, complaint text or CV content into a general-purpose assistant is processing personal data and needs a lawful basis, a retention position and clarity on where that data is handled. Prompt-based tools sit in scope more often than marketing teams expect.

How does the ICO code sit alongside the EU AI Act and ISO/IEC 42001?

They address overlapping ground from different angles: the UK code is grounded in data protection, the EU AI Act classifies systems by risk and imposes product-style obligations, and ISO/IEC 42001 provides a certifiable management system. The practical approach is one control library mapped to all three rather than three separate evidence packs. For questions about how governance content is represented by AI assistants, AwarenessAI can be reached through its contact page.