The Limits of Sovereignty – Architect the Future, Develop the World

“Digital sovereignty” appears on every conference agenda, in every government white paper, in every vendor pitch. Since the change of administration in the United States, the term has become even more urgent. European companies, public authorities, and institutions are now discovering that the IT infrastructure they have relied on for a decade follows a political logic they do not control. The Cloud Act of 2018 obliges American technology companies to grant access to data upon order from US authorities — regardless of where that data is physically stored. The law was always public. It only became a problem now. Why?

When I ask people what they mean by “digital sovereignty,” I mostly get answers that describe what sovereignty is not: no American hyperscalers, data stored in Europe, the ability to switch providers. That is symptomatic: “digital sovereignty” has become a political buzzword that signals resolve without providing a blueprint. The answers describe reactions, not properties. They name what people want to get rid of — not what they need to build instead. And that vagueness is dangerous. Because if you don’t know precisely what independence means, you also don’t know when you have it. You swap one dependency for another and call that sovereignty.

What I want to do in this piece is something different: take the concept seriously. Not out of academic interest, but because an imprecise concept leads to imprecise measures. If you understand independence as the absence of connections, you build architectural decisions on a false foundation. If you understand it as a quality of how you manage connections, you arrive at very different — and far more useful — questions.

I draw on philosophy, physics, and biology. Not to impress, but because these fields have worked through the concept longer and more deeply than IT has. The IT world tends to rediscover the same insights over and over and reinvent half the wheel. The later sections bring it back to the concrete world of software and infrastructure — but I’m laying the foundation here.

What Independence Is Not — and What It Is

The most widespread misunderstanding: independence as the absence of connections. An entity that needs nothing, owes nothing, is influenced by nothing. An island that is self-sufficient.

This picture is not just simplified — it is fundamentally wrong. Spinoza worked through this in the seventeenth century with relentless logic. In his Ethica he defines substance as that which “is in itself and is conceived through itself.” His conclusion: there is exactly one such substance — the totality of being. Everything individual is merely a mode of this substance, partial, relational, never fully self-contained. Three and a half centuries later, physics agrees: quantum entanglement, experimentally confirmed by Alain Aspect (1982), shows that the state of one particle cannot be described independently of another — even when they share no common location. Complete independence is not the normal condition of reality. It would be the rare exception.

What, then, is independence, if not isolation? Niklas Luhmann gives the decisive answer: operational closure. A system operates according to its own rules. It decides for itself what counts as a relevant signal from its environment. It is not isolated — but it is not determined by its environment. It has relationships, but it is not the product of those relationships. In Taoism the same idea sounds as Ziran — the self-so, being-from-itself: not the absence of influences, but the quality of acting from one’s own nature without being distorted by external compulsion.

The history of the concept confirms this finding across every era. Antiquity thought independence cosmologically as an expression of perfection: Aristotle’s unmoved mover acts without itself being moved. The Stoics relocated it inward: Epictetus drew a sharp distinction between what is within our power (eph’ hēmin) and what is not — independence became a practice, not a possession. The Middle Ages reserved it for God alone. The Enlightenment rehabilitated the subject through Kant’s autonomy — freedom through reason, not freedom from causality. The twentieth century dissolved the sovereign individual once and for all: Maturana and Varela showed that a living system is independent not because it can do without an environment, but because it reproduces itself while drawing its own boundary. No era has ever found independence in the external — it has always been relocated inward, because the external inevitably refutes it.

The most apt symbol for real independence is therefore not the circle — closed, self-sufficient, like Leibniz’s monad with no windows to the outside — but the semipermeable membrane. In biology the cell membrane is not a wall but a selective boundary. It determines what may pass through and what may not. It generates the interior through exclusion, not through isolation. It is active, selective, sovereign. Independence is less a circle than a well-managed threshold — and I will come back to this image when we get to concrete architectural decisions.

Translated to the IT sovereignty debate: anyone who wants to declare independence from US hyperscalers must ask not only from whom they are separating — but what kind of boundary they are drawing and who controls that boundary. The answer to that question is not trivial. It requires a look at the structure of dependencies themselves.

