The 5 Questions to Ask an "EU-Compliant" AI Vendor Before You Sign

A client sent me a link last month and asked one question: "Is this one safe to use? It says German, EU-hosted, GDPR-safe." It was one of the bigger German AI platforms. Clean site, confident security page, all the right words.

So I pulled it apart. The interface was German. The app itself ran on Microsoft Azure in an EU region. The actual model call went out to Claude on AWS Bedrock. Nothing on that page was technically a lie. And almost all of it was misleading, because "German company on EU servers" turned out to mean "German login screen on top of two American hyperscalers."

That is the whole game right now. A lot of the tools sold as an EU-compliant AI vendor, sovereign, EU-hosted, GDPR-safe, are a nice interface on top of Claude or GPT, wrapped in wording that is carefully true. I wrote before about 6 Signs That AI Product Is Just ChatGPT in a Trench Coat. This is the compliance version of that. Here are the five questions I now ask any EU-compliant AI vendor before I let a client sign anything, and what a good answer versus an evasive one actually sounds like. Think of it as the sequel to 5 Questions to Ask Before Paying for Any AI Tool, except this time the stakes are your clients' data.

Question 1: Which backend runs which model?

Ask them to name, per model, where the inference actually happens: AWS Bedrock EU, Google Vertex EU, or Microsoft Azure AI Foundry. Not "the EU." The specific backend, for the specific model you'll use.

Here is why that question is a filter. "We run our own data centers in the EU" is usually just false. Most of these companies are a SaaS running on a US hyperscaler in an EU region. That is fine, honestly. What is not fine is calling it something it isn't. And there is one fact that catches a lot of them: for the current Claude models, there is no European data zone on Azure AI Foundry yet. Anthropic's own residency guarantees cover Bedrock and Vertex. Foundry Europe is listed as coming in 2026, with no firm date. So if a vendor tells you "we use Azure" for Claude and then tells you your data stays in the EU, those two statements do not currently fit together. A vendor who can map model to backend without flinching knows their stack. One who says "it's all in the EU, don't worry" just told you they either don't know or don't want you to.

Question 2: Who actually owns the company?

Pull the Handelsregister entry and the Gesellschafterliste. On more than one "German" AI vendor, you'll find a GmbH that is 100 percent owned by a US Inc., usually a Delaware C-Corp sitting on top.

This is not an accusation. For a YC-funded startup, a Delaware C-Corp over the operating GmbH is completely normal. And US ownership of a GmbH does not, by itself, flip the CLOUD Act switch. That is the part critics get wrong and it hands the vendor an easy rebuttal. Whether US law can reach the data depends on who actually controls it and what US nexus that entity has, not on the ownership chart alone. GDPR Article 48 says a foreign authority needs an international agreement to demand data, and there is no EU-US agreement that specifically blesses the CLOUD Act, so the tension is real but it is not automatic doom. What the ownership does kill, cleanly, is the marketing line. The moment the parent is in Delaware, "we're a German provider, US law can't touch us" is no longer a sentence they get to say. Make them stop saying it.

Question 3: Is "EU-only" a guarantee or a toggle?

This is the one that matters most, so slow down here. "EU-only" is almost never a property of the platform. It is a configuration. It depends entirely on which models the admin switched on.

On AWS Bedrock, the boundary is literally a prefix on the model ID: eu. keeps inference inside an EU geography, global. does not. On Vertex, an EU-regional endpoint gives you residency and the global endpoint gives you none. So "EU-only" is a choice someone made and can prove, or it is a checkbox somebody forgot. Ask them which. And here is the detail that trips up the "nur Deutschland" crowd: Germany-only does not exist for current Claude models. Frankfurt is a source region for EU cross-region inference, which means requests get routed across the EU geography, Ireland, Stockholm, Frankfurt, Paris and so on, depending on load. That is still EU. It is not Germany. If a vendor promises your data never leaves Germany while running current Claude, they are describing something that isn't on the menu. This is the exact kind of claim I flagged in 7 AI Myths Your LinkedIn Feed Keeps Repeating: a marketing sentence dressed up as a technical fact.

Question 4: Is zero-data-retention contractually in place, and on which backend?

Ask whether zero-data-retention is contractually enabled, on which backend, and which of the models they turned on fall outside it. Retention is contractual and configurable. It is not architectural.

That distinction is the whole point. A lot of vendors imply that because the model runs on someone else's infrastructure, the model provider can't see your prompts. That is not how it works. Foreign hosting does not automatically wall off the provider. Access is governed by contract and configuration, not by the physics of where the server sits. Even with ZDR switched on, providers keep some safety-classifier results, and some newer models carry a mandatory short retention window for safety review that ZDR does not cover. I'm keeping that last part deliberately vague because I could not fully pin down the current model list against primary docs, and I'd rather you ask than trust my half-confirmed notes. So ask: which enabled models are exceptions? While you're at it, one small thing people constantly get backwards. The reason these tools resend your whole conversation on every follow-up isn't ZDR. It's that the Messages API is stateless, there is no server-side memory of your chat, so the context gets shipped again each turn. I dug into that in The 1 Million Token Context Window. It happens with or without ZDR, so don't let anyone sell it to you as a privacy feature. This is the same trust-gap problem I wrote about in Everyone's Selling AI Shovels. Nobody's Checking If Their Own Barn Is Locked., just pointed at your vendor instead of your own code.

Question 5: Will they put the data flow in writing?

Everything above collapses into one final test. Ask for the DPA, the AVV, plus a written data-flow that names the backend per model. Bedrock EU, Vertex EU, or Foundry, model by model.

Here is why this is the real filter. That backend-per-model map is almost never stated publicly. It lives nowhere on the marketing site. A vendor who will put it in writing is a vendor you can work with, because now the promise is yours to hand to a client and theirs to stand behind. A vendor who suddenly gets vague, who wants to "hop on a call" instead of emailing you a document, just answered the question. And the stakes moved this year. Since the second of August 2026, the EU AI Office can actually enforce the obligations on general-purpose AI providers, with fines reaching up to 3 percent of global turnover. "Trust us, it's compliant" is no longer a shrug. Once you repeat it to your own clients, it becomes your liability, not the vendor's.

The honest part

None of this means these tools are scams. Most of them are competent, and some of the German ones are genuinely good products I'd happily use. The problem was never the software. It's the gap between what the marketing says and what the stack does, and the person who eats that gap is you, the moment a client asks where their data actually goes and you realize you only know the slogan.

I don't have a villain for you here. Nobody in this story is lying, exactly. They're just letting a carefully true sentence do the work of a promise they never made. So ask the five questions, get the answers in writing, and then you can relax, because now you actually know what you bought.

If you'd rather have someone trace the stack for you before you sign, read the terms, pull the Handelsregister, map the backends, that's the kind of thing I do at wunderlandmedia.com. Better to know now than to explain it to a client later.