You Own the Business. Who Controls What Keeps It Running?

The popular advice on software sovereignty is to build everything at home. That sounds decisive, but it confuses ownership with control. A country can fund a domestic model and still depend on foreign chips, cloud capacity, proprietary orchestration, external support and contracts that make exit impractical.

I see sovereignty as graded control over the chokepoints of the stack. The relevant question is not whether an organisation owns every component. It is whether someone else can deny access, change the terms, inspect sensitive data, restrict deployment, or capture the value created above a dependency.

That makes the stack on software and sovereignty a political-economy question. The answer determines who controls AI, who captures its margins, how much bargaining power buyers retain, and whether public procurement creates durable capability or merely rents access to another company's infrastructure.

Sovereignty Is About Control, Not Ownership

The first mistake is treating sovereignty as a flag attached to a product. A service can carry a local brand while its compute, software supply chain, updates, support access or legal exposure remain external. Conversely, an organisation can retain meaningful control over a mixed stack if it can audit the components, move workloads, protect its keys and negotiate from a credible alternative.

The European Commission's Cloud Sovereignty Framework gives this idea an operational shape. It assesses sovereignty across 48 criteria in eight categories, including openness, transparency and independence in the technological stack, rather than treating data location as the whole question. The criteria ask whether software is open-licensed, auditable, modifiable and redistributable, and whether the buyer holds practical rights to inspect code, switch providers and keep control of encryption keys. Sovereignty, in that framing, is something a buyer can test.

Earlier this year I asked who controls AI and answered that it is decided in contracts, not parliaments. In June, when a U.S. order pulled Fable 5 three days after launch, I wrote that the off-switch isn't yours. One was a clause, the other a switch, each at a single layer. This piece is the map of the whole stack, and of where the rest of the switches sit.

Control points sit at different heights. Export controls can limit access to advanced chips even when the code remains open. Cloud concentration can give a small group of providers influence over price, deployment capacity and legal exposure. Proprietary formats can make a supposedly portable workload expensive to move. Contracts can decide who may reuse data, train a model, operate the system or recover it after termination.

The practical test: identify the dependency that can stop deployment or extract the highest rent, then measure how easily you can substitute it.

I approach the subject from a European vantage, but the logic travels. Governments, investors and company operators face the same underlying choice: localise a dependency, diversify it, or accept it while negotiating safeguards. The right answer depends on the layer, the threat and the value at stake.

A binary question, sovereign or not sovereign, produces poor decisions. A graded map of control tells you where to spend money, where to tighten procurement and where a sovereignty label offers little beyond reassurance.

What the Stack Actually Is: From Silicon to Application

The software stack runs from silicon to application, and each layer creates a distinct dependency. Semiconductors and manufacturing tools form the foundations; cloud infrastructure supplies the operating environment; middleware and orchestration coordinate the internal functions; models provide specialised capabilities; and applications convert those layers into services for customers and public institutions.

The foundation begins with advanced chips, the equipment used to manufacture them and the supply chains that make large-scale computation possible. These components determine which workloads can run, at what capacity and under which legal permissions. The U.S. export-control sequence shows why this layer belongs in any sovereignty assessment. Controls began on 7 October 2022, expanded on 17 October 2023, and a rule published on 13 January 2025 introduced worldwide licensing constraints for advanced chips and AI model weights, with compliance set for 15 May 2025 — before the rule was withdrawn ahead of that date, which makes the point rather than weakening it: access to this layer changes by administrative decision. Onelex Partners' practitioner's guide to the U.S. controls traces how those decisions reshape access to the physical and model artefacts beneath software.

Cloud infrastructure sits above that foundation. It provides computing, storage, networking and managed services that turn hardware into an accessible operating environment. Cloud sovereignty therefore concerns more than the location of a server. It includes provider ownership, jurisdiction, control-plane access, support arrangements, resilience and the ability to impose technical or commercial conditions.

Middleware and orchestration connect infrastructure to workloads. They schedule containers, manage identity, expose interfaces and coordinate data movement. Their design often determines whether a customer can move an application without rewriting it. Documented interfaces and replaceable components give buyers more practical control than private formats or undisclosed behaviour.

