A working definition of Digital Sovereignty for people who have to ship work on Monday
You have to ship something on Monday. The tools you already use will probably get it done. They are fast, familiar, and mostly invisible — until the day a vendor changes terms, a region becomes politically awkward, or a model provider decides your account is no longer worth the risk.
That is the moment “digital sovereignty” stops sounding like a conference panel and starts sounding like an operational question: who can turn this off, who can read it, and what can you switch to without stopping the work?
I do not have a polished war story to sell you. I am learning this in public, from a standing start, because the phrase is everywhere and the useful meaning is not. Governments use it. Vendors print it on datasheets. Communities argue about it. Those are different kinds of claim, and mixing them up is how you get a strategy that feels righteous and fails on Tuesday.
Here is the working definition I am using — and inviting you to stress-test.
Digital sovereignty is the capacity of a person, organisation, or polity to control its data, compute, identity, software supply chain, and AI inference. That includes the ability to inspect, switch, and operate without a single foreign vendor, cloud, or jurisdiction being able to shut the system off or compel disclosure on terms you did not choose.
Two words do the real work: capacity and switch. A logo in an EU region is not capacity. A marketing page that says “sovereign cloud” is a vendor claim until you can name the kill-switch, the export path, and the people who could run the alternative.
In the rest of this note I break that definition into six layers you can score against the stack you will actually use this week. The point is not purity. The point is a shared vocabulary for people who still have to ship.
Four kinds of claim (keep them apart)
Before the layers, a small hygiene rule I am forcing on myself:
- Definition — how I am using a word in this note.
- Policy — law, regulation, or a government programme (needs a primary source and a date).
- Vendor — what a company asserts about its product.
- Community — what practitioners or open-source projects claim.
If a slide mixes all four, you do not have a strategy. You have a mood.
Six layers — a Monday checklist
Score each layer against the tools you will actually touch this week: 0 = no real control, 1 = partial, 2 = you could inspect, switch, and keep operating.
1. Data
Who holds it, under what terms, and can you export and delete for real — not “request a ticket and wait”?
Monday question: If this vendor disappeared on Friday, which records would you still have in a usable form on Monday morning?
2. Infrastructure
Where does the work run? What happens if that region, cloud account, or provider is compelled or cut off?
Monday question: Name the dependency you cannot move in a week. That is your infrastructure concentration.
3. Software and standards
Can you inspect and replace parts of the stack, or are you sealed into a suite whose interfaces only face inward?
Monday question: Which file format, identity provider / SSO, or API would strand you if the vendor changed the terms overnight?
4. AI models and inference
Who controls the weights (if any), the inference location, the prompts, the logs, the tools the model can call, the billing, and the kill-switch?
Monday question: If the model provider suspended you today, what work stops — and what, if anything, runs locally or under a contract you actually control?
Open weights are not the same thing as sovereign inference. An EU data-centre pin is not the same thing either. Those are common shortcuts. I am treating them as claims to unpack later, not as answers.
5. Legal and political
Which jurisdiction can compel disclosure, restrict transfer, or force a shut-off — including over a vendor you never meet?
Monday question: If a competent authority asked for your data or for the service to stop, whose law are you actually under, and who decides?
I am not offering legal advice here. This layer is a prompt to name the jurisdiction you are already in, not a verdict on any programme.
6. Operational competence
Can your people run the alternative, or does “sovereignty” live only on a slide?
Monday question: Who on the team has restored from backup, rotated keys, or run the fallback path in the last quarter — not in a workshop, in anger?
This sixth layer is where honest projects separate from theatre. Control you cannot operate is not capacity. It is a brochure.
What this definition is not
It is not anti-American or anti-cloud theatre. Plenty of useful work runs on foreign infrastructure. The question is whether you know the kill-switch and have a switch path proportional to the risk.
It is not “open source equals sovereign” by slogan. Open tooling can help inspect and switch. It does not, by itself, give you ops capacity, legal clarity, or inference you control.
It is not “EU data centre equals sovereign AI.” Location can matter. It does not settle weights, logs, tools, billing, or who can compel whom.
You will hear the word attached to programmes and products — for example names that show up in European public-sector and cloud debates — openDesk, La Suite numérique, Gaia-X as a trust/data-spaces framework, and (separately) hyperscaler “sovereign cloud” offers. I am not scoring those here. I am saying: when you meet them, ask which of the six layers they actually move, and which kind of claim is being made.
Why start with a definition
I am building a public trail of notes on digital sovereignty and AI from scratch. Definition first, then stack maps, then an AI control-plane checklist. Without a shared vocabulary, every later piece turns into an argument about adjectives.
If your Monday constraints break this definition — too strict, too soft, missing a layer — I want that stress test. That is the point of learning in public.
Next action
Print the six Monday questions. Score your current toolchain 0 / 1 / 2. Do not aim for a perfect twelve. Aim for knowing where you are concentrated.
If you are mapping this inside a UK team — SME, public, or third sector — tell me where the definition fails for you in practice. Reply or DM with the layer that hurts first. I am collecting those breaks so the next notes stay useful rather than pure.
Digital sovereignty, as I am using it, is a control problem you can inventory. It is not a vibe. Ship on Monday — and know who can stop you on Tuesday.
Drafting note: This piece was drafted with help from Grok Bot (I see the irony; I’m not pretending it away), then edited by me. I own the published wording, the working definition, and any errors. Corrections welcome.
Not legal advice. Policy and programme names are illustrations unless linked to a primary source.
