EU vs EEA for AI compliance: which countries count and where your model actually runs in 2026

Published September 21, 2026. Legal statuses and vendor region definitions verified at publish time, and we revisit this page as they change.

If you route AI traffic for a European organization, at some point a policy, a DPA or a procurement questionnaire will ask whether data stays "in the EU", and someone will point out that your Norwegian inference route, your Swiss cloud region or your UK-registered provider is or is not covered, depending on how the question was phrased. We went through exactly that confusion ourselves when we started tagging every route on the Opper gateway with where it runs, so this article starts with the part the geography explainers never reach, what any of it means when the thing crossing the border is a prompt, and then explains the terms in one place. Every legal and vendor claim links to a primary source, checked in September 2026, and nothing here ranks one location above another: every jurisdiction below has data protection law and a law under which authorities can compel access, and the point of separating the dimensions is that your rule can say what your policy actually says.

EU vs EEA at a glance

One collision worth clearing up immediately: EEA also abbreviates the European Environment Agency, an EU body in Copenhagen with a country list of its own. Everything below means the European Economic Area.

What "EU data residency" means for an AI request

A single model call touches more places than a database row does, and the vocabulary has not caught up. When a vendor says "EU data residency" it can mean any one of five things, and a contract that pins only one of them leaves the other four open. The five, in the order a request meets them:

1. Inference location is the country where the GPUs that run the model sit, and where your prompt is decrypted and processed. OpenAI's documentation now calls this inference residency, to separate it from storage, and Anthropic calls the same thing the inference geo. It is what most people mean by residency and the property least often written into a contract.
2. Storage location is where anything that persists ends up: logs, abuse-monitoring copies, cached responses, traces, uploaded files. The vendors separate this from inference themselves. OpenAI's help page says non-GPU processing may still occur globally under inference residency, and Amazon Bedrock's cross-region documentation says that to the extent it stores data for abuse detection, prompts and outputs are stored in the destination region, so a route can run inference in one country and keep its copies in another.
3. Provider country is the legal home of the company that operates the endpoint and signs your DPA. It decides which government can compel the operator, and it is often different from the inference location: on the Opper directory alone, US-registered hyperscalers run Frankfurt, Paris and Stockholm regions, a Dutch-registered operator runs in Finland, a Chinese-registered one runs a Frankfurt route, and a US-registered one runs in Norway. The country under "provider" and the country under "inference" agree far less often than the region names suggest.
4. Maker country is where the lab that trained the weights is based. No data flows to the maker when someone else hosts the weights, so it changes nothing about residency, but it matters for procurement policy, for sanctions and export-control screening, and for the AI Act, which places provider obligations on whoever puts a general-purpose model on the EU market. Open weights make the point cleanly: DeepSeek's lab is in Hangzhou and its own API processes data in China per its privacy policy, while the same weights served from Stockholm or Helsinki never leave the EEA, and the directory lists both so you can pick. Same model, same maker, two different residency answers, because residency was never a property of the model.
5. Retention posture is what happens to the content afterwards: whether it is used for training, how long it is logged, whether a moderation classifier reads it. Zero data retention answers "how long", not "where", and the two are routinely swapped in vendor copy.

The gateway itself is a hop too. Opper's runs in AWS Stockholm, so that hop is inside the EU, and the trap we described in our comparison of European AI gateways is the gateway that markets European hosting while forwarding your request to an endpoint elsewhere, keeping exactly one hop in Europe. Everything in this article is about the hops after the gateway.

What is the difference between the EU and the EEA?

The European Union is the union of 27 member states that pool sovereignty across a customs union, a common trade policy, agriculture and fisheries, foreign policy, justice and home affairs, and, for 21 of them, a currency. It makes law through the Parliament and the Council, and the Court of Justice in Luxembourg has the final say on what that law means. The most recent change to the membership was the United Kingdom's departure on 31 January 2020, and the most recent accession was Croatia's on 1 July 2013.