Models add another dependency. Their weights, training data, inference requirements, safety controls and update processes may sit under different ownership and legal regimes. An organisation can control its application while remaining dependent on a model provider's access policy, pricing, release timetable or permitted uses. That dependency affects both procurement options and the margin available to the application owner.

Applications occupy the visible layer, turning the stack into commercial or public value. They hold the workflows, customer relationships and operational knowledge, so revenue often appears there. Yet lower layers can capture the margin through charges for compute, access, switching and support.

The architecture matters because value can accumulate at a layer the customer never sees. A polished application may depend on infrastructure controlled elsewhere. A local service may still inherit foreign legal exposure. A model may appear open while its compute requirements make independent operation unrealistic.

How Each Layer Creates a Sovereignty Chokepoint

Sovereignty fails at points where another actor can deny access, raise costs, inspect activity, impose conditions or make substitution difficult. Each layer creates a distinct form of control, and the decisive question is who can interrupt operations or capture the resulting margin.

Silicon turns regulation into capacity control

The chip layer converts law into lawful access to scarce technical capacity. Export controls moved from China-specific restrictions in 2022 towards broader oversight in 2025, covering advanced chips and model weights across a wider geography. The documented export-control timeline shows why open code cannot guarantee sovereign capability when the hardware required to run it remains subject to external licensing.

Control here works through permission. A regulator does not need to own an application to influence who can train, deploy or scale it. Whoever controls the relevant manufacturing tools, components or legal authorisations determines the feasible boundary of the software economy. Procurement teams should therefore treat compute access as a contractual and political dependency, not merely an infrastructure input.

Cloud converts concentration into bargaining power

Cloud concentration creates both a commercial and a jurisdictional chokepoint. Synergy Research's Q2 cloud market analysis shows a small number of providers holding a large share of worldwide cloud infrastructure, which places enterprise computing, storage and AI deployment capacity in relatively few hands.

The effect reaches beyond price. Concentration shapes procurement terms, resilience planning, data location and exposure to foreign legal jurisdictions. A buyer that cannot move a workload without redesigning it has surrendered negotiation power before the next renewal. Switching costs transfer value from the application owner to the infrastructure provider, even when the customer owns the end-user relationship.

Software provenance decides whether control can be verified

The software layer determines whether an organisation can inspect, modify and redistribute the components on which it depends. Open licensing does not remove every dependency, but it creates the legal and technical conditions for audit and substitution. Closed components may suit a workload, yet the buyer should price that reliance rather than describe it as sovereignty.

The Sovereign Cloud Stack makes this engineering choice concrete. It uses modular open-source components, including OpenStack and Kubernetes, with open APIs and documented interfaces. The design aims to make provider switching technically feasible while giving users a basis for auditing and adapting the stack without dependence on one supplier. It treats sovereignty as a design property rather than a promise in a sales presentation.

Contracts decide who captures downstream value

At the application boundary, contracts allocate rights over data, formats, models, support and exit. The OECD's analysis of AI in public procurement warns that restrictive data-licensing agreements create data lock-in, and that proprietary technology and formats can leave a public authority heavily reliant on its supplier. Procurement terms are a direct mechanism for allocating interoperability, exit costs and bargaining power.

I therefore treat sovereignty as a map of control, not a description of nationality. An organisation may control its encryption keys, depend on external chips and retain partial control over orchestration. Its position depends on which weakness can interrupt operations, restrict choice or move margin to a supplier. A dependency becomes political when an actor can decide who participates, under which conditions and at what cost — the same logic I applied to social networking maps.

Three Models of Stack Sovereignty in Practice

Three policy models compete for influence, and none delivers complete self-sufficiency. The European approach seeks graded assurance and interoperability. The U.S. approach combines control over critical chokepoints with the reach of hyperscale infrastructure. China's approach places greater weight on substitution when external constraints threaten access.

The European model starts with measurement. The Cloud Sovereignty Framework defines criteria for openness, transparency and independence, while the Cloud and AI Development Act sets four assurance levels for cloud and AI sovereignty. Level 2 requires providers to demonstrate independence from third countries and transparency over their software supply chain, and Member States can recognise providers only after an audit. Provenance and governance become conditions of market access.

