Let’s talk
FREN

The blogTake back control · Episode 1/5

Published on

Take back control: how to get started with sovereign AI in Europe in 2026

A snapshot, a roadmap, and the only question that really matters.

"Take back control" series, Episode 1/5 · 2. The AI Act explained · 3. GDPR and AI · 4. Building your first sovereign AI agent · 5. Scaling up

Just another Monday morning

Picture the scene. Monday, 9 a.m. The CTO of a mid-sized industrial firm discovers that the R&D team has wired a consumer AI assistant into the company's library of blueprints. Convenient. Free. Effective. Except that those blueprints, fifteen years of accumulated know-how, are now leaving, query after query, for servers he doesn't control, under a jurisdiction that isn't his.

Nobody decided anything. AI simply climbed in through the window while the leadership team was still debating strategy.

That story is the story of most organisations across Europe and the UK today. Most sensitive data still flows to US-based AI services exposed to the Cloud Act. And it isn't a detail: US providers capture around 83% of the European cloud-software market, €54 billion for France alone (Asterès study for Cigref and Numeum, 2025). The infrastructure that runs Europe's AI is, overwhelmingly, not European.

That's the starting point. Now let's talk about how you are going to do things differently.

The tipping point: why 2026 is the pivotal year

Ten years ago, Europe watched the digital revolution happen in California. Today, three forces have aligned, and they change everything.

Public money is flowing. European governments are investing heavily in AI. Under national strategies, France's France 2030 has committed billions of euros across hundreds of AI projects, and EU-level programmes, sovereign AI is now a funded priority rather than a slogan. Several states are rolling out their own sovereign conversational assistants for public administrations, built on European models and certified infrastructure. The UK, which has no equivalent AI Act, is pursuing a distinct path: heavy compute investment (the AI Research Resource, sovereign compute capacity) and a pro-innovation stance, while still pushing public-sector AI adoption.

Regulation is tightening. The EU AI Act applies in waves: the prohibitions and the obligation to train staff on AI are already in force, general application and penalties arrive on 2 August 2026, and full compliance for high-risk systems (HR, credit, health...) is set for 2 December 2027 following the "Digital Omnibus" rescheduling of May 2026. Working with a non-EU provider makes demonstrating compliance considerably harder. The UK, by contrast, has no AI Act: it favours a principles-based, pro-innovation approach delivered through existing regulators (the ICO for data protection, plus sector regulators). That means a UK reader faces different obligations, lighter statutory AI rules today, but the same data-protection and extraterritoriality exposure. (We unpack the AI Act in Episode 2 of this series.)

A credible champion. Mistral AI, valued at €11.7 billion in its September 2025 Series C (a new round under discussion would push it to around €20 billion), offers open-weight models that now rival the best. In 2023, the gap between proprietary and open-source models was gaping. In 2026, across 80% of business use cases, it has all but disappeared, and Mistral is Europe's clearest answer to the question "can we do this without depending on a US lab?".

And yet adoption remains low: in 2025, just 20% of EU enterprises used AI, around 18% in France (Eurostat), with the UK in a similar range. The head start is wide open. Now is the moment.

The one idea to hold on to: sovereignty ≠ location

If you remember a single sentence from this article, make it this one.

Data hosted in Europe but subject to a foreign law is not sovereign.

The European servers of Microsoft, Google or Anthropic change nothing: the US Cloud Act lets American courts reach into them, wherever the datacenter sits. The real criterion isn't the geography of the server. It's legal immunity.

In France, that immunity has an official name: the SecNumCloud label from ANSSI, which forbids any control by a non-European power, one national example among several. At EU level, the equivalent conversation runs through the emerging EUCS cloud certification scheme and industry initiatives such as Gaia-X, all shaped by Schrems II and the GDPR. In the UK, the picture turns on data adequacy with the EU (currently maintained) and a growing set of British sovereign cloud offerings.

So judge the sovereignty of any solution against three pillars:

  1. The data is processed and stored within your jurisdiction (EU or UK), with clear access governance.
  2. The models run on infrastructure you, or a European/British operator, control.
  3. The compute sits on a cloud immune to extraterritorial laws.

One detail that matters: the country of origin of the model is neutral as long as it runs on your infrastructure. A Chinese model (DeepSeek, Qwen) or a US one (Gemma, Llama), self-hosted in Europe or the UK, is sovereign. The same model called through its native API is not. Sovereignty is decided at execution, not by the logo.

What do you actually need?

This is where most articles abandon you. Not this one. Here are the five decisions that make up your roadmap.

Decision 1: Map your use cases by criticality

