ICO identifies shortcomings at UK developers
The UK ICO checked ten AI foundation-model makers and opened a call for evidence on agentic AI. What this means for proof about data use per system.
You must now demonstrate, per AI system, which personal data you process, for which purpose, on which legal basis, and with which safeguards in place. General privacy statements no longer satisfy regulatory scrutiny.
The prompt is an analysis of 15 October 2026 of ICO oversight of foundation models and agentic AI, which argues that broad assurances about data protection are insufficient without concrete, system-specific justification. The regulator examined ten major foundation-model developers and opened a six-week call for evidence on agentic systems, closing on 20 November 2026. In our assessment, this signals a shift in regulatory practice: controllers and integrators can no longer rely on supplier assurances or generic compliance claims. You will need to hold documented evidence per system before deployment, not after complaint or audit.
What shortcomings did the regulator identify in current practice?
The ICO found that foundation-model developers had submitted weak justifications for legitimate interests assessments, underdeveloped data protection impact assessments (DPIAs), and inadequate transparency about training data and the processing of special categories such as health or origin information. Broad purpose descriptions and general references to "safeguards" proved insufficient. The regulator is now working with eleven major model developers on evidence of compliance and has commissioned research into data protection harm across the foundation-model lifecycle. This is not a one-off exercise: the findings feed into future ICO guidance and a statutory code of practice on AI and automated decision-making.
Which risks does agentic AI introduce that differ from standard model assessment?
Agentic systems—those that carry out tasks and take actions independently—create specific governance challenges. Responsibilities across the chain become unclear, automated decision-making operates at larger scale, and the rights of data subjects become harder to exercise. The ICO identifies particular risks: controller and processor roles may be ambiguous when you integrate a supplier's agent; special categories of data can be inferred from neutral input, meaning a system you classified as low-risk may still process health or origin information; and access or deletion requests may become harder to coordinate across dynamic system chains. The regulator states explicitly that organisations remain responsible for compliance when they develop, deploy or integrate agentic AI, regardless of who built the underlying model.
What are the concrete compliance gaps you must address?
- Weak legitimate interests assessments — insufficient justification for why processing is necessary and proportionate.
- Inadequate data protection impact assessments — DPIAs that do not substantiate risk or mitigation per system.
- Opaque training data provenance — lack of transparency about which data was used and whether special categories were included.
- Unclear controller and processor roles — ambiguous responsibility allocation in agentic chains.
- Inferred special categories — failure to test whether neutral input can reveal health, origin or other protected data.
- Unlogged data subject rights — inability to track which retrievals, tool calls and decisions occurred, making access and deletion requests harder to fulfil within statutory deadlines.
What evidence must you be able to demonstrate before go-live?
- Document the model, its purpose and the lawful basis — record which model each workflow uses, the personal data it touches, and the legal ground for processing.
- Complete a substantiated DPIA where required — do not rely on the supplier's category classification; test actual input and output to identify whether special categories are inferred.
- Define and record controller and processor roles — include explicit clauses in procurement and integration contracts stating who holds which responsibility and who may stop or revoke agentic actions.
- Map data flows and logging across the chain — record which retrievals, tool calls and decisions are logged so you can respond to data subject requests within statutory deadlines.
- Test the system's actual behaviour — verify that the supplier's risk assessment matches what the system does in practice, particularly for inference of protected data.
How should you interpret the ICO's call for evidence?
A significant risk is that organisations read this call as something for model makers alone. The regulator's explicit statement is that organisations that procure, deploy or integrate agentic AI remain responsible for compliance. This means you cannot treat the call as a matter for suppliers to address. The ICO publications do not establish a universal error rate and do not create new legal duties for every organisation. In our assessment, they clarify how existing data-protection expectations under GDPR apply to foundation models and agentic systems. Start with an inventory per system and work towards verifiable evidence. Treat agentic systems with system access as you would privileged identities: make human oversight of AI decisions testable and auditable.
No tool can substitute for your own assessment of which data your organisation holds, which purpose justifies its use, and which safeguards you must implement. Compliance tooling can help you document and track these decisions, but the professional judgement—whether a particular processing is lawful, proportionate and transparent—remains yours. The regulator's findings make clear that this judgement must be recorded and defensible before deployment, not reconstructed afterwards.
Sources: This article draws on reporting and guidance from UK Information Commissioner's Office, Burges Salmon and TLT LLP.
Written by
Marit Halversen
Covers AI governance and regulatory design, with a focus on how compliance obligations land on architecture rather than on paperwork.