Does Your Chatbot Need EU Data Residency? Residency, SCCs, and Sovereignty for Procurement

Procurement teams in the EU ask one question of every chatbot vendor before any other: where is the data hosted? Short answer: GDPR does not require EU data residency. A chatbot hosted in the United States can be a lawful processor under Standard Contractual Clauses with a transfer impact assessment behind them. Residency is required in three situations, a localization law, a contract or procurement rule, or a transfer assessment that fails, and outside those it is a preference that removes work rather than a rule you must meet.

A few terms first, because everything below depends on them. GDPR is the General Data Protection Regulation, the EU law governing personal data. A controller decides why and how personal data is processed (you, the business running the chatbot). A processor processes it on the controller's behalf (the chatbot vendor). A DPA, or Data Processing Agreement, is the contract Article 28 requires between the two. SCCs are Standard Contractual Clauses, the European Commission's template terms that make transfers of personal data outside the EU lawful.

Three more. A TIA, or transfer impact assessment, is the documented check a controller runs before relying on SCCs, asking whether the destination country's law undermines them. The DPF is the EU-US Data Privacy Framework, the 2023 adequacy arrangement that lets certified US companies receive EU data without SCCs. And data residency is where data is physically stored and processed, which, as this page explains, is not the same as data localization (a law that mandates it) or data sovereignty (whose law governs access to it).

Residency, localization, and sovereignty are three different things

Vendor comparison tables use the three words interchangeably. A DPO cannot, because each answers a different question and only one of them is a legal requirement.

The gap between the rows is where procurement gets misled. A vendor can satisfy residency (the disk is in Frankfurt) without localization ever having been required, and without delivering sovereignty (its US parent can still be compelled). The reverse is true too: a US-hosted vendor with SCCs, a transfer impact assessment, and strong technical measures can be fully lawful under GDPR while satisfying none of the three words.

What GDPR actually says about where data lives

Nothing in GDPR requires personal data to stay in the EU. What Chapter V requires is that any transfer to a third country meet its conditions. Article 44 sets the principle: a transfer "shall take place only if, subject to the other provisions of this Regulation, the conditions laid down in this Chapter are complied with," so that the level of protection "is not undermined." The chapter then offers three routes.

Adequacy, Article 45. The Commission decides that a country, or a framework within it, offers essentially equivalent protection. For the United States that is the EU-US Data Privacy Framework, adopted on 10 July 2023, which covers US companies that self-certify. The General Court upheld it in Latombe v Commission on 3 September 2025, and an appeal to the Court of Justice filed on 31 October 2025 is pending.

Appropriate safeguards, Article 46. Where no adequacy decision covers the recipient, the exporter relies on safeguards, and the standard one is the Commission's SCCs, adopted on 4 June 2021 as Decision 2021/914. Binding corporate rules under Article 47 do the same job inside corporate groups.

Derogations, Article 49. Explicit consent, contract necessity, and a few other narrow grounds, meant for occasional transfers rather than a processor arrangement. A chatbot vendor relationship should never rest on these.

The judgment that changed how SCCs work is Schrems II (C-311/18), decided on 16 July 2020. It invalidated the DPF's predecessor, the Privacy Shield, and held that SCCs remain valid but that an exporter must check, case by case, whether the destination country's law undermines them, and add supplementary measures where it does. The EDPB's Recommendations 01/2020, finalized on 18 June 2021, turned that into a six-step roadmap, and the document a controller produces at step three is the transfer impact assessment.

For the wider set of obligations a chatbot deployment must clear, of which transfers are only the third gate, see GDPR and your website chatbot: lawful basis, DPA, and transfers.

The three situations where residency is required

Residency stops being a preference and becomes a requirement in exactly three cases. Check all three before writing "EU hosting" into a tender, because each one has a different owner and a different remedy.

1. A localization law applies

Some countries legislate location outright. Russia's Federal Law 242-FZ, in force since 1 September 2015, requires that personal data of Russian citizens be recorded, stored, and updated in databases physically located in Russia. China's PIPL Article 40 requires critical information infrastructure operators, and processors above thresholds set by the Cyberspace Administration, to store domestically collected personal information within China.

The EU has no equivalent general rule for personal data. Where an organization serves Russian or Chinese users through the same chatbot it serves EU users, the localization question arises for those users, and the usual answer is to not deploy the chatbot in those markets rather than relocate an EU deployment.

