Digital sovereignty in Europe and dependence on AI

By Ivo Donker — compiled with AI assistance (Claude & Gemini) · Last updated: August 7, 2026

The rapid rise and integration of artificial intelligence (AI) and large language models (LLMs) into business processes, government systems, and societal infrastructure has brought the question of digital sovereignty to the forefront of the European policy debate. AI is no longer merely a category of software applications; it increasingly forms a fundamental infrastructure layer on which decision-making, productivity, and innovation rest. When crucial parts of this infrastructure lie outside one's own jurisdiction or sphere of influence, strategic vulnerabilities arise.

In European societal and political discussions, terms such as 'sovereignty,' 'autonomy,' and 'self-sufficiency' are regularly used interchangeably. This can lead to unrealistic expectations and unclear policy. A thorough analysis of AI dependence requires dissecting the entire chain — from physical silicon chips to the final user interface —. Each level, after all, has its own dynamics, concentration of market power, and specific dependency risks.

Conceptual confusion: Sovereignty, autonomy, and self-sufficiency

To conduct the debate about Europe's position in the global AI sector properly, a clear distinction between three frequently confused concepts is necessary:

• Digital self-sufficiency (autarky): This refers to the situation in which a region or state produces and manages the entire technology chain within its own borders, without any dependence on foreign suppliers. In global AI infrastructure, full self-sufficiency has proven practically unattainable due to extreme complexity, the geography of raw materials, and the global distribution of specialized knowledge.
• Strategic autonomy: This concerns the ability to make decisions and choices independently, as well as having alternative options available when a dominant supplier or trading partner falls away. Autonomy does not imply that everything is built locally, but it does mean that dependencies cannot be used as a means of coercion.
• Digital sovereignty: This concerns the rule-of-law and political capacity to enforce one's own laws, values, and norms on digital technologies used within one's own territory. It is about governments and citizens retaining control over the rules that data processing, algorithmic decision-making, and market access must comply with.

When the objective of digital policy is framed as 'full self-sufficiency,' one risks inefficient capital allocation and lagging innovation. If, instead, the emphasis is placed on strategic autonomy and legal sovereignty, the focus shifts to risk management, diversification of suppliers, and anchoring legal protection.

The AI stack: Seven layers of dependence

Dependence in AI is not a binary fact, but manifests itself in different ways across the individual layers of the technology chain. To understand where the biggest bottlenecks lie, the so-called 'AI stack' must be analyzed layer by layer.

1. Chips and hardware production

The bottom layer of the stack consists of physical silicon: specialized graphics processors (GPUs), accelerators, and memory modules. This market has extreme technological barriers and geographic concentrations. Design, advanced lithography, and final chip manufacturing are divided among a very limited number of global players. A disruption in the hardware supply chain has direct consequences for the capacity to train models or run them at scale. For deeper insight into the global hardware balance, we refer to the analysis on the global chips and hardware race.

2. Data centers and energy infrastructure

AI models require significant computing power, which translates into physical data centers with high requirements for electricity, cooling, and network capacity. Although these data centers can be geographically located on European soil, the management, cooling technologies, and required network equipment are often dependent on international suppliers. In addition, the strain on the local power grid forms a physical limit to expanding compute capacity. You can read more about this in the overview of data centers and AI in the Netherlands.

3. Cloud platforms and hosting

The storage of data and the execution of training and inference processes predominantly take place through large cloud platforms (hyperscalers). These parties provide not only the physical servers but also the software orchestration layers, databases, and management services. When an organization builds its AI architecture entirely on proprietary cloud services, a strong technological dependence arises that makes switching to another provider costly and complex.

4. Model weights and architecture

The foundation model itself forms the computational core of modern AI use. Models whose parameters (model weights) remain locked behind an API give the user no insight into the exact workings and no control over updates or the revocation of access. Not having access to the model weights means organizations are dependent on the model maker continuing to provide the service.

5. Training data and curation

A model is the product of the data on which it was trained. The quality, diversity, and representativeness of the texts, images, and source code used determine the output. When training datasets are mainly composed of foreign or English-language sources, the values, legal frameworks, and cultural assumptions embedded in them seep into the model. Control over high-quality, locally relevant training data is therefore a crucial layer in the chain.