The European Economic Area is narrower and wider at the same time. Narrower, because the EEA Agreement only extends the single market, the four freedoms of goods, services, capital and persons, plus the competition and state-aid rules and the flanking policies that make a single market work. EFTA's own summary lists what it leaves out: the common agriculture and fisheries policies, the customs union, the common trade policy, foreign and security policy, justice and home affairs, and monetary union. Wider, because it adds three countries that chose the market without the union: Norway, Iceland and Liechtenstein. The agreement was signed in Oporto on 2 May 1992, entered into force on 1 January 1994, and Liechtenstein joined in 1995, which is why "EU plus three" is the shorthand.

The mechanics matter for everything that follows. EU law applies in Norway not because Norway is in the EU, it is not, but because the EEA Joint Committee takes each EU act that the EU has marked "Text with EEA relevance", decides to incorporate it into an annex of the agreement, and the three states then implement it under their own constitutions. That is a two-pillar structure: on the EFTA side the EFTA Surveillance Authority and the EFTA Court mirror the Commission and the Court of Justice, and the EFTA Court's jurisdiction, in its own words, largely corresponds to that of the Court of Justice. Two consequences: an EU act is in force in the EEA only once its Joint Committee decision is adopted, which can lag the EU by months or years, and you can always check the status of any act in EFTA's public register, EEA-Lex. Keep that register in mind, it settles the AI Act question below.

Which countries are in the EEA in 2026?

Thirty countries: every EU member state plus Norway, Iceland and Liechtenstein. Because the EEA, EFTA and the Schengen area overlap without coinciding, the useful form of the list is a matrix. Sources: the EU country list, EFTA on the EEA and the Commission's Schengen page.

A few edges that come up once you start tagging data centres rather than capitals. The EU's outermost regions, French Guiana, Guadeloupe, Martinique, Mayotte, Réunion, Saint-Martin, the Azores, Madeira and the Canary Islands, are an integral part of the EU and EU law applies there in full. The Faroe Islands were never in the EU and Greenland left in 1985, and both sit outside the EEA as well, the Faroes with an adequacy decision of their own. Norway excluded Svalbard from the EEA Agreement under Protocol 40. And the microstates, Andorra, Monaco, San Marino and the Vatican, are not in the EU or the EEA, although the Commission's proposed association agreement would give Andorra and San Marino market access it describes as comparable to Norway, Iceland and Liechtenstein's. Serbia, Ukraine and Türkiye are European countries and EU candidates, and outside both.

Is Norway in the EU, is Switzerland in the EEA, and where does the UK sit?

These three are where every European routing rule has to make a decision, because each hosts real inference capacity and each sits in a different place on the map.

Is Norway in the EU?

No. Norway is in the EEA, in EFTA and in Schengen, and not in the EU or the euro. The GDPR has applied there since 20 July 2018, the day the Joint Committee decision incorporating it entered into force and Norway's own Personal Data Act made the regulation Norwegian law, and the Norwegian supervisory authority sits on the European Data Protection Board with the same rights and obligations as its EU counterparts, bar the vote. Personal data moving from Berlin to Oslo is therefore not an international transfer, and needs no adequacy decision, no standard contractual clauses and no transfer impact assessment. Norway also hosts real inference capacity, Microsoft's two regions and specialist providers such as Geodd in Stavanger, which makes it the case that turns the EU versus EEA distinction from trivia into a routing decision. Iceland and Liechtenstein are in the same position, they simply host less.

Is Switzerland in the EEA?

No. Switzerland negotiated the EEA Agreement, rejected it by referendum in 1992, and built a set of bilateral agreements with the EU instead, while staying in EFTA and joining Schengen. Its own authorities state the consequence plainly: the GDPR is not binding on Switzerland, which applies its revised Federal Act on Data Protection, and the EU treats it as adequate, so a transfer from an EU controller to a Swiss processor is a third-country transfer that needs no clauses and no assessment, governed by Swiss law once the data arrives. Switzerland recognises the United States in turn under its own Swiss-US Data Privacy Framework, in force since 15 September 2024.

