The Real Risks Behind Technology Sovereignty

Technology sovereignty is not about eliminating dependencies. It is about understanding the leverage they create: who can change the rules, who pays the price, and who still has options when things change.

Amodiovalerio Verde

• 9 min read
The Real Risks Behind Technology Sovereignty

An exploration of technological sovereignty - Part 2.

In Part 1, I argued for selective sovereignty: use the strongest technology available, keep credible alternatives for critical dependencies and apply a higher threshold to context competitors cannot easily recreate.

But that leaves a question: what exactly are we protecting ourselves from?

Terms such as control, resilience and strategic autonomy only become useful when we can describe a failure mode.

So I tried a different approach.

Rather than asking whether a technology is sovereign, I started asking what power our dependency gives somebody else.

The list became longer than I expected.

Can they stop me?

This is probably the most obvious risk.

A critical technology comes from somewhere else.

One day, for whatever reason, access changes.

Perhaps your provider makes the decision, or their government does.

Maybe it is the result of sanctions, export controls, national-security policy or a deteriorating geopolitical relationship.

We already know that governments are willing to restrict access to important technology. US export controls currently place restrictions on advanced computing technology depending on destination, end use and entity. And while some countries are eligible for certain AI-related authorizations, other destinations face much tighter restrictions.

That distinction matters.

I am not suggesting Europe is about to lose access to US technology.

That would be speculation and my point is simpler.

The mechanism exists.

Governments have demonstrated that access to advanced technology can become an instrument of national policy. The US has already restricted China's access to some advanced computing chips and semiconductor technology, for example.

If AI becomes as important to economic competitiveness as many of us expect, it seems optimistic to assume access will always remain purely a commercial decision.

Access also does not have to disappear entirely. New licenses, capacity restrictions, delayed access or limits on particular workloads can be enough to hurt. A critical dependency does not need to disappear completely to become strategically painful.

That is why second sourcing matters, but the principle is not new.

During my MBA studies, I remember learning the fairly unremarkable idea that relying on one supplier for something critical creates risk.

There was nothing particularly technological about it.

AI infrastructure is not fundamentally different.

Except that in this case, the supplier relationship can also sit inside a geopolitical relationship.

Can they make me less competitive?

This risk interests me more.

Imagine nobody switches you off.

You still have access, your applications continue working and your engineers can still call the API.

But the economics change.

What happens if the cost of a critical technology increases significantly in your market but not another?

What happens if companies in one jurisdiction receive earlier access to capacity?

Or preferential access to a new model? Or better commercial conditions? Or simply more certainty about future access?

The effect does not need to look like a sanction.

It can show up in unit economics.

Suppose two companies compete globally.

They use similar models for a capability representing a meaningful part of their cost base.

One can access the technology at €1 per unit.

The other, because of geography, regulation or policy, effectively pays €1.40.

Neither company has been prevented from competing.

But one starts every transaction forty cents behind.

Do that across enough of the technology stack and sovereignty stops looking like a political concept and it becomes margin.

The reverse can also happen.

Europe can impose requirements on European companies that increase cost or slow deployment while competitors elsewhere operate under different constraints.

That is part of the same strategic question.

Sovereignty is not automatically an advantage. Poorly designed sovereignty can become its own competitive disadvantage.

This is why I struggle with the argument that the answer is simply to use European technology.

A sovereign alternative that is materially more expensive or significantly less capable imposes a real economic cost. That trade-off needs to be justified by the risk it mitigates.

The objective cannot be independence at any price.

The objective should be to understand where dependency gives somebody else enough leverage to alter your competitive position.

Can they decide what I am allowed to use?

Access is not binary.

There is another version of dependency where I keep the platform but not necessarily its best capabilities.

A provider, or the jurisdiction behind it, may decide that certain models, chips, features or tools are available only to particular customers or countries.

Again, there is precedent for technology access being differentiated geographically.

The US introduced an AI Diffusion Rule in January 2025 that would have given countries different levels of access to advanced AI computing. The US later decided not to enforce it. But other export controls still restrict access based on country, company and intended use.

I find that revealing, even though the rule was never enforced.

Advanced AI capability can be treated as strategic infrastructure, not simply ordinary software.

Once that happens, I think companies need to consider a new risk:

What happens if the technology continues to exist, but I am no longer in the group allowed to use the best version of it?

That question would have sounded strange for most SaaS products ten years ago.

It sounds less strange now.

Can they learn something from me?

This is where I think the sovereignty discussion gets mixed up with the data discussion.

They overlap, but they are not the same.

There are at least three different risks here.

The first is privacy.

We already have frameworks such as the GDPR governing how personal data can be processed and transferred.

The second is jurisdiction.

Where the server sits does not necessarily tell you which laws can reach the provider.

Under the US CLOUD Act, for example, providers subject to US jurisdiction can be required through valid legal process to produce data within their custody or control even where that data is stored outside the United States. The US Department of Justice is also explicit that this is not unlimited government access and does not remove the normal legal requirements for obtaining the data.

The important point for me is not specifically the CLOUD Act.

Other jurisdictions have their own mechanisms.

It is that data location and legal jurisdiction are different things.

Putting something in a Frankfurt data centre does not necessarily mean the strategic question has been solved.

Then there is competitive information.

Suppose I send a provider customer conversations, proprietary research, source code, expert corrections, evaluation results, agent traces or thousands of examples showing how my business actually works.