6. Talent, developers, and academic knowledge

The development of advanced AI models requires highly specialized knowledge of model architectures, optimization algorithms, and data processing. A lack of local experts and researchers limits the ability to build, validate, or adapt models independently. Knowledge dependence means that a region can indeed procure technology, but cannot independently steer its direction.

7. The application layer and integration

At the top of the stack are the software applications end users work with: chatbots, assistants, analysis tools, and integrated business systems. If this application layer is closed and directly tied to specific underlying models, end users have little room to replace underlying components or adapt them to local requirements.

Technical versus legal dependence

A common misunderstanding in the sovereignty debate is that physically storing data or running a model within the borders of the European Union automatically means full sovereignty. This overlooks the crucial distinction between technical and legal dependence.

Technical dependence concerns the question of whether a system can keep functioning when the connection to an external supplier is interrupted. If a locally installed application is continuously dependent on authentication servers, license checks, or telemetry connections to servers outside Europe, the system remains vulnerable to operational disruptions, regardless of where the primary data is stored.

Legal dependence concerns the legal system that applies to the organization providing the service or managing the infrastructure. A subsidiary of a foreign entity operating within the EU must indeed comply with the European GDPR (Algemene Verordening Gegevensbescherming, AVG), but can simultaneously be subject to the legislation of the parent country. Laws with extraterritorial effect can require the parent organization to grant access to data or systems, regardless of the physical location of the server. Storing data on European soil with a non-European provider therefore only partially resolves the legal dependence.

For organizations working with privacy-sensitive or commercially confidential information, this distinction is essential. In practice, decision-makers must map out both the technical data flows and the legal ownership and control structures of their suppliers. For further depth on the contractual aspects, see the guide on data retention and AI suppliers and the requirements for on-premise LLM infrastructure.

The role and limits of open model weights

In the debate about reducing AI dependence, making open model weights available (often referred to as open-source AI) is regularly presented as a partial solution. When a model's weights are freely accessible, organizations can download the model, host it themselves, and adapt it without depending on an external API service.

What open model weights do solve

• Continuity and independence from the supplier: Once a model has been downloaded, it cannot be remotely disabled or changed by the original creator. The organization retains control over the version running in production.
• Data privacy and confidentiality: Because inference can take place entirely on the organization's own infrastructure, no data needs to be sent to external servers. This prevents sensitive data from being used to retrain external models.
• Adaptability and control: Open weights allow developers to further fine-tune the model on specific domain knowledge or tasks, and to inspect internal layers for unwanted patterns.

What open model weights do not solve

• Hardware dependence: Running large open-weight models still requires powerful compute infrastructure. The dependence thus shifts from the AI software supplier to the supplier of the hardware and cloud infrastructure.
• Maintenance and security updates: Managing a model yourself means the organization is itself responsible for monitoring performance, applying security controls, and implementing improvements. The continuous support that a commercial API service offers falls away.
• Transparency of the training pipeline: Having the model weights available does not automatically mean that the full training data, curation code, and exact training steps are also public. As a result, the model's origin story remains partly opaque.

The choice between open and closed models is therefore not a simple trade-off between 'full freedom' and 'total dependence,' but rather a strategic choice between different kinds of costs, risks, and management burdens. For a broader market analysis, see the publication on open versus closed models and market developments.

Language and culture as a sovereignty issue

AI models are not neutral; they reflect the language, culture, and values embedded in the data they are fed. For smaller language regions, such as the Dutch language area, this poses a specific sovereignty risk.

When large foundation models are trained mainly on English- or Chinese-language data, with only a limited fraction of Dutch-language sources, several content-related and functional bottlenecks arise:

1. Blurring of nuance and terminology: The model may struggle with specific legal, administrative, and cultural terms that are unique to the Dutch or Belgian context. Translations can be legally imprecise or misinterpret societal concepts.
2. Cultural and values bias: Models adopt the norms, values, and social conventions from the dominant part of their training data. This can lead to answers that do not align with local legislation, ethical standards, or social conventions.
3. Economic and functional drawbacks: If models handle Dutch-language text less efficiently (for example due to less optimal 'tokenization'), processing costs per task rise for Dutch-language applications compared to English-language applications.

