GDPR and AI: Why Your Provider's Location Is Now a Business Risk

In the space of a few weeks in the summer of 2026, two things happened that should give pause to any company relying on American AI services.

In late June, Austrian privacy campaigner Max Schrems asked the European Commission to begin winding down the legal basis for sending personal data to the United States. The trigger was a US Supreme Court ruling known as Trump v. Slaughter, the US Supreme Court held that the independence of the FTC is no longer constitutionally guaranteed. That very independence was one of the conditions under which the EU had, back in 2023, declared transfers to the US permissible in the first place.

A few days earlier, a different kind of risk had surfaced. The US Department of Commerce ordered Anthropic to cut off access to its most capable AI models for all foreign nationals. Within hours the affected models were offline worldwide, including on the major cloud platforms. Anyone who had built their workflows on top of them was suddenly left without a tool.

Both events point to the same conclusion. Where your AI provider is based is no longer a cosmetic detail. It is a strategic decision with direct consequences for data protection, legal certainty, and operational reliability.

First, what this is and is not about

This article is not a call to panic, nor a blanket warning against American technology. US models are often excellent, and for many purposes they are perfectly fine.

What matters is a sober assessment of risk. Which data are you handing over, to whom, under which legal regime, and how dependent are you becoming on a single provider in a jurisdiction you cannot influence. Answer those questions cleanly and you will make better decisions than someone who simply reaches for the best known tool.

The problem starts at the prompt

With traditional software, you think about which data a system stores. With AI language models the situation is trickier, because the sensitive data is not a byproduct. It is the actual input.

Every prompt can contain highly sensitive information. An employee pastes in a customer email to have a reply drafted. Someone uploads a contract to have it summarized. A developer sends source code to a model to hunt for a bug. HR uses a model to pre-sort applications.

In each of these cases, personal data, trade secrets, or protected code leaves your organization. If it lands with a provider in the US, that counts under the GDPR as a transfer to a third country. And third-country transfers need a solid legal basis.

The legal position in 2026: allowed, but on shaky ground

At present, transferring personal data to the US is generally permitted, provided the American recipient is certified under the so-called Data Privacy Framework. That framework rests on an adequacy decision issued by the European Commission in July 2023, meaning an official finding that the US offers an adequate level of data protection.

In September 2025 the framework survived its first challenge before the European General Court. The decision stood. However, the court examined only the situation as it stood in 2023, not later developments.

And that is where it gets uncomfortable. The entire construct rests on a US presidential order, not on legislation. An order can be changed or revoked by a new administration. With the ruling against the FTC's independence mentioned above, a central assumption behind the adequacy decision has been thrown into question. Privacy experts are already talking about a possible third round before the Court of Justice of the European Union. An initial view from the court is expected in late 2026 or early 2027.

The two predecessors of this framework, Safe Harbor and Privacy Shield, were both struck down by the court. Anyone building their entire data protection strategy on the current framework alone is betting that what happened twice will not happen a third time.

The CLOUD Act: why an EU region is not enough on its own

Many providers point out that your data sits in a European data center, in Frankfurt or Dublin for example. That sounds reassuring, but it only partly solves the problem.

A US law, the CLOUD Act, allows American authorities to compel US companies to hand over data regardless of where in the world that data is physically stored. What matters is not the location of the server, but the nationality of the parent company.

In practice this means that if a US corporation hosts your data in a European data center, it may still be legally required to hand that data to US authorities. A European region is a sensible measure, but not complete protection.

It is not only about data: the availability risk

Even if data protection left you entirely unmoved, a second risk remains, one that is easy to overlook: plain availability.

In June 2026 a leading US model was switched off worldwide within hours on the order of the US Department of Commerce, for all customers, without warning, including across the major cloud platforms. The reason was an export control directive justified on national security grounds. After a little over two weeks, access was restored.

For companies that had built their processes on that one model, this was a real outage. Those who had documented their dependencies cleanly and could switch to a fallback model got off lightly. Everyone else came to a standstill.

The lesson is clear. If you rely on a tool whose availability depends on the political decision of a foreign government, you are carrying an operational risk that has nothing to do with data protection. A model you run yourself, or one that originates in your own jurisdiction, cannot be switched off overnight by someone else.

The honest part: not everything has to stay in Europe

It would be dishonest to insist that everything must be European and self-hosted. The sensible approach is to sort your data by how much protection it actually needs.

For low-stakes tasks there is little reason to avoid American tools. If you have a blog post drafted, brainstorm an idea, or rewrite a publicly available text, no sensitive data is in play. Here, simply use the best tool for the job.

It becomes critical the moment personal data, contract contents, source code, or health and personnel records enter the picture. For this category you should choose a provider where the data never leaves your jurisdiction and where no foreign legal regime can gain access.

A simple rule of thumb: for every AI tool, ask what kind of data it gets to see. Anything you would not show a stranger on the street belongs in a protected environment.

What European AI actually means in practice

If you want to keep sensitive data local, you essentially have three routes.

The first route is providers based and hosting in your own region, with no US parent company. There are now capable European model providers. The upside is a clear legal position and no CLOUD Act exposure. The downside is a smaller selection, and in raw peak performance some US models still lead.

The second route is running open models on your own or on regional infrastructure. Open models can be downloaded and run yourself, either in-house or with a regional cloud provider. This means no third-country transfer happens at all, because the data never leaves your control. The price is the technical effort and the cost of running the necessary hardware.

The third route is a middle path: a regional cloud provider combined with technical safeguards such as pseudonymization and encryption. This lowers the risk considerably, even where a powerful model still sits in the background.

Which route fits depends on your protection needs, your budget, and your technical setup. For many small and mid-sized companies a combination makes sense: low-stakes work through convenient mainstream tools, sensitive work through a protected regional solution.

A pragmatic roadmap

Five steps to approach this in a structured way.

First, get a clear picture of which AI tools are already in use across your organization and what data flows into each of them. In practice, staff often use more tools than management realizes.

Second, sort your data types by how much protection they need. Draw a clear line between low-stakes and sensitive.

Third, do not rely on the current transfer framework alone. Wherever you use US services, additional contractual safeguards such as Standard Contractual Clauses should be in place, so that if the framework falls away you are not left exposed.

Fourth, move the sensitive category onto regional or self-hosted solutions. This is where the biggest gain in legal and operational certainty lies.

Fifth, document your decisions. A clean record of processing activities and a short risk assessment are not just an obligation, they also keep you able to act when it matters.

Conclusion

The most convenient answer to all this uncertainty is also the most robust: keep your regional data where it counts, in your own jurisdiction.

That turns the question of what courts will decide about transatlantic data transfers in the coming years into a side issue rather than an operational risk. And a model you control yourself, or one that originates in your own region, cannot be shut down overnight by a foreign authority.

Where your AI provider is based is therefore no longer a detail for the IT department. It is a strategic decision for the leadership. Make it deliberately today and you spare yourself unpleasant surprises tomorrow.

Fragon Studios helps small and mid-sized companies adopt AI in a privacy-compliant way, from the first assessment through to running European and self-hosted solutions. If you want to know where your company actually stands, get in touch.