Is the UK in the EEA?

No. The United Kingdom left the EU on 31 January 2020, ceased to be a party to the EEA Agreement at the end of that year, and is a third country for GDPR purposes. It kept the regulation's text as the UK GDPR and amended it through the Data (Use and Access) Act 2025, which received Royal Assent on 19 June 2025. On the EU side the 2021 adequacy decision was due to expire on 27 June 2025, was extended to 27 December 2025 while the Commission reviewed the new Act, and was then renewed with a new expiry of 27 December 2031. The UK's position is therefore the same shape as Switzerland's: not the GDPR, but adequate.

Why the GDPR says EEA, not EU

The regulation itself is an EU act that applies from 25 May 2018 and, in Article 3, to processing in the context of an establishment "in the Union" or aimed at data subjects "in the Union". What turns "the Union" into "the EEA" is Joint Committee Decision No 154/2018 of 6 July 2018, which incorporated the GDPR into Annex XI of the EEA Agreement with one adaptation that does all the work: the terms "Member State(s)" and "supervisory authorities" are to be understood to include the EFTA states and their supervisory authorities. From that day the Commission has described the regulation as applicable throughout the European Economic Area, and its guidance on international transfers is explicit that EU data protection rules apply to the EEA, which includes all EU countries and non-EU countries Iceland, Liechtenstein and Norway, with the special safeguards of Chapter V kicking in "when personal data is transferred outside the European Economic Area".

Chapter V is where the geography bites. Article 44 says a transfer to a third country may take place only under the conditions of that chapter, and the regulation never defines "third country" itself, the EEA reading comes from the Joint Committee adaptation and from the supervisory authorities, which is why the EDPB and the ICO both frame transfers as movements outside the EEA. The EDPB's Guidelines 05/2021 then give the three cumulative criteria for a transfer: an exporter subject to the GDPR, a disclosure to a separate controller or processor, and an importer in a third country, whether or not that importer is itself subject to the GDPR. Two points in those guidelines matter for AI specifically. Remote access from a third country, even if it takes place only by means of displaying personal data on a screen, and storage in a cloud situated outside the EEA, are both transfers. And a processor located inside the EEA but subject to third-country legislation is not a transfer, though the guidelines note the possibility of government access requests as something the controller still has to assess. That second point is the seam between residency and sovereignty, and it gets its own section below.

Which countries have an EU adequacy decision?

Adequacy is the Commission's finding under Article 45 that a third country protects personal data essentially as well as the EEA does, so transfers there need no further tool. It is a different thing from being in the EEA: an adequate country runs its own law, an EEA country runs the GDPR. Norway, Iceland and Liechtenstein are absent from the list for exactly that reason, they do not need to be on it. As of September 2026 the Commission recognises: Andorra, Argentina, Brazil, Canada (commercial organisations), the Faroe Islands, Guernsey, Israel, the Isle of Man, Japan, Jersey, New Zealand, the Republic of Korea, Switzerland, the United Kingdom, the United States (commercial organisations participating in the EU-US Data Privacy Framework), Uruguay, and the European Patent Organisation. The two newest entries are the European Patent Organisation in July 2025 and Brazil, adopted on 26 January 2026, the same day Brazil's data protection authority recognised the EU in return.

The United States entry covers organisations, not the country: the EU-US Data Privacy Framework, adopted on 10 July 2023, applies to US organisations on the framework's list, so an AI provider's certification status decides whether adequacy or standard contractual clauses is the tool for that route. The framework survived its first court test when the General Court dismissed Latombe v Commission on 3 September 2025, and the appeal, lodged on 31 October 2025, was still pending at publish time. Its predecessor fell in Schrems II in 2020, which kept standard contractual clauses valid on condition that exporter and importer verify the destination's protection before any transfer. Without adequacy, the tools are the Commission's 2021 standard contractual clauses, binding corporate rules, and the narrow derogations of Article 49. On the Opper directory the transfer field on each route records which of these applies, and one detail there shows the provider-country dimension at work: a Norway route whose operator is registered outside the EEA carries standard contractual clauses even though its GPUs are inside it, because the EDPB's third criterion looks at where the importer is, not where the servers are.

