← Blog

UK GDPR and AI: The Six Obligations That Bite When a Prompt Leaves Your Network

The UK has no AI Act. AI use is governed under the UK GDPR and the Data Protection Act 2018, enforced by the ICO, with sector regulators layering their own expectations on top. Six obligations do the work: lawful basis, purpose limitation, data minimisation in the prompt, Article 22 automated decisions, international transfers when a prompt crosses a border, and Article 30 records. This walks each and marks where the evidence has to come from.

ByParminder Singh· Founder & CEO, DeepInspect Inc.
Compliance & Regulationcomplianceai-governanceregulationauditai-securitydata-protection
UK GDPR and AI: The Six Obligations That Bite When a Prompt Leaves Your Network

The UK has not passed an AI Act, and that fact gets read as a lighter regime. The UK GDPR and the Data Protection Act 2018 already apply in full to AI systems processing personal data, the ICO enforces them, and the FCA published the Mills Review on July 6, 2026 as the first review of its kind initiated by a financial regulator anywhere. A UK organisation running AI is regulated. The regulation is just distributed across instruments that predate the technology.

The moment that matters is narrow and concrete: an HTTPS POST leaves your network carrying a context window. If that context window contains personal data, six obligations attach to that single request. I want to walk each one and be specific about where the evidence comes from, because that is where UK AI programmes tend to be thinnest.

1. Lawful basis for the processing in the prompt

Every processing operation needs an Article 6 basis, and sending personal data to a model is a processing operation distinct from whatever you collected it for. Legitimate interests is the basis most organisations reach for, which requires a documented balancing test that accounts for the model provider as a recipient.

Special category data under Article 9 needs a second condition, and health, biometric, and criminal-offence data appear in prompts more often than intake forms suggest. A clinician pasting a consultation note into an assistant has moved special category data across a boundary in one paste.

Evidence: documentary at assessment, observable in operation. The assessment records the basis. Only the request layer shows which data classes actually travelled.

2. Purpose limitation

Personal data collected for one purpose cannot be used for an incompatible one without a fresh basis. Using customer support transcripts to fine-tune a model is a different purpose from handling the support request, and the compatibility assessment is not a formality.

The provider's own terms matter here. Whether a provider retains prompts, for how long, and whether they enter training determines whether your purpose limitation position holds after the request leaves. Enterprise tiers commonly exclude training use where consumer tiers do not, which is why the approved-endpoint list is a data protection control and not just a security one.

3. Data minimisation, applied to the context window

Article 5(1)(c) requires personal data to be adequate, relevant, and limited to what is necessary. A prompt is where this obligation gets tested most directly, because a context window is assembled by whoever is typing.

A support agent asking a model to draft a reply pastes the whole ticket thread, which carries the customer's name, address, order history, and a complaint about a family member's medical appointment. The necessary content was two sentences. Minimisation at the prompt layer means classifying and reducing what actually leaves, at the moment it leaves. A data retention policy on the CRM does nothing about a paste into a chat window.

Evidence: enforceable at the request layer, and nowhere else. The relevant numbers: 77% of employees using unauthorised AI admit to pasting sensitive business data into unsanctioned models, and 86% of IT leaders report being completely blind to those interactions (Cloud Radix).

4. Article 22, solely automated decisions

Article 22 gives data subjects the right not to be subject to decisions based solely on automated processing that produce legal or similarly significant effects. The tests are "solely" and "significant", and agentic deployments erode the first one quietly.

A human reviewing and approving a model's recommendation takes the decision outside "solely" only when the review is meaningful. A caseworker approving 200 model recommendations a shift, with no realistic capacity to overturn them, is a rubber stamp, and the ICO has been clear that token human involvement fails the test. An agent acting within pre-set goals with no human between steps sits squarely inside Article 22, which is the accountability gap the FCA's Mills Review names for retail finance without closing. The mechanics are in GDPR Article 22 automated decisions.

Evidence: a per-decision record showing which identity initiated the call, what the model was asked, what came back, and whether a human intervention point was reached. Without it, demonstrating that a decision was not solely automated is an assertion.

5. International transfers

The UK maintains its own adequacy regulations and its own transfer mechanisms: the International Data Transfer Agreement and the UK Addendum to the EU SCCs. A prompt sent to a model endpoint hosted outside the UK is a restricted transfer.

