The ICO code of practice arrives as a duty, not a suggestion
A statutory code carries weight that guidance does not — a regulator must take it into account and a court may. The instrument requiring one on AI and automated decision-making is already in force, and the position it will encode is already published.
The line appears in a lot of UK readiness plans, and it is doing more work than the people who wrote it intended. It says something like await the ICO code, and it sits under a system that is already making decisions about people.
There are two problems with it. The first is that a statutory code is not a document that changes what is required — it is a document that describes what is already required, in a form that has legal weight. The second is that the regulator has been publishing its position on automated decision-making, fairness and transparency for years, and a code of practice will be built from it rather than in place of it.
The claim: the code will not be a surprise, and an organisation waiting for it is waiting for something it has largely already read.
What has actually happened
- 16 April 2026 The regulations are made The Data Protection Act 2018 (Code of Practice on Artificial Intelligence and Automated Decision-Making) Regulations 2026.
- 12 May 2026 They come into force The Information Commissioner is required to prepare a code on processing personal data in connection with AI and automated decision-making.
- Consultation, closed May 2026 Draft guidance on automated decision-making and profiling The regulator’s substantive position, put out for comment before the code is drafted.
- Ahead The code itself Preceded by a statutory panel and a period for representations. The date is not the useful part.
The instrument itself is short and worth reading rather than being told about — the regulations are on legislation.gov.uk — because it establishes the shape of what is coming rather than the content, and the shape is the part that changes an organisation’s exposure.
Why a code is different from guidance
| Guidance | A statutory code of practice |
|---|---|
| Persuasive. The regulator will point at it | The regulator must take it into account when exercising its functions |
| Evidence of good practice if followed | Admissible in legal proceedings where a provision appears relevant |
| Updated when the regulator chooses | Prepared through a defined process, with consultation and parliamentary steps |
| Departure is a judgement call | Departure is a position you may have to explain |
That last row is the practical difference. An organisation doing something other than what a code describes is not thereby breaking the law — a code is not legislation — but it has taken on a burden of explanation it did not previously carry. In an enforcement conversation or a claim, the question stops being whether your approach was reasonable in the abstract and becomes why you departed from the published one.
What to do with the time
The regulator’s existing material on AI and data protection is substantial, and the themes that recur in it are the themes any code will carry: a lawful basis identified before deployment rather than after, fairness assessed on outcomes rather than asserted from intent, transparency that a person can act on, human review that is meaningful rather than nominal, and the ability to explain a decision about an individual.
Every one of those is testable against a system you already run.
The third line is where UK systems most often fail on inspection, and it fails quietly. Human review is recorded as present because a person clicks approve. It is meaningful only if that person sees what the system relied on, has time to consider it, and is not measured on throughput in a way that makes disagreement costly. None of that is visible in a system diagram, and all of it is visible in an operations floor.
The agentic question underneath
Automated decision-making rules were written with a particular picture in mind: a system produces a decision, a person is subject to it. Agentic systems complicate that picture, because the consequential act may be a sequence of small steps none of which looks like a decision about a person, taken by a system nobody framed as a decision-maker.
The regulator has said, in its published work, that design and architecture determine how data protection law applies to these systems. That is not a placeholder. It means the classification of an agentic system is decided by choices your engineers are making now, and it will be assessed against those choices rather than against how the system was described in a policy document.
What this does not tell you
This is not legal advice and it is not a prediction of the code’s content. Drafting is not finished, the statutory process includes consultation, and anybody claiming to know what the final text says is describing their own expectations. Interpretation for your organisation remains with your counsel and your data protection officer.
Nor does preparing against the regulator’s published positions put an organisation in line with the eventual code as a matter of course. It reduces the distance. The alternative — doing nothing until publication and then attempting to retrofit explainability, review quality and outcome monitoring into deployed systems — is the expensive path, and it is the one the await the code line commits an organisation to without saying so.
The reader who acts differently is whoever owns that line in the readiness plan. Replace it with the six checks above, run against one live system this quarter. The findings will be the same findings the code eventually asks about, and you will have them a year early.