Suppose a European company wants to build an agent that can qualify customers, access CRM data, prepare an offer and eventually execute parts of the sales process.
Should it use a European LLM? Run on a European cloud? Avoid US technology altogether?
There is no single answer.
A company can run a European model on American infrastructure. It can use American cloud technology operated by a European entity. It can run an open model in its own environment while relying on non-European chips. Or it can use a US frontier model while keeping its proprietary data, agent logic and business processes under its own control.
All can reasonably be described as more or less sovereign.
That is why I think we need to stop treating AI sovereignty as a binary vendor choice.
Sovereignty is the deliberate management of dependency across the AI stack.
The relevant management question becomes: which dependencies are we prepared to accept, what risks do they create, and where would losing control materially constrain the business?
Sovereignty has layers
The European Commission has started approaching cloud sovereignty in a similarly layered way. Its 2026 Cloud Sovereignty Framework evaluates providers against 48 criteria across eight areas, including legal and jurisdictional sovereignty, data and AI, operations, supply chain and technological sovereignty.
It distinguishes between data sovereignty, technological autonomy and ultimately full sovereignty.
That distinction matters for AI because an agentic architecture contains several layers with very different dependencies.
I currently look at six:
Compute → Cloud & infrastructure → Foundation models → Data & intelligence → Agent orchestration → Application & process
Governance and control sit across all six.
The closer we get to proprietary intelligence and actual business execution, the more cautious I would become about giving up control.
Europe is building alternatives across the stack
At the bottom of the stack, Europe is investing heavily in compute.
EuroHPC is implementing 19 AI Factories across Europe, supported by 13 AI Factory Antennas. In July 2026 it also launched the procurement process for much larger AI Gigafactories, intended to provide large-scale European capacity for model training and inference.
This is meaningful infrastructure. But it also demonstrates why sovereignty is not binary. European compute facilities can still depend on non-European accelerators, networking technology and software.
Full hardware sovereignty would therefore be an extraordinarily high bar.
Move one layer higher and the choices become more tangible.
European cloud providers such as OVHcloud and Scaleway offer infrastructure under European ownership and control. But another category has emerged between European cloud and the traditional hyperscaler.
S3NS, for example, combines Google Cloud technology with a French legal entity, French operations and French infrastructure. AWS now operates a separate European Sovereign Cloud. Microsoft has expanded its own sovereign cloud options.
These architectures can substantially increase European operational and data control without eliminating the underlying technological or corporate dependency.
That distinction is important.
European data residency is not the same as European operational control. And European operational control is not the same as technological independence.
The model layer is becoming a real European choice
The model layer is perhaps where the change is most visible.
Mistral has developed from a French model company into a broader European AI infrastructure player, offering commercial and open models, regional inference and increasingly its own European compute strategy.
Switzerland offers a different approach.
Apertus 1.5, developed by ETH Zurich, EPFL and the Swiss National Supercomputing Centre, is designed as a fully open model. Its model, code and development process are available for inspection and adaptation. Its developers explicitly position it as infrastructure for sovereign AI rather than simply another commercial chatbot.
Other European initiatives are emerging as well. EuroLLM focuses heavily on European languages. OpenEuroLLM aims to create a family of transparent European foundation models, with more substantial releases planned over the coming years.
These initiatives should not all be treated as equivalent to today's frontier commercial models. They differ considerably in maturity, capability and intended use.
But they change the strategic choice.
European organisations increasingly have the option to decide where frontier performance matters enough to accept external dependency and where transparency, deployment control or model ownership matters more.
I would not optimise for a fully European stack
There is a danger of taking sovereignty too far.
For many commercial organisations, insisting that every processor, cloud service, model and software component must be European would be expensive and could restrict access to better technology.
A US frontier model may simply perform materially better for a particular task.
Using it can be a perfectly rational decision.
But the dependency is not free.
A non-European provider can create additional questions around international data transfers, jurisdiction, provider access, data retention, auditability, continuity and exit.
For transfers of personal data to the United States, for example, the EU-US Data Privacy Framework provides an adequacy mechanism for participating US organisations. Other transfer mechanisms can apply in other circumstances.
The US CLOUD Act introduces a different consideration. It establishes that companies subject to US jurisdiction can, under valid legal process, be required to produce data within their custody or control regardless of where that data is stored.
That does not mean US cloud services are automatically incompatible with GDPR.
It does mean that server location alone does not answer the sovereignty question.
This is why compliance and sovereignty should not be confused.
A European AI service can be badly governed and non-compliant. A US service can be deployed compliantly in Europe. The AI Act similarly imposes obligations according to the role and use of AI, not the nationality of the technology provider. General-purpose AI provider obligations have applied since August 2025, with the Commission's enforcement powers applying since August 2026.
Sovereignty can make some risks easier to control. It does not replace compliance.
The most valuable layers may not be the models
There is another reason I would resist making the LLM the centre of an enterprise sovereignty strategy.
Consider what happens when an organisation builds serious agents.
The model provides reasoning capability. But around that model the organisation gradually builds something much more specific:
customer and product context;
retrieval and proprietary knowledge;
agent memory;
system instructions;
tool definitions;
permissions;
workflow logic;
human approval points;
evaluation sets;
escalation rules;
and connections into operational systems.
That collection increasingly describes how the company works.
European technology is developing here as well. Germany's deepset/Haystack provides model-agnostic agent and retrieval infrastructure. n8n offers self-hosted workflow and agent orchestration. European vector and retrieval technologies such as Qdrant and Weaviate allow organisations to keep important parts of their context architecture portable.
European governance companies including Saidot, LatticeFlow AI and Giskard are developing controls for AI systems and agents, while Langfuse provides self-hostable tracing and evaluation.
The individual products will change. The architectural principle is more durable:
Keep proprietary intelligence more portable than the model that reasons over it.
An organisation could then use Mistral for one workload, a US frontier model where its performance creates enough value, and perhaps Apertus or another open model for a highly controlled workload.
Changing the model should not require rebuilding the company's intelligence and operating model.
Dependency creates work
This also changes the economics of technology selection.
When we choose an external technology, we usually compare functionality, performance, implementation effort and price.
But dependency creates continuing work.
A non-European model or cloud provider may require additional privacy assessments, contractual safeguards, security controls, data classification, monitoring, model evaluation, architecture work and exit planning.
A proprietary agent platform may make implementation faster but make workflows, memory and business logic harder to move later.
Conversely, self-hosting an open European model creates its own costs. Someone has to operate it, secure it, evaluate it and keep it performing.
So there are costs on both sides.
I would therefore add four less visible dimensions to major AI architecture decisions:
Compliance burden. Control burden. Exit burden. Capability burden.
They do not automatically make an external dependency unattractive. A global technology provider may create so much additional value that these costs are easily justified.
But they belong in the decision.
Decide sovereignty per layer
This leads me to a relatively simple approach.
For every important layer of the AI architecture, ask:
- What are we actually putting here?
Commodity compute is different from customer memory or proprietary decision logic. - What dependency are we accepting?
Technology, jurisdiction, operations, knowledge or all four? - What happens if that dependency becomes unacceptable?
Could we realistically change provider, or only contractually? - What continuing work is required to control it?
Security, privacy, evaluation, governance and operational resilience all consume capacity. - Which capability must remain ours?
Outsourcing technology should not accidentally mean outsourcing the ability to understand and change the operating model.
The answer will differ by layer.
I would generally accept considerably more global dependency in compute and foundation models than in proprietary data, agent permissions, business logic and process execution.
That is not a universal architecture rule. A bank, defence organisation and mid-sized B2B manufacturer will rationally draw the boundaries differently.
But that is exactly the point.
Sovereignty should be designed, not declared.
The objective is not to make every component European. It is to remain in meaningful control of the parts of the architecture that the organisation cannot afford to lose.
Use global technology where its advantage justifies the dependency. Use European or internally controlled alternatives where jurisdiction, proprietary intelligence, operational freedom or continuity make control more valuable.
And for every dependency you accept, understand what keeping it under control will continue to cost.