Data residency used to be a procurement conversation. You signed a data processing agreement, the vendor named a region, and a clause asserted that your data stayed inside it. For analytical workloads that was largely sufficient. For generative AI it is not, because the data does not merely sit in a region, it moves through a model whose weights, operator, and legal nationality may all sit somewhere else, and the prompt you send to that model is itself the sensitive data. Residency has become an architecture problem, and the architecture has consequences that a contract clause cannot paper over.
European enterprises now face a genuine trade-off rather than a checkbox. The frontier models, measured on most capability benchmarks, are predominantly operated by US companies, and even when hosted in an EU region they remain subject to the legal reach of their parent jurisdiction. The in-region, EU-operated alternatives have closed much of the capability gap but not all of it. Choosing between them is a real decision with real costs on both sides, and pretending otherwise, in either direction, is how organisations end up either non-compliant or needlessly handicapped.
What sovereignty actually requires
It helps to separate three things that get bundled under 'sovereign AI'. The first is data residency: the personal data and the prompts physically remain on infrastructure inside the EEA. The second is operational sovereignty: the entity that can technically access the running system, including for support and maintenance, is itself EU-controlled, so that no foreign administrator can be compelled to hand over data. The third is jurisdictional sovereignty: the provider is not subject to extraterritorial laws, the US CLOUD Act being the one European data protection authorities cite most often, that could compel disclosure regardless of where the bytes sit.
GDPR governs the personal data flowing through these systems regardless of model choice, and Chapter V still governs any transfer outside the EEA, including the implicit transfer that occurs when a prompt containing personal data reaches a model operated under foreign control. Layered on top, the EU AI Act's obligations phase in through 2026 and 2027, and several member states add national rules for public sector and critical infrastructure, France's SecNumCloud qualification and Germany's BSI C5 being the most concrete. A US frontier model hosted in a Frankfurt region satisfies the first requirement and, depending on the contract and the operator, frequently not the second or third. Knowing which of the three you actually need is the whole decision.
The EU-hosted option and what it costs you
The practical sovereign architecture keeps both the data and the inference in-region. That means an EU-operated model, Mistral being the most prominent European frontier developer, or an open-weights model such as Llama or Qwen that you host yourself on EU infrastructure, behind a retrieval layer whose vector store and document corpus also never leave the region. Self-hosting open weights gives you the strongest sovereignty position, because nothing leaves machines you control, at the cost of running the inference infrastructure yourself, which is a real and recurring engineering commitment rather than a settled solved problem.
The trade-off you are accepting is capability and operating burden. On the hardest reasoning, coding, and long-context tasks the leading US frontier models retain an edge, and that edge is widest exactly where the work is most valuable. You are also taking on patching, scaling, and evaluation work that a managed frontier API absorbs for you. The honest framing for a board is not 'sovereign or not' but 'for which workloads is the sovereignty premium worth a measurable capability and operating cost, and for which is it not'. That question has different answers for different data classes, and answering it well is the actual work.
A workload-by-workload architecture
The mistake is treating this as one decision for the whole organisation. The right unit is the workload, segmented by data classification. Public and low-sensitivity content, marketing drafts, summaries of already-public documents, can use the strongest available model wherever it runs, because there is little to protect. Special-category personal data under Article 9, health and biometric records, and anything touching national critical infrastructure should default to the in-region, EU-operated path even at a capability cost, because the downside of a transfer finding is regulatory and reputational rather than merely commercial.
The interesting middle is where most real work sits, and it is where a hybrid architecture earns its complexity. Keep an EU-hosted model as the default for anything carrying personal data, and route the genuinely hard, low-sensitivity reasoning tasks to a frontier model under appropriate safeguards. This requires a routing layer that classifies each request by data sensitivity before it chooses a model, which is more engineering than a single endpoint, and it is the design that lets a European enterprise stay compliant without conceding the capability frontier on the work where capability actually pays. The classifier is the asset. Build it once, well, and the model market underneath it becomes a set of swappable choices rather than a single irreversible bet.