← Back to The Sky View

    UK ICO Opens a Call for Evidence on AI Agents: What Data-Protection Teams Should Prepare

    By David Ginsburg ·

    The UK Information Commissioner’s Office has opened a call for evidence on AI agents, and it closes on November 20, 2026. If your organization deploys agents that read, write or act on personal data, you have about five weeks to decide whether to tell the regulator what you see in practice, and to be ready for the questions that follow.

    A call for evidence is not a rule. It is the stage where a regulator decides what it needs to understand before it writes guidance, and where it learns which concerns are theoretical and which are already causing problems. The organizations that respond shape the guidance. The ones that do not inherit it.

    This post sets out why agents raise different data-protection questions from chatbots, the five questions we expect the ICO to probe, and a checklist your team can work through before the deadline.

    Why agents are not just chatbots with a new name

    An agent changes the data-protection picture because it acts, not just answers. Three differences matter most.

    1. Chained access. One agent task can touch a CRM, a mailbox, a ticketing system and a data warehouse in a single run. Personal data moves across systems that were never assessed together.
    2. Purpose drift. A person asks an agent to “prepare for tomorrow’s call.” The agent decides which records to pull. The purpose was set by the user; the scope was set by the model.
    3. Decisions without a person in the loop. When an agent approves, routes, flags or declines something that affects an individual, the rules on automated decision-making apply, and “a human could have reviewed it” is not the same as “a human did.”
    Chatbot versus AI agent: an agent chains access across CRM, mailbox, ticketing and data warehouse, decides its own scope, and acts without a person in the loop
    Figure 1. A chatbot answers; an agent pulls personal data from several systems and acts on it.

    None of this is new law. The existing principles in UK GDPR still apply: lawfulness, purpose limitation, data minimization, accuracy, security and accountability. What is new is that the evidence you need to show you meet them now has to come from a system that decides its own steps.

    Five questions to be ready for

    The ICO has not published its questions in a form we can quote here, so treat these as our reading of where UK GDPR meets agent behavior. Each pairs a question with the evidence a regulator, or your own DPO, would want to see.

    QuestionWhat to have ready
    What personal data can each agent reach?A current inventory of agents, the systems and data each can access, and who approved that access
    Is the purpose still the purpose?A record of the intended purpose per agent, and a way to detect when it pulls data outside that scope
    Who decided, and can you show it?Logs that tie each action to an agent, a user, a prompt and a data source, kept long enough to answer a complaint
    Where does a human actually intervene?Defined approval points for actions that affect individuals, with evidence they are used, not just available
    What happens when the agent is wrong or attacked?Controls for prompt injection and over-broad tool use, plus an incident process that covers agent behavior

    If you cannot answer one of these in an afternoon, that gap is the most useful thing you could describe in a response to the call for evidence.

    The standards gap: policy on paper, nothing at runtime

    Most organizations will reach first for the frameworks they already know, such as the NIST AI Risk Management Framework and ISO/IEC 42001. They are good at governance: roles, risk assessments, documentation. They say much less about how to enforce a limit on an agent while it is running.

    That gap is where data-protection teams get stuck. A policy that says “agents may only access data needed for the task” is a statement of intent. A regulator will ask what stops an agent from breaching it at 2 a.m. on a Sunday, and how you would know afterward.

    The practical answer is controls that act at the point of the agent’s action: scoped credentials per agent, checks on tool calls before they run, and a tamper-resistant record of what happened. Evidence produced that way is what turns a policy into an accountable control.

    The standards gap: governance frameworks state the rule, while runtime controls (scoped identity, checks before each tool call, a tamper-resistant action record) enforce it and produce accountability evidence
    Figure 2. Governance states the rule; runtime controls enforce it and produce the evidence a regulator asks for.

    A checklist for the next five weeks

    • List every agent in production or pilot, with owner, purpose and the systems it can reach
    • Map which of those systems hold personal data, and note any special-category data
    • Give each agent its own identity and the narrowest access that lets it do its job
    • Turn on action-level logging, and confirm you can answer “who, what, which data, when” for a single run
    • Mark every agent action that affects an individual, and define where a person approves it
    • Update your DPIA for agent use, or start one if none exists
    • Add agent misbehavior and prompt injection to your incident response plan
    • Decide what you will tell the ICO, and submit before November 20, 2026

    Skyrelis builds the runtime controls and audit evidence this list depends on. Our compliance-controls playbook walks through how to put them in place. If you want to test your own readiness first, we’ve published an agent security scorecard where you can check your controls.