The Web of Dependencies

Once multiple entities interact, the web of dependencies becomes the ontological baseline — not an exception but the rule. Newton’s third law — no force acts unilaterally — describes this physically: every dependency generates a counter-dependency. Barabási shows that real networks are not evenly distributed structures but scale-free networks with hubs: a few highly connected nodes, many sparsely connected ones. Independence is asymmetrically distributed in any network — not all actors have equal negotiating power. And dependencies exist simultaneously on multiple levels: informational, material, causal, temporal. An entity can be fully autonomous on one dimension and fully dependent on another.

In a network, independence is therefore not a binary state but a dimensioned vector. The right question is never “Is this system independent?” but rather “Independent of what, to what degree, on which level?” That question is more uncomfortable — but it is the only one that leads to useful answers. Whoever doesn’t ask it imagines themselves sovereign where they are not.

What determines a network’s behaviour is the quality of its connections. I distinguish between warm and cold dependencies — a distinction that is more practically significant in the IT context than the usual separation into tightly and loosely coupled.

Warm dependencies arise through conscious, voluntary coupling: through mutual benefit, resonance, or shared function. Both sides could exist without the other, but are better off in the connection. Mycorrhiza — the symbiosis between fungus and tree root — is the biological model: terminable without being existentially threatening, stable through incentive rather than coercion. In game theory, this corresponds to a Nash equilibrium through mutual optimisation. Warm dependencies are visible, negotiable, symmetric — power here arises through attractiveness, not through control.

Cold dependencies are the opposite: structural, often unchosen, rarely fully visible. They don’t arise through decisions but through growth — through comfort, incremental usage, the absence of an exit strategy. They disguise themselves as the normal state. Charles Perrow describes the consequence: tight coupling in complex systems, where a local failure propagates undamped through the entire network because the apparent boundaries are not real boundaries. Nassim Nicholas Taleb extends this: systems with hidden cold dependencies accumulate silent fragility. They appear stable until a shock activates the entire concealed network — a phase transition without warning. The ice that stays cold, stays cold — and then suddenly melts.

Apparent independence in a covertly entangled network is more dangerous than known dependency, because it prevents the protective reflexes that visible dependency would trigger. Power accumulates where the cold connections are known — with the actor who can see the network that others cannot. That is the asymmetric information advantage of dependency: whoever knows my coldness knows more about my vulnerability than I do myself.

At this point it is worth pausing on the current IT sovereignty debate: what is being described there as an awakening is precisely this phase transition. The law did not change — the political will to apply it changed. The cold dependency was always there. It only became visible now. And the question is not whether Europe is “sovereign” or not — but whether the measures taken in response create warm dependencies or, again, cold ones.

This raises a further obvious question: doesn’t a network of sovereign entities with symmetric relationships inevitably tend toward collapse in the long run? The collapse I fear is not the dramatic one — not the implosion where everything falls apart at once. It is the quiet one: fragmentation, where nodes drift apart, connections erode, and the network ceases to exist not through a shock but through indifference. That is the point where resilience comes into play — but not the way I know it from hierarchical systems. In a hierarchy, resilience is the capacity of the centre to absorb losses at the periphery. In a network of sovereign entities there is no centre. What sustains it is distributed resilience: each node can persist without the others — and the network can reconfigure itself around lost or compromised connections. A resilient network also keeps its exit ramps open — not as a threat but as an enabler. And a network that regularly processes small stresses discovers its hidden cold dependencies before they become systemic. Taleb calls this antifragility: not the absence of disturbances, but the capacity to emerge from them stronger.

Independence as Practice

If independence is not a one-time achievement but a relational quality, then it is also a practice — and like every practice, it begins with awareness.

The first step is always mapping. I can only protect what I understand. Every hidden cold dependency is a potential vulnerability — not because dependency is inherently bad, but because unconscious dependency permits no sovereign response. The Stoics called this basic stance prosoche — self-attention, the continuous observation of one’s own states and their conditions. Not a one-time analysis, but an attitude. From this it follows structurally: full disclosure of all dependencies, redundancy on critical paths, the distinction between core and periphery. What is essential to continued existence must be separated from what serves only growth or comfort. We tend to mistake comfort dependencies for existential ones over time — because we have accepted them unquestioned long enough.