Before any technical choice, ask one question per use case: what happens if this data leaks?

  • Non-sensitive data (marketing content, brainstorming, non-strategic code) → anything goes, including a standard API.
  • Personal data / GDPR & UK GDPR (HR, customers) → EU or UK perimeter mandatory, no Cloud Act exposure.
  • Ultra-sensitive data (health, legal, defence, critical R&D) → certified sovereign cloud (e.g. SecNumCloud) or self-hosting, full stop.

The right strategy is almost never "all sovereign" or "all API". It's hybridisation: the right tool for the right level of risk.

Decision 2: Choose your path: sovereign API, GPU cloud, or on-premise

There are three routes, from simplest to most demanding.

Path What it is For whom
A. Sovereign API You call a model via the API of Mistral, Scaleway or OVHcloud (data in the EU, no Cloud Act) Getting started fast, no infra to manage
B. Sovereign GPU cloud You deploy an open-weight model on GPUs rented in Europe (Scaleway, OVHcloud, Outscale, and UK providers) Large volumes, strong control
C. On-premise You run the model on your own hardware Air-gap (a machine fully isolated from the internet), classified data, very high volumes

The good news: a sovereign API is already a huge step forward compared with a US API, for near-identical effort. It's often the best starting point.

Decision 3: Choose your model

The Mistral ecosystem (European, Apache 2.0 licence, so free commercial use and self-hosting) covers almost every need:

  • Ministral 3 (3B / 8B / 14B): the small models. They run on ~8, 12 and 24 GB of VRAM respectively. Perfect for classification, extraction, lightweight RAG, edge.
  • Mistral Small 4 (119B, MoE, 6.5B active): multimodal, 256k context, Apache 2.0, and fits (quantised) on a single high-end GPU. The best quality/cost ratio to start seriously.
  • Mistral Medium 3.5 (~128B): built for agents (tool calls, structured outputs, multi-step reasoning).
  • Mistral Large 3 (675B, MoE, 41B active): the open-weight flagship, 256k context. A mixture-of-experts architecture: it has the capacity of a 675B but the compute cost of a ~41B. On the API, roughly $0.50 / $1.50 per million tokens (input/output).

And if you're not dogmatic: DeepSeek or Qwen for code and reasoning, Gemma or Llama as generalists, all self-hostable within the EU or UK.

Decision 4: Choose your inference engine

The model is the engine. It needs a chassis to serve requests.

  • Ollama: "the Docker of LLMs". One command and it runs. OpenAI-compatible endpoint. Ideal for prototyping, a single user, or local dev. Limited parallelism by default, then queues the rest: latency explodes under load.
  • vLLM: the production standard. Its PagedAttention technique and continuous batching let it serve far more requests in parallel on the same GPU than Ollama's limited parallelism, far higher throughput under heavy concurrency. Reach for it as soon as you're serving several simultaneous users.
  • LM Studio: a GUI, perfect for testing and comparing models without the command line.
  • llama.cpp / SGLang: for edge cases (Apple Silicon, CPU offload, multi-turn RAG).

Crucial point for migration: they all expose an OpenAI-compatible endpoint. Switching from an API to your own server often means changing a single line (base_url). Your existing API calls have already trained you for this format.

Decision 5: Size the hardware

The VRAM rule to know by heart:

VRAM ≈ (number of parameters × bits per weight) ÷ 8 + KV cache + ~20% margin

In plain terms, 4-bit quantisation (Q4) sharply cuts the memory footprint while preserving most of the quality, enough to let large models run on a handful of GPUs:

  • 7–13B → fits on a single RTX 3090/4090 (24 GB).
  • 70B at Q4 → a single A100/H200 80 GB, or two 24 GB GPUs in parallel.
  • Very large models (400B+) → multi-GPU node, specialist territory.

On the European sovereign cloud side, as orders of magnitude: H100 GPUs at Scaleway around €2–3/hour (the most readable and dev-friendly, Paris datacenters); OVHcloud with ready-to-use AI Endpoints (~€0.09/M tokens input) and its SecNumCloud-qualified Hosted Private Cloud; Outscale (Dassault), A100 80 GB around €3.60/hour within a full SecNumCloud perimeter, for the most sensitive data. UK teams can add domestic sovereign-cloud providers to this shortlist; the same criteria, jurisdiction, immunity, certification, apply.

The 4-phase roadmap

Here's how to chain all of this together without drowning.

Phase 0, Framing (1 week). List 3 use cases. Classify each dataset by criticality. Set a target monthly budget.

Phase 1, Proof of value (2–4 weeks). Take the least sensitive use case. Wire in the Mistral sovereign API or Scaleway Managed Inference. Measure: quality, latency, real cost per token. You now have a quantified baseline.

Phase 2, Control (1–2 months). For a sensitive or high-volume use case, deploy Mistral Small 4 quantised on a GPU rented from Scaleway or OVHcloud, served by vLLM, with Open WebUI as the interface. Compare the cost against your API baseline.