Perhaps the provider contractually commits not to train its models on any of it.

Good. That materially changes the risk.

But I still want to understand what is retained, logged, processed, observable, recoverable and accessible.

These questions are about assessing the safeguards around a dependency, not assuming that a provider will misuse information.

Because I may want a higher bar before strategically valuable information leaves a boundary I control.

There is a useful distinction here:

Compliance asks whether and how information may lawfully be processed. Strategy asks whether exposing it is a good decision in the first place.

Those questions can produce different answers.

Can I realistically leave?

Part 1 raised the problem of credible alternatives. The risk becomes real when a company has to switch under pressure: can it move a critical workload within the time the business can tolerate?

A company tells itself it has optionality because there are three major cloud providers.

Technically true.

But perhaps its application uses one provider's database. And identity system. And event bus. And AI gateway. And model API. Its engineers have spent five years becoming experts in that ecosystem.

This problem is significant enough that the EU Data Act includes explicit measures intended to make switching between cloud and other data-processing services easier.

It addresses issues including lengthy migration procedures, interoperability and data-egress charges. From 12 January 2027, charges for switching between data-processing providers, including associated data-egress charges, are due to be prohibited under the Data Act.

Regulation may lower switching barriers, but it cannot redesign the architecture or train the team. A slide showing two providers, or even a procurement contract, does not establish resilience.

The old disaster-recovery principle applies: a backup you have never restored is not really a backup. A second source deserves the same test. Can a critical workload move? How long would it take, and what would break or degrade?

Who gets the scarce capacity?

There is another risk that does not require anyone to act against you: scarcity.

We tend to discuss cloud as though it is infinite.

AI reminds us that it is physical.

GPUs must be manufactured, data centers need electricity, and networks and supply chains have bottlenecks.

The European Commission's proposed Cloud and AI Development Act explicitly describes computing infrastructure as a strategic resource and points to Europe's limited and geographically concentrated computing capacity and dependency on non-European providers as resilience and competitiveness concerns.

Imagine another major shortage of advanced compute.

Nobody needs to block Europe.

There may simply not be enough capacity for everybody.

Then allocation matters.

Who gets served first?

Governments? The provider's largest strategic customers? Domestic companies? Long-term contracted capacity? Or maybe whoever is willing to pay the most?

I do not know.

That uncertainty is the risk.

When an input becomes both scarce and strategic, your position in the queue becomes part of your resilience architecture.

Can they change the rules underneath me?

There is one final category I initially missed because it is less dramatic.

What if nothing is taken away?

The service remains available, the price remains acceptable and the data remains protected.

But the behavior changes:

A model update can change outputs. A new safety policy can redefine what a system is allowed to do. APIs can be deprecated, capabilities can move behind different commercial tiers, and previously supported workflows can become restricted. Ecosystem standards evolve, and providers may take their platforms in directions that no longer align with your needs.

None of this requires geopolitics.

It is ordinary supplier power.

But geopolitical dependency amplifies it because the alternatives may already be limited.

This is why I increasingly think technical portability is part of sovereignty.

Not because everything needs to be portable.

That would impose its own cost.

But the more critical the capability, the more uncomfortable I become when all of the technical decisions make leaving progressively harder.

I think there are five questions

Some scenarios overlap. Restricted capabilities are a form of restricted access; scarcity can become a competitive disadvantage. I find it useful to reduce the risks to five questions.

1. Can they stop me?

Can somebody outside my control remove or materially constrain access to something critical?

2. Can they make me less competitive?

Can they alter my economics, capacity or capability relative to competitors?

3. Can they learn something from me?

Am I exposing information that is difficult to reproduce and strategically valuable?

4. Can I realistically leave?

Do I have an alternative that works in practice, rather than one that exists on a procurement slide?

5. Can they change the rules faster than I can respond?

Would the system remain acceptable if commercial incentives, regulation or geopolitical relationships changed?

I find these questions more useful than asking whether a provider is sovereign.

Because the answer does not have to be yes or no.

Different workloads produce different risk.

Not every dependency needs solving

There is an obvious trap in this argument. Once you start listing risks, everything can sound dangerous.

That leads quickly to: build everything yourself; store everything yourself; use only domestic suppliers; never depend on anyone. Resilience taken too far can lead to bankruptcy.

The goal is not to eliminate dependency. It is to identify concentrated dependency with asymmetric consequences.

If a minor internal tool disappears and I can replace it next week, the supplier's headquarters may not matter. If the same event would stop my product, expose differentiating information or structurally change my economics, it matters considerably more.

Some choices are non-negotiable because of law, regulation or customer commitments. Beyond that, the level of sovereignty should follow the consequence.

Which brings me back to leverage

I started Part 1 thinking about control. After working through these risks, I think the more useful word is leverage.

The risk is not simply that someone else provides my technology. It is how much unilateral power that dependency gives them. If that power is limited, perhaps sovereignty matters less for that capability. If it is substantial, I want options, whether through another provider, portability or tighter control of the information I share.

Sovereignty cannot be reduced to where technology comes from. It is about how much power you give away when you depend on it.

And perhaps that is the risk test I was looking for:

If this dependency changed tomorrow, who would have more decisions available to them: us, or them?

The more asymmetric that answer becomes, the more seriously I would take sovereignty.

Sources

Disclaimer

The views expressed are my own and do not represent those of any current or former employer. Hypothetical scenarios are illustrative and are not intended to describe any employer, its customers, partners, or internal practices.