2. A contract or procurement rule requires it

This is the common case in the EU, and it is legally real even though GDPR does not impose it. Public tenders often specify EU or member-state hosting. University framework agreements and consortium contracts may carry the term. A controller's own customers may have written EU-only processing into their DPAs, which flows down to every processor the controller appoints.

The remedy here is contractual, not regulatory. If the term exists, a US-hosted vendor is out, however strong its transfer mechanism is, and the honest vendor will say so early. If the term does not exist and someone proposes adding it, ask whether it comes from the organization's own risk analysis or is a habit copied from another tender. The public-sector angle for EU universities, where legitimate interests is also unavailable as a lawful basis, is covered in AI chatbots for universities under GDPR.

3. The transfer impact assessment fails

The third case is a risk decision the controller documents. The TIA asks whether the destination country's law and practice would undermine the SCCs for this data, and whether supplementary measures (encryption the importer cannot break, short retention, pseudonymization) close the gap. For most customer service chatbot data, which is names, emails, and questions about products, the assessment supports the transfer. For special category data, such as health information, or for data about people a foreign government would have reason to seek, it may not.

Where the TIA finds that no measure suffices, EU-only processing is the residual option, and it should be recorded as the outcome of the assessment rather than as a starting assumption. The assessment is yours. The vendor's job is to supply the inputs, which is what the questions later on this page are for.

When residency is a preference, and what it costs

A preference for EU hosting is a legitimate preference. It removes the transfer analysis from the review, it is easy to verify at the hosting layer, and it reads well to a steering committee. Vendors that have it lead with it for those reasons, and where it is real it is a real advantage.

The cost is what the preference excludes and what it hides. Screening on hosting alone rejects lawful vendors that would pass a TIA comfortably, and accepts vendors whose EU hosting covers the application server but not the parts of the stack that process the actual conversation. It also swaps a checkbox for the analysis Schrems II requires, and an EU-hosted vendor with US subprocessors still needs that analysis.

The chatbot DPA checklist covers the contract terms that survive either choice: scope, subprocessor notification and objection rights, deletion, and audit. None of those get easier with residency, and a vendor that leads with hosting and stumbles on Article 28 has answered the wrong question.

The AI model layer, where EU-hosting claims break

An AI chatbot does something a conventional SaaS application does not. For every message, it sends the visitor's text and the retrieved content to a language model and gets a generated answer back. That call processes personal data whenever the message contains any, and the largest model providers are companies established in the United States.

So the question that decides whether a chatbot's data stays in the EU is not where the widget is served from. It is where inference runs.

Three practical points follow. A vendor advertising EU residency should be able to name the model provider, the region inference runs in, and whether the provider retains prompts; if the answer is a US endpoint, the residency claim covers the front end only. A vendor that is honest about US processing across all four layers is easier to assess than one with a mixed picture, because the TIA has one destination country to analyze. And zero-data-retention arrangements at the model layer, where the provider does not store prompts or completions, are a supplementary measure worth asking about, because they shorten the window in which any access request could reach the data.

Where the same review also has to satisfy US health data rules, the twelve questions to ask a chatbot vendor about HIPAA covers the model-layer and retention questions from that side.

How to evaluate a US-hosted chatbot vendor

The EDPB's six steps, applied to a chatbot vendor, produce a review a DPO can file. The controller owns each step. The vendor supplies the inputs listed against it.

Two questions tend to expose more than the rest of the review combined. Ask whether the vendor is established in the EU, and if not, whether it has appointed an Article 27 representative, because Article 27 is mandatory for non-EU organizations offering services into the EU and it is the obligation most small vendors skip. And ask for the DPA text before the sales conversation, because a vendor that will only share it after signature is asking you to assess a transfer you cannot yet read.

SiteGPT's position, stated plainly

SiteGPT does not offer EU data residency and has no regional hosting option. The privacy policy states that service providers are primarily located in the United States. The published subprocessor list, last updated July 2026, names no EU-based subprocessor: Convex (backend database) and Pinecone (vector database) run in the United States on AWS, OpenAI and Cohere (language models and embeddings) are United States, Cloudflare (hosting and delivery) is listed as Global, and Paddle (payments) is United Kingdom.

If your requirement is EU-only processing, whether from a tender, a customer DPA, or a failed TIA, SiteGPT does not meet it, and vendors that offer real EU processing across every layer have a genuine advantage for that requirement.