The economic aim is buyer power. Public authorities that can compare assurance, retain control of keys, inspect software and switch providers keep more AI-generated value within the European market. The trade-off is practical: criteria, audits and interoperable architecture increase procurement work and may reduce the number of eligible suppliers. European sovereignty is a purchasing discipline, not a nationality test.

The U.S. model works through chokepoint control. Export controls shape access to advanced computing, while U.S.-based providers hold a dominant combined share of global cloud infrastructure. Concentration at the infrastructure layer lets scale reinforce strategic influence. The model captures value through controlled inputs and the recurring rents generated by widely used infrastructure. Customers and foreign governments, in turn, face concentrated dependency, jurisdictional exposure and weaker switching power.

China's model pushes substitution where external restrictions threaten access. Domestic replacement protects continuity and supports domestic demand, but it also creates duplication, compatibility costs and less efficient access to global systems. Its objective is strategic resilience. Its price is the capital and coordination required to replace external components instead of governing dependence on them.

The three models allocate control differently:

• European graded assurance. Lever: criteria, audits, open interfaces and procurement conditions. Trade-off: more verifiable control, with a greater compliance and integration burden.
• U.S. chokepoint control. Lever: export controls, access to advanced computing and hyperscale infrastructure. Trade-off: strategic leverage and scale, with concentrated foreign dependency for buyers.
• Chinese substitution. Lever: domestic replacement of externally constrained components. Trade-off: continuity and policy control, with duplication and interoperability costs.

The relevant question is who pays and who captures the resulting margin. Europe tries to shift power towards buyers and public institutions. The U.S. model concentrates value around controlled inputs and infrastructure. China prioritises continuity through substitution. A European organisation choosing an AI stack is choosing an economic logic as well as a technical arrangement.

Sovereignty is graded by control of chips, cloud capacity, software provenance and contractual exit — not by ownership of every layer.

Turning Sovereignty Into Contracts and Procurement Power

Sovereignty becomes real when a buyer can verify it before signing and enforce it after deployment. A supplier's nationality does not answer the operational questions. The contract must establish who can inspect, move, operate, update and recover the system.

Start with rights, not labels

The European framework offers a useful procurement vocabulary. Buyers should ask whether they can inspect relevant code, modify permitted components, redistribute them where the licence allows, control encryption keys and switch providers without losing essential functionality. These rights turn a broad political objective into acceptance criteria.

The technical architecture must support the contract. The Sovereign Cloud Stack model relies on open APIs and documented interfaces so that provider switching remains feasible. That does not guarantee a cheap migration, but it changes the buyer's position from theoretical portability to an engineering requirement that can be tested.

A serious procurement pack should require evidence for:

• Software provenance: a maintained inventory of critical components, licences, dependencies and update responsibilities.
• Audit access: rights to inspect relevant code, configurations, logs and supply-chain records, subject to legitimate security controls.
• Key authority: customer-controlled encryption keys and a clear process for access, rotation, recovery and revocation.
• Portability: documented export formats, usable interfaces and assistance obligations that do not depend on a single supplier's discretion.
• Operational independence: named responsibilities for incident response, recovery, patching and continuity if the supplier becomes unavailable.
• Termination economics: defined exit support, data return, deletion evidence and limits on charges that could make departure impractical.

Contractual rule: if a supplier cannot explain how you will leave, its sovereignty claim describes dependence, not control.

Treat data rights as value rights

The OECD's procurement analysis places data licensing at the centre of lock-in. A public authority may possess the data physically yet lack the legal right to share it with another developer, reuse it in a replacement system or preserve the formats needed for migration. That arrangement gives the supplier control over the buyer's future options and over the downstream value generated from the data.

Procurement teams should separate three questions that vendors often combine. Who owns or controls the source data? Who may use it to improve a service or model? Who receives the derived outputs, metadata and operational records when the contract ends?

The answers affect margins. If a buyer must pay the incumbent to interpret its own data, the supplier captures value long after the original implementation. I discuss the wider allocation problem in AI task force analysis, where the focus is governance rather than product selection.

