ICO identifies data protection shortcomings at major foundation-model developers

The UK privacy regulator ICO checked ten major AI foundation-model makers and opened a call for evidence on agentic AI in October 2026. General privacy claims no longer suffice: anyone training, procuring or deploying AI models with personal data must demonstrate per system which data, which purpose, which basis and which safeguards apply.

The call for evidence runs for six weeks and closes on 20 November 2026. The responses feed into future ICO guidance and the statutory code of practice on AI and automated decision-making. According to TLT’s analysis of the ICO consultation, the call covers themes including data security, transparency, accountability, automated decision-making, fairness, purpose limitation and lawful processing. These ICO themes touch on subjects that are also relevant to obligations for certain high-risk systems under the EU AI Act; that comparison is our editorial reading and not a conclusion of the ICO.

What exactly did the ICO find at the ten AI foundation-model makers?

The ICO describes the outcomes of its oversight of the largest foundation-model developers in the UK. Ten developers have committed to or implemented improvements around transparency, the rights of data subjects and safeguards. At the same time, the regulator identifies shortcomings that are more broadly relevant.

According to the analysis by Burges Salmon on the ICO foundation-model report, these include weak justification of legitimate interests assessments, insufficiently developed data protection impact assessments (DPIAs), inadequate transparency about training data and the possible processing of special categories of personal data, such as data on health or origin. The message: broad purpose descriptions and general references to "safeguards" are insufficient without specific, substantiated evidence per model.

The ICO does not frame this as a one-off publication. In its strategy update, the regulator reports that it is working with eleven major model developers on evidence of compliance and policy positions, and that it has commissioned research into the nature, scale and severity of data protection harm across the foundation-model lifecycle.

Which new risks does the ICO identify for agentic AI and the call for evidence?

For agentic AI, systems that carry out tasks and take actions independently, the ICO identifies risks that go beyond classic model assessment. Responsibilities across the chain become less clear, automated decision-making larger in scale and the rights of data subjects harder to exercise.

In its publication ICO tech futures on agentic AI, the regulator names, among others:

• unclear allocation of controller and processor responsibility between developer, integrator and user;
• purposes framed too broadly and processing beyond what is necessary;
• possible inference of special categories of personal data from seemingly neutral data;
• more complex exercise of data subject rights in dynamic chains;
• new cybersecurity risks from autonomous tool use and data access.

The ICO states explicitly that organisations remain responsible for compliance when they develop, deploy or integrate agentic AI. The call for evidence seeks views and practical experience on these themes, including how organisations address the data-protection risks associated with agentic AI.

What does this shift from model promises to demonstrable evidence mean for our readers?

Our analysis: because the ICO requests evidence of compliance and broad privacy statements without concrete justification prove insufficient in this oversight context, practical attention shifts from the supplier's sales presentation to your own file; in our view, the controller within your organisation should be able to show, per AI system, an appropriately justified DPIA where required and a documented legal basis for the relevant processing operations, rather than prepare that evidence only after a complaint or audit. Because the ICO names unclear controller and processor roles for agentic AI as a risk, your organisation may bear responsibility for compliance with an agent that a supplier designed; our recommendation is therefore that, before go-live, every procurement or integration contract should include a clause recording who holds which role and who may stop or revoke the agentic actions. Because special categories of personal data can be inferred from neutral input, a system you assessed as low-risk may still process health or origin data; our recommendation is therefore that your privacy professional should test the actual input and output rather than rely solely on the supplier's category classification. Because the rights of data subjects are harder to exercise in dynamic chains, an access or deletion request may become harder to coordinate across a dynamic system chain; our recommendation is therefore that the product owner record which retrievals, tool calls and decisions are logged, so that the organisation can better assess how a request should be answered within the statutory deadline.

In our assessment, a significant risk is that organisations read the call for evidence as something for model makers alone. The regulator states that organisations that develop, deploy or integrate agentic AI remain responsible for compliance. In our analysis, this means that organisations that procure or integrate a system should not treat the call as a matter for model makers alone. Note, however: the ICO publications do not establish a universal error rate and do not create a new legal duty for every organisation. In our assessment, they primarily clarify how existing data-protection expectations may apply to foundation models and agentic AI.

Which steps demonstrably record data use and responsibilities per AI system?

Start with an inventory per system and work towards verifiable evidence. The following steps follow directly from the risks the ICO identifies and align with privacy by design as a lifecycle duty under GDPR Article 25:

1. Make a data and tool inventory per agent: which sources are consulted, which tools called, which actions carried out.
2. Describe purpose, basis and necessity for each processing step, not for the model as a whole.
3. Record which party holds controller or processor responsibility, including the chain from developer to deployment.
4. Give data subjects understandable information about sources, use, rights and opt-out options.
5. Test whether safeguards actually work instead of merely naming them; limit access and actions according to least privilege.
6. Log retrievals, tool calls, decisions and human approvals, and ensure independent monitoring with an external stop or revocation option.

Those working with independently acting agents would be wise to treat them like governing an AI agent with system access as a privileged identity and explicitly making human oversight of AI decisions testable. More background on bases and rights is available in the topic hub on AI privacy and GDPR.

Sources: The article draws on publications from the UK Information Commissioner's Office and on analyses by Burges Salmon and TLT LLP of the ICO foundation-model report and the agentic-AI call for evidence.