AI sovereignty between the United States, China, and Europe

An AI project often looks like a sequence of technical decisions: choose a model, connect data, build an interface, test quality. Beneath each decision sits another layer. Who controls the compute? Which law applies to the provider? Who may supply chips, model weights, or updates? What happens when a government changes export rules, a provider withdraws a service, or a licence becomes narrower?

These are not foreign-policy extras. They affect cost, schedule, procurement, architecture, and operational continuity. Geopolitics is therefore a normal project factor.

AI sovereignty is not a claim about origin. It is the demonstrated ability to understand, limit, and—when necessary—change critical dependencies.

Why geopolitics appears in the project plan

The United States, China, and Europe pursue different industrial, security, and regulatory objectives. Those objectives reach markets through export controls, investment, procurement rules, standards, platform terms, and national regulation. A project does not experience this as abstract world affairs, but as a model catalogue, region setting, contract clause, price, review, or delivery time.

Geopolitical exposure belongs in risk, architecture, and procurement decisions. Dependency itself is not automatically bad. Invisible and untested dependency is.

Sovereignty is not autarky

No realistic team controls the entire AI value chain: semiconductor design, fabrication, data centre, energy, foundation model, framework, data, application, and operations. Complete independence is therefore not a practical objective.

Operational sovereignty means knowing which external services are critical, which rights and restrictions apply, which parts remain replaceable, and how long a switch would take. The project deliberately decides where dependency is acceptable and where an alternative is required.

Data residency is only one question

A European server location may matter for privacy, latency, or procurement. It does not automatically answer which corporate law governs the provider, who controls keys and administrative access, whether subprocessors are involved, or whether models, telemetry, and support processes originate elsewhere.

Four questions must be assessed separately: Where is the data? Who can technically access it? Which law binds the parties? Who can change or terminate the service? Only the combination produces a robust view.

The AI value chain as a dependency chain

A project should not draw its value chain as a single “cloud” box. At least these layers belong in the map:

The map shows why a locally operated model can still depend on imported hardware, foreign drivers, external weights, or a restrictive licence.

Control, capability, and optionality

Sovereignty has three dimensions. Control concerns rights, keys, configuration, and decision authority. Capability asks whether the internal team can understand and operate the system. Optionality asks whether realistic alternatives exist.

A project may own extensive contractual rights and still lack sovereignty if nobody can perform an export, model switch, or restart. Technical skill, in turn, cannot replace missing rights. All three dimensions matter.

The United States: scale, private platforms, and strategic exports

The US approach combines private innovation and capital strength with large-scale infrastructure, semiconductor policy, and international technology policy. The official 2025 AI Action Plan frames innovation, infrastructure, and international diplomacy and security as three pillars. It explicitly addresses exporting American AI technology and enforcing controls on advanced compute.^[1]

Projects gain access to high performance and a broad ecosystem, but often face concentration around a small number of platforms. Corporate decisions and government rules can therefore affect model access, cloud capacity, and hardware at the same time.

China: industrial coordination, infrastructure, and controlled openness

China combines rapid industrial deployment, expansion of computing infrastructure, domestic chips and models, and state security and content requirements.^[4] Its 2025 Global AI Governance Action Plan emphasises infrastructure, open ecosystems, interoperability, national sovereignty, and safety and controllability.^[3]

Chinese models may be technically or economically attractive to a European project. Origin, licence, hosting route, update policy, content rules, and possible trade restrictions still require examination. Open weights do not remove those questions.

Europe: rules, infrastructure build-out, and strategic autonomy

Europe combines rights- and market-based rules with efforts to build its own compute, data, and semiconductor capacity.^[8] Since January 2026, EuroHPC can support AI Gigafactories.^[5] In April 2026, EuroHPC reported 19 AI Factories and 13 Antennas under implementation or coordination.^[6]

This is an infrastructure pathway, not completed independence. Projects must still verify what capacity is actually accessible, which models and tools run there, what waiting times apply, and whether their operating case is supported.

No region is a uniform product attribute

“US provider,” “Chinese model,” or “European cloud” are too broad for approval. Operators, owners, subprocessors, licences, security practices, and technical portability vary widely inside every region.

Regional origin is an input signal, not a verdict. Decisions require concrete provider, service, version, and contract data.

Export controls become architecture parameters

Export controls do not only address states. They can affect chips, manufacturing equipment, software, re-exports, use, and supply chains. In 2025, the US Bureau of Industry and Security published guidance about certain advanced Chinese computing chips and warned about possible enforcement consequences.^[2]

A project team need not become a trade authority. It must recognise when hardware origin, user location, data-centre region, or contracting party triggers specialist review. That review belongs before procurement, not after disruption.

Regulation can split markets

A model or service may be available in one region, restricted in another, and usable only with additional controls in a third. Reasons range from privacy and product safety to content, security, and national requirements.

A global application therefore needs a deployment matrix rather than one blanket approval: region, user group, data type, model route, required control, and permitted feature scope.

Open source is not automatically sovereign

Open code supports inspection, adaptation, and switching. Open weights may enable operation outside one API provider. Yet training data may remain unknown, licences may restrict uses, hardware needs may be high, and updates may depend on a small organisation.

The right question is not “Is it open source?” but: Which rights, artefacts, capabilities, and resources do we actually possess to keep operating without the original provider?

Closed APIs are not automatically non-sovereign

A closed API can be a sound choice for a non-critical, bounded workload. If inputs are controlled, outputs reviewed, data exportable, and a replacement route prepared, the dependency can remain manageable.

Sovereignty does not require ownership of every component. It requires that the loss of an external component does not unexpectedly destroy the entire service.

Concentration risk spans multiple layers

A team may use three apparent providers while still depending on the same infrastructure. Several model APIs may run on one hyperscaler. Different clouds may rely on the same chip family, identity provider, or open-source library.

Concentration must therefore be measured at the last common economic and technical dependency. Provider count is not proof of diversity.

The Dependency Ledger exposes the real position

Create one record for every critical project function:

The ledger is a living project artefact, not a one-off compliance appendix.

Assess criticality before origin

Not every foreign dependency requires a fallback. A replaceable translation feature deserves different treatment from a model that carries medical prioritisation, a production process, or the core product promise.

Assess outage impact, restart time, data loss, contractual consequences, and customer harm first. Then decide what level of control and redundancy is economically justified.

Substitutability must be demonstrated

“We can switch later” is a hypothesis. Evidence consists of a successful export, a running replacement route, a measured quality difference, a documented changeover, and a realistic time estimate.

Without a test, the supposed fallback is often just another provider name on a slide.

Portability starts with your own artefacts

Prompts, system rules, evaluation cases, data models, interface contracts, embeddings, logs, and decision logic should be stored independently of the provider wherever practical. Proprietary capabilities should sit behind adapters rather than spreading unnoticed through the whole process.

Exportable raw data and reproducible evaluation sets are especially important. A team that keeps only final outputs cannot reliably assess a model switch.