European open-source AI models deployed on sovereign infrastructure represent a category of artificial intelligence capability where the full supply chain, from training compute to inference hardware, remains under European legal jurisdiction and governance. For compliance officers, CISOs and data protection officers in public-sector bodies and regulated industries, this distinction is not theoretical: it determines whether sensitive data processed by an AI system is reachable by foreign governments under instruments such as the US CLOUD Act, FISA Section 702 or the forthcoming EU e-Evidence Regulation, and whether the organisation can demonstrate compliance with GDPR Article 25, NIS-2 Article 21 and, from August 2025, the EU AI Act’s General-Purpose AI provisions.
The Supply-Chain Sovereignty Gap Between EU and US Open-Weight Models
Open-weight models are not all equivalent from a jurisdictional standpoint. The origin of training compute, training data curation and the legal entity responsible for weight publication each create distinct risk profiles.
Models trained on the EuroHPC Joint Undertaking’s LUMI supercomputer, hosted in Kajaani, Finland and operated under a consortium of European member states, carry a demonstrably European provenance. LUMI ranked among the top five most powerful supercomputers globally at its launch (EuroHPC Joint Undertaking, 2023) and forms the backbone of the EU AI Factories programme, which funds the creation of open-weight foundation models under European governance. The GenAI4EU initiative, funded through the Digital Europe Programme call DIGITAL-2025-AI-08, extends this by co-funding sovereign AI deployment projects in member states.
By contrast, US-origin open-weight models such as Meta’s Llama series, even when self-hosted in an EU data centre, carry supply-chain exposure that a CISO cannot entirely eliminate. The training process, the data-sourcing decisions and the licence terms governing weight redistribution all occurred under US jurisdiction. Meta Platforms is subject to FISA Section 702 collection and to CLOUD Act disclosure obligations if US authorities present a qualifying order. The weights themselves may have been generated using data scraped from jurisdictions with different consent regimes, creating both a data-protection risk and a reputational risk for regulated deployers.
Mistral AI, headquartered in Paris and publishing open-weight models such as Mistral 7B and Mixtral 8x7B, occupies an intermediate position. Mistral is incorporated under French law, is not subject to CLOUD Act obligations, and its models are trained under European governance. This makes Mistral-family models a credible sovereign choice when combined with on-premises deployment, though organisations should verify that no training infrastructure was contracted from US-headquartered cloud providers, as that would reintroduce jurisdictional exposure at the compute layer.
What the Collapse in Inference Costs Means for Self-Hosting Decisions
The economic argument for consuming proprietary AI via a US-based API has eroded substantially. The cost of running AI inference has fallen by more than 99% between 2022 and 2024 (a16z, 2024), a reduction driven by hardware efficiency gains, quantisation techniques and the proliferation of competitive open-weight models.
In practical terms, a public body processing internal legal documents, citizen correspondence or clinical records can now deploy a 30-billion-parameter open-weight model on two high-memory data-centre GPUs, serve it over an internal API endpoint, and retire the recurring cost of a proprietary subscription. The residual cost is hardware depreciation, energy and the salary of the engineer maintaining the deployment. Against this, the average total cost of a data breach reached USD 4.88 million in 2024 (IBM Cost of a Data Breach Report, 2024), the highest in 19 years of tracking. For organisations handling sensitive personal data, the risk-adjusted economics strongly favour sovereign self-hosting.
EDPS Generative AI Orientations: Controller and Processor Roles for Self-Hosted LLMs
The European Data Protection Supervisor published its Generative AI Orientations in October 2025, providing the first authoritative GDPR role analysis specifically for public institutions deploying self-hosted large language models.
As the EDPS stated in that document: “Public institutions deploying generative AI tools for internal use must clarify, before deployment, whether they act as data controller, joint controller or data processor, and document that determination in a record of processing activities.” When a ministry or regulatory agency deploys a self-hosted open-weight model to process internal documents, the institution is unambiguously the data controller under GDPR Article 4(7): it determines both the purpose (internal document analysis) and the means (the chosen model, hardware and access policy). If a managed-service provider operates the inference infrastructure under contract, that provider is a data processor and must execute a data-processing agreement under GDPR Article 28.
The EDPS Orientations also address data-minimisation obligations directly: the model must not retain user inputs beyond the session unless a specific legal basis and retention schedule are documented, and no personal data may be used to update model weights without explicit consent or an equivalent legal basis under Article 6. This has a direct architectural implication: the inference stack must be configured with stateless sessions and weight-freezing by default.
AI Act GPAI Obligations Applicable from August 2025
The EU AI Act’s General-Purpose AI provisions under Articles 51 to 56 of Regulation (EU) 2024/1689 became applicable in August 2025. The EU AI Office, the body responsible for implementation within the European Commission, has clarified that providers of open-weight models above the 10^25 floating-point operations training threshold must publish a sufficiently detailed summary of training data and maintain up-to-date technical documentation.
| Scenario | AI Act GPAI Role | Key Obligation |
|---|---|---|
| Organisation deploys unmodified EU open-weight model internally | Deployer (not provider) | Conduct fundamental rights impact assessment if high-risk; document use case |
| Organisation fine-tunes model and uses it only internally | Deployer (not provider) | Same as above; no GPAI provider obligations triggered |
| Organisation fine-tunes model and distributes it to other entities | GPAI model provider | Technical documentation, training data summary, copyright policy, GPAI Code of Practice compliance |
For the majority of regulated organisations, internal fine-tuning on sovereign infrastructure does not trigger GPAI provider obligations. The organisation becomes a provider only when it places the modified model on the market or into service for third parties. CISOs and data protection officers should document the internal-only deployment scope explicitly in their AI system register to evidence this boundary.
Assessing Supply-Chain Integrity: A CISO’s Checklist
Deploying an open-weight model does not eliminate supply-chain risk; it relocates it. The attack surface shifts from the API provider to the model weights themselves and the fine-tuning pipeline.
Concrete steps for supply-chain integrity assessment include: verifying the SHA-256 or SHA-3 hash of downloaded weights against the hash published by the model originator on a separate channel; reviewing the training data card published by the original model provider for jurisdictional provenance and consent basis of each dataset; scanning fine-tuning datasets for personally identifiable information before ingestion using an automated PII-detection pipeline; isolating the fine-tuning environment from the internet and logging all outbound connection attempts; and running a suite of adversarial prompts post-fine-tuning to detect anomalous refusals or unexpected data exfiltration behaviours that may indicate weight poisoning.
For EU AI Factories models, the EuroHPC Joint Undertaking publishes governance documentation covering training data lineage, which provides a verifiable audit trail unavailable for most US-origin open-weight releases. Organisations should request and retain this documentation as part of their AI system register under the AI Act.
Hardware and Network Baseline for NIS-2 and GDPR Article 25 Compliance
Deploying a 30-billion-parameter open-weight model in 16-bit precision requires approximately 60 GB of GPU VRAM. In practice this means at least two NVIDIA A100 80 GB GPUs or equivalent data-centre-class hardware. Consumer-grade GPUs are insufficient for production workloads and create maintenance and reliability risks incompatible with NIS-2 Article 21’s continuity requirements.
The minimum sovereign deployment baseline for a 30B-parameter model that satisfies NIS-2 Article 21 and GDPR Article 25 data-protection-by-design includes: physical placement in an access-controlled server room with CCTV and entry logging; network isolation via a dedicated VLAN with no direct internet routing from the inference node; full-disk encryption at rest using AES-256 with keys managed by a hardware security module; role-based access control restricting model API access to authenticated internal users only, with MFA enforced; TLS 1.3 minimum for all internal API calls; and structured logging of all inference requests, retained for a period consistent with the organisation’s incident-response and audit obligations under NIS-2 Article 23.
Post-quantum readiness should be considered at the network layer even for internal deployments. If the inference endpoint is accessed by remote or travelling staff, the VPN gateway should support CRYSTALS-Kyber or another NIST-standardised post-quantum key encapsulation mechanism to prevent harvest-now-decrypt-later attacks against inference traffic containing sensitive document fragments.
FAQ
Does running a self-hosted open-weight model on EU infrastructure eliminate CLOUD Act exposure?
Yes, provided the infrastructure is owned or exclusively operated by an entity not subject to US jurisdiction, the data never traverses US-controlled networks, and no US-parent company controls the hosting provider. A Swiss or EU-based operator with no US parent falls outside the CLOUD Act’s reach. Using a US-headquartered hyperscaler’s European data centre does not eliminate this exposure.
From August 2025, which EU AI Act GPAI obligations apply when a regulated organisation fine-tunes a Mistral model on its own infrastructure?
If the organisation deploys the fine-tuned model only internally and does not place it on the market or put it into service for third parties, it is unlikely to qualify as a GPAI model provider under the AI Act. However, if the fine-tuned model is distributed to other entities or integrated into a product offered to others, GPAI transparency documentation obligations under Articles 53 and 55 of Regulation (EU) 2024/1689 apply from August 2025.
What distinguishes an EU AI Factories model from a US open-weight model such as Llama in terms of jurisdictional risk?
EU AI Factories models are trained on EuroHPC infrastructure under European governance, with training data curated under EU data-protection rules and model weights published under European oversight. US-origin open-weight models, even when self-hosted, carry supply-chain risk: the training process, data sourcing and weight release occurred under US jurisdiction, and licence terms may impose conditions subject to US law.
What is the minimum hardware baseline for self-hosting a 30-billion-parameter model in a NIS-2-compliant environment?
A 30B-parameter model in 16-bit precision requires approximately 60 GB of GPU VRAM, meaning at least two high-memory data-centre GPUs such as NVIDIA A100 80 GB cards. The hardware must sit in an access-controlled server room with network isolation via a dedicated VLAN or air-gap, full-disk encryption at rest, and HSM-backed key management. Access must be governed by role-based access control and logged for audit, satisfying NIS-2 Article 21(2)(i) and GDPR Article 25 data-protection-by-design requirements.
Under the EDPS Generative AI Orientations, who is the data controller when a ministry deploys a self-hosted LLM to process citizen correspondence?
According to the EDPS Generative AI Orientations published in October 2025, the deploying public institution is the data controller because it determines the purposes and means of processing. If a third-party vendor provides the model infrastructure under contract, that vendor is the data processor and must sign a data-processing agreement under GDPR Article 28. No data may leave the controller’s sovereign infrastructure without a valid legal basis and transfer mechanism.