At the level of systems architecture, there is an elegant answer to the problem that complete atomic independence is neither achievable nor sensible: hierarchical encapsulation — the onion model. Not every unit needs to be independent. The overall system is independent when it is correctly layered.

Biology has long figured this out. The eukaryotic cell encapsulates its nucleus with a double membrane. The nucleus does not communicate directly with the outside world — it releases messenger molecules that are processed by ribosomes operating at the outer membrane. Three layers, three translation processes, before a signal from outside reaches the genetic core. The nucleus is not isolated — it is protected through translation. Each outer layer understands two languages: the language of the world outside it and the language of the world inside it. It is a translator, not a conduit — it buffers, filters, transforms. The burden of independence shifts thereby from the atomic unit to the architecture of the layers.

A well-layered system can contain external components internally — as long as control over their integration rests with the system. The decisive questions are never “Where does this component come from?” but: Do I control it fully, or does it control me? Can I replace it — or am I existentially bound to it? Does it know too much about its context, does it have access to internal structures it doesn’t need? The mitochondria of the cell were once independent bacteria — fully integrated because the cell set the terms of integration, not the mitochondria. The external origin of a component does not per se compromise independence. What matters is who sets the conditions of integration.

The layer is ultimately a communication boundary — and so communication is the central instrument of any independence architecture. Shannon captured this mathematically: the channel determines what is transmittable and what counts as noise. An entity that defines its own channel thereby defines the grammar of all possible communication with it. Sovereign communication management has three dimensions: the input decides which signals count as relevant — that is self-definition. The output determines what reaches the outside — informational sovereignty protects against exposure and unwanted dependency. The translation between inside and outside is the most critical layer: whoever adopts the other’s language unfiltered also adopts their categories and worldview — and has already surrendered the actual boundary without noticing it.

When two independent entities must communicate, a protocol negotiation problem arises: which grammar applies? At best, a bilaterally negotiated protocol — a shared contract that neither side has defined unilaterally. At worst, communication runs over a protocol that only one side controls. Wittgenstein spells out the consequence: the limits of my language are the limits of my world. Whoever must adopt the other’s protocol language adopts not just the language — they adopt the worldview behind it. Unilateral protocol ownership is not a neutral technical decision — it is a structural gesture of power.

Components, Trust, and Structural Stability

No complex system consists entirely of components it has produced itself — that is not a weakness but the very precondition for complexity. The second law of thermodynamics makes this clear: a closed system that takes in no energy tends toward maximum entropy. External resources are necessary — the question is only how the dependency on them is structured.

Resilient ecosystems respond to resource scarcity through diversification and redundancy. A monoculture system is highly efficient under stable conditions and reliably collapsing under disruption. Seneca framed this as praemeditatio malorum: what I do not imagine losing, I have already in effect delegated to fate. From this it follows structurally: keep critical components internal, cultivate the capacity for self-production even while currently sourcing externally, diversify sources, and draw a clear line between core and periphery.

A distinct dimension of vulnerability arises when an integrated component can no longer be considered trustworthy. Immunology knows this as autoimmune disease: the immune system attacks the body’s own cells because it has lost the distinction between self and non-self. Thucydides knew this politically: the most dangerous destabilisations come not from outside but from within. The Zero Trust principle — as an epistemological stance, not merely a security paradigm — therefore holds: trust is never inherent, always temporary, must be continuously earned. That sounds like distrust; it is the opposite: structured vigilance that does not abolish trust but places it on a durable foundation.

The consequences of a trust failure depend on whether the system was also built for decoupling from within. A compromised peripheral layer is detachable — if the layer boundaries are clear and the core does not depend on it directly. A compromised core component requires a complete reconstruction of the trust foundation. The compromised communication layer is the most dangerous: it manipulates all incoming and outgoing information without itself becoming visible. When the boundary between inside and outside is itself compromised, the distinction between self and non-self is destroyed.

