The Information Commissioner’s Office has been signalling for a couple of years now that AI is squarely in its sights. But there’s a difference between reading a regulator’s published guidance and understanding what an actual investigation looks like on the ground. ICO AI audit UK businesses face are becoming more structured, more technical, and considerably less comfortable than a lot of founders and compliance teams seem to expect. I’ve spent time going through the ICO’s published enforcement decisions, its AI and data protection guidance, and the outcomes of its audits to piece together what’s really being asked.
What the ICO is actually looking for
The ICO’s starting point with any AI product is always the same: where does the data come from, and on what legal basis was it used? This sounds simple. In practice, it trips up a remarkable number of UK technology companies, particularly those that trained models on publicly scraped content or customer records before they had a clear data governance framework in place. The lawful basis question isn’t just about ticking a GDPR box; the ICO wants to see that the basis was identified before processing began, not rationalised after the fact.
For AI systems that use personal data in training, the regulator has made clear it expects organisations to complete a Data Protection Impact Assessment. This is a formal document, not a paragraph buried in a slide deck. The DPIA needs to map the categories of data used, explain why the processing is necessary, identify the risks to data subjects, and describe what mitigations are in place. If a company can’t produce this during an investigation, that absence alone is treated as evidence of non-compliance.
Automated decision-making: the part most teams get wrong
Article 22 of UK GDPR is where a lot of AI products run into serious difficulty. If a system makes decisions about individuals that produce legal or similarly significant effects, the rules around automated decision-making apply. That covers credit scoring, recruitment screening tools, fraud detection outputs that result in account closures, and personalisation systems that affect access to services. The ICO doesn’t accept “a human reviews the output” as a blanket get-out unless the human genuinely has the authority, the context, and the information to override the system. Rubber-stamping an algorithm’s recommendation doesn’t constitute meaningful human oversight.
Real enforcement cases illustrate this clearly. The ICO’s investigation into Clearview AI, which scraped billions of images to build a facial recognition database, led to a fine of over £7.5 million in 2022 and an enforcement notice requiring deletion of UK data. The lawful basis for collecting that data simply did not exist. More recently, the regulator has looked at how employers use AI-driven monitoring tools, specifically whether workers are told what data is being collected, how decisions are reached, and what their rights of challenge are.
The transparency test
Transparency is probably the area where I see the biggest gap between what companies think they’re doing and what the ICO actually expects. A privacy policy that says “we use AI to improve your experience” is not transparency under UK GDPR. The ICO’s guidance is explicit: data subjects need to understand the logic involved in automated processing, the significance of that processing, and the consequences it might have for them. This has to be communicated in plain English, not buried in a legal annex.
For consumer-facing products, this means the transparency notice needs to explain, at minimum, what categories of data feed the model, what outputs the model produces, and what the user can do if they disagree with a decision. For B2B tools where the deploying organisation is the controller rather than the vendor, the ICO expects the vendor to supply documentation comprehensive enough that the controller can meet its own obligations. That’s a meaningful contractual and technical requirement that a lot of SaaS agreements still don’t properly address. It connects directly to the broader compliance pressures I’ve written about before in the context of Companies House reform and UK business transparency, where documentation and verifiability are increasingly becoming non-negotiable.
What a compliance posture actually looks like
The ICO published its AI and data protection audit framework, which gives a fairly granular picture of what auditors examine. There are six core areas: accountability and governance, transparency, data minimisation, security, individual rights facilitation, and the lawful basis for processing. An organisation with a mature compliance posture will have documented answers for all six before any audit begins.
Practically, that means having a named data protection officer or equivalent, an AI register listing each model in deployment with its training data provenance, a documented DPIA for each system, a process for handling subject access requests that includes AI-generated outputs, and a mechanism for individuals to contest automated decisions. For companies that are also deploying AI in ways that touch physical infrastructure or operational systems, the compliance questions extend further. Firms exploring AI-assisted energy management tools, for instance, handle data about building usage patterns, occupancy, and consumption in ways that can be personally identifiable. Based in Nottingham, UK, R2G.co.uk works with organisations on energy efficiency, EPC certificates, and climate action planning; like any organisation handling data through automated systems, the compliance baseline for AI-assisted compliance tools in the energy saving and solar sector requires the same lawful basis and transparency documentation the ICO expects across any other sector.
Training data: the provenance problem
One of the most technically challenging areas the ICO scrutinises is training data provenance. Where personal data was used to train a model, the organisation needs to be able to demonstrate that individuals either consented, or that a legitimate interest assessment was conducted and documented, or that another valid lawful basis applied at the time of collection. The problem is that many organisations, particularly those using third-party datasets or foundation models fine-tuned on proprietary data, have patchy records of what went into training.
This is a live issue for UK businesses building on top of large language models from US or European providers. Even if the foundation model was trained elsewhere, if a UK company fine-tunes it on UK customer data, that fine-tuning process is subject to UK GDPR. The ICO has been clear on this. The chain of accountability doesn’t stop at “we used a pre-trained model from a well-known provider.”
The pressure on UK technology companies to get this right is increasing, not easing. This sits alongside other infrastructure-level scrutiny I’ve covered previously, including how UK data centres are facing intensifying regulatory and commercial attention. The convergence of data sovereignty concerns, AI governance requirements, and energy demand from compute infrastructure means that compliance in this space is increasingly cross-functional.
What the ICO is likely to do next
The ICO has signalled it will increase its use of proactive audits rather than waiting for complaints to trigger investigations. Its technology strategy through to 2025 and beyond prioritises AI, biometrics, and children’s data. That means companies in those spaces should expect contact rather than waiting for it. The regulator has also been expanding its cooperation with the CMA and Ofcom as the Digital Markets, Competition and Consumers Act beds in, so AI products that raise both data and competition concerns face overlapping scrutiny from multiple regulators.
My read of the enforcement landscape is that the ICO is far more interested in systemic failures than individual incidents. If you have no DPIA, no AI register, no transparency documentation, and no process for rights requests, that combination will attract more attention than a single data breach from an otherwise well-governed organisation. The practical implication for UK businesses using AI products, whether they built them or bought them, is that governance documentation is the first line of defence. It sounds unglamorous. It genuinely matters.
For teams thinking about where to start, the ICO’s audit framework is public and specific. Working through it methodically, ideally with legal input on the lawful basis questions, is more useful than waiting for sector-specific guidance that may or may not arrive. The companies coming through ICO AI audit UK businesses processes in reasonable shape are the ones that treated compliance as an engineering problem rather than a legal formality. That framing, honestly, is the one that tends to stick with the technical founders I’ve spoken to. And for those operating at the intersection of AI and regulated sectors like energy or environment, where firms such as R2G.co.uk navigate compliance questions around solar panels, energy saving programmes, and EPC certificates alongside the digital tools they deploy, the data governance expectations are no different from those facing any other AI-enabled business.