Most tutorials for building a support agent start with an OpenAI key and a vector store on someone else's cloud. I build these sovereign AI support agents for French online shops, and for a lot of them that starting point is a non-starter: the customer data has to stay in the EU, on infrastructure they can point to, running a model whose weights they can keep. This post is about the parts of the build that change once "stay in the EU" is a hard requirement instead of a nice-to-have.
I run one dedicated instance per merchant, self-hosted in France, on an open-weight French model (Mistral). None of that is exotic anymore. What is less obvious is which engineering decisions get harder and which ones get easier once you commit to it.
Before writing a single prompt I draw where each piece of data physically goes. For a support turn there are usually four hops: the customer message, the retrieval query against the shop's knowledge base, the model call, and any tool call that touches the order system. With a hosted US model, hops one, two and three leave the EU by default, and hop four often does too if the order data sits in a foreign helpdesk SaaS.
Keeping it in the EU means every hop has a named home. The model runs on a box in a French datacenter. The knowledge base and its embeddings live next to it. The order lookups go straight to the merchant's own store API (Shopify, WooCommerce) over a server-to-server call, not through a third party. The map is boring to draw and it is the single most useful artifact in the whole project, because it is what a merchant shows their DPO and what you check every new feature against. We keep the GDPR groundwork for an automated support desk in one place for exactly this reason.
The honest trade-off is model quality. An open-weight model you can host in France will not top the same leaderboards as the largest hosted models. For open-ended reasoning that gap is real.
Support is not open-ended reasoning. A support turn is a narrow task: understand one customer intent, pull the right fact from a known knowledge base, then answer or hand off. Once the task is scoped that tightly, the model spends its budget on wording and intent detection rather than on world knowledge. That is exactly where a mid-size open model is strong enough. The heavy lifting moves out of the model and into retrieval and tool design, which you control and can test.
If the model does not carry the shop's facts, retrieval has to. Hosting retrieval in the EU is easy. Making it good enough that a smaller model can lean on it is the actual work. Two things earned their keep here. First, the knowledge base is curated per merchant, not scraped: return policy, shipping zones, sizing, restock rules, each as a short passage with a source. Second, retrieval returns the passage and its source id, and the agent is only allowed to state facts that came back with a source. A smaller model plus tight retrieval beats a bigger model plus loose retrieval for this job, and it keeps every claim traceable to a document the merchant actually wrote. This is the same discipline that lets a French e-commerce support tool answer with facts instead of guesses.
The part teams forget: your logs are customer data too. A support transcript is full of names, addresses, order numbers. Ship those to a hosted observability tool outside the EU and you just undid the data map.
So logging stays in the EU with the rest, transcripts get a retention window instead of living forever, and anything used to improve the system gets stripped of direct identifiers first. Under the GDPR the transcript is processing like any other, so it belongs on a GDPR checklist for an automated support desk next to retention and access. And "we sent it to a US logging SaaS for debugging" is a transfer you now have to justify, which is why the data processing clauses for an AI support vendor are worth pinning down before launch, not after.
Article 50 of the EU AI Act requires that a person is told when they are interacting with an AI system, unless it is already obvious. For a support agent that is a one-line disclosure at the start of the conversation and a clean path to a human. It costs nothing to implement and it removes a whole category of argument later. We put the disclosure in the first message and make escalation to a human a first-class action the agent can take, not a fallback it stumbles into.
Working inside "stay in the EU" is more upfront design: the data map, curated retrieval, EU-hosted logging, one instance per merchant instead of one shared model behind an API. What it buys is a system a merchant can explain to their customers and their DPO without hand-waving, running on a model they are not renting by the token from a provider that can change terms next quarter. For an online shop answering real customers, before the sale and after it, that turns out to be worth the extra design.
I'm Amine, founder of Bynevo Labs. We build sovereign AI support agents for French e-commerce, answering customer questions before the sale and after it, hosted in France on an open-source stack. Happy to talk architecture in the comments.