There is, however, a still more subtle form of dependency: the linguistic. Whoever controls the definitions by which a relationship is evaluated controls the relationship itself. Wittgenstein shows in the Philosophical Investigations that the meaning of a concept lies in its use — whoever controls the use controls the meaning. Definitions that shift according to the power position of the definer are not rules — they are instruments of power dressed up as rules. Redefinitions are legitimate when they arise from a bilaterally agreed process from which both sides benefit, and when that process itself cannot be steered unilaterally. They become instruments of dominance when they are declared unilaterally, when they proceed as gradual semantic erosion, or when they are legitimised as operational necessity while the necessity itself is defined by one side.

And so to the final structural question: how can warm dependencies be designed to remain stable without sliding into cold ones? Thomas Schelling describes the principle of mutual vulnerability: stability arises not through moral appeals but through the structural fact that unilateral action causes the greatest damage to the acting side itself. In nature this appears in co-evolution: predator and prey develop together such that neither destroys the other — the system stabilises through mutual necessity, not through affection. I call this structural parity: both sides hold comparable information or resources in the arrangement; a unilateral withdrawal exposes both. The function of both sides is bound to the continuation of the arrangement — not by contract but by operative reality. Kant formulates the philosophical foundation: an arrangement is structurally stable when both sides could accept the other’s maxim as a universal law without harming themselves.

What Independence Really Means — and What That Implies for IT

These reflections form a spiral, not a checklist. It begins with the concept and discovers that independence is not a property but a relationship. It condenses into a symbol and finds the membrane instead of the circle. It breaks apart against the network and differentiates through the temperature of entanglement: warm or cold, visible or hidden. It seeks operative answers in mapping, layering, and communication sovereignty; it is challenged by external components, supply disruption, and internal breach of trust — and finds its stabilisation in the normative integrity of agreements and the structural parity of their breach conditions.

Independence is not a state I possess. It is a practice I exercise — through self-knowledge, through boundary design, through the structure of the agreements I enter. And it is never absolute — it is always: sovereignty in a specific dimension, against a specific influence, at a specific moment in time.

Translated to the IT sovereignty debate, this means: sovereignty is not achieved by switching providers. It is not achieved by keeping servers in Europe. It is not even achieved by using a European provider. Sovereignty is achieved when I know my dependencies, have classified their temperature, have built redundancies and exit ramps for the existential ones — and when the protocols between my layers are open enough that no single external party controls my boundaries. That is a high bar. But it is also the only one that deserves the name.

Whoever understands this stops asking: “How do I become independent from X?” They ask instead: “Which of my dependencies are cold — and how do I make them warm or substitutable?” That is the more productive question. And it leads to concrete architectural decisions.

Cold Dependencies in IT Infrastructure

Back to the starting point: what actually happened last year? No change to the Cloud Act. No new technology. A shift in political conditions made visible what had always been there structurally: a cold dependency that had been perceived as a warm business relationship.

The decision to use US hyperscalers was rational under the conditions of the 2010s. They offered genuine capabilities: global availability, scalability, a service ecosystem that could not have been replicated internally. Vendor lock-in was known and was consciously accepted as the price — in exchange for performance, speed, and costs that could not be achieved with own infrastructure. That was not stupidity. It was a rational decision with incomplete mapping.

What was inadequately mapped was the legal-political layer behind the commercial one. The Cloud Act was a third party sitting quietly in the background of every bilateral business relationship, waiting. As long as the political climate remained cooperative, that third party stayed invisible. The relationship appeared warm: performance for money, fair market, terminable in theory. In reality it was cold — structural, legal, asymmetric. The dependency had not been consciously chosen; it had grown while attention was focused on the visible commercial surface.

The European response follows a pattern I watch with some caution: it attempts to replace the cold dependency with another without changing the dependency structure itself. The discussion revolves essentially around the question of whose hyperscaler you use. European providers such as OVHcloud, Hetzner, or IONOS offer solid alternatives in certain areas — but not the ecosystem depth of the big three. Anyone seriously wanting to switch encounters a capability gap that cannot be closed in a year. This creates a new cold dependency — not legal-political but technical-ecological: you are dependent on services and integrations that simply do not exist elsewhere in that form.

