What data sovereignty means for an executive

Data sovereignty is not a technical concept. It is a concept of control. It means your company decides where its data resides, who accesses it, under which laws it is processed and what happens if you switch providers.

When you use a cloud AI model (ChatGPT, Claude, Gemini), your data travels to servers outside your control. In most cases, they are in the United States. That implies:

• Jurisdiction: your data is subject to US laws (CLOUD Act, FISA 702). US authorities can access it without a European court order.
• Opaque processing: you do not know exactly what the provider does with your data. The privacy policies of major AI providers reserve the right to use data to improve their models (though many offer opt-out).
• Dependency: if the provider changes prices, terms or shuts down the service, you lose access to your own processes. On March 15, 2025, a major AI provider raised prices by 40% with 30 days' notice. Dependent companies had no alternative.

Sovereignty means having options. It does not necessarily mean self-hosting. It means you can choose, migrate and control.

The regulatory framework: GDPR, AI Act, NIS2

Three European regulations converge to make data sovereignty a strategic matter, not just operational:

GDPR and international transfers

The GDPR requires that personal data of European citizens be processed with adequate safeguards. Transfers to the US are covered by the EU-US Data Privacy Framework (DPF), but its legal stability is questionable. The Court of Justice of the EU already invalidated two prior frameworks (Safe Harbor and Privacy Shield). If the DPF falls, every company processing personal data via US APIs is in non-compliance overnight.

Implication for AI: if your AI system processes personal data (names, emails, client histories, employee data) and sends it to a US API, you are assuming a real regulatory risk.

AI Act and data requirements

The AI Act requires that high-risk systems document training data, demonstrate they have no significant bias and allow auditing. If you use a proprietary model (GPT-4, Claude), you have no access to the training data. You cannot document what you do not control. For high-risk systems, this is a compliance problem.

NIS2 and critical sectors

The NIS2 Directive (mandatory since October 2024) affects essential and important entities: energy, transport, banking, healthcare, water, digital infrastructure, public administration. These entities have reinforced cybersecurity obligations that include the supply chain. If your AI provider is part of your digital supply chain, it is subject to your NIS2 obligations.

Open-weight models explained without jargon

AI models fall into two categories: proprietary (closed) and open-weight (open). The difference is not quality. It is control.

Proprietary models

GPT-4o, Claude, Gemini. You access them via API. You cannot download, modify or run them on your own infrastructure. They are excellent in capability, but you depend entirely on the provider for pricing, availability, data policies and performance.

Open-weight models

Llama (Meta), Qwen (Alibaba), DeepSeek, Mistral. You can download the model weights and run them on your own infrastructure. Your data never leaves your network. There is no dependency on an external provider for execution.

What an executive needs to know about the most relevant open-weight models in 2026:

Cloud vs self-hosted vs hybrid: decision framework

There is no universal answer. The decision depends on 4 factors you can evaluate with your team:

Factor 1: Data sensitivity

• Public or non-sensitive data (marketing content, product information, FAQs): cloud is sufficient. No significant regulatory risk.
• Internal data (financial reports, strategy, operational data): evaluate case by case. Cloud with a solid DPA (Data Processing Agreement) may be acceptable.
• Personal or regulated data (client data, employee data, patient data, financial data): self-hosted or hybrid with end-to-end encryption. The regulatory risk justifies the investment.

Factor 2: Industry regulation

• Banking, insurance, healthcare: strict regulation on where data is processed. Self-hosted or European cloud with specific certifications.
• Public administration: ENS (National Security Framework) requires strict control in High categories. Self-hosted mandatory for classified data.
• Other industries: risk assessment, not an absolute obligation.

Factor 3: Technical capability

• No technical team: cloud. It makes no sense to set up AI infrastructure without the capacity to maintain it.
• Basic IT team: hybrid. Cloud for general tasks, self-hosted for sensitive data using managed solutions.
• Full technical team: self-hosted is viable and often more economical long-term.

Factor 4: Usage volume

• Low (under 1 million tokens/day): cloud is more economical. The cost of own infrastructure is not justified.
• Medium (1-10 million tokens/day): crossover point. Evaluate comparative costs.
• High (over 10 million tokens/day): self-hosted is significantly cheaper. The per-token cost on own infrastructure can be 5-10x lower than API.

Real cost comparison

