SI 2026/425 requires the Information Commissioner to prepare a statutory code of practice on processing personal data when developing and using AI and when making automated decisions, including children's data. It gives guidance on good practice rather than new obligations, but once issued the Commissioner, courts and tribunals must take it into account.
What is SI 2026/425, and when did it come into force?
SI 2026/425 is The Data Protection Act 2018 (Code of Practice on Artificial Intelligence and Automated Decision-Making) Regulations 2026. It was made on 16 April 2026, laid before Parliament on 21 April 2026, and came into force on 12 May 2026, extending to England, Wales, Scotland and Northern Ireland.
Some commentary has treated this as an AI law. It is not. It regulates nobody. It is a commissioning instrument: it puts a duty on the Information Commissioner to write something. Your obligations still sit in the UK GDPR and the Data Protection Act 2018. What changes is that a statutory code will sit on top and describe what good looks like.
Who has to prepare the code, and under what power?
The Information Commissioner, under section 124A of the Data Protection Act 2018, headed "Other codes of practice" and inserted by the Data (Use and Access) Act 2025. It says the Commissioner "must prepare appropriate codes of practice giving guidance as to good practice in the processing of personal data if required to do so by regulations made by the Secretary of State". SI 2026/425 is that requirement.
The route is long. Section 124A(4) requires consultation with the Secretary of State, trade associations, data subjects and bodies representing them. Section 124B requires a panel of subject-matter experts plus people likely to be affected, whose report the Commissioner must answer in public.
Regulation 3 modifies that process for this code. It inserts a new section 124B(7A): "The panel must not consider or report on any aspect of the code relating to national security." That is why the Regulations cite section 124B(11) as an enabling power alongside section 124A.
Section 125 governs approval. The Commissioner submits the final version to the Secretary of State, who lays it before Parliament. If neither House resolves against it within forty days, discounting dissolution, prorogation and long adjournments, the Commissioner issues the code, and it comes into force twenty-one days later.
What will the code cover?
Regulation 2 sets the scope, and it is the only authoritative statement of scope that exists. The Commissioner must prepare a code giving guidance as to good practice in the processing of personal data "in relation to (a) developing and using artificial intelligence, and (b) automated decision-making", with automated decision-making defined by reference to specific provisions of the UK GDPR and the 2018 Act. The code must also include guidance on processing children's personal data.
Two limbs. Development and use of AI is the wider one: training data, lawful basis, purpose limitation, minimisation. Much of that ground the ICO's existing AI guidance already covers. Automated decision-making is the narrower and sharper limb, where most regulated buyers will feel this.
Beyond the Regulations, the ICO's published plan of action says the code will give guidance on transparency and explainability, bias and discrimination, and rights and redress. That is stated intention, not law. The code itself has not been published: as I write in September 2026 there is no draft code and no panel statement. Anything more specific than those two sources is guesswork, worth remembering when a supplier sells you readiness.
Why is children's data called out separately?
Because the safeguards around automated decisions assume a data subject who can notice a decision, understand it and push back, and a child often does none of the three. Where profiling drives ranking, recommendation or eligibility, a child is more exposed and less likely to contest it.
This is continuity rather than a new front. The Commissioner already maintains the Age Appropriate Design Code under section 123 of the same Act. Naming children's data in regulation 2 means the AI code must speak to that population in its own terms, rather than leaving organisations to reconcile two documents.
Does the code create new legal obligations?
No. Section 124A is a power to give guidance on good practice, and a code issued under it creates no new duty and no new cause of action. That is the honest answer, and also the one that gets organisations into trouble, because the next part matters more.
Section 127 sets out the effect of a code issued under section 125(4). The Commissioner must take a relevant provision into account when exercising functions under the data protection legislation. The code is admissible in evidence in legal proceedings. A court or tribunal must take a relevant provision into account when determining a relevant question. So the code will not tell you that you must do a particular thing. It describes what good practice looks like, and if you did something else you are the one explaining why, to a regulator or tribunal obliged to have read it.
How does it sit next to the Data (Use and Access) Act 2025?
The Act supplies the obligations and the code will supply the method. Section 80 of the Data (Use and Access) Act 2025 replaced Article 22 of the UK GDPR with Articles 22A to 22D, with parallel changes for law enforcement and intelligence services processing.
Article 22A defines a significant decision, and defines a decision based solely on automated processing as one with no meaningful human involvement, with the extent of profiling relevant to that question. Article 22B restricts significant solely automated decisions taken on special category data. Article 22C requires safeguards: information to the data subject, and the ability to make representations, obtain human intervention and contest the decision. Article 22D lets the Secretary of State add to them.
Read that alongside regulation 2 and the code's job is visible. Article 22C says a human must be able to intervene. It does not say what counts as intervention, how you evidence it, or how a reviewer six months later distinguishes a person who approved a decision from a person who was shown a screen. Closing that gap is what the code has been commissioned to do.
What should you put in place before the code lands?
Build the inventory and build the record. Both survive whatever wording the Commissioner settles on.
The inventory lists every place in your organisation where a decision about a person is taken wholly or partly by a machine, including the ones nobody calls AI: scorecards, rules engines, queue routing, thresholds in a workflow tool. For each, record whether the decision is significant, whether a human is genuinely in the loop, and what happens when the person affected objects.
The record is the harder half. You need to reconstruct a specific decision about a specific person, months later, to the satisfaction of someone hostile. That is a design problem, not a reporting problem, and it is why we built Mickai SIOS the way we did. The Open Audit Record seals every consequential action under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024. Consequential actions wait for a named person to approve them, and that approval sits inside the sealed record, not in a note beside it. The system runs on hardware the customer owns, offline capable, with private knowledge bases and no data egress.
The record is tamper-evident, not tamper-proof, and the difference is the point. Nothing stops an administrator with enough access altering stored bytes. A signature makes the alteration fail verification, so the change is detectable by someone outside the organisation holding nothing but a public key. Tamper-proof is a promise no cryptography delivers.
What evidence will you need about automated decisions?
Expect to be asked what the system decided, on which inputs, under which version, and who approved it. Those four, bound to each other, are the backbone of every explanation you will ever give.
In practice: a per-decision record holding the data subject and the decision taken, the input data and its provenance, the model or rule version in force, any human review with the person named and what they were shown, and the outcome of any representation, intervention or contest under Article 22C. You also need to hand an auditor an export they can check without your supplier present. An auditor verifies an exported Open Audit Record offline with a public key, using tools that are not ours. Logs written by the system that made the decision, verifiable only with that vendor's tools, are the weakest form of this, and in my experience the most common, which is the case for building the audit trail into the substrate rather than bolting it on.
None of this puts us against the companies building the compute and cloud layers, and cloud remains a good answer for work that is not regulated. What the code will press on is an older assumption: that a regulated organisation must rent its intelligence, ship data offsite and take a supplier's word for what happened to it. Our closed beta is open with one regulated company onboarding as a design partner, and that partner asked to see the record before the model.
Frequently asked questions
Is the ICO code of practice in force yet?
No. SI 2026/425 came into force on 12 May 2026, but that instrument only requires the Information Commissioner to prepare the code. As at September 2026 no draft code has been published. Once prepared it must go through a panel, then to the Secretary of State, then Parliament, and it takes effect twenty-one days after the Commissioner issues it.
Does the code apply to us if we only use AI internally?
Regulation 2 covers developing and using artificial intelligence, with no carve-out for internal use. If you process personal data, internal deployment is in scope: staff are data subjects too. An internal tool that scores, ranks or filters people can produce a significant decision, and the Article 22C safeguards apply regardless of whether the system faces customers.
What happens if we do not follow the code?
Not following the code is not itself unlawful. Under section 127 of the Data Protection Act 2018, though, the Commissioner must take relevant code provisions into account when exercising functions, the code is admissible in evidence, and courts and tribunals must take it into account. Departing from it is permitted. Being unable to explain the departure is the exposure.
Does this replace the ICO's existing guidance on AI and data protection?
No. The ICO's guidance on AI and data protection remains published and usable, and the ICO consulted on updated automated decision-making and profiling guidance between 31 March and 29 May 2026, which the ICO has said will inform parts of the code (see the AI and biometrics strategy update, March 2026), and add https://ico.org.uk/about-the-ico/our-information/our-strategies-and-plans/artificial-intelligence-and-biometrics-strategy/ai-and-biometrics-strategy-update-march-2026/ to the CITATIONS array. A statutory code carries the section 127 effect that ordinary guidance does not.
What records should we be keeping about automated decisions now?
Keep a per-decision record: who the decision was about, what was decided, the inputs and their source, the model or rule version in force, and any named human review with what that person saw. Add the outcome of any representation, intervention or contest. Keep it in a form an auditor can verify without your vendor's tools.
Written by Micky Irons, founder and chief executive of Mickai LTD, which builds a sovereign AI operating system for regulated organisations. More at mickai.co.uk.
Top comments (0)