All articles
AILock-inSovereignty

Don't Let AI Become the Next Cloud Lock-In

Europe spent fifteen years becoming dependent on a handful of foreign cloud providers. It is now on track to do the same thing with AI, except faster, and one layer deeper. The good news: this time we can see it coming.

Ilke Tosunoğlu
Ilke TosunoğluJune 11, 20268 min readUpdated July 20, 2026
Two padlocks side by side: "Cloud lock-in (10 years)" and a larger, faster-closing "AI lock-in (18 months)" wrapped in cables labelled API dependence, data gravity, fine-tuning and agents, with a time-to-lock-in strip showing AI lock-in arriving far sooner.

Part of the pillar series Sovereign AI, Explained.

Every dependency starts as a convenience. The cloud did: elastic, cheap, easier than running your own data centre, until three companies held roughly 70% of Europe's cloud market and leaving became unthinkable. AI is now running the same play, and the tell is how fast it's moving. Cloud needed a decade to become load-bearing; AI is doing it in eighteen months.

This is the companion to the technical piece on why sovereign AI means keeping inference at home. Here, the strategic question: how do you adopt AI aggressively without waking up in three years locked to a foreign model you can't leave?

The stakes: a familiar gap, one layer up

First, the shape of the dependence, because it rhymes with cloud. The US builds the frontier models; Europe consumes them.

Metric (2025) Europe United States
Notable foundation models ~3 ~50
Share of global AI compute ~5% ~75%
Share of global AI venture capital ~6% ($15.8B) ~75% ($194B)

Sources: Stanford HAI AI Index 2026; OECD, 2026.

And the market is already concentrated: three vendors (Anthropic, OpenAI, and Google) account for roughly 88% of enterprise LLM API usage (Menlo Ventures, 2025). That's the same handful-of-providers structure that made cloud so hard to leave.

Why AI lock-in is deeper than cloud lock-in

Cloud lock-in was mostly about data gravity and migration cost. AI adds several new, stickier mechanisms, and most organizations crossed the line into them in 2025 without noticing, the moment AI stopped being "a feature" and became "the workflow layer."

  • API dependence. Your product now calls a specific provider's endpoint, tuned to its quirks.
  • Prompts that don't transfer. System prompts and behaviours optimised against one model degrade or break when ported to another.
  • Embedding data gravity: the sharpest one. A vector only has meaning inside the exact model that created it. Switching embedding providers means re-embedding your entire corpus; one worked example put moving 100M documents at "$3,000 just for the API calls, plus engineering time to rebuild indexes", and it only grows. So teams "pick one embedding model early and never change it." (Schift)
  • Fine-tuning welded to a base model. Fine-tune on a provider's base and your investment evaporates when they deprecate it.
  • Deprecation power. The vendor controls the clock, and uses it.

Two-column comparison. "Lock-in mechanisms": API dependence, embedding data gravity, fine-tuning welded to the base model, agent ecosystems, deprecation power. "Portability answer": model abstraction/gateway, multi-model routing, open weights, own your embeddings/data, ground rather than fine-tune. Caption: adopt AI aggressively; stay portable by design.

The access shocks are already happening

If lock-in still sounds abstract, look at the past eighteen months. These are real, and they hit production systems: a mid-2025 model API deprecated, the US "AI Diffusion Rule" issued and then rescinded, an export ban on advanced AI chips reversed months later, and, in early 2026, six models retired with roughly three months' notice.

Model deprecations force hard migrations on the vendor's schedule, not yours: OpenAI announced the retirement of six models in early 2026 with roughly three months' notice, against the six-to-twelve months enterprises say they need to re-validate production software (OpenAI deprecations; Remio). At the infrastructure layer, the US AI "Diffusion Rule" was issued and then rescinded within months, and export controls on advanced AI chips whipsawed on and off through 2025 (BIS; Bloomberg). Even the frontier vendors treat single-source AI as a risk: OpenAI itself signed a ~$38B deal to diversify its own compute away from a single provider. If they hedge, so should you.

The portability answer

Here's the encouraging part: because the models are converging in quality (the top US and Chinese models are now within a few percent on benchmarks), the differentiator is no longer raw capability. It's whether you can move. And enterprises are already acting: 37% now run five or more models in production (Typedef). The design patterns that keep you free:

  1. A model-abstraction layer. Put a gateway between your applications and any provider, so your code talks to one interface and you can swap or fail over underneath.
  2. Multi-model routing. Route by task and cost; never let one provider become a single point of failure.
  3. Open-weight models as the escape hatch. Open-weight frontier and small models (Europe's Mistral among them) let you keep the model itself under your control.
  4. Own your embeddings and data. Treat embedding-model choice as a migration decision, keep the corpus and vector store yours, and prefer grounding over fine-tuning: retrieval against data you control is far more portable than behaviour welded into a vendor's base model.

Your future AI architecture should look less like a stack and more like a portfolio.

Europe's response, and the honest gap

Europe is building compute: AI Factories, and an InvestAI plan aiming to mobilise ~€200B for AI Gigafactories (European Commission). It matters. But we should be honest that it's ambition, not yet capacity: Europe still holds ~5% of global compute and one frontier-scale lab, and think-tanks like Bruegel argue the smarter play may be to "prosper below the tech frontier" in applied AI rather than chase parity (Bruegel). Either way, the organisation-level lesson is the same: don't wait for the gap to close. Design for portability now.

How Soveryne keeps you unlocked

We built Counsel on exactly these principles. It answers from your frameworks and documents, grounded and cited, so the value lives in your knowledge, not in a vendor's proprietary model behaviour. It runs on the Soveryne Cloud Foundation, where AI and LLM inference are EU-sovereign and the embeddings stay in your jurisdiction, under your control, not tied to a foreign provider's endpoint. The design goal is deliberate: adopt AI fully, keep your data and your optionality, and never trade one dependence for a deeper one. That's the difference between using AI and being captured by it.

FAQ

Why is AI lock-in worse than cloud lock-in? It forms faster and adds new binding mechanisms (API dependence, non-transferable prompt tuning, embedding data gravity, fine-tuning welded to a base model, and vendor-controlled deprecation) on top of ordinary data gravity.

What is embedding data gravity? A vector embedding only has meaning inside the model that created it, so switching embedding providers means re-embedding your entire corpus, often expensive enough that teams never switch. It's one of the strongest AI lock-in forces.

How do you avoid AI vendor lock-in? Use a model-abstraction layer, route across multiple models, favour open-weight models, keep your embeddings and data under your control, and prefer grounding (RAG) over fine-tuning into a provider's base model.

Is sovereign AI realistic for Europe? For frontier-model parity, not soon. But sovereignty at the level that matters to most organisations (keeping your data, inference, and optionality under EU control) is achievable today, and is where the practical value is.


Adopt AI aggressively; stay portable by design. See a grounded, cited, EU-sovereign AI assistant that keeps your data and your optionality: explore Counsel and the Soveryne Cloud Foundation.

Sources