Tag: data protection impact assessment

  • The ICO’s New AI Guidance Is Out, What UK Engineering Teams Need to Change Right Now

    The ICO’s New AI Guidance Is Out, What UK Engineering Teams Need to Change Right Now

    The ICO has been telegraphing this for a while, but the updated guidance on AI and automated decision-making is now substantive enough that ignoring it is genuinely risky. I’ve read through the ICO’s AI and data protection guidance so you don’t have to wade through all of it cold, and what strikes me is how specifically it targets the kinds of systems that UK engineering teams are actually shipping in 2026. Personalisation engines, credit-scoring wrappers, HR screening tools, fraud detection layers. The ICO has clearly been paying attention.

    ICO AI guidance UK engineering compliance is the thing your legal team has been flagging in Slack for three months and your product squad has been quietly deprioritising. That’s about to become untenable. Here’s what actually needs to change, and in what order.

    Developer reviewing ICO AI guidance UK engineering compliance requirements on a laptop
    Photo by Christina Morillo on Pexels

    Lawful bases: the bit most teams get wrong from the start

    The default assumption in many UK product teams is that consent covers everything. It doesn’t. The ICO is explicit that consent is a high bar for automated processing, particularly when the AI output has any meaningful effect on an individual, whether that’s a loan decision, a job application ranking, or a content moderation outcome. If you’re relying on consent as your lawful basis for automated decision-making, you need to be able to demonstrate that consent was freely given, specific, informed, and unambiguous. In practice, that means no pre-ticked boxes, no bundled consents, and a genuine opt-out that doesn’t degrade the service.

    Legitimate interests is often a better fit for B2B contexts, but the balancing test has to be documented. That means actually writing it down: what interest are you pursuing, why does it override the individual’s rights, what safeguards are in place. If that document doesn’t exist, you’re exposed. Legitimate interests assessments (LIAs) are not optional paperwork, under the ICO’s current posture, they’re the thing an auditor will ask to see first.

    Transparency obligations: what you have to tell users, and when

    This is where most engineering teams have the biggest gap. Under UK GDPR Article 13 and 14, individuals must be told that automated decision-making is happening, what logic is involved in a meaningful way, and what the significance and consequences are. The ICO’s guidance makes clear that “meaningful” does not mean a paragraph buried in a privacy policy. It means something a non-technical user could actually understand.

    The practical implication is that your privacy notice almost certainly needs rewriting. But the deeper implication is architectural: you need to be able to generate a human-readable explanation of why a specific decision was made for a specific user, on demand. If your model is a black box that your team can’t interrogate at inference time, that’s a problem. I’d argue this is where the ICO’s guidance is pushing engineering teams hardest, and it aligns with what I’ve seen increasingly in the fintech space, where teams are building explainability into their pipelines from day one rather than retrofitting it. That compliance-by-design approach isn’t just good regulatory hygiene, it’s becoming a competitive requirement.

    DPIAs: when you need one and what it has to cover

    A Data Protection Impact Assessment is mandatory when your AI system is likely to result in high risk to individuals. Automated decision-making that produces legal or similarly significant effects is on the ICO’s explicit list. That covers a broader range of outputs than most teams realise. A ranking algorithm that determines which job applicants a recruiter sees is a significant effect. A fraud score that automatically blocks a transaction is a legal effect. A content recommendation engine that shapes what vulnerable users are exposed to sits in a grey area, but one the ICO is actively watching.

    If you shipped any of those without a DPIA, you need to do one retrospectively and document it properly. The DPIA has to cover: a description of the processing and its purposes, an assessment of necessity and proportionality, identification of risks to individuals, and the measures you’re taking to address those risks. Critically, it needs to involve your Data Protection Officer if you have one, and if you’re processing at scale without a DPO, you should check whether you’re required to have one under UK GDPR Article 37.

    The ICO has been conducting AI audits across UK businesses and the DPIA is one of the first documents they request. Teams that can produce one quickly, and show it was done before deployment, are in a materially better position.

    The specific gotchas for AI that affect individual users

    A few things in the ICO’s guidance catch teams out because they’re specific to AI rather than general data protection principles.

    First, solely automated decisions with legal or significant effects require a specific lawful basis under Article 22 of UK GDPR. This isn’t the same as your general processing lawful basis. If a human reviews the AI output before the decision is made, you may fall outside Article 22, but the human review has to be genuine, not a rubber stamp. The ICO has been clear that a human who sees a recommendation and approves it in two seconds without access to the underlying data does not count as meaningful human review.

    Second, special category data. If your model was trained on or infers data that falls into special categories (health, ethnicity, political opinion, and so on), additional restrictions apply. This catches teams who built models on data that seemed clean but where protected characteristics are proxied by other variables. Postcode as a proxy for ethnicity is the classic example, and it’s the kind of thing an ICO audit specifically looks for.

    Third, the right to explanation. Under UK GDPR Article 22(3), individuals subject to solely automated decisions have the right to obtain human intervention, express their point of view, and contest the decision. You need a process for this. Not a theoretical process, an actual one, with a named owner, a response time, and a genuine mechanism to override the system. If your AI is making calls and there’s no route for a user to challenge them, that’s a compliance failure.

    Where to start if you’re behind on this

    Most teams aren’t starting from zero, but plenty are further back than they should be. My honest recommendation: start with a systems audit. Map every AI system that touches individual user data and classify it by the significance of its outputs. Anything that affects access to services, financial products, or employment sits at the top of the list and needs immediate attention.

    Then work backwards from the transparency obligation. If you can’t explain what your model does in plain language, you can’t meet your Article 13 duties. That’s the single most common finding in ICO AI audits right now, and it’s one of the easier things to fix, at least at the documentation level, without rebuilding your model.

    It’s also worth knowing that the ICO’s guidance connects closely to the broader CMA oversight of AI systems, particularly where market power is involved. If you’re building on top of a major foundation model or cloud AI service, the CMA’s scrutiny of AI cloud arrangements adds another layer to your compliance picture that your legal team should be across.

    The ICO isn’t trying to kill AI products. The guidance is actually reasonably workable once you strip out the legalese. But it does require engineering teams to treat privacy as a design constraint rather than a deployment checkbox. If you’re a CTO or product lead who’s been treating this as someone else’s problem, the updated guidance is a clear signal: it’s now yours.

    Frequently Asked Questions

    What does the ICO's AI guidance actually require UK developers to do?

    The guidance requires developers to identify a valid lawful basis for automated processing, provide meaningful transparency to users about how AI decisions are made, conduct Data Protection Impact Assessments for high-risk systems, and implement processes for human review and contestation where decisions have legal or significant effects on individuals.

    When is a DPIA required for an AI system in the UK?

    A DPIA is required when your AI processing is likely to result in high risk to individuals. Automated decision-making that produces legal or similarly significant effects, processing of special category data at scale, or systematic monitoring of publicly accessible areas all trigger the requirement. If in doubt, the ICO says you should carry one out regardless.

    Does a human reviewing an AI decision mean Article 22 UK GDPR doesn't apply?

    Only if the human review is genuine. The ICO is explicit that a token review, where a person approves an AI recommendation without meaningful access to the underlying data or genuine capacity to override it, does not satisfy the requirement. The human involvement must be substantive and documented.

    What counts as a 'significant effect' under UK GDPR Article 22?

    The ICO considers effects significant when they influence access to services, affect financial decisions, determine employment opportunities, or substantially alter how an individual is treated. This goes beyond purely legal effects and captures many common AI use cases including credit scoring, recruitment screening, and content moderation.

  • Inside the ICO’s AI Audits: What UK Businesses Are Actually Being Asked to Prove

    Inside the ICO’s AI Audits: What UK Businesses Are Actually Being Asked to Prove

    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.

    Professional reviewing ICO AI audit compliance documentation in a UK office
    Photo by Kampus Production on Pexels

    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.

    ICO AI audit UK businesses compliance documents and data governance records on a desk
    Photo by Mikhail Nilov on Pexels

    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.

The Latest