This post is for CTOs and engineering leads shipping AI systems for UK customers who need an ICO review to be uneventful. It is the engineering version of UK GDPR: the DPIA as a build document, lawful bases for training data, Article 22 human review, international transfers, data-subject rights through embeddings and indexes, and the ICO's AI guidance, with the patterns we use on UK engagements.
The shape of UK AI compliance in 2026 is broadly stable. The UK GDPR and the Data Protection Act 2018 still set the baseline, and the ICO has published AI-specific guidance clarifying how the existing law applies to large language models, RAG systems, automated decision-making, and synthetic data. The headline: the UK has not built a separate AI Act on the EU's pattern. The existing law applies, and the ICO expects you to have done the engineering to honour it.
The DPIA is the engineering document, not the legal one
Whenever an AI system processes personal data at meaningful scale, the UK GDPR requires a Data Protection Impact Assessment. The mistake most UK teams make is treating the DPIA as a legal artefact written by the DPO after the engineering is done. The DPIA that survives an ICO review is written collaboratively with the engineering team in week two of the build, before the architecture is locked in.
The reason is structural. Many DPIA recommendations are architectural: encrypt PII at rest with a customer-managed key, redact identifiers before they cross to a hosted LLM, log model inputs and outputs to a tamper-evident audit log, design the retrieval index so a deletion request actually removes the data subject's data. These decisions are cheap in week two and expensive in week ten. The DPIA written after the fact lists the gaps; the DPIA written collaboratively closes them.
Lawful basis for training data is harder than it looks
Article 6 requires a lawful basis for every processing of personal data, including training and fine-tuning AI models. On most UK engagements we run, the relevant bases are consent, contract, legal obligation (rare for AI), or legitimate interests, which is the most common and the most contestable.
Legitimate interests requires a documented Legitimate Interests Assessment, a three-part test: is the interest legitimate, is the processing necessary to achieve it, and is it overridden by the data subject's rights and freedoms. The ICO's generative AI guidance has been clear that mass training on web-scraped data without serious consideration of the third limb is not a defensible LIA. Engagements relying on legitimate interests for training data need an LIA that engages properly with proportionality, and the engineering controls (anonymisation, opt-out mechanisms, retention limits) that follow from it.
Article 22: automated decisions and the human in the loop
Article 22 gives data subjects the right not to be subject to a decision based solely on automated processing, including profiling, that produces legal effects or similarly significantly affects them. The keyword is solely. A decision with a meaningful human in the loop falls outside Article 22; a decision rubber-stamped by a human reading the model's recommendation does not.
In engineering terms: if your AI system makes credit, recruitment, insurance underwriting, benefit eligibility, or any other decision with legal or significant effect, the architecture needs a real human reviewer with enough context and time to disagree with the model. The reviewer needs the model's confidence, the input features that drove the decision, the prior cases it is consistent with, and the ability to override. The audit log needs to capture whether the override was meaningful or a rubber stamp. ICO guidance is explicit that human involvement must be meaningful, and the override rate is a relevant signal: if virtually every decision matches the model's recommendation, the human is not actually a reviewer.
On a UK insurance underwriting RAG we shipped, the underwriter sees the model recommendation, the confidence, the top three cited policies that informed it, and the prior cases it is consistent with. The override rate is around 18%, meaningful enough that the human is genuinely in the loop. The Article 22 exposure is documented in the DPIA and discharged by the architecture.
International transfers: the post-Schrems II reality
The UK has its own adequacy regime, but many AI engagements still touch US-located LLM providers and observability vendors. Transfers from the UK to the US require an adequacy route (the UK-US Data Bridge, in force since 2023), the UK International Data Transfer Agreement (IDTA), or Standard Contractual Clauses with a transfer risk assessment.
The engineering implication is concrete. For UK engagements with EU-region customer constraints, default the hosted-LLM endpoint to an EU region. Azure OpenAI offers Sweden Central, OpenAI offers EU data residency on its enterprise tier, and Anthropic offers EU data residency; confirm the current terms with each provider before you commit. Where a US transfer is unavoidable, document it in the DPIA with the specific safeguard (Data Bridge or IDTA) and the supplementary measures (encryption, redaction, contractual restrictions). The default in 2026 is no longer "the provider's main US region with SCCs". It is EU-region inference unless there is a documented reason otherwise.
Data subject rights through embeddings and retrieval indexes
When a data subject exercises the right to erasure or rectification, the AI system must honour it everywhere their data exists: the source database, the embedded vector representation, the retrieval index, the prompt cache, the fine-tuning dataset, and the model checkpoints if their data was used in training. Most teams handle the source database and forget the rest.
- Embeddings store: deletion of the source row must trigger deletion of the corresponding embedded chunk. Wire this in at the data layer, not as an afterthought.
- Retrieval index: the same. With pgvector inside the same Postgres as the source data, a single delete cascades. With an external vector database, you need explicit synchronisation.
- Prompt cache: invalidate cached prompts that included the data subject's data on a deletion event.
- Fine-tuning dataset: deletion is harder. If a model was fine-tuned on the data subject's records, erasure may require retraining without them, which is why most UK engagements we run use RAG rather than fine-tuning on personal data.
- Model checkpoints: the same as fine-tuning. Document the retention of model artefacts derived from personal data.
These are not optional. The ICO's position is that the right to erasure applies through derived representations of personal data, not just the original record. Our UK GDPR AI development page details the patterns we run for this on UK engagements.
Processor obligations and sub-processor visibility
When an Aiinfox team builds an AI system for a UK customer, we are typically a processor under Article 28, handling personal data on the customer's instruction. The Article 28 contract terms are well understood. Less well understood is the obligation to maintain a full sub-processor list and notify the customer of changes.
On AI engagements the sub-processor list is non-trivial. It typically includes the cloud provider (AWS, Azure, GCP), the LLM provider (Anthropic, OpenAI, Google), the vector store if external (Pinecone, Weaviate), the embedding provider if external (Voyage, Cohere), the observability provider (Datadog, Sentry, Langfuse), and any communication providers (Twilio, LiveKit). Each needs to be on the list with the appropriate Article 28 terms, and the customer needs to be able to object to changes. UK customers increasingly want this visible in the contract, not in a separate document.
UK cloud and the EU-region default
For UK customers with EU-region partners or European clients, defaulting to EU-region inference is operationally simpler than a UK-only option. Data flowing between the UK and the EU is generally unproblematic under the adequacy framework: the EU granted the UK adequacy in 2021 and has since renewed it. In practice for AI: AWS London or Frankfurt for compute, EU-region inference for the LLM, pgvector in the same region as the application database, and observability scoped to the region. Avoid splitting personal data across UK and US regions while the transatlantic transfer framework remains subject to political uncertainty.
ICO AI guidance: what changed
The ICO published its first comprehensive AI guidance in 2020 and has updated and supplemented it several times since, including guidance specific to generative AI. The recent updates are where most current engagements need to engage. The headline themes:
- Accuracy of generative AI outputs is part of the data protection principle of accuracy (Article 5(1)(d)). A system that fabricates personal data about a data subject is processing inaccurate personal data, which is a breach.
- The lawful basis for training generative AI on web-scraped personal data is contested; the ICO has signalled scepticism of legitimate-interests claims without serious proportionality analysis.
- Synthetic personal data may itself be personal data if it can be linked back to an individual; the test is identifiability, not the synthetic label.
- The right to explanation under Article 22 applies to AI decisions even where the model is complex; the explanation needs to be meaningful to a non-technical data subject.
- Bias and discrimination assessments are part of fairness under Article 5(1)(a); the ICO expects documented evaluations of fairness across protected characteristics.
Sector overlays: fintech and healthtech
UK GDPR is the floor. UK financial-services engagements add FCA expectations (Consumer Duty for retail products and the FCA's guidance on AI in financial services) and PRA expectations for prudentially regulated firms, including SS1/23 on model risk management. UK healthtech engagements add MHRA medical-device regulation where the AI is a clinical decision-support tool, the NHS DTAC framework for NHS deployments, and the Caldicott principles for patient-identifiable information.
A UK fintech AI vendor that talks GDPR but not SS1/23 or Consumer Duty has not shipped enough UK financial-services AI to take the sector seriously. Our UK fintech AI development page covers the pattern we run on FCA-regulated engagements, and our healthcare AI development page covers the clinical side.
The breach notification clock: 72 hours
Article 33 requires the controller to notify the ICO of a personal data breach within 72 hours of becoming aware of it, where the breach is likely to result in a risk to the rights and freedoms of natural persons. For AI systems, breaches include the obvious (database exfiltration) and the less obvious: prompt injection that exfiltrates another tenant's data, model regurgitation of training data, an embedding store left unsecured.
The incident-response runbook needs to cover AI-specific incident classes, and the on-call engineer needs to be able to detect them inside the 72-hour window. Drift monitoring on production traffic, prompt-injection detection in the agent pipeline, and per-tenant data-access audit are the standard controls. Without them, a breach has likely already happened before the team notices.
Putting it together
UK GDPR for AI is not a separate regime. It is the existing UK GDPR applied seriously to AI-specific failure modes. The teams that get this right treat the DPIA as an engineering document, build the data-subject-rights plumbing through embeddings and retrieval, design Article 22 compliance into the human-review architecture, and document everything for the day the ICO asks. The teams that get it wrong write a legal-essay DPIA after the build and discover the gaps when the first subject access request lands.
If you are scoping a UK AI build that needs to clear an ICO review, an FCA review, or an NHS DTAC assessment, and you want a 30-minute conversation where we name specific engineering controls rather than recite the law, book a discovery call. We have shipped UK GDPR-aligned AI across fintech, healthtech, legal, and SaaS, and the patterns above are the ones that survived in production.
Frequently asked questions
Does the UK have a separate AI law like the EU AI Act?
No. The UK GDPR and the Data Protection Act 2018 apply to AI systems, supplemented by ICO guidance on how the existing law applies to LLMs, RAG, automated decision-making, and synthetic data.
Does the right to erasure apply to embeddings and vector indexes?
Yes. Erasure has to reach every derived representation of the data subject's data: the embeddings, the retrieval index, the prompt cache, and any fine-tuning data or model checkpoints derived from it.
When does Article 22 apply to an AI decision?
When a decision with legal or similarly significant effect is based solely on automated processing. A meaningful human reviewer with the context and authority to override takes the decision outside Article 22; a rubber stamp does not.