What SiteGPT offers is the other path: the evidence a transfer impact assessment needs.

• Transfer mechanism, stated publicly. The privacy policy states that transfers relating to EU, EEA, and UK residents rely on "the European Commission's Standard Contractual Clauses and, where the provider is certified, the EU-U.S. Data Privacy Framework." DPF coverage is per provider, not blanket.
• Article 27 representatives in both regions. Prighter EU Rep GmbH, Schellinggasse 3/10, 1010 Vienna, Austria, under Article 27 GDPR, and Prighter Ltd, 20 Mortlake High Street, London SW14 8JN, under Article 27 UK GDPR.
• A public subprocessor list with countries and purposes, covering all four layers, including the model providers. It also records that OpenAI is used through zero-data-retention endpoints for HIPAA deployments, which is the supplementary measure described above, stated for that program.
• SOC 2 Type II on the security page, and data export and deletion from the dashboard.
• A DPA executed for Enterprise customers. The DPA page generates a template and states the agreement binds only when signed by both parties; customers on other plans contact support. The text is not published for pre-review, which is weaker than SiteGPT's HIPAA posture, where the standard BAA is public.

Best forEU and UK controllers whose transfer impact assessment is the deciding document rather than a hosting checkbox, and who want a vendor that answers the residency question with a public subprocessor list instead of a claim.

The documents named above are collected on the compliance hub. For handling access and deletion requests once conversations exist, see DSARs and deletion requests for chatbot conversations.

Which path fits your organization

Frequently asked questions

The rules

Does GDPR require EU data residency for a chatbot? No. GDPR has no rule that personal data must stay inside the EU. Chapter V governs transfers to third countries and allows them under an adequacy decision (Article 45), appropriate safeguards such as Standard Contractual Clauses (Article 46), or narrow derogations (Article 49). A chatbot vendor hosted in the United States can be a lawful processor if a valid transfer mechanism is in place and a transfer impact assessment supports it. EU residency removes the transfer analysis. It does not satisfy a requirement of its own.

What is the difference between data residency, data localization, and data sovereignty? Data residency is where data is physically stored and processed: a geographic fact. Data localization is a legal mandate that certain data must stay within a country's borders, such as Russia's Federal Law 242-FZ or China's PIPL Article 40 for critical infrastructure operators and large processors. Data sovereignty is the broader question of whose law governs the data and who can compel access to it, including who holds encryption keys and administrative access. A vendor can satisfy residency on paper and still leave a customer without sovereignty if its parent company answers to a foreign government's access requests.

Are Standard Contractual Clauses still valid for transfers to the US in 2026? Yes. The European Commission adopted the current SCCs on 4 June 2021 (Decision 2021/914), and they remain the most common transfer safeguard. After the Schrems II judgment of 16 July 2020, a controller relying on SCCs must also run a transfer impact assessment and add supplementary measures where the destination country's law requires them. The EDPB's Recommendations 01/2020, finalized on 18 June 2021, set out a six-step roadmap for that assessment.

What is the status of the EU-US Data Privacy Framework? The European Commission adopted the adequacy decision on 10 July 2023, allowing transfers to US companies that self-certify under the framework. On 3 September 2025 the EU General Court dismissed the first direct challenge to it, Latombe v Commission (T-553/23), finding the redress court sufficiently independent and US bulk collection limits adequate. Philippe Latombe appealed to the Court of Justice on 31 October 2025, and that appeal is pending. Certified recipients can rely on the DPF today. A cautious DPO keeps SCCs in place as a fallback.

Does the UK have the same transfer rules as the EU? Similar but separate. The UK GDPR governs UK transfers, and since 21 March 2022 exporters use the International Data Transfer Agreement (IDTA) or the UK Addendum to the EU SCCs, with a transfer risk assessment. The UK also has its own extension to the Data Privacy Framework for certified US recipients. A vendor serving both regions should reference both mechanisms and, if it is not established in the UK, appoint a UK representative under Article 27 UK GDPR.

The decision

When is EU data residency actually required for a chatbot? In three situations. First, a localization law applies, which is rare for EU personal data but real in Russia and, for some operators, China. Second, a contract or procurement rule requires it: a public tender, a university framework agreement, or a customer's own DPA that specifies EU-only processing. Third, a transfer impact assessment concludes that the destination country's law undermines the safeguards and no supplementary measure fixes it, which is a documented risk decision rather than a statutory rule. Outside those three, residency is a preference.