Phase 3, Industrialisation (as needed). Add RAG over your internal knowledge bases, fine-tuning if required, monitoring (Prometheus/Grafana), redundancy. Move to a fully certified sovereign perimeter (SecNumCloud or equivalent) or on-premise if regulation demands it.

Never skip Phase 1. It gives you the numbers that make every subsequent decision obvious.

Pros & cons: self-hosting vs API calls

This is the question. Here's the honest answer, and it isn't philosophical, it's a maths problem.

The upsides of self-hosting (vs API)

  • Maximum sovereignty. Your prompts and data never leave your perimeter. It's the only route for air-gap and classified data.
  • Near-zero marginal cost at high volume. Once the GPU is paid for, each additional token costs only electricity. The cost is fixed, not linear.
  • Latency. Local inference removes the network round-trip (time to first token < 100 ms, versus often +300 ms for a remote API). Decisive for agents that chain many calls.
  • No vendor lock-in. No imposed rate limits, no model deprecated overnight, no sudden change of terms.
  • Total control. Fine-tuning, quantisation, frozen versions: the model is yours.

The downsides of self-hosting (vs API)

  • Fixed cost even when idle. You pay for the GPU 24/7, whether you use it or not. At low volume, that's ruinous compared with a pay-per-use API.
  • Operational complexity. CUDA drivers, vLLM tuning, KV cache, monitoring, redundancy: a lone GPU is a single point of failure. Budget €200–500/month of ancillary infra, and above all engineering time.
  • Skills required. Without expertise, the first three months cost more in wasted GPU hours and debugging than a whole year of API.
  • You carry everything. Updates, security, availability: it's your problem now, not a provider's.

The upsides of API calls (vs self-hosting)

  • Immediate start. A key, a few lines of code, operational in minutes.
  • Pay-per-use cost. You only pay for what you consume. Unbeatable at low and medium volume.
  • Zero maintenance. Scalability, availability, model updates: handled for you.
  • Access to the biggest models without investing in a cluster.

The downsides of API calls (vs self-hosting)

  • Conditional sovereignty. A non-sovereign API (OpenAI, Anthropic, Google) exposes you to the Cloud Act, even with EU servers. A sovereign API (Mistral, Scaleway, OVHcloud) removes that point: but your data still transits through a third party.
  • Cost that explodes at scale. Cost grows linearly with tokens. At very high volume, the bill becomes the number-one argument for bringing it in-house.
  • Dependence. Rate limits, model deprecation, evolving prices and terms: you're along for the ride.
  • Irreducible network latency.

The quantified tipping point

  • As long as only humans are consuming: even a hundred diligent colleagues, i.e. a few euros per person per month, the API (ideally sovereign) is almost always cheaper. Don't self-host.
  • Around a few hundred thousand requests per month: typically when automated pipelines join the humans, the calculation depends on your model, your GPU and your team. This is the grey zone: run the Phase 1 numbers.
  • Beyond that, or the moment a regulatory constraint mandates a sovereign perimeter, self-hosting becomes rational.

The formula to remember: self-hosting is a cost problem, except when it's a compliance problem. If the law imposes a certified sovereign cloud, the tipping-point debate doesn't even arise.

The last word

In 2023, digital sovereignty was a job for the CISO. In 2026, it's a boardroom subject, and soon, a simple matter of professional hygiene, on a par with backing up your files.

The truth is there's no such thing as "total" sovereignty. There's an architecture: the right level of control for the right level of risk. Start small, with a sovereign API on a non-sensitive case. Measure. Then take back control, brick by brick, where it counts.

The CTO in our Monday-morning story had decided nothing. You, now, have the keys to make the decision.

The question is no longer "US or European provider?". It's: who controls your data when geopolitics shakes? Those who build their architecture now will be the only ones navigating calmly through the world that's coming.

Over to you.

📖 In the same series, Episode 2: "The AI Act explained for people with no time" (the risk pyramid, your obligations, the five traps, plus what changes if you're in the UK) · Episode 3: "GDPR and AI" (legal bases, DPIA, data-subject rights, EU GDPR and UK GDPR) · Episode 4: "Building your first sovereign AI agent" (the 5 building blocks, 7 steps, budgets) · Episode 5: "Scaling up" (users, models, machines and euros). Sovereignty answers the "where", the AI Act the "am I allowed", the GDPR the "what do we owe people", Episode 4 assembles the whole, and Episode 5 makes it grow.

*Key sources: European and national AI strategy publications, UK government AI and compute announcements, Mistral AI docs, sovereign-cloud comparisons (Scaleway/OVHcloud/Outscale and UK providers), Eurostat, the Asterès study for Cigref and Numeum (2025), Schrems II / EDPB guidance, vLLM/Ollama inference benchmarks (2026). Prices and certifications move fast: check the current regi

← Back to the blog