Does the EU AI Act apply in the EEA?

Not yet, and this is the point most often assumed wrongly. Regulation (EU) 2024/1689 is marked "Text with EEA relevance", entered into force on 1 August 2024, and applied in stages inside the EU: the prohibitions and AI-literacy duties from 2 February 2025, the general-purpose model obligations from 2 August 2025, and most of the rest, including the Article 50 transparency duties, from 2 August 2026. The Digital Omnibus on AI, Regulation (EU) 2026/1744 of 8 July 2026, in force since 27 July 2026, then moved the high-risk obligations to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I products, while keeping 2 August 2026 as the general application date. Article 50 still applies from that day, with one grace period: generative systems already on the market before 2 August 2026 have until 2 December 2026 to meet the Article 50(2) marking duty.

None of that is EEA law yet. EFTA's register lists both the AI Act and the Omnibus as marked EEA-relevant and "under scrutiny for incorporation into the EEA Agreement by Iceland, Liechtenstein and Norway", with no Joint Committee decision adopted. Norway's communications regulator Nkom said the same on 10 August 2026: the regulation is for now not incorporated into the EEA Agreement nor implemented in Norwegian law, and the government has announced a new consultation on the Norwegian AI Act following the EU's changes. The Data Act, applicable in the EU since 12 September 2025, sits in the same "under scrutiny" state, so the lag is structural rather than specific to AI.

Three things follow. A Norwegian, Icelandic or Liechtenstein company is not directly bound by the AI Act today, but Nkom's same note points out that it is caught the moment it offers an AI system in the EU, because the Act reaches providers and deployers outside the Union whose systems are placed on the EU market or whose output is used there. Switzerland and the UK, outside the EEA entirely, are reached only that way. And an inference route hosted in Norway is inside the GDPR area and outside the AI Act area at the same time, which is a perfectly consistent position, it just cannot be expressed with one "EU" checkbox. On this site we therefore describe Norwegian routes as GDPR-native and never attach an AI Act claim to them.

Data residency vs data sovereignty

Residency is where the data physically is. Sovereignty is whose law can reach it, which depends on the physical location and on the legal home of whoever controls it. The two come apart precisely on the provider-country dimension above, and every major jurisdiction has a statute that makes the point, so this section lists them without ranking them. In the United States, 18 U.S.C. § 2713, added by the 2018 CLOUD Act, obliges a provider to produce data in its possession, custody or control "regardless of whether such communication, record, or other information is located within or outside of the United States". China's Personal Information Protection Law, in force since 1 November 2021, requires operators above a threshold to store domestically the personal information collected in China and to route foreign law-enforcement requests through Chinese procedure. The United Kingdom's Investigatory Powers Act 2016, amended in 2024, governs interception and the acquisition of communications data. And the EU has its own instrument in the Data Act's Article 32, which requires providers of data processing services to prevent third-country governmental access to non-personal data held in the Union where that would conflict with EU or member-state law, recognises foreign orders when they rest on an international agreement and, absent one, allows compliance only under the three conditions in Article 32(3).

The consequence for a routing rule is simple. Inference location answers the residency question and, together with storage location, the GDPR transfer question. Provider country answers the sovereignty question. A policy that says "EU only" has to say which of those it means, and if it means all of them, the rule needs all three fields set, not one.

When a vendor says "EU region", which countries does it include?