Is a chatbot with EU hosting automatically GDPR compliant? No. EU hosting addresses one part of one obligation, the transfer analysis under Chapter V. It does nothing for lawful basis, the Article 28 processor contract, transparency, retention, data subject rights, or security. It also often overstates what stays in the EU: many chatbot vendors host the application in the EEA while the AI model inference, analytics, or email delivery runs through US subprocessors. Read the subprocessor list, not the hosting claim.

Where does the AI model run, and why does it matter for residency? Almost every AI chatbot sends the visitor's message and retrieved content to a language model API, and the largest model providers are US companies. An EU-hosted widget backed by a US inference endpoint still transfers personal data to the United States for every message that contains any. Ask the vendor which model provider it uses, in which region inference runs, whether the provider retains prompts, and whether the provider appears on the published subprocessor list with a country. That single question separates real EU processing from EU hosting of the front end.

What is a transfer impact assessment, and who has to do it? A transfer impact assessment (TIA) is the documented analysis a data exporter runs before relying on SCCs. It checks whether the law and practice of the destination country undermine the protection the clauses promise, and records any supplementary measures. The EDPB's six steps are: know your transfers, identify the transfer tool, assess the destination country's law, adopt supplementary measures, take procedural steps, and re-evaluate periodically. The controller owns it. The vendor supplies the inputs, such as encryption details, access controls, and its policy on government access requests.

Can a chatbot vendor be sovereign without EU residency? Not in the strict sense. Sovereignty means EU law alone governs access to the data, which a US-owned processor cannot promise, because it is subject to US legal process. What a US vendor can offer is transparency (a public subprocessor list, a stated policy on government access requests), technical measures (encryption in transit and at rest, short retention, zero-data-retention endpoints at the model layer), and contractual commitments under SCCs. Whether that is enough is exactly what the transfer impact assessment decides.

SiteGPT

Does SiteGPT offer EU data residency? No. SiteGPT's privacy policy states that service providers are primarily located in the United States, and the published subprocessor list names no EU-based subprocessor: Convex and Pinecone run in the United States on AWS, OpenAI and Cohere are United States, Cloudflare is listed as Global, and Paddle is United Kingdom. Transfers for EU, EEA, and UK residents rely on the European Commission's Standard Contractual Clauses and, where the specific provider is certified, the EU-US Data Privacy Framework. If your requirement is EU-only processing, SiteGPT does not meet it.

What does SiteGPT offer instead of residency? A documented transfer mechanism (SCCs, plus the DPF where a provider is certified), Article 27 representatives in both the EU (Prighter EU Rep GmbH, Vienna) and the UK (Prighter Ltd, London), a public subprocessor list naming each company and its country, a SOC 2 Type II report, and a Data Processing Agreement executed for Enterprise customers. That is the evidence a transfer impact assessment needs, which is a different thing from avoiding the assessment.

Sources

• GDPR Article 44 and Chapter V for the general principle and the three transfer routes, read 12 September 2026
• GDPR Article 27 for the representative requirement for organizations not established in the EU
• GDPR Article 28 for the processor contract
• European Commission, EU-US data transfers for the 10 July 2023 adequacy decision
• IAPP, European General Court dismisses Latombe challenge for the 3 September 2025 judgment, and WilmerHale for the 31 October 2025 appeal
• Mayer Brown on EDPB Recommendations 01/2020 for the 18 June 2021 final version and the six-step roadmap
• IAB Europe, Case C-311/18 Schrems II for the 16 July 2020 judgment
• Duane Morris on Russia's Federal Law 242-FZ for the localization requirement in force since 1 September 2015
• Future of Privacy Forum on China's PIPL for Article 40's localization requirement
• Tidio GDPR page for an example of an EEA-hosting statement that also discloses US transfers under SCCs and the DPF, read 12 September 2026
• SiteGPT privacy policy for the US location statement, the SCC and DPF wording, and the Article 27 representatives, verified 12 September 2026
• SiteGPT subprocessor list, last updated July 2026, for every subprocessor, purpose, and country, verified 12 September 2026
• SiteGPT DPA page for Enterprise execution and the both-parties signature requirement
• SiteGPT security page for SOC 2 Type II