Built with Claude, run in the EU: what sovereignty actually measures

Sooner or later, every European buyer evaluating software asks a version of the same question: is it really sovereign if the tool was built with Claude, or Copilot, or Cursor, or any other US technology? It is a fair question, and it deserves a straight answer, because it comes up the moment a buyer looks closely at how a product is made. The one-line answer is this: the tool that writes the code is not the tool that processes your data. A coding assistant helps developers write software faster. It never sees the call, the transcript, the document, or the record that the finished product handles.

Data sovereignty measures where your data is processed and which jurisdiction can compel access to it while the product runs. It does not measure which editor, compiler, or coding assistant the developers used to build the software. This post draws that line precisely, walks the full landscape of AI coding tools that teams actually build with today, grounds the argument in what the GDPR and the EDPB actually say, and then shows how to apply the test to any vendor, including the ones that host in the EU but still route your data somewhere they would rather not mention. If you want the checklist version, our sovereignty washing checklist applies the same logic vendor by vendor.

The category error: build-time versus run-time

Two different questions get collapsed into one. The first is how the software gets made. The second is what happens to your data when you use it. Conflating them is a category error, and it is the error hiding inside the "built by a US company" objection.

Almost every European software company builds with US-origin tools. The laptop is probably a Mac. The editor is often VS Code. The code lives on GitHub. Continuous integration runs on US-headquartered runners. And in 2026 the coding itself is increasingly done with an AI assistant, which is almost always US-headquartered too. None of that touches a customer's data, because none of it sits on the path your data travels when you actually use the product. Writing a function with an AI assistant is build-time. It never receives your data. Judge sovereignty on the run-time path, because that is the only path your data is on.

The tools developers actually build with

The objection used to name Claude because Claude happened to come up in the conversation. In practice a modern engineering team reaches for a whole shelf of AI coding assistants, and the shelf is overwhelmingly American. Here is the honest map of who owns what.

• GitHub Copilot: GitHub, owned by Microsoft. United States.
• Cursor: Anysphere. United States.
• Codex: OpenAI. United States.
• Claude Code: Anthropic. United States.
• Windsurf: now part of Cognition. United States.
• Gemini coding assistants: Google. United States.
• Amazon Q Developer: AWS. United States.
• Tabnine: headquartered in Israel, and one of the few that offers a fully self-hosted, air-gapped deployment where no code leaves your network.
• JetBrains AI: JetBrains, a European company, with processing kept in the EEA by default.

Two things stand out. First, if using a US-built coding assistant disqualified a product from being sovereign, almost no software on earth would qualify, European products included, because the best assistants are nearly all American. That alone should tell you the test is measuring the wrong thing. Second, the rare non-US and self-hostable options exist, which is worth knowing, but choosing one of them changes where your developers' code is processed. It does not, by itself, change anything about where your customers' data is processed when the finished product runs. Those are two different questions, and the next section is about not confusing them.

The real question these tools raise, and whose data it is about

There is a genuine data-governance question sitting inside AI coding assistants, and it is worth being precise about rather than waving away. Many of these tools learn from the code you type into them. As of mid-2026, several major assistants trained on or retained the developer's code by default on their free or individual tiers unless the user opted out or switched on a privacy mode, while their business and enterprise tiers generally excluded training from the code by contract. The exact defaults differ by tool and tier and change often, which is itself the reason to read each vendor's current data page rather than trust a blanket claim in either direction.

So the concern is real. But notice whose data it is about. When a coding assistant retains or trains on code, the data in question is the software company's own source code and prompts. It is that company's intellectual property and that company's governance decision. It is not the calls, meetings, files, or records that the company's customers hand to the finished product. Even in the worst case, where a vendor left training-on-code switched on for its own developers, the coding assistant still never receives the end customer's data, because that data is not in the source code. The build-time data question and the run-time data question do not touch. A company can be sloppy about the first and airtight about the second, or the reverse. Judging the second by the first tells you nothing.

Why a coding assistant is not a sub-processor

This is where the law is clearer than the marketing. Under the GDPR, "processing" means operations performed on personal data (Article 4), and a processor is an entity that processes personal data on a controller's behalf. The European Data Protection Board, in its guidelines on the concepts of controller and processor, sets two conditions for being a processor: being a separate entity, and actually processing personal data on the controller's behalf. It adds that the role "does not stem from the nature of an entity that is processing data but from its concrete activities in a specific context." Being a large, data-hungry technology company does not make you a processor. Processing the specific personal data in question does.

The EDPB even works a directly analogous example: an IT consultant hired to fix a bug, whose access to any personal data is incidental, is concluded to be neither a processor nor a controller. A coding assistant stands on cleaner ground still. It is not hired to touch the customer's personal data, and in the normal case it never receives that data at all, because a vendor's source code and prompts are not where the customer's calls and records live. No processing of that personal data means no "processing on behalf of," which means it is not a sub-processor of it. That is why a coding assistant does not belong on the sub-processor list you are entitled to see, while the transcription model, the analysis model, the hosting provider, and the backup provider all do.