This is the section we most wanted to exist when we started, because the four largest AI platforms draw the "EU" line in two different places, EU plus EFTA for OpenAI and Microsoft, the 27 member states for Google and AWS, and each of them documents it, just not side by side. Every row below quotes the vendor's own page.

One further fact belongs here: the region prefixes themselves are not a jurisdiction claim. Oracle uses "eu-" for Jovanovac in Serbia and Zurich, AWS uses it for London, and Google's endpoints, per its own docs, don't guarantee data residency or in-region ML processing unless you use the residency-specific ones. None of this is a criticism of any vendor, each definition is reasonable and each is documented. It is a reason to write the rule in country terms rather than in region words.

Setting the rules per route on Opper

Opper exposes each of the five dimensions as its own field, per route, and lets you set them as an organization-wide rule that projects can narrow but never loosen. Every route in the model directory carries a compliance block with the residency answer, EU for a member-state host, EEA for a host in Norway, Iceland or Liechtenstein, or US, global, or a named country elsewhere, the inference location as a country code, the storage location where one applies, the provider's home country, the maker's country, and the training, logging and moderation posture. The rules screen filters on exactly those fields, and the location pickers offer the two areas this article is about as separate values, "European Union (EU)" and "European Economic Area (EEA)", next to "not pinned to any jurisdiction" and the individual countries, so the rule can say EU or EEA in as many words. Set inference location to Germany and the catalogue shrinks to routes whose GPUs are in Germany. Set provider country to the EU and a route whose operator is registered outside the EU drops out even when its GPUs are in Frankfurt, while the same open-weight model on an EU-registered operator stays. Set maker country and you are choosing labs, which changes nothing about where data goes and everything about a procurement policy that cares. Set the provider data policy to zero data retention and the no-training and no-logging requirements switch on together, because the platform then only routes to providers with a zero-retention agreement, with no-moderation available as a further step under a signed agreement.

The EEA distinction is handled the way this article recommends: the residency convention is EU for a route hosted in a member state and EEA where the host is inside the GDPR area but outside the Union, and the inference-location field carries the country itself, so a Norway route sits inside the GDPR area by one field and outside the Union by the other, and a rule can key on whichever the policy names. Live examples from the provider directory as of September 2026: Geodd's Stavanger route reads EEA with country Norway, the Stockholm routes on AWS Bedrock, Azure, Berget, evroc and Inceptron read EU with country Sweden, Nebius reads EU with country Finland, Mistral and the Paris routes on AWS and Azure read EU with country France, Regolo reads EU with country Italy, Nextbit reads Spain, Infercom reads Germany, and a handful of routes carry a storage location outside Europe even though nothing in their provider name suggests it, which is precisely why the field exists. The sub-processor list records the hosting countries contractually, and the DPA treats a transfer outside the EEA, not outside the EU, as the event that triggers safeguards, which is the line the GDPR draws.

The same fleet, three rules, three answers

Take a team in Munich that wants "European" inference and writes the rule three different ways, each of which is a value the picker actually offers.

None of those outcomes is wrong. The first is the right rule if the policy text says "European Union", the second if it says "GDPR" or "EEA", the third if the concern is which company can be compelled, and a contract that just says "Europe" has not chosen yet. Separating the fields is what lets the rule say what the policy actually says.

EU vs EEA FAQ

Write the rule the way the policy is written

The distinction between the EU and the EEA is not a technicality once the thing crossing the border is a prompt, it is the difference between a route that needs no transfer paperwork and one that does, and between a vendor's "EU region" that includes Zurich and one that stops at the member states. The whole article reduces to one question about the policy text.

If your policy names the GDPR, the line is the EEA. If it names the Union, the line is the 27. If it names a company's jurisdiction, the line is the provider's country, wherever its GPUs are. Opper lets you set each of those as its own rule and shows the answer per route before you commit, so you can browse the routes hosted in the EU or the EEA, read how every provider is tagged, and check the compliance overview for how the platform itself is hosted. Then write the rule in the same words as the policy, and let the directory do the rest.