Add to this the structural fragility of Europe itself. A single Europe as a sovereign digital entity does not exist. What exists is a confederation of states with substantially divergent interests: Germany thinks in terms of industrial data sovereignty, France of strategic autonomy, eastern member states of geopolitical security. Gaia-X, the most ambitious European attempt at a shared data infrastructure governance framework, has so far not made it past exactly this fragmentation. That is not Euro-scepticism — it is the direct application of what I have written about networks of incomplete parity: when the nodes themselves hold different power positions and no shared governance structures exist for the shared space, new cold dependencies emerge within the network.

The right question is therefore not “American or European hyperscalers?” but: what kind of dependency structure am I building — and how do I design it so that it is warm rather than cold? That requires architectural decisions.

Recoverable Architectures

If the infrastructure layer is the visible face of dependency, then software architecture is its hidden skeleton. Whoever changes the infrastructure but not the architecture has painted over the surface and left the crack in the foundation.

Vendor lock-in at the software level does not arise from a single law but from a thousand small decisions: the proprietary messaging system chosen for convenience; the database whose specific extensions have been used for years; the authentication system embedded deep in every application; storage formats that no other system can read without effort. Each decision was reasonable on its own. Together they form an architecture that can no longer move without giving up substantial parts of itself. The once-warm symbiosis has become a cold dependency — not through malice but through the absence of conscious boundary design.

Recoverable does not mean faultless. It means that a system can absorb a component failure, a trust breach, or a forced provider change without losing its overall function. The system knows its layers. It has exit ramps. It can degrade in partial areas without collapsing as a whole — and it regenerates after the damage.

The membrane principle becomes concrete here. The core — the domain logic, the data, the identities — should not know on which substrate it is running. If the core has an opinion about whether it runs on AWS, Azure, a European cloud, or bare metal, the membrane has been compromised: the external has already reached the internal language. Open standards are the language of this membrane — not because open source is morally superior, but because a protocol that no single party controls alone satisfies the basic condition of structural parity between layers.

When designing a recoverable architecture, I ask myself four questions. First, portability: can I move this workload to a different provider within thirty days — practically, without rewriting applications? Does this also apply to data and identities? If not, I have built in a cold dependency I cannot yet see. Second, graceful degradation: when a component fails, does the overall system collapse — or does it degrade in a controlled way to a reduced but functional state? Third, recoverability: can I establish a state in which a compromised component never existed, without losing the entire historical state? That is the technical operationalisation of Zero Trust: compromise is not a catastrophic scenario but a manageable event — if the layer boundaries were real boundaries. Fourth, observability: can I see at any given moment which dependencies are active, which services are communicating with each other, where data is flowing? Without observability, no conscious dependency mapping is possible — and without mapping, sovereignty is an illusion.

The distributed logical entity is the synthesis of these four requirements: a domain function distributed across multiple physical substrates but experienced and operated as a unit. Multi-cloud not as complexity for its own sake, but as an architectural decision that makes no single platform an existential precondition.

A final warning: whoever applies these principles and concludes that switching to a European provider with an otherwise unchanged architecture is sufficient is making the same mistake a second time. Vendor lock-in with a European provider is structurally identical to lock-in with an American one — just with a different political risk profile. And the next terrain where the same trap is already being laid is visible: AI platforms and large language model infrastructure. Proprietary models, proprietary inference APIs, proprietary fine-tuning infrastructure — the pattern is identical, the cycle begins again. Establishing structural parity here means: favour open models where they are sufficiently capable; retain model weights yourself where the function is critical; abstract the inference infrastructure so that the model can be swapped without touching application logic.

What genuine independence management in IT means is now clear: not autarky, but a practised, conscious, architecturally anchored sovereignty. I know my dependencies. I have classified them — warm or cold, existential or comfortable. I have designed for exit ramps and redundancies for the existential ones. I keep the protocols between my layers open. And I regularly review whether new connections have silently changed the map.

The limits of sovereignty do not disappear through this. But they become shapeable limits — membranes, not walls. That is the difference between a system that is determined by its environment and one that engages with it sovereignly.