Digital sovereignty in 2026: how to run AI on infrastructure you control

On June 12, a US export-control order told Anthropic to cut off its two newest models, Fable 5 and Mythos 5, for every foreign national. To comply, Anthropic disabled them for everyone, three days after launch. No warning, no appeal, no transition period. If your product was built on those models and you sit outside the US, your roadmap changed that afternoon. This is the moment digital sovereignty stopped being a policy-panel topic and became an operations question: which part of your stack can someone else switch off?

Chat stopped being the product

We build an AI workspace called Navigator, and for a while we treated the chat box as the thing. A clean chat box used to feel like a product. Now every tool ships one, and a slightly nicer version of the same window is not worth charging for. Chat is a commodity. So we stopped trying to win at it.

The question that actually matters is whether the software creates value for the people doing the work. For us that means removing manual steps, connecting the tools a team already uses, and turning messy conversations into clean output. The chat window is one feature of an operating system, not the system itself. Once you see it that way, where the model runs and who controls it becomes a real decision rather than a default.

The dependency you don't see until it breaks

Managed frontier models are genuinely good. They are the easiest way to start, you always get the latest version, and you avoid running anything yourself. For a lot of teams that is the right call, and we still use hosted models where they earn their place.

The catch is that convenience and control are not the same thing. The Fable case showed how fast access can vanish for reasons that have nothing to do with you or your contract. And it is not only access. The bill is moving too. TechCrunch reported in June that companies are starting to balk at the price of AI, with Uber burning through its entire 2026 AI coding budget by April. Per-token prices keep falling while total bills climb, because agentic workloads consume far more tokens than a chat window ever did. You are renting a capability whose price and availability are set by someone else, in another jurisdiction, under rules that can change on a Friday.

What digital sovereignty actually means

Sovereignty here does not mean cutting yourself off or rebuilding everything from scratch. It means optionality: the ability to keep running, on your terms, if any single supplier changes the rules. In practice it comes down to four things you can actually own.

• Software you are allowed to run yourself, not only rent.
• Models you can host, so a remote switch cannot turn them off.
• Hardware and infrastructure you or a European provider control.
• Data that stays in your hands and your jurisdiction.

None of these is all-or-nothing. You can move one layer at a time and keep the parts of the cloud that still pull their weight.

A practical path to self-hosted AI

You do not need to flip everything at once. A realistic order of operations:

1. Start with open-source software you can self-host. Pick tools that publish their source and allow self-hosting, so you are never one pricing email away from a forced migration. Open source is also auditable, which matters the moment the software touches customer data.
2. Run open-weight models locally. Models like Llama, Mistral, Qwen and DeepSeek now cover most day-to-day work: drafting, extraction, classification, summarisation. This is the practical side of a bring-your-own-model strategy: keep the hosted frontier models for the few tasks that genuinely need them, and route everything else to a model you control. Most routine work looks more like a reliable automation than an open-ended agent, and it does not need the most expensive model on the market.
3. Own the hardware, or rent it inside your jurisdiction. That can be a single GPU workstation under a desk, an on-prem server, or a European cloud region. The point is that the machine answers to you.
4. Secure and harness your own data. Your documents, tickets and conversation history are the real moat. Put them behind retrieval on infrastructure you control rather than uploading them into a service whose terms can shift without you.

This is the reasoning behind opening Navigator to the public and making it simple to connect local models. You can run it on infrastructure you control, keep your own data, and skip the lock-in. The hardware question is real too, which is why we are building a small box, the NAV-01, for teams that want the model sitting in their own office instead of a datacentre they will never see. If your concern is the data itself, the same logic leads to keeping sensitive records on a private AI server rather than on a third party's.

Open source is not just a license

Open source does more than remove a vendor. It changes who shapes the tool. The people using Navigator every day can read the code, fix what annoys them, add what they need, or fork it in a direction we never planned. We get to spend our time where we can add value instead of polishing a chat window that already exists in fifty other products.

The code is public. Take it apart, build on it, and tell us what is missing: github.com/keinsaasforever/better-chatbot ↗.

What would you run on your own infrastructure?

Sovereignty is shaping up to be the theme of 2026, and not for ideological reasons. The Fable shutdown and the rising token bill are the same lesson from two directions: depending entirely on infrastructure you cannot control is a risk you can measure and price. You do not have to leave the cloud. You do have to know which parts of your stack would keep running without it.

If you want to see what a model-agnostic, self-hostable workspace looks like in practice, that is what we built Navigator to be. Start with one workflow, one local model, one dataset you keep in-house, and grow the part you own from there.

What would you want running on infrastructure you actually control?