API providers charge per token. Own infrastructure has a fixed cost. The crossover point depends on volume. This comparison assumes a ~30B parameter model, enterprise quality:

For an SME with 50 employees using AI for general productivity (emails, reports, analysis), typical volume is 500K-2M tokens/day. In that range, cloud is usually more economical and practical. For a 500-employee company with intensive usage, self-hosted can save 60-80% on AI costs.

Vendor lock-in: the risk nobody calculates

Vendor lock-in is when your company depends so heavily on a provider that switching is impractical or prohibitively expensive. In AI, lock-in is particularly dangerous because it accumulates across three layers:

Layer 1: Prompt format

Each model responds differently to the same prompts. If you have invested months optimizing prompts for GPT-4, migrating to Claude or Llama requires re-optimizing all of them. Cost: weeks of work.

Layer 2: Integrations

If your workflows are connected to the OpenAI API, migrating requires rewriting integrations. Every automation, every plugin, every connector. Cost: months of development.

Layer 3: Training data

If you have done fine-tuning with a provider, that data and trained model belong to them. You cannot take a fine-tuned model from OpenAI to another provider. Cost: lost investment.

How to mitigate

• API abstraction: use an intermediary layer (LiteLLM, portkey.ai) that allows switching models without changing code.
• Model-agnostic prompts: document the intent of the prompt, not just the text. This makes adaptation easier.
• Fine-tune on open-weight models: if you invest in training, do it on models you control.
• Multi-vendor: use at least 2 providers for critical tasks. If one fails or raises prices, you have an alternative.

When sovereignty matters (and when it does not)

Sovereignty is not an absolute value. It is a risk management tool. It matters more or less depending on context:

Critical sovereignty (high priority)

• Regulated industry (banking, insurance, healthcare, public administration)
• Patient data, financial client data, minor data
• High-risk systems under the AI Act
• Contracts with EU data residency clauses
• Competitors who could benefit from your data (provider AI trained on your inputs)

Important sovereignty (evaluate)

• Strategic internal data (business plans, non-public financial data)
• Intellectual property (designs, source code, pending patents)
• Employee data (evaluations, salaries, medical data)
• High usage volume (cost justifies infrastructure investment)

Secondary sovereignty (cloud is sufficient)

• Marketing and public communication content
• Customer service with non-sensitive data
• Individual productivity (writing, summarization, brainstorming)
• Prototyping and experimentation
• Internal training and education

How to implement sovereign AI without being Google

You do not need your own data center or a team of 20 ML engineers. Sovereign AI in 2026 is accessible for any company with a basic technical team. Three options ordered by complexity:

Option 1: Managed European cloud (easy)

Use open-weight models on European providers: OVH, Hetzner, Scaleway, Mistral La Plateforme. Your data is processed in the EU, under European legislation, without transfer to the US. No GPU management needed.

Cost: similar to US APIs. Control: medium. Complexity: low.

Option 2: Dedicated GPU server (medium)

A server in a European datacenter with a GPU (Hetzner GEX44 or similar). You install the model, configure it once. Your technical team maintains it. Fixed monthly cost.

Cost: EUR 130-300/month. Control: high. Complexity: medium.

Option 3: On-premise (complex)

Own hardware in your offices or a contracted datacenter. Maximum sovereignty. Only justifiable if your regulation demands it (defense, intelligence, critical infrastructure) or if your volume is very high.

Cost: EUR 5K-50K initial + maintenance. Control: total. Complexity: high.

Decision patterns by industry

Financial services

Strict regulation. Highly sensitive client data. Recommendation: hybrid. European cloud for general tasks. Self-hosted for scoring, compliance and client data analysis.

Healthcare

Patient data protected under reinforced GDPR. Recommendation: self-hosted or certified healthcare cloud. No patient data should leave the EU under any circumstances.

Consulting and professional services

Varied client data, some sensitive. Recommendation: hybrid. Per-project policy: public data in cloud, confidential client data in controlled infrastructure.

Retail and e-commerce

Client data (purchases, preferences). Recommendation: cloud is sufficient for most cases. Evaluate self-hosted only if there is massive volume or direct financial data.

Public administration

ENS mandates strict control. Recommendation: self-hosted or sovereign cloud certified under ENS. Mistral as a native European option. No exceptions for High-level data.

Practical exercise

Puntos clave