AI This article was created with the help of AI.
Sovereignty Washing vs. Genuine EU Control
Sovereignty washing is the practice of marketing cloud and AI compute services as European or sovereign while retaining underlying legal, corporate, or operational dependencies on non-EU jurisdictions. As European enterprises face mounting regulatory obligations under GDPR, the NIS2 Directive, and the EU AI Act, marketing departments across the cloud sector have slapped sovereign labels onto infrastructure that remains fundamentally tied to foreign corporate parents and offshore control planes.
The commercial pressure driving this branding surge is evident in market telemetry. Leading global cloud providers account for 70% of the European cloud market, leaving European service providers with a combined local market share of approximately 15%. At the same time, enterprise demand for genuine local autonomy is accelerating: Gartner forecasts that European sovereign cloud IaaS spending will grow 83%, from $6.9 billion in 2025 to $12.6 billion in 2026, and reach $23.1 billion in 2027.
To evaluate whether a provider offers verifiable control or superficial marketing wrappers, engineering and procurement teams need an objective evaluation framework. The European Commission set a precedent with the Cloud Sovereignty Framework it used in its own cloud tender: an overall sovereignty score built from 48 defined criteria, grouped into eight categories reflecting key sovereignty objectives, namely strategic, legal and jurisdictional, data and AI, operational, supply chain, technological, security and compliance, and environmental sustainability. Building on these principles, we have codified an eight-question test designed to audit infrastructure claims across corporate ownership, physical routing, stack autonomy, and verified credentials.
Questions 1-3: Corporate Jurisdiction and Foreign Legal Reach
The foundation of cloud sovereignty is legal and corporate jurisdiction. An infrastructure stack hosted within European borders still fails basic sovereignty standards if the operating entity or its parent company can be compelled by a foreign court to turn over encryption keys, prompt telemetry, or model weights without European judicial review.
Question 1: Where is the provider headquartered, and who holds ultimate operational authority?
Engineering teams must look past local sales entities and identify the ultimate parent corporation. A provider operating through a German or French subsidiary while remaining a wholly owned subsidiary of a foreign multinational remains bound by the board resolutions, parent-company governance, and extraterritorial laws of that parent jurisdiction. A valid answer provides the exact corporate registry details of the contracting operating entity and identifies the ultimate beneficial ownership structure without nesting behind offshore holding entities.
Question 2: Are processing workloads, data, or metadata subject to foreign extraterritorial laws?
The core legal vulnerability for European AI infrastructure is foreign statutory reach, most notably the United States CLOUD Act and Section 702 of the Foreign Intelligence Surveillance Act (FISA). Under the CLOUD Act, US federal law enforcement can compel US-headquartered tech companies to provide access to data stored on their servers, regardless of whether that data physically resides in Frankfurt, Dublin, or Paris. When evaluating an AI or inference provider, verify whether telemetry logs, prompt caches, or system metrics are routed through foreign parent infrastructure, creating legal exposure under Schrems II precedent.
Question 3: Who owns and operates the upstream physical and network infrastructure?
Virtual machine abstractions often obscure the underlying ownership chain. A software vendor may assert complete European autonomy, yet host its GPU instances on third-party hyperscaler capacity or route public API traffic through foreign transit networks. You must ask who holds title to the server hardware, who manages the bare-metal hypervisors, and which corporate entities control the physical data centre leases.
| Question | What to Ask the Provider | What a Good Answer Looks Like | What the Answer Proves |
|---|---|---|---|
| Q1: Corporate Headquarters | Where is the contracting entity and ultimate parent registered? | EU-incorporated entity with European beneficial ownership and governance | Immunity from non-EU corporate board directives and administrative orders |
| Q2: Foreign Legal Reach | Can foreign authorities compel data access via parent company statutes? | Explicit legal declaration that infrastructure and parent entities sit outside US CLOUD Act reach | Protection of prompt text, weights, and telemetry from extraterritorial warrants |
| Q3: Upstream Ownership | Who owns the bare-metal servers, GPU nodes, and network transit? | Directly managed or owned hardware in verified European facilities | Absence of hidden hyperscaler dependencies and intermediary legal exposure |
Questions 4-5: Physical Infrastructure and Per-Model Residency
Physical location remains a necessary condition for EU data residency, even though it is not sufficient on its own to guarantee full data sovereignty. For AI infrastructure, evaluating physical hosting requires looking beyond broad platform-level badges down to individual cluster topologies and model routing layers.
Question 4: Is the hardware and software supply chain fully transparent?
A sovereign infrastructure provider must disclose the provenance of its facilities and operational dependencies. Ask the provider to specify the physical locations of its data centres, the identity of its co-location partners, and how network transit is handled between regions. A credible provider openly identifies the countries hosting its compute nodes and provides clear documentation on whether support and operational maintenance are performed exclusively by EU-based engineering personnel.
Question 5: Is data residency guaranteed across every model and service, or does it vary per endpoint?
In AI inference, umbrella claims are frequently misleading. A provider may advertise an EU-sovereign platform while silently routing specific large language models, reasoning endpoints, or multimodal pipelines to US or non-EU GPU clusters due to localized capacity constraints. Buyers evaluating open-weight AI models must require a transparent, endpoint-by-endpoint residency mapping.
- Examine API endpoint documentation to verify whether regional model strings (such as eu-north1) are explicitly declared or hidden behind opaque load balancers.
- Confirm whether model inference, KV-cache storage, and temporary scratchpad memory remain locked to European accelerators during peak traffic failover.
- Verify that batch training jobs and fine-tuning pipelines do not dynamically spin up auxiliary compute nodes in offshore partner facilities.
- Ensure that auxiliary services such as tokenizers, vector databases, and embeddings endpoints share the exact same physical residency boundaries as the primary model.
Questions 6-8: Open-Stack Autonomy and Audited Compliance
The final tier of sovereignty vetting evaluates operational resilience, software independence, and the rigor of third-party compliance verification. A platform that is legally European but entirely dependent on proprietary, black-box orchestration layers introduces severe vendor lock-in and audit opacity.
Question 6: Does the compute stack rely on open-standard orchestration or proprietary black boxes?
True technological autonomy requires an open, auditable software stack. When a provider uses standard open-source runtimes such as vLLM, PyTorch, and NVIDIA Triton, engineering teams can audit the execution environment, inspect memory handling, and migrate workloads without refactoring their client libraries. Proprietary, closed inference engines prevent independent code audits and make it impossible to verify how prompt buffers and model parameters are handled in GPU VRAM.
Question 7: Are Data Processing Agreements (DPAs) and sub-processor lists contractually defined?
Under GDPR Article 28, data controllers must maintain strict visibility over every entity processing personal data on their behalf. A compliant AI provider must offer a binding DPA that outlines processor responsibilities and explicitly lists all third-party sub-processors. Generic promises of privacy without a clear contractual mechanism or an itemized list of infrastructure subcontractors fail enterprise vendor vetting.
Question 8: Are security and compliance claims externally audited, or purely self-asserted?
Marketing pages routinely blur the line between formal, audited certifications and self-asserted compliance. For instance, GDPR is a European legal framework rather than a commercial certification scheme; there is no official issuing body that grants a GDPR certificate. Conversely, standards like ISO/IEC 27001 require accredited third-party registrar audits, while SOC 2 produces an AICPA attestation report detailing operational control design and testing. Enterprise buyers must demand actual audit documentation rather than relying on self-asserted statements.
| Evaluation Criterion | Self-Asserted Statement (Low Assurance) | Audited or Contractual Proof (High Assurance) |
|---|---|---|
| Data Protection (GDPR) | Marketing assertion of GDPR compliance without contractual terms | Signed Data Processing Agreement (DPA) incorporating standard contractual clauses |
| Information Security | Claiming enterprise-grade security protocols | Accredited ISO/IEC 27001 certificate issued directly to the operating entity |
| Operational Controls | Internal documentation of monitoring procedures | Independent SOC 2 Type II attestation report evaluated by a certified CPA firm |
| Data Retention | Unverified claims of zero prompt retention | Contractual zero-retention terms with clear in-memory execution guarantees |
Running the Test on Ourselves: Jurisdiction and Infrastructure
To demonstrate how this vetting framework functions in practice, we run Questions 1 through 5 directly on our own service. A framework designed to eliminate marketing ambiguity must apply the same transparent scrutiny to the provider publishing it.
Corporate Entities and Registry Details
We operate through two distinct, registry-verifiable legal entities, both published in our imprint. The German operating company is Lyceum Technology Germany GmbH, Alte Jakobstr. 86, 10179 Berlin, registered at the District Court of Charlottenburg under commercial register number HRB 274593 B (VAT ID DE457056874), with Magnus Hans Grünewald serving as managing director. The Swiss entity is Lyceum Switzerland GmbH, Grubenstrasse 29, 8045 Zurich, registered at the District Court of the Canton of Zurich under company registration number CHE 470.395.013, with Maximilian Niroomand serving as managing director.
Physical Infrastructure and Regional Footprint
We operate GPU compute capacity across European data centres, with physical machines located in Paris and Finland. Dedicated capacity for On-demand GPU VM, Dedicated Inference, Serverless Training, and Large-Scale GPU Cluster workloads is provisioned through European supply partners that are not named publicly. We do not currently operate a data centre facility in Germany, which is an important operational boundary for buyers whose internal compliance mandates require domestic German data residency rather than broad EU/EEA residency.
Per-Model Residency Transparency
Data residency across our infrastructure is accurate per model rather than a uniform platform-wide absolute. Most of the model catalogue is hosted and executed on European GPU infrastructure, while specific serverless models are recorded as Global (multi-region) and not pinned to the EU. Examples include Nemotron-3-Ultra-550b, Qwen3.5-397B-A17B, MiniMax-M2.5, and Nemotron-3-Super-120b-a12b; this is not a complete list. For those models, we apply neutral commercial framing and make no claims of EU data residency or sovereignty.
Because our public model directory displays parameters, context lengths, and per-token pricing without printing explicit hosting region flags on the web page, engineering teams requiring strict European residency must confirm their specific model routing requirements with our technical team in writing.
Where We Fall Short: Certifications, Sub-Processors, and SLAs
Applying the second half of the framework (Questions 6 through 8) reveals the areas where we do not currently meet standard enterprise procurement criteria. Transparency requires stating our compliance boundaries in plain, present-tense terms.
Security Certifications and Third-Party Audits
We do not hold an ISO/IEC 27001 certificate. The physical data centres and upstream facilities we run on are ISO certified, and we provide those upstream facility certificates to customers upon request, but the ISO credentials belong exclusively to those upstream facility operators, not to us. We have also not completed a SOC 2 audit, and no SOC 2 attestation report has been issued for our platform. Our GDPR compliance is self-asserted as a direct legal obligation; we do not present it as an audited credential alongside independent standards.
Data Retention and Sub-Processor Visibility
Our zero data retention architecture means prompts, token buffers, and model completions are processed in volatile GPU memory and never persisted to non-volatile disk or used for training. However, this zero-retention mechanism is currently self-asserted and has not been audited by an external third party. Additionally, while our Data Processing Agreement (DPA), Privacy Policy, and Terms of Service are available on request, we do not maintain a publicly named sub-processor list. For regulated enterprises that require an itemized sub-processor registry prior to contract execution, this represents an operational limitation.
Service Commitments, Incident Response, and SLAs
We publish no Recovery Time Objective (RTO), Recovery Point Objective (RPO), or standardized breach-notification window. Our public Serverless Inference and Smart Routing offerings are self-serve, per-token services that carry no contractual SLA, no availability tier, no uptime percentage target, and no automated service credits. Our public status page displays real-time incident telemetry, but it is a live-incident display rather than a contractual availability commitment.
- Serverless Inference and Smart Routing operate without a contractual uptime guarantee or availability tier.
- For Dedicated Inference, On-demand GPU VM, Serverless Training, and Large-Scale GPU Cluster deployments, custom SLAs and availability parameters are negotiated individually per commercial contract.
- Incident response is managed directly by our core engineering team with 24/7 technical escalation paths, eliminating multi-tier ticket routing in favor of direct developer communication.
Evaluating Inference Providers Against Your Risk Profile
Achieving digital sovereignty in AI infrastructure is not an all-or-nothing proposition. Every engineering team and enterprise buyer operates under a distinct set of regulatory constraints, performance targets, and risk appetites. A financial institution handling sensitive customer records requires strict corporate entity insulation, binding DPAs, and guaranteed EU execution nodes. Conversely, an early-stage startup building developer tooling may prioritize raw token throughput, open-stack portability, and flexible per-second billing over formal audit certifications.
The purpose of an eight-question vetting test is not to demand perfection from every vendor, but to strip away marketing narratives and expose the structural realities of the stack. By asking precise questions regarding corporate ownership, foreign legal reach, bare-metal provenance, per-model routing, open-stack foundations, and audit status, engineering leaders can make deliberate infrastructure decisions grounded in verified telemetry rather than vendor branding.
For European development teams that require OpenAI-compatible endpoints running open-weight models on dedicated European GPU hardware, our Serverless Inference service provides a transparent, developer-first compute foundation built for European operational demands. Put these eight questions to every provider on your shortlist, including us.