Recent articles

Over a decade ago I saw this first-hand, with customers of QuarkXPress, the software once used to lay out most of the world’s books, magazines and newspapers. Many of them made a perfectly rational decision: they froze. They stayed on an old version and stopped upgrading, to avoid paying for changes they didn’t feel they needed. And for a while it worked beautifully. They owned their software, their files, their machines, and depended on no one’s release schedule but their own. That felt like sovereignty, and they had it. ...

Do you need to be sovereign? And if yes, for what? This is the last article in the series, so let me start with answering this question. Sovereignty is contextual; not everything needs to be sovereign. And just because someone else treats a workload as sovereign doesn’t mean it has to be for you. The first move is always deciding whether the yes is even yours. Deciding in whose interest, and whether the pursuit is worth it at all, is a piece in its own right – one the loop doesn’t answer. But assume you’ve asked it honestly, and for some part of your estate the answer is yes. ...

A companion to the digital sovereignty series. It doesn’t replace your business-impact analysis, threat modeling or vendor-risk process — it puts them on one causal chain, one unacceptable consequence at a time. The method in one line: don’t decide how sovereign something should be. Decide what must not happen, and work backward until the remaining dependencies can no longer make it happen — or until you’ve decided you can live with them. ...

How to become digitally sovereign? Five moves: Start with the consequences you cannot accept. Identify what could lead to them, who or what holds those levers, and how far the dependencies reach. Mitigate accordingly – including the new dependencies your mitigation creates. You are sovereign enough when the levers that remain cannot produce consequences you are unwilling to accept. Revisit it regularly. That also answers the question: “How much sovereignty do you need?” ...

You’ve probably read that AI makes everything look the same – the decks, the landing pages, the copy, all drifting toward one voice. It’s true, and the cause is no mystery: a default is an average. Different tools, the same few models underneath; reach for the default and you get the middle of everything the model has seen. What’s worth your attention is what the sameness is. It’s a dependency nobody chose – and unlike most, you can’t buy your way out. Bring the model fully in-house, your hardware, nothing leaving the building, and the defaults come with it. You ran the model; you didn’t make it. You can control that all the way down only by building your own – the most expensive thing in AI, and we’re back to the price we put on this last time. ...

Your postman can’t read your letters. He knows a great deal about you anyway – who writes to you and how often, the envelope from the bank, the law firm, the hospital, the official-looking window envelope. He never opens a thing and could still sketch your month from the outside of your mail. And he’s only the part you can see. Behind him a sorting system logs every item, and an operator could be asked by a court who sent you what. None of them read the contents. They don’t need to. This is metadata, and the first thing to notice is that it’s old – recording the outside of the envelope is centuries of postal practice, not a new failure of the cloud. Which is the clue that you can’t make it go away. It isn’t a leak someone introduced. It’s how any delivery system works. ...

A global company decides to become fully sovereign. Every system in its own data centers, in its own jurisdiction. Foreign providers out, cross-border transfers stopped, the estate air-gapped. Customer data untouchable, IP locked down. Then it goes bankrupt. It was in the pizza delivery business, and the ordering platform was inside the air gap with everything else. Of course nobody would do this. But notice what went wrong: not the ambition, not the execution. They applied it uniformly. The recipe and the order line got the same treatment, and only one of them needed it. ...

You love eating well. What you can’t stand is being at the mercy of someone else’s kitchen – their hours, their rules, the night they close early or change the menu you’d built your evening around. So you think about building your own kitchen. Best equipment, finest ingredients, no one else’s schedule. Your food, your terms. Hold that thought. Because in AI, more and more companies are reaching for exactly that kitchen – and for good reason. Three cases from infra work you probably remember. ...

Sovereignty done right makes you resilient. But sovereignty you don’t operate is the opposite: a risk. You move a workload in-house to be more sovereign. Your jurisdiction, your rules, no outside provider in the loop. More control – which was the point of the move. But the provider you left wasn’t only running the service. They were also keeping it up, patching it, and making sure you could still reach it when something broke. You didn’t see that part, because you never had to. ...

A cloud that passed the sovereignty test, storage that passed it, a model on top that passed it too. Each piece certified, so the sum must be too. It isn’t necessarily. The sum may have parts no certificate covered – the pieces someone adds, the way they’re joined, the provider’s own dependencies, whoever operates the result. Any one of them can make the whole not sovereign. Sovereignty doesn’t add up from the parts. ...

If the series has a point – that sovereignty measures can silently shift under you – this article is where it caught up with me. One of those measures shifted under it, after I hit publish, and I spotted it months after. Written against CSF v1.2.1; the June 2026 guidance changed how the overall SEAL level reads – update at the end. Still worth your time – most of it stands. One part has dated: the article flags that an overall SEAL could hide an extreme low; the new EU guidance has since fixed that. ...

This is the second of two articles on a sovereignty paradox. The first, Control Isn’t Sovereignty?, argued that delegating to systems with broader resilience can produce more outcome sovereignty than direct ownership. This one is about the harder question underneath. Most sovereignty design follows the same logic. To protect operations against grid failures: Install generators on site. Stock diesel reserves to keep them running through an extended outage. Arrange supply contracts with fuel suppliers for resupply during a crisis. ...

— or rather, why more control can still leave you less sovereign April 2025. The Iberian peninsula loses power. Continental Spain and Portugal go dark, the most severe power-system failure in Europe in more than twenty years. Power is largely restored within about a day. When the grid fails, data centers fall back on diesel generators. When power goes out for long enough, diesel reserves run down. Standard reserves last 24 to 72 hours. Beyond that, every operator depends on resupply. And resupply, during a regional crisis, doesn’t happen on first-come-first-served terms. ...

Sovereignty is no longer just a privacy or data-residency question. It has become a question of strategic control, resilience, and competitiveness across the entire digital stack. The debate is not about decoupling. It is about understanding the levers that others hold over critical operations, and deciding deliberately which ones to accept, mitigate, or neutralize. For CIOs and risk leaders, sovereignty decisions now shape uptime, legal exposure, cost trajectories, and time‑to‑market – not just compliance. ...