Mastery, not Ownership — Where AI Sovereignty Actually Takes Shape in 2026

Sovereignty doesn't belong in a strategy paper. It belongs in the stack.

In 2026, AI sovereignty emerges not from ownership but from mastery of critical stack layers. Data, inference, post-training, evaluation, compliance/audit, and operations are the six axes that decide how sovereign an organisation actually operates in 2027. The European reflex of 2024 — "We need our own ChatGPT" — framed sovereignty as a question of ownership. By 2026, the question has matured: which layer do we keep, which do we delegate deliberately? Without that differentiation, sovereignty stays in the strategy paper, not in the stack.

At a Glance

• Sovereignty in 2026 is a question of mastery, not of ownership: which layers of the AI stack a company controls itself determines how sovereign it really is in practice.
• Six stack layers are the decision axes in 2026: data/residency, inference, post-training, evaluation, compliance/audit, and operations. Each can be kept in-house, delegated, or run hybrid — but not ignored.
• The boardroom dichotomy — "proprietary = enterprise-ready, open source = hobby project" — no longer holds in 2026. Open-source software dominates the cloud — often wrapped as SaaS. Open-weight stacks run in production in regulated industries — given a correctly sorted layer architecture.
• What stalls sovereignty is rarely the software or the model: procurement reflexes on "vendor with SLA", skill gaps or the outsourcing of responsibility, the persistent security myth, the unanswered day-one plan.

Open Source Is Not a Business Model — It's a Question of Control

Yann Lechelle, Executive President & Chairman of probabl and former CEO of Scaleway, put the decisive sentence on record:

"Open source is not a business model. It's a distribution, it's a community, it's a federation, it's a governance concept, it's a marketing asset."

In decision-making language: you are not buying free software. You are deciding where control and adaptability matter for your business — and where an external partner runs the layer more cheaply and cleanly than you can. The question is no longer "open or closed?" — it is: which layer of the stack do we keep, and which do we delegate deliberately?

Ines Montani (spaCy) put the related boardroom myth to rest:

"People use open source not because it's free, I think that's one of these misconceptions, but because it's flexible, it's extensible, you can program with it. Composable."

Companies use open stacks in 2026 not to save money but because it is the only way to retain control of the layers above the base model. The cost calculation no longer backs the old picture either: are the total costs of training, support, and customisation for proprietary software really lower than investing in your own skills? Rarely — and the comparison overlooks what an open stack adds on the other side of the ledger: control over data, inference, eval, and roadmap.

A consequence of this: running open-weight models on an open-source stack in 2026 isn't ideology — it is architectural logic. Pick open weights, then layer proprietary orchestration underneath, and you hand back part of the control you just gained — the audit chain breaks where inspectability ends.

Europe as an ecosystem is often invisible: the maintainers of critical open-source libraries sit in the EU. Three OSS titans without which no enterprise stack runs — scikit-learn, spaCy, Jupyter — come straight from this ecosystem: probabl carries scikit-learn, the spaCy team works out of Berlin, QuantStack maintains Jupyter. By 2026 these actors plus Mistral and many others are a credible service market too. Not a replacement for US Big Tech, but a different infrastructure architecture — one already in production.

Six layers make the question concrete.

The Six Stack Layers — Keep or Delegate?

1. Data / Residency

Which data may leave your control perimeter? Local models for sensitive workloads — confidential tickets, code repositories, contract drafts — stay on your own infrastructure. External APIs for non-sensitive paths reduce operating overhead without giving up the core. The maturity of the local stack in 2026 covers internal knowledge bases, coding assistance on confidential code, classification in regulated pipelines, document-grounded Q&A — not frontier-grade, but sufficient, and without data flowing to US servers.

2. Inference

Where does the model request run, and who sees the logs? Your own inference infrastructure for sensitive paths is practically achievable in 2026 with locally runnable open-weight models. Runtime audit logs stay in-house. With an external API, this layer stays with the vendor, even if it is now contractually fenced. Hybrid operation is the rule: local for sensitive, API for scalable.

3. Post-Training

Where does differentiation come from? This layer is hard to delegate — because the business itself lives here. Cursor's Composer 2 is the case study, covered in depth in the Stop Waiting, Start Shipping piece in this series: at its core Kimi 2.5 with additional reinforcement learning on top, publicly confirmed by Cursor co-founder Aman Sanger in March 2026. Composer 2 illustrates the pragmatic approach in miniature: building value on the shoulders of giants beats every reflex to roll your own base model. Value is created not by the choice of base model, but by proprietary data, evals, harness, and product discipline.

Ines Montani put the economic logic behind it on record:

"It's like software 2.0. You have code and data, and a lot of the value is in the data. So we can provide the code basically for free and open source and then focus our product offering on the other part that's more custom."

The base model is the shared code layer. Your own data and the post-training on top of it are the layer where differentiation arises. Anyone delegating it is delegating their business.

4. Evaluation

How do you measure model behaviour — in-house? Eval discipline, your own eval suite, and a harness under your own control are the layers in 2026 where domain-specific quality becomes visible and a wrong model choice surfaces early. Without eval discipline, every sovereignty claim stays an assertion and every model migration a gut call. Cheap to build, expensive to neglect.

5. Compliance / Audit

Can we inspect the model when the regulator asks? Sylvain Corlay (QuantStack, Jupyter) put the argument in its most fundamental form:

"Anyone who's done science at some point in their life understands that there would be a huge contradiction in trying to understand the world like physics or biology or anything with a tool that you don't have the right to understand or look into."
"The core of the logic and of the intelligence will have to be open source. Otherwise, nobody is going to buy it. And that's a big part of the trust that people have in the software. It's that it's been audited by experts."

Banking supervisors, insurance regulators, and internal audit functions follow the same logic. Corlay's second sentence is the commercial consequence of the first — and the stronger argument in the boardroom.

What open weights deliver: model weights, your own inference, runtime audit logs, control over data flows. What doesn't come automatically: full training-data auditability. With Qwen, DeepSeek, Kimi as with Llama, Gemma, Mistral, training-data provenance is rarely fully documented. Anyone building a compliance argument on provenance has to make the open-weight / open-data separation explicit.

Proprietary enterprise providers are no longer pure black boxes: OpenAI Enterprise, Anthropic Claude for Work, and Azure OpenAI offer data residency, zero-retention, BAAs, and inference-level audit logs. What remains: no model weights in your hands, no training-data control, no direct access to model behaviour. Sufficient for many use cases — not for model inspection or in-house post-training as part of the compliance argument.

6. Operations

What do we do on day one if a central provider falls away? QuantStack has answered the question operationally: migration of all services to European providers, a "contingency forge" as a GitHub mirror so the team can keep working the next day if the main access drops. Sylvain Corlay calls this economic survivalism.

"We've migrated all of our services to European providers … we even have a contingency forge with pretty much everything we touch on GitHub mirrored so that we have something to do the next day, if we are shut down, basically."

Translated to enterprise stacks: service partners instead of vendor licences, documented backup paths, a day-one answer that sits in the boardroom — before it is needed. That capability alone is leverage at the negotiating table. This layer decides whether the architecture still holds in 2027 or breaks at a single vendor decision.

An Honest Reading of Model Choice

The model choice matters — but it is not what matters most. What matters is control of the layers above it: data, eval, harness, post-training. More on this in the Stop Waiting, Start Shipping piece in this series.

The Organisational Blockers

What stalls sovereignty is rarely the model — it is organisational blockers. Four are the most stubborn in 2026.

Procurement Reflex on "Vendor with SLA"

Procurement teams are conditioned to "vendor with SLA". An open stack needs a different contract model: service provider, engineering advisory, internal responsibility. Programmes that fail to reframe procurement early do not fail at the model — they fail at the contract template.

Ines Montani delivered a warning that belongs in every procurement discussion:

"You adopt a project and then the startup behind the project goes and raises a lot of money, and they pivot here, they pivot there, and in the end the open source is kind of collateral."

VC funding is not proof of stability. Stability sits in governance.

My own point on this: open-source licences are typically irrevocable. After a pivot or insolvency on the vendor side, the right to use, fork, and develop the software remains — a structural safeguard no vendor contract delivers.

Skill Gap: Operations, Training, OSS Composition

The skill bottleneck in 2026 rarely sits with the ML PhD. It sits in three mutually dependent disciplines: operations (local inference stacks, audit logs, documented migration paths, the day-one plan), training (post-training, continued pre-training on your own corpus, eval suite, harness discipline), and OSS composition — the often overlooked key discipline of selecting, integrating, and maintaining the open components into a coherent architecture.

Without these three disciplines — in-house or at a service partner — no layer programme runs. The thesis "domain expert with appetite for experimentation before ML PhD" still holds, but does not suffice on its own. Anyone delivering sovereignty in earnest needs a bridge between internal engineering substance and external advisory.

The Open-Source Security Myth

The notion that open source is less secure than proprietary is empirically hard to support. The code is open, and therefore auditable. Proprietary code typically isn't — what happens at the vendor stays at the vendor. On the security question, the point goes to open source: more eyes watch the code than at any single vendor, CVE processes are transparent, the patch path is in the open.

Security doesn't end there. It also depends on technically enforceable guardrails — tool permissions, filesystem access, API keys. With an open stack, you can inspect that layer yourself. With a black-box API, you depend on trust in the vendor.

The Unanswered Day-One Plan

What do we do on day one if AWS, Azure, or a central service provider suspends our accounts? Most enterprise stacks have no rehearsed answer in 2026 — not from technical impossibility, but from the assumption it won't happen to us. Sovereignty that lets this assumption stand is theatre, not architecture.

For Decision-Makers, This Means

First: Take a Sovereignty Inventory Along the Layers

Which workloads must run locally, which may go into the cloud? Which layer do we keep, which do we delegate to a service partner? This inventory is the foundation of any sovereignty architecture — and in 2026 a concrete working document, not a strategy paper.

Second: Reframe Procurement

Don't search for a "vendor licence" — search for a "service partner for the open stack". A different contract logic, more shared engineering responsibility — and an explicit examination of the partner's governance, not just its SLA logo.

Third: Build a Use-Case Island, Not a Pilot

A "pilot" is defensive and rarely becomes architecture. A use-case island is an internal programme with a local model, your own post-training, your own eval discipline, and your own harness — on a clearly bounded use case. The island is the smallest complete implementation of the layer map — and therefore the shortest path from strategy paper to stack.

Fourth: Prepare a Day-One Answer Before You Need It

What do we do if a central provider falls away tomorrow? A documented migration path, a mirror of the critical repositories, a service partner that can step in — in 2026 not paranoia, but architectural duty. Corlay's economic survivalism belongs in every board paper that claims sovereignty.

Sovereignty in 2026 is no longer a question of ownership. It is a question of mastery. Which layer of the stack a company controls — and which it deliberately delegates — determines how sovereign it really is in 2027.