The Problem Is Not Capability
The debate over European AI often begins in the wrong place. It starts with benchmarks, parameter counts, and the gap between what Mistral can do and what GPT-4 can do. This framing is a trap. It assumes the primary constraint is capability, that Europe is simply behind, and that sovereignty is a handicap to be overcome once we catch up.
The real constraint is jurisdiction.
Modern AI is no longer just models. It is supply chains, control planes, update paths, and legal exposure. It is the question of who can compel disclosure, who can modify weights silently, who controls the keys to your fine-tuned checkpoints, and who decides whether your inference logs become evidence in a foreign court. When you call an American API, you are not merely renting compute. You are subjecting your data, your users, and your organisation to a legal regime you do not control and cannot predict.
I want to start from a red line: no American clouds, no US-controlled APIs, no vendors subject to CLOUD Act reach-through, and no opaque managed services that could silently shift data or weights. Everything must either be European by governance or fully self-hosted on European soil with auditable control.
The question is not whether Europe can build AI platforms under these constraints. It plainly can. The question is what kind of AI platforms these constraints produce. And whether they might, paradoxically, be better.
A Spectrum of Sovereignty
Sovereignty is not binary. It exists along a spectrum, and understanding that spectrum is essential for making pragmatic decisions about what to build and how to build it.
Pragmatic Sovereignty
At one end sits what I’d call pragmatic sovereignty: open models trained elsewhere but redistributed under permissive licences, hosted entirely in Europe, weights frozen, inference local, no upstream calls.
This is where LLaMA-derived models live. It is where Qwen and other Chinese-origin models can be deployed. It is where older checkpoints (Falcon, BLOOM, and the long tail of Hugging Face) find their utility. The weights were trained on American or Chinese infrastructure, but they are now artefacts. Static, auditable, downloadable. They can be pulled into European data centres, run on European hardware, and served without any call home.
The sovereignty here is legalistic rather than philosophical. You control the deployment, but you did not control the training. You can inspect the weights, but you cannot know what biases were encoded by a dataset you never saw. You have operational independence, but not provenance.
For many use cases, this is enough. A frozen model running in Frankfurt, fine-tuned on proprietary data, serving inference to European users, and logging nothing to external systems is functionally sovereign. It may have been born elsewhere, but it lives and dies under European law.
Operational Sovereignty
Move along the spectrum and the focus shifts from model origin to system architecture. Operational sovereignty asks: even if the base model came from elsewhere, is every layer of the stack under European control?
This means European cloud providers: OVH, Scaleway, Hetzner, or sovereign infrastructure from national providers. It means European data centres, with physical security subject to European law. It means European key management, your encryption keys held by European HSMs, never exported, never accessible to foreign subpoena. It means European observability, logs, metrics, and traces flowing to systems that cannot be compelled to disclose by non-European authorities.
Under operational sovereignty, the model is one component among many. It might be LLaMA, it might be Mistral, it might be a Chinese model you downloaded and never update. What matters is that training, fine-tuning, serving, and monitoring are fully controlled. The platform is modular. Any component can be swapped the moment a risk is identified. No single vendor has lock-in. No upstream dependency can introduce silent changes.
This is sovereignty as systems engineering. The guarantee is not purity of origin but integrity of operation.
Strict Sovereignty
At the far end of the spectrum lies strict sovereignty. European-founded model labs. European training runs on European compute. European datasets, curated under European data protection law. European governance, with no foreign investors holding blocking stakes or board seats.
This is where Mistral sits today. It is where Aleph Alpha has positioned itself in Germany, where academic efforts like BLOOM attempted to operate, where national AI labs in France, Germany, and the Nordic countries are beginning to invest.
The trade-off is explicit. At the frontier, strict sovereignty means slightly less breadth. If OpenAI or Anthropic releases a capability breakthrough tomorrow, the strictly sovereign platform cannot simply adopt it. It must wait for the European system to catch up, or accept that some capabilities will remain out of reach.
But strict sovereignty offers guarantees that the other modes cannot. Full auditability of training data. Clear alignment with GDPR, the AI Act, and whatever regulatory frameworks emerge next. No risk that a foreign government will classify your model lab as a strategic asset and restrict its outputs. Long-term stability that does not depend on the political relationship between Brussels and Washington.
For applications where trust is the product (healthcare, legal, government, critical infrastructure) strict sovereignty may not be a constraint at all. It may be a requirement.
The Uncomfortable Layer: OSS Tooling
The sovereignty spectrum above is tidier than reality. I’ve described models as artefacts that can be “pulled into European data centres, run on European hardware.” But I’ve glossed over what runs them.
The entire AI software stack sits on American-maintained open source:
- PyTorch (Meta)
- TensorFlow / JAX (Google)
- CUDA / cuDNN (NVIDIA, and not even open source, just proprietary)
- Transformers, Accelerate, PEFT (Hugging Face, French-founded but now heavily US-VC backed)
This creates an awkward middle category that doesn’t fit cleanly into the sovereignty spectrum.
At the pragmatic level, you’re not just using “frozen weights.” You’re using constantly-updated frameworks. Do you freeze PyTorch at a specific version? Then you miss security patches. Do you update? Then you’re trusting American maintainers with every commit.
At the operational level, I talked about European HSMs and European observability. But what about European ML frameworks? Forking PyTorch is theoretically possible but practically a massive maintenance burden. Nobody’s doing it.
At the strict level, the logic breaks down entirely. Mistral can train on European compute with European data. But they’re still using PyTorch. The “European-founded model lab” remains dependent on American tooling.
Open Source Is Both Gift and Trap
Open source provides auditability in theory. In practice, nobody audits every PyTorch commit. The XZ Utils backdoor in 2024 showed how sophisticated supply chain attacks can be: a patient, multi-year social engineering campaign that nearly compromised SSH on most Linux distributions. The attacker gained maintainer trust, then introduced obfuscated malicious code. It was caught by accident, by one engineer noticing a half-second latency regression.
PyTorch has far more contributors, far more complexity, and far more surface area than XZ Utils. The odds that every commit is benign are… optimistic.
The Inference/Training Split
There may be a partial escape hatch. Inference can run on lighter-weight, more auditable runtimes: ONNX, llama.cpp, vLLM with careful dependency management. These are smaller codebases. Auditing them is at least conceivable.
Training at scale is a different story. Training a frontier model basically requires the American toolchain. There is no European alternative to PyTorch that operates at that scale. If you want strict sovereignty all the way down to the framework layer, you either accept a massive engineering burden or you accept that training happens on American tooling.
This is uncomfortable. But it’s honest.
Hardware Lock-in Compounds Everything
The software sovereignty question cannot be separated from the hardware question. CUDA is proprietary. Even ROCm (AMD’s alternative) is American. The European chip efforts (SiPearl, various national initiatives) are years from production ML workloads.
So the practical situation is this: even a “strictly sovereign” European AI platform runs American frameworks on American silicon. The sovereignty exists at the data layer, the policy layer, the control layer. But the execution layer remains dependent.
I don’t have a clean answer to this. The best I can offer is honesty about where the sovereignty actually lives and where it doesn’t. Models can be commoditised and swapped. Frameworks are harder. Hardware is hardest of all.
The Platform Is Not the Model
This is where the analysis needs to shift. Under sovereignty constraints, the interesting engineering happens not inside the model but around it.
A modern AI platform is an orchestrated system. It includes model routing: deciding which of several models handles which request, based on cost, capability, latency, or policy. It includes policy-aware inference, rules that govern what data can flow to which model, what outputs must be filtered, what requests must be logged or refused. It includes fine-tuning pipelines, infrastructure for adapting base models to specific domains without exposing training data to external systems. It includes vector search and retrieval, the RAG architectures that turn generic models into specialists by grounding them in proprietary knowledge. It includes evaluation, continuous measurement of model quality, drift, and alignment with organisational standards. It includes human-in-the-loop feedback, mechanisms for users to correct, approve, or reject model outputs, feeding back into fine-tuning and policy.
All of this lives inside your perimeter. Under sovereignty constraints, none of it can depend on external APIs that might change terms, raise prices, or become legally inaccessible.
The valuable bit, in this architecture, is not the model. The model is a commodity. Powerful, yes, but interchangeable. The valuable bit is the control layer that decides when, how, and why a model is used. It is the retrieval system that knows which documents matter. It is the policy engine that ensures compliance. It is the evaluation framework that measures whether the system is actually working.
American AI giants compete on model capability because they can. European AI platforms must compete on system integration, because that is where sovereignty lives.
Data as the Real Moat
The deepest advantage of a sovereignty-constrained platform is also its most counterintuitive: the data cannot leave.
When your data must stay in Europe, when it cannot be sent to American APIs for training or inference, you are forced to build systems that make the most of local data. Retrieval stays local. Embeddings are generated in-region. Logs are minimised. Evaluation datasets never leave the boundary.
This constraint forces a particular architecture. Instead of relying on ever-larger foundation models to have memorised everything, you build retrieval systems that inject proprietary knowledge at inference time. Instead of fine-tuning on the vendor’s cloud, you fine-tune locally, keeping the resulting weights under your control. Instead of trusting the general model’s judgment, you build evaluation pipelines that measure performance on your specific distribution.
The result is that a weaker general model becomes a stronger domain system. A 7B parameter model with excellent retrieval over your internal knowledge base can outperform a 70B parameter model that has never seen your data. A locally fine-tuned model, adapted to your terminology and your users’ patterns, can be more useful than a frontier model that treats your domain as a tiny slice of its training distribution.
This is the counterintuitive promise of sovereignty: by constraining where data can go, you force architectures that use data better.
What Kind of AI Does Europe Want to Build?
The question that frames this entire discussion is not “can Europe build AI without America?” The answer to that question is obviously yes. Europe can host models, run inference, fine-tune, build applications. The technology exists. The engineering talent exists. The capital, increasingly, exists.
The real question is: what kind of AI does Europe want to build?
One answer is: AI that competes on American terms. Raw benchmark dominance, largest models, most parameters, highest scores on standardised evaluations. This path requires massive compute investment, aggressive data acquisition, and a willingness to operate at the same ethical and legal boundaries as American and Chinese competitors. It is possible. But it is not clear that Europe will win this race, or that winning it would serve European interests.
Another answer is: AI that competes on European terms. Systems optimised for trust, resilience, and long-term autonomy. Platforms where sovereignty is not a constraint but a feature. Architectures designed from the ground up for auditability, for compliance, for integration with proprietary data that cannot leave European soil.
This is the framing that makes the sovereignty constraint productive rather than limiting. Sovereignty is not a handicap to be overcome. It is an architectural discipline that forces better systems.
The organisation that builds under sovereignty constraints learns to decouple model capability from system capability. It learns to treat models as commodities and invest in the control layers that make models useful. It learns to build retrieval systems that multiply the value of proprietary data. It learns to operate without dependencies that could be revoked, modified, or subpoenaed.
These are not just regulatory accommodations. They are good engineering practices that produce more auditable, more controllable systems. The sovereignty constraint, fully embraced, produces platforms that are better prepared for a future where AI regulation tightens everywhere, where supply chains become more contested, and where the organisations that control their own infrastructure have advantages that those dependent on foreign APIs do not.
Conclusion
The path forward for European AI is not to pretend that American services do not exist, or to hope that European alternatives will reach parity next quarter. It is to recognise that the constraint is real, that it is unlikely to relax, and that building under the constraint produces systems with distinct advantages.
Pragmatic sovereignty gets you started. Operational sovereignty gets you control. Strict sovereignty gets you guarantees. All three have their place, and the choice among them depends on your threat model, your regulatory environment, and your tolerance for trade-offs.
But I should be honest about the limits. The OSS tooling layer, the framework dependencies, the hardware lock-in: these represent genuine gaps in the sovereignty story. You can control your data, your policies, your infrastructure. You cannot, today, control the full stack down to silicon. Pretending otherwise would be dishonest.
What you can do is understand where sovereignty actually lives and invest there. The model is not the platform. The platform is not the model. The organisations that understand this, that build the orchestration, the policy layers, the retrieval systems, the evaluation frameworks, the data flywheels, will be the ones that thrive under sovereignty constraints.
And perhaps, over time, the tooling gap will close. European chip initiatives may mature. Auditable inference runtimes may become standard. The dependency on American frameworks may become manageable rather than total.
But that’s a bet on the future. The architecture you can build today is still valuable. Sovereignty is not a limitation. It is an architecture. And it may be the architecture that matters most.