Hardly any question comes up as reliably in our conversations with managing directors as this one: "Do our AI systems have to run in Germany?" The honest answer is: it depends. And not on gut feeling, but on three very concrete things: which data is being processed, which obligations arise from laws and contracts, and how much dependency you are strategically willing to accept.
Exactly this distinction is missing from many discussions. Some declare every US cloud a data protection problem across the board; others dismiss the location question as typical German hand-wringing. Both lead to bad decisions. In this article, we sort the topic the way we do in projects: first the technology, then the obligations, then the strategy.
What "where does the AI run" means technically
If your company uses a language model, there are essentially four deployment models, and they differ considerably in where your data flows.
Model API in the US. The simplest case: you call the API of a US provider directly. Your inputs, meaning prompts, documents, customer data, are processed on servers in the US. This is technically straightforward and often the most capable option, but the data leaves the EU.
EU region of a US hyperscaler. Providers such as Microsoft, Amazon, or Google operate data centers in Frankfurt, Amsterdam, or Paris and also offer AI models there, including the well-known US models. Processing then takes place physically in the EU. It is important to understand: the operator remains a US corporation subject to US law. The data processing is in Europe; the control over the infrastructure is not entirely.
European provider. Serious European alternatives now exist. The French company Mistral, for example, offers capable models, some with open weights, that can be operated in European clouds or on your own infrastructure. Add to that European cloud and hosting providers where both the infrastructure and the corporate headquarters are located in the EU. The performance gap to the top US models exists, but for many business applications it is irrelevant, because the tasks simply don't require it.
Own infrastructure and local models. Open models can be run on your own servers, in your own data center or on rented hardware. Then the data never leaves the company at all. The price for this: you need hardware, operational expertise, and you must make do with the capabilities of smaller models or invest in larger GPU capacity.
The legal level: what is actually required
First things first: we are a technology partner, not a law firm. But the basic logic of the GDPR can be explained soberly, and it is simpler than many think.
The GDPR applies as soon as personal data is processed: names, email addresses, customer numbers, HR data. Then you need a data processing agreement with every service provider that processes this data on your behalf. This applies to an AI provider just as it does to your email provider. If a provider processes the data outside the EU, the so-called third-country transfer comes into play: you need an additional legal basis for the data leaving the EU.
For the US, the EU-US Data Privacy Framework has existed since 2023, an adequacy decision by the EU Commission that permits data transfers to certified US companies. The catch: this foundation is shakier than you would want for an architecture decision. Its two predecessors, Safe Harbor and Privacy Shield, were struck down by the European Court of Justice. The current framework survived an initial legal challenge in 2025 but remains under pressure, most recently due to developments in the US concerning the independence of the oversight bodies the decision is built on. Many companies therefore hedge and additionally agree on Standard Contractual Clauses. That is sensible, but it doesn't change the basic finding: anyone building their data processing on this framework is building on a legal basis that has already collapsed twice in similar form.
Alongside the GDPR, there is a second, often overlooked source of obligations: your own contracts. Many SMEs have customer contracts with confidentiality clauses, requirements regarding subcontractors, or explicit stipulations about the place of processing. Anyone who works for automotive corporations, public authorities, or the healthcare sector knows this. These contractual obligations can be stricter than the GDPR, and they also cover design data, cost calculations, or source code, meaning data with no personal reference whatsoever.
The most important sorting question is not "Is US cloud allowed?" but: which types of data flow into which system? Personal data, contractually protected data, and non-critical data have different requirements. Throwing them all into one pot makes the location question unsolvable. Separating them makes it answerable.
The strategic level: not a legal requirement, but smart risk management
Even if everything is legally clean, a second question remains: how dependent do you want to be? That is not a data protection question, but an entrepreneurial one.
Three risks belong on the table. First, pricing power: anyone who integrates their processes deeply into the services of a single provider negotiates from a weak position at the next price increase. Second, the shutdown and change risk: providers discontinue models, change terms or behavior, and geopolitical upheavals can alter access to services faster than contracts can reflect. Third, the legal uncertainty of the third-country transfer itself: if the Data Privacy Framework falls, the architecture needs an answer that isn't "rebuild everything".
For us as founders, European AI sovereignty is also a cause of our own: we believe it is healthy for Europe to build its own capabilities in a key technology instead of importing them entirely. But we would never advise a customer to make architecture decisions out of conviction. The good news is: nobody has to. The sober arguments, contract stability, legal certainty, negotiating position, carry the case on their own.
Which tier for whom: an honest assessment
Not every company needs its own GPU servers. Whoever claims otherwise is usually selling some. In practice, we see three sensible tiers.
Tier 1: EU processing with clean contracts. For most SMEs, this is the right starting point: AI models running in EU data centers, with a data processing agreement, training on your data disabled, and documented data flows. This covers the GDPR requirements for the vast majority of use cases and is achievable without major investment.
Tier 2: European providers for sensitive processes. Where customer contracts, industry requirements, or your own risk appetite demand more, it is worth looking at providers whose corporate headquarters and legal jurisdiction are also European. This largely eliminates the third-country question and reduces the dependency on the stability of transatlantic agreements.
Tier 3: local models for core data, designed as a hybrid. For truly sensitive data, design documents, formulas, client or patient data, a locally operated model can be the right answer. The mistake would be to run everything locally because of it. A hybrid architecture is usually smarter: non-critical tasks run on capable cloud models, while the core data stays in-house. That way, each type of data gets the infrastructure that suits it.
Location is an architecture decision, not a matter of faith
The question "Where should our AI run?" can be answered systematically. First: which types of data are involved, and which of them are personal or contractually protected? Second: which obligations follow from that, from the GDPR, from customer contracts, from your industry? Third: how much dependency on individual providers and on the durability of the Data Privacy Framework are you willing to carry? From these three answers, the appropriate tier follows almost by itself, and it can differ for different processes within the same company.
What comes out of this is rarely the most radical solution. It is almost always an architecture that fits the actual data and obligations, rather than a blanket conviction. If you want to sort out for your company which data may go where and which tier is appropriate for your processes, we are happy to walk through it together, with a view to your contracts, your systems, and your risk appetite.
