If your AI product processes personal data about people in the UK, UK GDPR applies, and it has just changed in a way that matters specifically for AI. This is a plain-language walk through what UK GDPR actually requires, why it exists, and the genuinely new development every team building an AI agent or decision system for UK users needs to understand: a 2026 rewrite of the rules on automated decision-making.

What UK GDPR actually is

UK GDPR is the United Kingdom's own version of the EU's General Data Protection Regulation, kept in UK law after Brexit and enforced by the ICO (the Information Commissioner's Office). It works alongside the Data Protection Act 2018, which fills in UK-specific detail the regulation itself leaves to national law. If you have read our explainer on EU GDPR, the core concepts carry over directly: a data controller (the organization that decides why and how personal data is processed) has obligations toward the people whose data it holds, and a data processor (a vendor processing that data on the controller's behalf, which is exactly the role an AI vendor or LLM API provider plays) needs a contract in place before it touches that data.

The two regulations started identical and are now diverging on specific points. The most significant divergence as of this writing is UK GDPR's rewritten rules on automated decision-making, covered in full below. A system built to satisfy EU GDPR is not automatically UK GDPR compliant, and the reverse is also true; each has to be checked on its own terms.

Why UK GDPR exists

Personal data, once collected, can be used in ways the person never agreed to and never sees: sold to third parties, combined with other datasets to build a profile, or used to make a decision about someone without their knowledge. UK GDPR exists to put a legal floor under how personal data can be collected, used, and shared, giving people rights over their own data (to see what is held, to correct it, to have it deleted) and giving organizations clear obligations for handling it responsibly. Automated decision-making rules exist for a more specific reason: a machine making a consequential decision about a person, with no human involved, removes the normal opportunities a person would have to explain their situation, catch an error, or contest an outcome.

Why a company follows it

The ICO enforces UK GDPR and can investigate complaints and take regulatory action, so there is real legal exposure for getting this wrong. But for most companies building an AI product, the more immediate concern is market trust: a UK buyer, particularly in a regulated sector, will ask directly how personal data is handled inside an AI feature, whether a data processing agreement is in place with the model vendor, and what happens when someone asks to see or delete their data. A vague answer to that question is a lost deal before it becomes a legal problem.

The 2026 change every AI builder needs to know: automated decision-making rewritten

This is the single most important UK-specific AI development to understand right now, and it is a genuine shift, not a minor clarification.

Until early 2026, UK GDPR's Article 22 worked as a near-prohibition: a person had the right not to be subject to a decision based solely on automated processing, including profiling, if that decision produced legal effects or similarly significantly affected them, with only narrow exceptions. In practice, this meant a fully automated system (including an AI-driven one) making, say, a loan approval or a hiring decision sat on shaky legal ground by default.

The Data (Use and Access) Act 2025 changed that. It came into force in stages starting 5 February 2026, and its Section 80 rewrote the automated decision-making rules, replacing the old Article 22 with four new articles: 22A, 22B, 22C, and 22D. The new framework flips the default: solely automated decisions, including AI-driven ones, are now permitted, subject to safeguards rather than treated as presumptively restricted. Those safeguards are specific and have to be built into the product, not bolted on as a policy document:

For anyone building an AI agent or system that makes or meaningfully influences decisions about UK individuals, loan approvals, hiring screens, insurance pricing, eligibility decisions, and similar use cases, this is the development that changes the shape of the build. It is now realistic to ship a solely automated decision system for these use cases in the UK, provided the three safeguards above are designed in from the start: a logging and explanation layer the system can actually produce an answer from, a working human-review queue, and a real contest-and-response process, not just three checkboxes in a privacy policy.

A concrete example
Picture a small UK fintech building an AI-driven loan pre-approval tool. Under the new framework, the team can let the model make a fully automated approve or decline call, but only if it also builds three things alongside it: a mechanism that can explain, in plain terms, what drove that specific decision, not just "the model said so"; a real queue where a declined applicant's case reaches a human reviewer with authority to overturn the automated result; and a documented process for handling a contested decision that produces an actual answer, not a form-letter acknowledgment. Skipping any one of the three leaves the automated decision on the same shaky ground the old Article 22 created.

The ICO's AI code of practice, in development

Separately from the automated decision-making rewrite, the government has directed the ICO to prepare more detailed guidance specifically for AI. The Data Protection Act 2018 (Code of Practice on Artificial Intelligence and Automated Decision-Making) Regulations 2026 (SI 2026/425) were made on 16 April 2026 and came into force on 12 May 2026. They direct the ICO to prepare a statutory code of practice on AI and automated decision-making, which will give more concrete, practical guidance once finalized. As of this writing that code is still in development, not yet finalized, so teams should design against the statutory safeguards described above now rather than waiting for the code before building the required safeguards.

What still applies: the core UK GDPR principles

The automated decision-making rewrite does not replace UK GDPR's foundational principles, which apply to every AI system that touches personal data, decision-making or not:

Lawful basis for processing

Every use of personal data needs a lawful basis: consent, contract necessity, legitimate interest, and a handful of others. For an AI feature, this means being specific about which basis covers, for example, sending a user's message to a third-party model API, not assuming that "the user is using the product" is itself a basis.

Purpose limitation and data minimization

Personal data collected for one purpose should not be silently repurposed for another, and only the data actually needed for a task should be collected or processed. For an AI agent, this means being deliberate about what data it is allowed to retrieve or send into a prompt for a given task, not giving it broad access because it might be useful.

Storage limitation

Personal data should not be kept longer than necessary. Conversation logs, prompt histories, and fine-tuning datasets that contain personal data all need a retention policy, not indefinite storage by default.

Data protection by design

Privacy has to be built into a system from the start, not added afterward. For an AI product this means the architecture itself, what the agent can access, what gets logged, how long data is retained, reflects these principles, rather than a privacy policy describing intentions the system does not actually enforce.

What GreyScript AI does, and does not, do here

GreyScript AI builds AI systems designed to align with UK GDPR: scoping what an agent can access and log, building the explanation, human-review, and contest mechanisms the new automated decision-making framework requires when a system makes or influences a consequential decision, and keeping personal data handling deliberate rather than incidental. We do not certify compliance, and we do not give a legal opinion. A formal compliance determination, or a decision about whether a specific use case needs a data protection impact assessment, stays yours to commission, typically through counsel. See our AI governance and security service for how this fits into a build.

If your product also needs to work across the wider EU, our EU GDPR explainer covers the equivalent framework there, and our EU AI Act explainer covers the separate, risk-based AI regulation that can apply alongside it.