The buyer should also demand assurance proportional to the workload. The Cloud and AI Development Act's four-level structure offers a model for graded requirements. A sensitive public service may need verified third-country independence and transparent software supply-chain controls. A low-risk internal workflow may need portability and data rights without the same assurance burden.

The Economics of Sovereignty: When Duplication Pays and When It Does Not

A sovereign stack has a cost, but so does dependence. The mistake is to count only duplicated infrastructure and ignore the price of lost bargaining power, restricted access, regulatory delay or an exit that arrives during a crisis.

IDC reported in 2026 that 63% of organisations were more likely to adopt sovereign cloud services because of geopolitical events. The same analysis projects that by 2028, 60% of multinational firms will split AI stacks across sovereign zones, with integration costs tripling as fragmentation rises. Demand for control is rising while fragmented architectures impose a material integration burden.

That does not make duplication irrational. It means the investment needs a defined purpose. Redundancy for critical infrastructure protects continuity. Local control preserves access to regulated markets. Open components reduce the future cost of switching. But duplicating a commodity service without reducing a real dependency transfers money from the buyer's margin to another infrastructure layer.

A portfolio decision for finance leaders

I would divide the stack into three portfolios.

Protect: localise or duplicate layers where failure, legal intervention or supplier withdrawal would threaten essential operations. Chips may be difficult to localise, but organisations can still plan capacity, workload priorities and alternative execution paths.

Negotiate: manage dependencies where replacement would be uneconomic. Use open interfaces, key control, audit rights and term limits to keep the supplier's influence bounded. This is often more rational than rebuilding every component.

Replace: invest in open or domestic alternatives where the dependency captures significant value and substitution is technically feasible. The decision should include migration cost, support capability, security maintenance and the effect on interoperability.

The EU's 2026 technology sovereignty agenda links semiconductors, cloud, AI and open source, and aims to triple data-centre capacity over five to seven years. The European Parliament's study on software and cyber dependencies shows why capacity-building cannot be separated from software and procurement choices. More capacity helps, but it does not create sovereignty if control planes, licences and support remain external.

The margin question is therefore sharper than "can we build it ourselves?" It is "which dependency can extract the most value from us, and what is the cheapest credible way to reduce that leverage?" I explore how concentrated suppliers capture economic surplus in producer surplus and monopoly.

What Decision-Makers Should Do Next

Operators should map the stack by dependency, not by vendor logo. Record who controls hardware access, cloud accounts, keys, source code, model weights, data formats, updates and recovery. Then rank each dependency by the damage it could cause and the cost of replacing it.

Investors should treat sovereignty claims as evidence questions. Ask whether a company controls a genuine chokepoint, has portable architecture, or repackages externally controlled infrastructure. Revenue can grow while strategic control declines if the supplier captures the critical margin.

Policymakers should set graded procurement gates rather than demand theatrical self-sufficiency. Require auditable software supply chains, open interfaces, portable data, customer key control and credible exit plans where public value or security justifies the burden.

The next quarter's decision is practical. Choose one high-value dependency, document the rights you need, test a migration path and price the cost of remaining exposed. Sovereignty becomes useful when it changes that decision.

Where this leaves our own stack

I ran the same test on ELECTE before writing this. The honest answer is not that we are sovereign. It is that we know which suppliers could interrupt us, what they can see, and what it would cost us to leave, and that we have kept that list short on purpose. ELECTE platform 4.5, which we announced this week, was built to the same rule. That is the only sovereignty claim I would ask you to verify, for us or for anyone else.

Sources

• European Commission, Sovereign Cloud Framework explained (June 2026)
• European Commission, Cloud and AI Development Act
• Onelex Partners, US export controls and AI: a practitioner's guide
• Synergy Research Group, Q2 cloud market passes $143 billion, highest growth rate in eight years
• Sovereign Cloud Stack, About SCS
• OECD, Governing with Artificial Intelligence: AI in public procurement (2025)
• IDC, The high cost of sovereignty in the age of AI (2026)
• European Parliament, Study on software and cyber dependencies (2025)

Fabio Lauria

CEO & Founder, ELECTE

Every week, we explore AI without the hype — using data, analysis and an independent perspective.