No. UK GDPR has no blanket rule that personal data must stay in the UK. It restricts transfers outside the UK unless you have a valid mechanism, such as adequacy regulations, an International Data Transfer Agreement, or an Article 49 exception. Running AI on servers in your own UK building means there is no transfer to assess.
Does UK GDPR contain a data localisation rule?
No. There is nothing in UK GDPR that says personal data must be stored on servers inside the United Kingdom. Chapter V restricts transfers of personal data to receivers outside the UK unless one of a defined set of conditions is met, which is a different thing from a prohibition.
The confusion is understandable, because a lot of organisations genuinely are bound by a localisation requirement. It usually comes from somewhere other than data protection law: a procurement schedule, a sectoral rulebook, a commitment made in a client contract, or an internal policy written in the week after an incident. Those obligations are real and someone will hold you to them. They are just not UK GDPR, or the Data Protection Act 2018 that sits alongside it. Work out which one binds you before your legal and infrastructure teams spend three months arguing past each other.
What counts as a restricted transfer when AI is involved?
The ICO's international transfers guide sets out three conditions, all of which have to be met, and its detailed guidance expands on each. UK GDPR applies to your processing of the data. You are sending the data, or making it accessible, to a receiver to which UK GDPR does not apply. And the receiver is legally distinct from you, meaning a separate company, organisation or individual.
Apply that test to an AI deployment and the surface area is wider than most buyers expect. A prompt is personal data whenever it contains personal data, and prompts in live use are full of it: names, case references, internal notes, entire documents pasted in by someone under time pressure. Then there is the context your system retrieves from internal stores, the output, the prompt and response logs, the telemetry, any samples pulled for evaluation, and the human review queue where a person reads flagged content. Every one of those is a place where personal data comes to rest or moves on.
When I map an AI pipeline I list all of them before looking at the model at all. The thing that catches organisations out is almost never the inference step. It is log retention in a region nobody mentioned, or a review queue staffed somewhere the contract never named.
Which transfer mechanisms are available under UK GDPR?
There are three routes. The first is adequacy: the UK has made adequacy regulations covering a list of countries and territories, and a transfer to one of those needs no further mechanism. The second is appropriate safeguards, which in UK practice usually means the International Data Transfer Agreement (the IDTA), or the UK Addendum used alongside the EU standard contractual clauses, and which also requires you to carry out a transfer risk assessment. The third is the set of exceptions in Article 49, which are narrow, situation specific, and not a sensible basis for a system you run every day.
Chapter V was amended by the Data (Use and Access) Act 2025, with those changes in force from 5 February 2026, including the test applied when adequacy regulations are made. The shape of the framework did not change. It is still those three routes, and the ICO's guidance remains the place to check the current detail before you rely on any of them.
Does an AI supplier's UK region satisfy the transfer rules?
Not on its own, and a region label is one of the weaker assurances in this market. A UK region tells you where a primary data store sits. It does not tell you where inference runs when nearby capacity is saturated, where logs and metrics aggregate, where backups replicate, which entity in the supplier's group is your counterparty, or where the engineers with production access sit at three in the morning. That gap between residency and sovereignty is where the argument actually lives.
There is a legal nuance worth knowing. If the receiver is itself caught by UK GDPR, the second condition in the ICO's test is not met, so there is no restricted transfer. That is a real analysis and it sometimes lands in the supplier's favour. It is not a bullet point to take on trust. Ask for the sub-processor list, the entity names, the countries each one operates in, and the mechanism relied on for each. If those four things cannot be produced in writing, you do not yet know what you are signing.
What is a transfer risk assessment, and when do you need one?
You need one when you rely on appropriate safeguards such as the IDTA, and its purpose is to check whether those contractual protections will actually hold in the destination. That means looking at the laws and practices of the receiving country, particularly public authority access to data, and whether a person whose data is transferred has enforceable rights and effective redress there. The ICO publishes guidance and a tool for this.
With an AI supply chain the exercise is harder than it looks, because you are assessing places you cannot inspect. A hosted assistant may sit on one company's platform, call a model served by another, log to a third and route escalations to a support function somewhere else again. Each layer adds a jurisdiction to assess and a party whose behaviour you are taking on trust. It is worth doing properly, and it is also when buyers notice how much of their risk register rests on assumptions about other people's infrastructure.
Does remote access by an overseas support team count as a transfer?
Usually yes. The ICO's test covers making personal data accessible, not only sending it, so an engineer outside the UK who can open a console and read records held on a UK server is within scope where that engineer works for a separate legal entity to which UK GDPR does not apply.
The carve-out is legal distinctness. Access by another office of the same legal entity is not a restricted transfer, although your security and accountability obligations do not go anywhere. This is the clause that quietly undoes a lot of UK-region architectures. The data never left the country. The support rota did the travelling instead.
What changes if the AI runs on your own hardware in the UK?
The question stops arising. If the system runs on machines your organisation owns, in a building in the UK, with no outside processor in the loop, there is no receiver and so there is no transfer to assess. No IDTA, no transfer risk assessment, no sub-processor list to chase each time a supplier reorganises.
I want to be precise about what that does and does not buy you. It does not make you UK GDPR compliant. You still need a lawful basis, transparency, a DPIA where the processing warrants one, security proportionate to the risk, retention limits, and a working process for individual rights. What it removes is one specific category of risk: the part of your compliance position that rests on infrastructure you cannot see and a chain of parties you cannot audit.
That is why the Mickai® Sovereign Intelligence Operating System (SIOS) is built to run on hardware the customer owns, offline capable, with no data egress. It seals every consequential action into an Open Audit Record under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024, so an auditor can verify an exported record offline with a public key, using tools that are not ours. That record is tamper-evident rather than tamper-proof, and the difference matters. Nothing stops someone altering a file. Altering it makes verification fail, visibly and provably, which is the property an auditor can use. Consequential actions also wait for a named person to approve them, so the record shows who decided what and when.
None of this is an argument against the companies building the compute and cloud layer. For a great deal of work, cloud is and will remain the right answer. The argument is with the assumption that a regulated organisation has no option but to rent its intelligence, ship its data offsite and accept a supplier's account of what happened to it.
What should you ask an AI supplier before you sign?
Six questions, answered in writing, before signature. Which legal entity is my counterparty, and where is it established? List every sub-processor, the country each one operates in, and the transfer mechanism relied on for each. Where are prompts, outputs, logs and telemetry stored, and for how long? Who can access production data, from which countries, and under what controls? If you rely on the IDTA or the Addendum, will you share the transfer risk assessment? And what evidence can I give an auditor that is verifiable without asking you?
The last question separates suppliers quickly. Anyone can describe their controls. Far fewer can hand you something an auditor checks independently. This article is general information about how the transfer rules work rather than legal advice on your circumstances, so take your own before you act on it.
Frequently asked questions
Does UK GDPR ban sending personal data abroad?
No. It restricts rather than bans. A transfer of personal data to a receiver outside the UK is permitted where adequacy regulations cover the destination, where you put appropriate safeguards in place such as the International Data Transfer Agreement together with a transfer risk assessment, or where one of the narrow Article 49 exceptions genuinely applies.
Is a UK data region enough to avoid a restricted transfer?
Not by itself. A region setting tells you where one data store lives. It does not account for logs, telemetry, backups, overflow capacity, which entity in the supplier's group contracts with you, or where support engineers sit. Ask for the sub-processor list, with countries and the mechanism relied on for each, in writing before signature.
Do we need an International Data Transfer Agreement for an AI supplier, including for overseas support access?
You need the IDTA, or the UK Addendum to the EU standard contractual clauses, whenever you make a restricted transfer that adequacy regulations do not cover. That includes giving an overseas support team access to UK-held data where that team belongs to a separate legal entity outside the UK. Appropriate safeguards also require a transfer risk assessment.
What is a transfer risk assessment for AI?
It is the check you carry out before relying on safeguards such as the IDTA. You ask whether those protections will hold in practice in the destination country, given local law on public authority access and whether individuals have enforceable rights and effective redress. With AI, assess each layer: platform, model hosting, logging and human review.
Does running AI on our own UK servers remove the transfer question?
Yes, where no outside processor is involved and the machines sit in the UK, because there is no receiver and so no restricted transfer to assess. It does not make you compliant on its own. Lawful basis, transparency, a DPIA where warranted, security, retention and individual rights all still apply, and you still need evidence of what the system did.
Related briefings
Data protection and UK GDPR
- UK Data Storage vs AI Processing: What Is the Difference
- Controller or Processor? AI Suppliers and UK GDPR Roles
- Right to Erasure in an AI Knowledge Base: How to Comply
- Employee Pasted Client Data Into AI: Is It a Breach?
- AI Call Transcription and UK GDPR: What Firms Must Do
Governance, audit and oversight
- Tamper-Evident vs Immutable Log: The Real Difference
- Human on the Loop vs In the Loop: AI Oversight Explained
Part of a series of 60 briefings on deploying and governing AI in UK regulated organisations, archived with a DOI at 10.5281/zenodo.22975756.
Evaluating AI for a regulated organisation? Mickai runs on hardware you own, offline. Consequential actions wait for a named person to approve them, and what the AI did is sealed into a signed record an auditor can check without us. Applications for the invitation-only closed beta are open. Apply for the closed beta.
Written by Micky Irons, founder and chief executive of Mickai LTD.
Top comments (0)