The ICO's agentic AI timetable moved. The design work remains.
Future agentic AI guidance does not remove current design responsibilities. Define the processing purpose, permitted tool access and routes for people to challenge significant automated decisions, while tracking the ICO’s publication status.
Keep sources linked to the record used for review. The diagram does not represent automatic approval.
An agentic AI design can make decisions about data access and human intervention before dedicated guidance is final. The organisation should document those choices against current law and published regulatory research, with unresolved questions kept visible for later review.
As checked on 2 October 2026, the ICO roadmap lists agentic AI guidance as drafting, a consultation planned for September 2026 and final guidance due in Autumn 2026. This replaces the Spring 2027 timetable previously stated here. A roadmap entry is a plan and does not establish that the consultation has opened.
Teams can prepare questions for a consultation while completing their present assessment. Purpose, access permissions and the effect of decisions on people need explicit treatment in the design. A future publication may inform that work without supplying evidence the organisation has not collected.
The consultation is planned, and the design work is current
The ICO maintains a public list of the guidance it has in development, showing the stage each item has reached and whether there will be a public consultation (guidance in development, technology). The roadmap entry identifies the planned stage and timing. Check the linked guidance or consultation itself for its actual publication, response terms and closing date before relying on the schedule.
The automated decision-making and profiling guidance is also being updated, including the Data (Use and Access) Act amendments. Its consultation is closed, and the roadmap lists Winter 2026 for a final version. Those are separate documents with separate timetables. Neither changes the need to identify which decisions in an agent’s trace affect a person.
The sequence for the agentic document now includes a chance to comment. It is useful for unresolved questions, but treating the planned consultation as a reason to postpone purpose definition or access control would confuse future guidance with current design responsibilities.
What the regulator has already put in print
The ICO’s 2026 Tech Futures report provides a published account of agentic AI data-protection concerns. It links legal and rights questions to choices about system architecture, governance and control.
The assessment needs to connect processing purposes and affected people to the system’s data access, tool permissions and operating controls.
The same passage names the choices it means — the data and tools that a system can access, and which governance and control measures are put in place (ICO tech futures: Agentic AI). It then describes a poorly implemented system as one with no clear purposes, one connected to databases not needed for its tasks, or one with no measures in place to secure access, monitor or stop activity, or control the further sharing of information. Those are architecture defects, not policy ones.
One item on the risk list is worth reading twice, because it is the tension at the centre of the technology rather than an incidental hazard. The ICO names the risk of purposes for agentic processing being set too broadly to allow for open-ended tasks and general-purpose agents. An agent is bought for its generality. A purpose has to be narrow enough to constrain what is processed. The wider the tool surface, the harder it becomes to write a purpose that is a purpose rather than a description of the product.
The safeguards are already law, and they are a build decision
The second published source is not guidance at all. Section 80 of the Data (Use and Access) Act 2025 replaced Article 22 of the UK GDPR with a new Articles 22A to 22D (section 80). Article 22A defines a decision as based solely on automated processing where there is “no meaningful human involvement in the taking of the decision”, and as significant where it produces a legal effect or a similarly significant effect for the person. Article 22B keeps a restriction, subject to stated conditions, on significant decisions built on special category data, and on decisions where the processing relies on Article 6(1)(ea). Everything else moves to Article 22C, which requires safeguards.
Each safeguard concerns a decision and the person affected. An agent trace may include retrievals, tool calls and intermediate steps without clearly marking which action constitutes a significant decision. Record that relationship where relevant and test the route for information, representations, intervention and challenge. A tool log alone may not support all of it.
- Layer 01 A decision exists The trace marks which step was a decision rather than a step towards one.
- Layer 02 It has a subject That step is joined to the person it affected.
- Layer 03 Its inputs are recoverable Which tool call, which record, which retrieved passage, at which version.
- Layer 04 A human can change it Someone with authority to alter the outcome, not only to explain it.
Article 22A adds a clause that reads like a warning to a particular design. In considering whether there was meaningful human involvement, a person must consider, among other things, the extent to which the decision was reached by means of profiling. A reviewer at the end of a long agentic chain, approving a recommendation whose derivation they cannot reconstruct, is exactly the arrangement that clause invites a regulator to look at.
What to do while the guidance is drafted
Write the purpose at the level of the task, not the product. “An assistant for the operations team” is a product. What is processed, for which decision, about whom, is a purpose. If the honest answer is that the agent may reach anything the team can reach, that is a finding, and better found now than produced for a regulator later.
Treat the tool surface as a recorded decision. Which systems the agent may call is the choice the ICO named first. Record what was connected, what was not, and why — a refused connection is the cheapest evidence of data minimisation there is, and it exists only if somebody wrote it down at the time.
Mark decisions inside the trace. This is an engineering change, not a policy one. A log of every tool call is not the same artefact as a record of which calls constituted a significant decision about a named person. No later document creates the second from the first.
Run one intervention end to end. Take a decision the agent made last week and attempt all four Article 22C measures for it. It produces the only honest answer available about whether the architecture supports the safeguards.
Keep a short list of questions the planned consultation could settle. When the draft opens, answer from a documented system design and concrete gaps rather than a general preference about agentic AI. Check the ICO roadmap for the actual opening date and response terms.
What this does not tell you
It does not tell you what the draft or final guidance will say. The regulator’s published research is a reasonable basis for design and a poor basis for certainty. It is not a substitute for the planned consultation document.
It does not tell you whether a particular decision your agent takes is “significant” for the purposes of Article 22A. That turns on the effect on the person, which is a question about your system and your users rather than about agents in general.
It does not tell you that the definitions will hold. Article 22D gives the Secretary of State power to make regulations about what is and is not to be taken as meaningful human involvement, and about which descriptions of decision have a similarly significant effect. A design built on today’s reading of those two phrases is built on something a statutory instrument can move.
The Institute provides architecture, governance and risk advice to identify relevant questions, assess existing controls and specify missing evidence. That work supports the client’s legal and compliance assessment. It does not establish that an organisation meets every UK GDPR obligation or provide a certification.
The architecture owner can now document the permitted processing, connected systems and consequential decision points. Test an intervention against that design and record the gaps. Future guidance can then be assessed against a specific system rather than a general description of an assistant.