Claude, GPT or Mistral: the model matters less than where the request lands

Every procurement conversation we have in Germany reaches the same question in about the third meeting: can we use this model without a transfer problem? And it is almost always asked as a model question, Claude or GPT or Mistral, when it is really a deployment question.

The same model can be a straightforward EU processing arrangement or a Standard Contractual Clauses discussion, depending entirely on which endpoint you call. Pick the path first. The model choice is a normal quality and cost decision after that, and it is the easier one.

The distinction that decides everything

Vendors use “data residency” to mean two different things, and the gap between them is where compliance projects go wrong.

Storage residency means your data sits at rest in a region you chose. Conversations, files, logs.

Inference residency means the model itself runs there: that the prompt is processed on hardware in that region, not merely filed there afterwards.

A vendor can offer storage residency without inference residency, and several do. If your requirement reads “personal data is not processed outside the EEA,” a diagram showing a Frankfurt bucket will not survive a competent audit.

Ask the question in exactly these words: where is inference performed, and is that contractually committed? Get the answer in the DPA, not in an email.

OpenAI

Direct. OpenAI offers data residency configured per project, with Europe among the available regions, covering both the API and ChatGPT Enterprise. It is sales-gated rather than self-serve and is normally set when a project is created: retrofitting an existing one is the awkward case. API projects can be configured for in-region handling with zero data retention, meaning requests and responses are not stored at rest.

The nuance: the headline guarantee is about storage in the selected region. Where inference runs is a separate commitment. Confirm it explicitly.

Via Azure. The established route for guaranteed EU processing of GPT models is Azure OpenAI, deployed into an EU region: France Central and Sweden Central are the usual pair. You get Microsoft’s contractual framework, which most German enterprises already have signed, and that is frequently the deciding factor rather than any technical property.

Verdict: the shortest path if the company already lives in Azure. The direct API is fine too, but the residency conversation is a sales process rather than a checkbox.

Anthropic

Claude has no EU data residency through claude.ai or the direct Anthropic API. That is a clear statement rather than a criticism: it is simply the wrong endpoint for an EU-only requirement.

The right one is a cloud deployment. Claude models run on AWS Bedrock in EU regions including Frankfurt (eu-central-1), Ireland and Paris, and on Google Cloud Vertex AI in EU regions. Region-locked Bedrock in eu-central-1 keeps inference inside Germany, and you inherit the AWS agreements the company has probably already executed.

On the data-protection basics, the API and Claude for Work are DPA-eligible and exclude prompts from training by default. Used directly, EU-to-US transfer rests on Standard Contractual Clauses, workable for many companies, insufficient for anyone with a contractual EU-only processing obligation.

Verdict: excellent models, and the compliance answer is “run it on Bedrock in Frankfurt.” If someone tells you Claude cannot be used in Germany, they are describing the direct API and stopping there.

Mistral

Mistral is the only one of the three where the EU is the default rather than a configuration. The company is French, under EU jurisdiction, with native hosting in Paris, and it is also available through AWS Bedrock in Frankfurt, Azure AI and Vertex AI in EU regions.

The stronger card is open weights. Models including Mistral Small 4 and the Ministral family ship under Apache 2.0, which means on-premise or private-cloud deployment where the data never leaves infrastructure you control. That is a different category of answer from any residency clause, and for a company with a genuinely strict requirement it is the only one that ends the conversation.

Framework agreements with the French and German governments for public-sector deployment, running through 2030.

Relevant if you sell into that world, or are part of it

Verdict: the shortest compliance conversation of the three, and the only one that can end with “the weights are on our hardware.” Evaluate the frontier-model gap honestly against your actual task; for classification, extraction and routing it is frequently irrelevant, and those are most of the jobs inside a company.

How we actually decide

If the company runs on Azure: Azure OpenAI in an EU region. The contract exists, the security team knows the surface, and the project starts a month earlier than any alternative.

If the company runs on AWS: Claude on Bedrock, eu-central-1. Same reasoning.

If the requirement is EU-only processing with no transfer at all, or the data is genuinely sensitive: Mistral, self-hosted or on its EU endpoints.

If none of that is settled yet: run the evaluation on whatever is fastest to access, prove the task works, and treat the deployment path as a separate decision with the security team. Nothing is more wasteful than a three-week procurement conversation about a workflow that turns out not to work.

One more thing worth saying plainly: for most of the tasks inside a mid-sized company (classifying an email, extracting fields from a PDF, drafting a reply from your own answers) all three models are good enough, and have been for a while. The differences that show up in benchmark tables rarely show up in a triage queue. Spend the energy on the data the model gets to see. That is still where the quality comes from.

Frequently asked questions