Does UK GDPR apply to an AI project?
If your system processes personal data about people in the UK, whether in training data, prompts, retrieved documents or outputs, UK GDPR and the Data Protection Act 2018 are in play. The Information Commissioner's Office (ICO) publishes guidance on AI and data protection that is worth reading with your counsel. This article is general information, not legal advice, and the detail of the law should be confirmed with a qualified UK adviser.
It helps to separate three situations. A tool that never touches personal data is outside the regime. A tool that touches staff or customer data in passing, such as an internal assistant over HR policies and tickets, is in scope. A tool that makes or supports decisions about individuals, such as credit, hiring or claims, raises the most questions.
The law is also moving. Parliament passed the Data (Use and Access) Act 2025, which amends parts of the regime, including the rules on automated decision-making, and its provisions are being brought into force in stages. Check the current position before you finalise your design.
What should you decide before you build?
- Define the purpose. Write down what the system is for in one paragraph. Purpose limitation and data minimisation both start here.
- Map the data. List every category of personal data that enters the system: training or evaluation sets, prompts, retrieved documents, logs and outputs.
- Identify roles. Work out who is controller and who is processor, including any model provider that receives data.
- Choose a lawful basis. Consent, contract, legitimate interests or another basis, recorded and, for legitimate interests, supported by a balancing test.
- Assess risk. Decide with your DPO whether a data protection impact assessment (DPIA) is needed. The ICO expects one where processing is likely to be high risk, which AI uses often are.
- Set retention. Decide how long prompts, outputs and logs are kept and how they are deleted.
Where do transparency and individual rights fit?
People should be told, in clear language, when their data is used and for what. For an AI system that includes telling customers when they are talking to an assistant and how to reach a person.
Rights of access, correction and erasure need a practical route into the system. If personal data sits in logs, a search index or a vector store, someone must be able to find it and remove it. Plan that retrieval path in the design, because it is far harder to add later.
What about automated decisions?
UK GDPR restricts decisions based solely on automated processing that have legal or similarly significant effects on individuals, and expects safeguards such as human involvement and a way to contest the outcome. The 2025 Act changes how these rules are framed, so confirm the current position with counsel. Whatever the wording, a sound design principle stays the same: for decisions that matter to a person, the system recommends and explains, and a trained person decides, with a record of both.
- Drafting and summarising: a person reviews before anything is sent.
- Triage and routing: low impact, with an easy route to a human.
- Eligibility, pricing, hiring and claims: a recommendation with reasons and source citations, a human decision, a way to contest it and an audit log.
Can personal data be handled by a team in India?
Yes, with planning. At the time of writing India is not among the countries covered by UK adequacy regulations, so a transfer of UK personal data to India needs an appropriate safeguard. Common routes are the ICO's international data transfer agreement or the UK Addendum to the EU standard contractual clauses, together with a transfer risk assessment. Confirm the current position with counsel.
Technical design often reduces the issue more than contracts do.
- Keep production data in a UK or EU region in your own cloud account.
- Give offshore engineers masked, synthetic or sampled data for development, and keep production access narrow, logged and time limited.
- Choose model providers and regions deliberately, and record them as sub-processors.
- Agree breach notification and audit terms in the data processing agreement.
What changes for regulated sectors?
Firms regulated by the FCA or PRA have to manage outsourcing and third-party risk, and a supplier of AI tools sits inside that process. Expect questions about exit plans, resilience, audit rights and where data is held.
Health sector suppliers face expectations around the Data Security and Protection Toolkit, DTAC and, for clinical software, the clinical safety standards DCB0129 and DCB0160. A supplier can document its controls and support these reviews, but responsibility for meeting them stays with the regulated organisation.
How do you document an AI system for a DPO or auditor?
| Document | What it answers |
|---|---|
| Data flow map | What personal data enters, moves and leaves, and where it is stored |
| Purpose and lawful basis note | Why the system exists and on what basis data is processed |
| DPIA, where required | Risks to individuals and the measures taken to reduce them |
| Model and sub-processor register | Which providers and regions are involved, and what each retains |
| Evaluation report | How accuracy, bias and failure cases were tested before launch |
| Human oversight note | Where people review or decide, and how outcomes can be challenged |
Writing these during the build is straightforward. Reconstructing them for an audit afterwards is slow and error-prone.
Where to start
Pick one use case, work through the six decisions above with your DPO, and pilot on a narrow slice of data. Our page on AI development for UK businesses explains how we work with UK teams across the shared day, our document AI and automation service covers paperwork-heavy cases, and you can contact us to talk through a specific project.