One honest caveat keeps this argument clean rather than glib. It holds only so long as the source code and prompts genuinely do not contain the customer's personal data. Real customer data hardcoded into a repository, pasted into a prompt, or committed in a test fixture would change the picture, which is exactly why disciplined teams keep production personal data out of code and out of coding-assistant prompts in the first place. Get that hygiene right and the development toolchain and the customer's data stay in two separate worlds that never meet.

What a run-time map actually looks like

The useful exercise is to trace the run-time path for the specific product in front of you. Take a tool that records and analyses conversations, a common case. Ask it to draw the path your data takes, layer by layer, and to name the provider and the region at each step.

• Capture: where is the audio or file first received? On the vendor's own infrastructure, or through a third-party capture service?
• Transcription: which speech model, running where? An open-source model self-hosted in the EU is very different from a call to a US transcription API, even though both may be described as "AI transcription." An open model can be US-origin in its weights and still never send your data anywhere, because it runs on servers the vendor controls.
• Analysis: which language model summarises, scores, or answers questions about your data, and where does it run? A US large language model API is on the run-time path. A self-hosted open model in the EU is not.
• Storage: where does the data rest, and under whose control?
• Backups: where do offsite backups sit, and who owns that provider? This is the layer vendors most often forget to mention.

Notice what this list does not include: the editor the developers used, the laptop, the code host, the coding assistant. None of those appear, because none of them are on the path your data travels. That absence is the whole point.

The touchpoint most vendors will not mention

Here is the part that separates real sovereignty from the polished version. Very few stacks are perfectly clean. A vendor that hosts its models and storage in the EU may still keep offsite backups with a US-owned provider, serve static assets through a US content delivery network, or run error monitoring on a US platform. None of that necessarily processes your live data, but each is a place where a US corporate parent sits somewhere in the chain.

The test of real sovereignty is not the absence of any US touchpoint on a slide. It is whether the vendor can name every one, tell you what governs it, and show you the direction of travel. A vendor that claims a perfectly clean stack with no caveats at all is usually a vendor that has not looked hard enough, or is not saying. Spotting an unstated US link is the core move of any honest sovereignty check. Run it on every vendor, and expect the good ones to have already run it on themselves.

Where the data sits is not the same as who controls it

There is a subtler trap on the run-time side, and it is the one that actually costs European buyers. A US-owned provider will happily give you an "EU region," and that sounds like sovereignty. It is not the same thing. Data residency is where the servers physically sit. Data sovereignty is which jurisdiction can legally compel access to the data. The European Commission draws exactly this line when it describes tech sovereignty as the ability to control data and infrastructure rather than merely host it. An EU postal address on a US company's data center does not, by itself, move the data out of US legal reach.

The mechanism is the US CLOUD Act. It requires US providers to disclose data in their "possession, custody, or control" when lawfully ordered, "regardless of whether" that data "is located within or outside of the United States." The trigger is the corporate reach of the provider, not the location of the disk. So the honest run-time question is not only "which region" but "who owns the company that operates it, and which government can lean on that company." A self-hosted open model on European infrastructure and a US large language model API behind an EU endpoint can look similar on a diagram and answer that question completely differently. We walk the legal detail in the EU data center CLOUD Act loophole.

How to test any vendor on this

You can run this same test on any vendor. Separate the questions and refuse to let the easy one answer the hard one.

1. The build-time question, low stakes: what tools did you use to write the software? Occasionally revealing, rarely decisive. Every vendor builds with something US-origin, so a "no" here is almost always either a misunderstanding or a fib.
2. The run-time questions, the ones that matter: when I use the product, where is my data first captured, where is it transcribed or parsed and on whose model, where is it analysed and on whose model, where is it stored, where are the backups, and who owns each of those providers?
3. The jurisdiction question, the one people skip: for every provider on that run-time path, which government can compel access to my data, regardless of which region label is on the console?

A vendor that answers the run-time and jurisdiction questions with named providers, named regions, named model hosting, and named corporate owners is describing sovereignty. A vendor that pivots to "we are an EU company," "we are GDPR compliant," or "our data center is in Frankfurt" is answering an easier question and hoping you will not notice the substitution. GDPR compliance is a data-protection standard, not a shield against foreign jurisdiction, and the two should never be traded for one another. For the full scorecard, use our sovereignty washing checklist, and for the wider framing across the model, hosting, and control layers, see our plain-English guide to sovereign AI.

The honest version, said plainly

So, is a tool sovereign if it was built with Claude, or Copilot, or Cursor, or Codex? On its own, that fact cannot tell you, because it is a build-time fact and sovereignty is a run-time property. Build velocity and run-time data governance are different questions with different answers, and the honest builders will say plainly that they use US assistants to write software faster while keeping your data on infrastructure they control in the EU. The two are not in tension. The only thing that would make a tool not sovereign is a US-controlled provider on the run-time path your data travels, and that is exactly the thing you can check, name by name.

We hold ourselves to this same test. Numi uses Claude and other US tools to build faster, and says so, while keeping the run-time path for conversations in the EU: self-hosted transcription and analysis on infrastructure we can point to, with no US AI provider in the loop for your calls. See how a sovereign meeting assistant draws its own run-time map rather than hand-waving at one.