--- title: "What is digital sovereignty" description: "Digital sovereignty: deciding over data, infrastructure, and AI models. Open source, self-hosting, and open weights against cloud-first anchors." date: 2026-07-25 locale: en url: https://escribano.dev/en/blog/005-digital-sovereignty/ --- # What is digital sovereignty As I previewed in the [cloud-first post](/blog/004-cloud-first-problem/), for me digital sovereignty means being able to decide over data, infrastructure, and AI models, without a vendor, a past decision, or market inertia making those choices for us. I'm not trying to write an anti-cloud manifesto. What interests me is something much more practical: understanding which parts of our stack we actually control, which we've delegated, and above all whether that delegation is reversible. The debate on digital sovereignty often focuses on data jurisdiction, regulation, or technological dependence between countries. But here I want to talk about an aspect closer to the day-to-day of those of us who develop software: the ability to revisit a decision when circumstances change. I like to think of digital sovereignty as three complementary layers. Two of them (data and infrastructure) we've known well forever: * **Data.** Where it's stored, who can access it, and whether you can export or delete it without depending on a third party. * **Infrastructure.** Who runs the software, with what tools, and how much it would cost to migrate it elsewhere. But now, with the rise of generative AI, there's a third layer: * **Cognition.** Which AI models process your information and to what extent you can switch models, providers, or even run them yourself. You can have your own VPS, run free software, and manage your own services. But if every document, every conversation, and every snippet of code ends up processed exclusively by a closed model, your sovereignty remains partial. In the earlier posts ([introduction](/blog/001-introduction/) and [cloud-first](/blog/004-cloud-first-problem/)), free software, open formats, and self-hosting form the foundation. But self-hosting a service doesn't guarantee sovereignty if, for example, your service requires a third-party API you don't control and that would be costly to replace if it stopped being available in your country tomorrow or changed its pricing. As I noted when discussing the [RPS principle](/blog/002-rps-principle/), decisions that preserve the ability to change are **bridges**; those that make it hard to abandon a technology are **anchors**. Free software and self-hosting usually build bridges in infrastructure. Open-weight models can do exactly the same in the cognitive layer. ## Cognitive sovereignty The arrival of AI adds a new question: who actually runs the model that processes your information? Closed models like GPT, Claude, or Gemini offer very strong capabilities, but the user depends entirely on the provider: you can't run those same models on your own or move them to an independent operator. Open-weight models work differently. If you work with families like Qwen, Gemma, DeepSeek, or Kimi, you can use the original developer's API, turn to different inference providers, or (if your hardware allows) run exactly the same model on your own infrastructure. The model stays; who runs it changes. Choosing an open-weight model keeps more options open for the future: today you can consume an external API, and tomorrow decide to move that same workload to your own server without having to rebuild your entire integration. A brief aside: some open-weight model licenses include commercial restrictions, but they usually target use at scale (a SaaS, a company with hundreds of users) rather than personal use. Even so, it's worth checking each license: not all follow that pattern. Cognitive sovereignty doesn't require setting up a multi-GPU server from day one. There's a reasonable spectrum of decisions: 1. A closed model API. 2. An open-weight model API. 3. Local inference (open-weight model). Option one anchors you to a specific model you don't control. Option two keeps the same model but lets you switch providers or bring it in-house. Option three offers maximum control, in exchange for more operational cost. When we evaluate a technology, we usually focus on the cost of entry: how long it will take to get running, how much it costs per month, or what the learning curve looks like. However, we rarely think about the cost of leaving it. Migrating a database, replacing an email provider, or swapping out an AI model can take weeks or months of work. The higher that cost, the less real capacity we'll have to decide in the future. In any case, we can always opt for hybrid solutions, for example, using a local model for most requests and reserving frontier models for one-off cases where extra power is needed. ## My experience with local inference My experience with local inference is limited, but it has helped me calibrate expectations. With **Gemma 4** (4B) and **SmolLM3** (3B) on CPU via Ollama, small models are usable, though slow; a GPU completely changes the experience. You don't need powerful hardware to get started: without a GPU you can already experiment and build personal tools; with a mid-range one, many open models are enough for development, writing, or automation. For more demanding tasks (especially agentic flows) I've chosen a midpoint on the spectrum: **open-weight models consumed via API**, specifically **`glm-4.7-flash`** and **`deepseek-v4-flash`** through Ollama Cloud. These are models I could, in principle, run on my own hardware (something like a Mac Mini) if I had the kit. I don't today, so I use the API: I'm still handing inference over to a third party. The bridge isn't sovereignty in current use, but the exit door: if tomorrow I have access to a machine with enough unified memory (or a GPU with 24 GB of VRAM), I can download the same weights and migrate inference with little to no change to the integration. That's the difference between a bridge and an anchor. ## When a closed model still makes sense Digital sovereignty doesn't mean rejecting closed models. They're still the best option when they offer capabilities that don't yet exist in the open-weight ecosystem, when the cost of being wrong is high, or when it's a one-off use. The problem isn't using them, but letting them become the default without evaluating whether a more open alternative would be enough. The same criticism that can be made of *cloud-first* can also be made of *LLM-first*: delegating out of habit rather than out of necessity. It's not about self-hosting everything or avoiding every commercial service, but about preserving the ability to choose. Free software, self-hosting, and open-weight models lower the cost of switching; closed models and big cloud will still solve many problems better than home infrastructure. The question isn't forbidding yourself from using them, but preventing initial convenience from turning into permanent dependence. If you enjoyed the post (or disagree on something), feel free to comment.