A vendor that hosts your tickets in a London data center can still send every customer message to a US model for processing. Data residency is about where data is processed, not only where it sits at rest, and the LLM layer is the part most buyers forget to ask about.
UK data residency for AI customer support means keeping the personal data your AI agent handles - the customer message, the account record it looks up, the reply it drafts - stored and processed inside the United Kingdom (or an approved jurisdiction), including the large language model layer that generates responses. Under UK GDPR, the obligation does not stop at your database. It follows the data through every sub-processor that touches it, and an AI support platform has more sub-processors than most buyers realize.
Residency splits into three questions: where data is stored, where it is processed, and which sub-processors (including the LLM provider) touch it. A vendor can pass the first and fail the other two.
UK GDPR survived Brexit largely intact. The UK keeps its own adequacy regime and the ICO as regulator, and the EU-UK adequacy decision was renewed in 2025, so EU-to-UK transfers remain lawful for now.
International transfers (UK to US, for example) require a safeguard: the UK Extension to the EU-US Data Privacy Framework, the IDTA, or the UK Addendum to the EU SCCs. Ask which one the vendor relies on.
The LLM layer is the residency blind spot. If the model runs in a US region or the provider trains on your data, residency claims about the storage layer are beside the point.
Lorikeet supports UK obligations with a separate UK instance, instance isolation, and contractual no-train terms with its model providers - but residency is a shared-responsibility exercise, not a checkbox the vendor ticks for you.
Last updated: June 2026
If you run customer support for a UK or EU business in a regulated sector - financial services, healthcare, insurance, gaming - your data protection officer will eventually ask a simple-sounding question: where does our customer data go when the AI handles a ticket? The honest answer is more complicated than "the UK," because an AI support platform is a chain of processors. The helpdesk stores the ticket, the platform orchestrates the workflow, integrations read your CRM, and a large language model generates the reply. Each link can sit in a different country. This guide explains what UK and EU data residency actually means across that chain, how UK GDPR frames the obligation, where international transfers create risk, the exact questions to put to a vendor, and how Lorikeet is built to support these obligations. It is written to be useful even if you never talk to us.
What Data Residency Means for AI Customer Support
Data residency is the requirement that personal data be stored and processed within a defined geographic boundary - here, the United Kingdom or an approved jurisdiction. For AI customer support it is not one decision but three, and vendors routinely conflate them. A platform can store your data in a UK region, process it in the US, and route it through a model provider in a third country, all while truthfully claiming "UK data residency" about the storage layer alone.
Data residency: A requirement that specified data be physically located, and often processed, within a particular country or region. It is a contractual and architectural commitment, distinct from the legal concept of an international transfer under data protection law.
Sub-processor: Any third party a vendor uses to process personal data on your behalf - cloud hosting, a model provider, a transcription service. Under UK GDPR you must be told who they are, and the vendor must flow your protections down to each of them.
Storage Residency: Where Data Sits at Rest
This is the easiest part and the one vendors lead with. Storage residency means the database holding your tickets, transcripts, and customer records physically lives in a UK (or EU) cloud region. Most serious platforms can offer this because the major cloud providers run UK regions. The mistake is treating it as the whole answer. Data at rest in London tells you nothing about where that data travels the moment a customer sends a message and the AI starts working.
Processing Residency: Where the Work Happens
Processing residency covers where the compute happens - where the application servers run, where the workflow engine executes, where logs are generated and held. A platform can store data in the UK but run its processing in a US region for latency or cost reasons. When that happens, customer personal data crosses a border every time a ticket is handled, which is an international transfer whether or not anyone labeled it one. Ask where the processing tier runs, not only where the database lives.
Sub-Processor Residency: The LLM Layer Everyone Forgets
This is the part that catches buyers out. An AI support agent does not generate replies on its own - it calls a large language model, and that model usually belongs to a third party (OpenAI, Anthropic, Google). The customer's message, and often the retrieved account context, is sent to that provider to produce a response. Two things matter here. First, where does the model run? If it runs in a US region, your data is being processed in the US regardless of where your tickets are stored. Second, what does the provider do with the data? If there is no contractual no-train agreement, your customers' messages could become training data. A residency story that covers storage and processing but goes quiet on the LLM layer is incomplete.
UK GDPR and Why It Differs From EU GDPR
After Brexit, the UK adopted its own version of the General Data Protection Regulation, known as UK GDPR, working alongside the Data Protection Act 2018. In substance it closely mirrors EU GDPR - same principles, same lawful bases, similar rights - but it is administered by the UK Information Commissioner's Office (ICO) and the UK sets its own adequacy decisions for international transfers. Treating UK and EU GDPR as identical is a reasonable starting assumption, but the divergence matters for transfers and for which regulator examines you.
The practical implications for an AI support deployment are concrete. You remain the data controller; your vendor is a processor and must sign a data processing agreement (DPA) that names its sub-processors and commits to UK-appropriate safeguards. You owe data subjects the usual rights - access, erasure, objection - and your AI system has to be able to honor them, which means being able to find and delete a specific customer's data across the helpdesk, the platform, and any retained model interaction logs. The ICO has published guidance on AI and data protection, and its expectation is that you can explain and document how personal data flows through an automated system. "The vendor handles it" is not a defensible position for a controller.
One point of reassurance for EU businesses serving UK customers, or vice versa: the European Commission renewed its adequacy decision for the UK in 2025, so personal data can continue to flow from the EU to the UK without additional safeguards for the duration of that decision. That removes one layer of friction, but it does not touch the harder question of transfers out of the UK to countries without adequacy, which is where most AI model providers sit.
International Transfers: The Real Risk Surface
An international transfer happens whenever personal data leaves the UK for a country the UK has not deemed adequate. The United States is the case that matters most, because that is where the major LLM providers and a lot of cloud processing live. Under UK GDPR you cannot transfer personal data to a non-adequate country unless you put a recognized safeguard in place. There are three mechanisms a vendor might rely on, and it is fair to ask which one applies to your data.
UK Extension to the EU-US Data Privacy Framework: If the US recipient is certified under the Data Privacy Framework and its UK Extension, transfers to that organization are covered. Ask whether the vendor's US sub-processors are DPF-certified.
International Data Transfer Agreement (IDTA): The UK's standalone contract for restricted transfers. A vendor may have IDTAs in place with US sub-processors that are not DPF-certified.
UK Addendum to the EU Standard Contractual Clauses (SCCs): Where a vendor already uses EU SCCs, the UK Addendum extends them to cover UK transfers. Common for vendors operating across both regions.
Any of these can be legitimate. The point is not that transfers are forbidden - they are routine and lawful when done properly - but that a transfer mechanism alone may not satisfy a strict residency requirement. If your DPO or your own regulator requires that data physically stay in the UK, a US transfer under SCCs does not meet that bar even though it is legally compliant for transfer purposes. This is exactly where buyers and vendors talk past each other: "compliant transfer" and "data stays in the UK" are different commitments. Decide which one you actually need before you evaluate vendors, because the architecture required for true in-region processing is more demanding than the paperwork required for a lawful transfer.
Why a Lawful Transfer May Still Fail Your Requirement
It helps to separate two stakeholders who often want different things. Your legal team usually cares whether a transfer is lawful, which an IDTA or the DPF Extension satisfies. Your security or risk team, or a regulator in financial services, sometimes cares whether data physically leaves the jurisdiction at all, which no transfer mechanism satisfies because the mechanism exists precisely to permit the data to leave. A platform built around US processing with UK paperwork can clear the legal bar and still fail the risk bar. If you have a hard residency mandate from a regulator or a major banking customer, you need in-region architecture, not a stronger contract. Establishing which bar applies early saves a late-stage procurement collapse when the security review surfaces a transfer the legal review had already blessed.
Data Subject Rights and the DPIA Your AI Deployment Will Need
Residency is one input into a wider data protection exercise, and a vendor evaluation that stops at residency leaves obligations on the table. Two are worth flagging because they touch the architecture you are buying. First, data subject rights: UK GDPR gives customers the right to access and to erasure, and an AI support system has to be able to act on both. That means finding and deleting a specific person's data not only in the helpdesk but in the platform's own records and in any retained model interaction logs. Ask the vendor to walk through an erasure request end to end. Second, a Data Protection Impact Assessment (DPIA) is expected for high-risk processing, and automated handling of regulated customer data in financial services or healthcare generally qualifies. The ICO expects you to document how personal data flows through the automated system and how you mitigate the risks. A vendor that can give you a clear data-flow diagram, a sub-processor list, and evidence of testable guardrails makes that DPIA far easier to complete - which is a practical reason to favor vendors whose behavior is auditable over vendors whose answer is "trust the model."
What to Ask an AI Support Vendor
Most vendor security pages answer the easy version of the residency question and stay silent on the hard parts. The questions below are written to surface the parts that matter. Bring them to the procurement call and ask for written answers, not verbal reassurance.
Where is our data stored at rest, and can you commit to a UK region in the contract rather than as a best effort?
Where does processing actually run - application servers, workflow execution, logging? Name the regions.
Which LLM provider do you use, in which region does the model run, and is there a contractual no-train agreement covering our data?
Can you provide a UK-only or UK-isolated instance, and what exactly is isolated - storage, processing, model calls, or all three?
List every sub-processor that touches personal data and the country each operates in. This belongs in the DPA, not a slide.
For any data that does leave the UK, which transfer mechanism do you rely on (DPF Extension, IDTA, or UK Addendum to SCCs)?
How do you handle a data subject erasure request - can you delete a specific customer's data from tickets, logs, and any retained model interactions?
What is your retention policy for transcripts and model interaction logs, and where are those logs stored?
A vendor that answers these clearly and puts the answers in the contract is one you can take to your DPO. A vendor that calls the questions "too technical" or routes you back to a generic "we are GDPR compliant" line has told you something useful.
How Lorikeet Supports UK Data Residency Obligations
Lorikeet is an AI customer support platform built for complex, regulated businesses, and roughly four in five of our customers are financial institutions or fintechs, so data residency questions are a normal part of how we are evaluated. We are deliberate about the language here: the architecture below is designed to support your obligations under UK GDPR. It does not relieve you of them. You are the controller, and residency is a shared responsibility.
Three parts of how we are built map directly to the three residency questions above.
Separate UK instance: Lorikeet offers data residency in the UK alongside the US and Australia. A UK instance is intended to keep your data stored and processed in-region rather than relying on a transfer mechanism after the fact.
Instance isolation: Customer instances are isolated from one another, so your data and configuration are not commingled with other customers in a shared pool. This matters for both the residency story and the broader security review.
Contractual no-train terms at the model layer: Lorikeet holds contractual no-train agreements with its model providers (Anthropic, OpenAI, Google), so customer data sent to a model to generate a response is not used to train that provider's models. This addresses the LLM-layer blind spot that storage-only residency claims miss.
On the wider compliance posture, Lorikeet is SOC 2 compliant, is GDPR-aligned, supports HIPAA workflows with a BAA, and provides PII redaction and role-based access control. The defence-in-depth model - pre-launch adversarial simulation, inbound message checks, outbound guardrails, and 100% post-facto QA through our Coach agent - means the behavior of the system is testable and auditable, which is the kind of evidence a UK regulator or a bank's security team asks for. We have passed security reviews with major US banks, and the same rigor applies to UK and EU deployments.
An Honest Limitation
Two caveats worth stating plainly. First, the major model providers are US-headquartered, and even with a UK instance and no-train terms, the exact regional footprint of model inference depends on the provider's available regions and the configuration we agree with you - so if your requirement is that no data ever, under any circumstance, leaves UK soil including for model inference, that is a conversation to have explicitly during scoping rather than an assumption to make from a marketing page. Second, residency is only one slice of a data protection review; it does not by itself satisfy your DPIA, your records of processing, or your obligation to be able to explain automated decisions. We can support all of those, but supporting and discharging are different things, and the obligation stays with you as controller.
Key Takeaways
Data residency for AI support is three questions, not one: where data is stored, where it is processed, and which sub-processors touch it. Vendors often answer only the first.
The LLM layer is the most-missed part of a residency review. Ask where the model runs and whether there is a contractual no-train agreement before you accept any residency claim.
UK GDPR mirrors EU GDPR but sets its own adequacy decisions and is enforced by the ICO. The EU-UK adequacy decision was renewed in 2025, keeping EU-to-UK flows lawful.
"Lawful transfer" and "data stays in the UK" are different commitments. Decide which your DPO actually requires before evaluating vendors, because true in-region processing is harder than a compliant transfer.
Lorikeet supports these obligations with a separate UK instance, instance isolation, and no-train terms at the model layer - but residency is a shared responsibility, and you remain the controller.
Conclusion
Data residency for AI customer support is solvable, but only if you ask the questions in the right order and refuse to accept a storage-layer answer to a processing-and-sub-processor question. The vendors worth shortlisting are the ones that will name their regions, name their sub-processors, name their LLM provider and its region, and put a transfer mechanism and a no-train commitment in writing. The ones to be cautious of are the ones whose residency story gets vaguer the closer you get to the model layer.
If you are evaluating AI customer support against UK or EU data residency requirements, talk to Lorikeet and bring your DPO - we will walk through the UK instance, the sub-processor list, and the model-layer terms before you sign anything.