Provider region selection is the control, and it is frequently misconfigured. A team assumes an EU or UK region because they selected one in a console, while a fallback endpoint, a different SDK default, or a second provider added later routes elsewhere. The only way to know where prompts actually went is to observe the destinations rather than the configuration intent.

6. Article 30 records and the DPIA

Article 30 requires records of processing activities: purposes, categories of data subjects and personal data, recipients including third countries, retention, and security measures. AI processing has to appear in that register with the model providers named as recipients.

Article 35 requires a DPIA for processing likely to result in high risk, and the ICO's own list of high-risk indicators catches most substantial AI deployments, including innovative technology, large-scale processing, and automated decision-making. The AI-specific structure is in GDPR AI DPIA.

Both documents share one dependency: they describe systems you know about. A ROPA missing three model providers that two teams adopted last quarter is inaccurate, and the inaccuracy is discovered during a subject access request or a complaint rather than during a review.

What I would do differently from most UK programmes

Build the register from observed traffic first and the interviews second. Every UK AI compliance programme I have looked at starts with a questionnaire sent to department heads, and the answers describe the tools people are willing to name. Run the traffic view first, then take the discrepancy list to the same department heads. The conversation is shorter and the register is accurate, and the people who were quietly using an unapproved assistant tend to be more forthcoming when the endpoint is already on the page in front of them.

The subject access request problem

A data subject asks what personal data you hold about them and who it was disclosed to. If their data went into prompts, the answer includes the model provider as a recipient, and answering requires knowing which requests carried that individual's data.

Application logs rarely support that query. They record that a request was made, not what class of personal data the context window carried or which individual it concerned. A request-layer record with data classification attached is what makes the answer producible within the statutory month rather than approximate.

DeepInspect

This is the gap DeepInspect closes. Four of the six obligations above resolve at the point a prompt leaves for a model endpoint, and DeepInspect sits inline on the HTTP path between authenticated users or agents and any LLM.

Every request is bound to a verified caller identity, classified against your own personal data categories, and evaluated against identity-aware policy, with a deterministic fail-closed decision before the request reaches the provider. Minimisation becomes a rule that executes on the actual context window rather than a principle in a policy document, destination endpoints are recorded so transfer positions rest on observation, and the register is built from traffic rather than recollection. Each decision commits a signed audit record on a write path the calling application never controls, which is what answers an ICO enquiry or a subject access request about a specific individual. DeepInspect governs the AI traffic and leaves consent capture, retention in source systems, and DPIA authorship to the teams that own them. If your ROPA names two model providers and your engineers are calling four, let's talk today.

Frequently asked questions

Does the UK GDPR apply to AI systems?

Yes. Any AI processing of personal data falls under the UK GDPR and the Data Protection Act 2018, enforced by the ICO. The UK has no separate AI Act, so AI obligations are read out of existing data protection law together with sector regulator expectations such as those of the FCA.

Is sending a prompt to an LLM an international transfer?

It is a restricted transfer when the model endpoint is outside the UK and no adequacy regulation covers the destination. UK organisations rely on the International Data Transfer Agreement or the UK Addendum to the EU SCCs, and the practical difficulty is confirming where prompts actually went rather than where a console setting says they should have gone.

Does Article 22 apply to AI agents?

It applies when a decision is based solely on automated processing and has legal or similarly significant effects. An agent operating within pre-set goals with no meaningful human review sits inside Article 22. Human involvement removes a decision from scope only where the reviewer has genuine authority and capacity to reach a different outcome.

Do we need a DPIA for AI?

Almost always for substantial deployments. The ICO's high-risk indicators include innovative technology, large-scale processing, and automated decision-making with significant effects, and most enterprise AI use hits at least one. The DPIA has to describe actual data flows, including which providers receive prompts and in which jurisdictions.

How does UK AI regulation differ from the EU AI Act?

The EU AI Act is a dedicated product-safety style regulation with risk tiers, conformity assessment, and penalties reaching €15 million or 3% of global turnover. The UK regulates AI through existing law and sector regulators instead, so UK obligations arrive as data protection duties and supervisory expectations rather than as a single AI statute. UK firms serving EU users can be caught by both.