"Should we use Mistral, Bedrock or Anthropic?" is the wrong question, and it's the one we get most. It treats three different kinds of thing as if they were items on the same menu. Mistral is a model maker. Anthropic is also a model maker (the one behind Claude). AWS Bedrock isn't a model at all — it's a platform that resells dozens of models, Anthropic's and Mistral's included, behind one API and one bill.
So you're really making two decisions, and they're easier to get right when you stop pretending they're one. Which model is good enough for the task? And where does the inference run, and who can see the data on the way? For an EU client, the second question usually decides the first.
Decide where the data runs first
We pick data residency before we pick a model, because residency rules out options and model preference rarely does. Get this backwards and you fall in love with a model you can't legally deploy.
Three constraints, in order of how often they decide it for us:
- "Processing has to stay in the EU." Common for healthcare, finance, public sector and anyone with a nervous DPO. Rules out anything that can't guarantee an EU region.
- "The data cannot leave our infrastructure at all." Defence, some health and legal work, the occasional very cautious bank. Rules out every hosted API — you're now self-hosting open weights.
- "Keep it sensible and documented." The honest majority. No hard residency line, but they want a DPA, no training on their data, and a clean answer when their customers ask.
What each option actually gives you
Anthropic direct — best-in-class models, US-shaped plumbing
Going straight to Anthropic's API is the simplest integration and, for a lot of reasoning, coding and agentic work, the strongest models on the table. Anthropic doesn't train on API data, offers a DPA, cut its default retention to seven days, and will sign a zero-data-retention agreement with qualifying customers.
The catch for EU work: the direct API doesn't publish a dedicated EU-residency region. Its routing controls cover "US" and "global", and "global" can run inference in Europe but doesn't guarantee it. So if your client needs processing pinned to the EU, you don't drop Claude — you reach it through a platform that does pin the region. Which is exactly what Bedrock is for.
AWS Bedrock — the platform that buys you the region control
Bedrock's value isn't a model, it's optionality. One API, one set of credentials, one bill, and behind it Anthropic, Mistral, Amazon's own models, Cohere and more — including Claude. You can swap models without re-plumbing the app, and you inherit AWS's compliance posture.
For residency, Bedrock gives you three routing modes, and the difference matters:
- In-region — requests never leave the single AWS region you name (e.g. Frankfurt,
eu-central-1). Strictest, sometimes capacity-limited. - Geographic (EU) — routes only between EU regions to spread load; all destinations stay inside the EU. AWS states customer data isn't stored in destination regions during cross-region inference.
- Global — routes worldwide for throughput and price. Do not use this when residency is a requirement.
If your client already lives on AWS, this is usually our default: you get frontier models, EU region control and a single subprocessor story your DPO can actually read. The cost is AWS's pricing and a bit more setup than a raw API key.
Mistral — EU-native, and the only one you can fully self-host
Mistral is headquartered in France, falls natively under the GDPR, and stores data in the EU by default. Its commercial API (La Plateforme) ships with a DPA. The part nobody else matches: Mistral publishes genuine open-weight models you can run entirely on the client's own infrastructure — no external call, no API at all.
That makes Mistral two different answers depending on the constraint. For "stay in the EU", it's a hosted EU-native API. For "the data can't leave", it's the only realistic path to a fully self-hosted frontier-ish model on the client's servers. You trade some top-end capability and take on the ops burden of running it yourself — and that burden is real, so we only reach for it when the requirement genuinely demands it.
Residency rules out options. Model preference rarely does. So we let the rules pick the shortlist, then pick the best model left standing.
How we actually decide
Stripped to a flowchart, it's almost boring — which is the point. Boring decisions are the ones that survive a DPO review.
- Data can't leave the building? → Open weights, self-hosted. Mistral's open models, on the client's infra. Stop here.
- Processing must stay in the EU? → A hosted EU option. Bedrock with an in-region or EU-geo profile, or Mistral's EU API. Pick on model quality and on whose cloud the client already uses.
- No hard residency line, just sane and documented? → Whatever model wins the benchmark, with a DPA and no-training terms. Often Claude via Bedrock or direct; sometimes Mistral; occasionally a mix, routed per task.
And one rule under all three: we benchmark on the client's own data before we commit. "European" is a procurement argument, not an accuracy one. The model that reads their contracts, tickets or records best wins — inside whatever residency box the rules drew.
The part clients forget: lock-in and exit
A model stack is a dependency, and dependencies should have an exit. We keep the model behind a thin internal interface so swapping providers is a config change, not a rewrite — the same discipline that lets Bedrock customers move between models pays off the day a price, a benchmark or a board decision changes the answer. Going direct to one vendor is faster on day one and costs you that flexibility on day four hundred. We weigh that out loud, with the client, instead of discovering it later.
FAQ
Is Mistral always the right pick because it's European?
No. Mistral's EU headquarters and data residency are a real advantage when sovereignty or self-hosting is the requirement, but model quality still has to clear the bar for the task. We benchmark on the client's own data, not on a flag.
Can I just use Anthropic's direct API for an EU client?
You can, and for many products it's fine — Anthropic doesn't train on API data and offers a DPA and zero-data-retention for qualifying customers. But the direct API doesn't publish a dedicated EU-residency region. If inference has to stay inside the EU, reach the same models through AWS Bedrock's EU regions or Google's Vertex AI instead.
Does AWS Bedrock keep my data in Europe?
It can. Bedrock offers in-region routing that never leaves the region you pick, and EU cross-region inference profiles that route only between EU regions. Customer data isn't stored in destination regions during cross-region inference. You have to choose the EU profile deliberately — the global endpoint does not guarantee it.
What if the client says the data literally cannot leave their building?
Then it's open weights on their own infrastructure — Mistral's open models are the usual answer, self-hosted on the client's servers or private cloud. You trade some model quality and a lot of ops work for total control. We only go there when the requirement genuinely demands it.
Does the model choice change our AI Act obligations?
The GPAI obligations sit with the model provider regardless of which one you pick. Your transparency duties and GDPR obligations attach to the product you ship. The stack changes where data flows and who your subprocessors are — both of which your client's DPO will ask about.
Sources: AWS, cross-region inference for EU data processing · Amazon Bedrock docs, cross-region inference · Anthropic, Claude in Amazon Bedrock · Mistral AI, La Plateforme. We're engineers, not your legal counsel — for residency sign-off, loop in your client's DPO and lawyers.
Stuck between a model your client loves and a rule that won't let them deploy it? Plan a call — we'll pick the stack with you, white-label.