Preserving one's own language and culture in the digital domain requires that sufficient high-quality, locally rooted training data is available and that models are developed that take the Dutch language and societal context as their starting point. For an extensive treatment of this specific topic, we refer to the background analysis on language diversity in LLMs and the position of Dutch.

Trade-off: Europe's own capacity versus the market

In the societal debate about AI sovereignty, two main schools of thought stand opposed: proponents of building strong, independent European AI capacity, and proponents of a market-driven, international approach. Both perspectives have valid arguments and substantial trade-offs.

Arguments for building Europe's own capacity

• Supply security and continuity: In the event of increasing geopolitical tensions or trade conflicts, access to foreign technology can be restricted or made conditional. Having one's own capacity protects critical processes against sudden cutoff.
• Enforcement of legal protection and ethical standards: By bringing the entire technology chain under European jurisdiction, compliance with privacy legislation, copyright, and transparency requirements can be enforced more strictly.
• International negotiating position: A region that has its own credible alternatives stands stronger in international discussions about standards, norms, and trade terms.

Counterarguments and practical obstacles

• Extremely high capital intensity: Developing advanced hardware and training the largest foundation models requires enormous investments. Raising such funds from public or private European sources can come at the expense of other priorities.
• Risk of a quality gap: When European alternatives lag behind in performance, functionality, or usability, local companies and institutions are forced to work with less competitive tools, which can weaken their global competitive position.
• Market fragmentation: Europe consists of multiple national markets with different languages, regulations, and priorities. Building a single consolidated European player that can compete in scale with global giants runs into administrative and cultural barriers.

The policy dilemma is not about choosing between 'making everything ourselves' or 'importing everything,' but about determining which parts of the technology chain are so critical that a lack of independent control creates unacceptable risks.

Practical courses of action for governments and organizations

For organizations and government bodies that need to make decisions in the short and medium term, waiting for full European technological independence is not a realistic option. There are, however, concrete strategic and operational measures to manage dependencies without giving up the benefits of advanced AI technology.

1. Separating workloads based on sensitivity

Not all data and processes carry the same risk profile. A well-thought-out security model categorizes tasks:

• Non-sensitive processes: Publicly accessible information or general creative tasks can safely make use of efficient, commercial cloud models.
• Confidential processes: Business-sensitive data or personal data require controlled environments, such as hosted open-weight models within a protected European cloud or certified virtual private environments.
• Critical infrastructure: Core state processes or highly confidential data set the highest requirements and should, where possible, run on-premise or within a fully isolated sovereign cloud.

2. Portability and architectural decoupling

Organizations must prevent their applications from being directly and inseparably tied to the specific API of a single model maker. By setting up an abstraction layer (a so-called model gateway or orchestration layer), an organization can quickly switch between different underlying models when costs, quality, or legal terms change.

3. Multi-provider and multi-cloud strategies

Spreading dependencies across multiple independent suppliers and geographic regions reduces the risk of operational outages or supplier coercion. This applies both to the cloud infrastructure and to the AI models used.

4. Sharp contractual terms and audit rights

When procuring commercial AI services, clear contractual safeguards must be demanded regarding:

• The explicit prohibition on using submitted customer data to retrain the supplier's models.
• Guaranteed options for data exfiltration and complete deletion of data upon termination of the service.
• The right to independent audits of compliance with agreed security and privacy parameters.

Open questions for the future

The debate about digital sovereignty and AI dependence is in constant flux. A number of fundamental questions remain unanswered for now and will shape policy in the coming years:

• How does technological protection relate to global innovation? Is there a danger that too strong an emphasis on regulation and local control leads to a wider digital gap with regions that embrace new technologies faster?
• Is a 'European sovereign cloud' feasible without foreign technology? To what extent can European initiatives function in the short term without using intellectual property, components, or software layers of foreign origin?
• How is the relationship between public funds and private market initiatives developing? Should the government act as a launching customer and investor in national AI infrastructure, or should market development be left primarily to private parties?

Digital sovereignty in the AI era is not a final destination reached with a single policy decision, but a continuous process of risk assessment, strategic investment, and thoughtful architectural design. Organizations that make clear choices now in separating their workloads, decoupling their systems, and diversifying their suppliers are building a resilient and future-proof digital position.