Three EU regulations — NIS2, DORA, and the EU AI Act — have converged on a single structural requirement that most enterprise AI procurement teams are still ignoring: true data sovereignty. Not data residency. Not contractual assurances. Not Standard Contractual Clauses. The actual, jurisdictional guarantee that no foreign government can reach into your AI vendor's infrastructure and compel disclosure of your data. For CISOs, CTOs, and DPOs at European financial institutions and critical infrastructure operators, the legal exposure created by deploying US-hosted AI tools in 2026 is no longer theoretical. It is documented, foreseeable, and increasingly indefensible to auditors and regulators.
This article maps exactly how NIS2, DORA, and the EU AI Act interact to create overlapping sovereignty obligations — and what a compliant AI stack actually looks like for regulated EU enterprises.
NIS2 Directive (EU Network and Information Security Directive 2022/2555) is the EU framework requiring critical infrastructure operators and essential service providers across sectors including energy, transport, banking, healthcare, and digital infrastructure to implement cybersecurity risk management measures, ensure supply chain security, and meet incident reporting obligations. NIS2 substantially expands the scope of its predecessor, NIS1, and introduces direct management accountability and cross-border enforcement cooperation.
How NIS2, DORA, and the EU AI Act create overlapping data sovereignty obligations
Each of these three regulations was drafted with a different primary concern — cybersecurity resilience, financial sector operational risk, and AI system safety respectively — but they share a common enforcement architecture: they all hold the regulated entity responsible for the compliance posture of their technology supply chain. That is the mechanism by which US-hosted AI tools become a structural compliance problem, not merely a theoretical risk.
NIS2 covers essential and important entities across sixteen sectors including energy, transport, water, banking, digital infrastructure, and public administration. Its supply chain security requirements (Article 21) require operators to assess and manage the security risks posed by their suppliers and service providers. This includes ICT vendors, SaaS platforms, and AI tools that process operational data. If a vendor is subject to a foreign jurisdiction that can compel data disclosure — specifically the US CLOUD Act or FISA section 702 — that creates a measurable supply chain risk that NIS2-regulated entities must address.
DORA (Regulation EU 2022/2554, applicable since January 2025) applies to financial sector entities including banks, insurers, investment firms, payment institutions, and crypto-asset service providers. Its ICT third-party risk management framework (Chapter V) requires financial entities to conduct thorough due diligence on all ICT service providers, maintain contractual guarantees around data residency and access controls, and conduct concentration risk assessments when critical functions rely on a single provider or a class of providers with shared systemic vulnerabilities.
The EU AI Act (Regulation 2024/1689, full applicability August 2026) imposes tiered obligations based on AI system risk classification. For high-risk AI systems — which include credit scoring, insurance underwriting, biometric identification, employment screening, and critical infrastructure management — deployers face direct obligations around data governance, human oversight, and auditability. Article 27 additionally requires Fundamental Rights Impact Assessments (FRIAs) for public sector deployers and private deployers using Annex III systems in areas such as credit and insurance. The EU AI Act also applies extraterritorially: any third-country operator whose AI systems affect EU market participants falls within scope.
The convergence point is this: all three regulations require regulated entities to demonstrate that their AI and ICT vendors cannot be subjected to foreign legal demands that would compromise data confidentiality, availability, or integrity. A vendor that is subject to US jurisdiction cannot structurally satisfy this requirement — regardless of where their servers are physically located.
DORA and financial services AI: what the third-party ICT rules actually require
DORA's third-party ICT provisions are more operationally specific than most financial institutions have absorbed. The regulation does not merely require general due diligence — it imposes contractual minimum content requirements that directly constrain which AI vendors financial entities can use without remediation.
Under DORA Article 30, contracts with ICT third-party service providers must explicitly include: precise descriptions of data locations including the countries in which data is stored and processed; provisions granting the financial entity full audit rights and inspection rights; and clear provisions on termination rights and exit strategies to avoid lock-in that could impair operational resilience. For AI vendors processing financial data, customer records, or operational intelligence, these requirements are not decorative — they are enforceable contract terms that supervisory authorities (the EBA, ESMA, EIOPA, or national competent authorities depending on sector) will verify during inspections.
The problem with US-headquartered AI vendors is not that they refuse to include these contract terms. Most will sign data processing agreements with EU data residency commitments. The problem is that those commitments are not legally defensible when the vendor is subject to the US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, signed 2018). The CLOUD Act allows US federal law enforcement to compel US companies to produce data stored anywhere in the world, including EU data centers, provided the data relates to a US criminal or national security investigation. The vendor's contractual promise to you is rendered unenforceable by US statute.
DORA's concentration risk provisions add a second layer of exposure. The regulation requires financial entities to assess and manage the risk of excessive dependence on a single ICT provider or a small number of providers with shared vulnerabilities. In 2026, the EU financial sector's growing dependence on three US hyperscalers (AWS, Azure, Google Cloud) for AI infrastructure represents exactly this kind of systemic concentration risk — one that the European Systemic Risk Board and the Joint Committee of European Supervisory Authorities have explicitly flagged in published guidance.
NIS2 and critical infrastructure: why US cloud providers cannot satisfy the requirements
For NIS2-regulated operators in energy, water, transport, and digital infrastructure, the data sovereignty problem is more acute than in finance — because the operational data at stake is more sensitive, the attack surface is larger, and the supply chain security obligations are correspondingly more demanding.
NIS2 Article 21 requires essential entities to address security in supply chains including the relationships between each entity and its direct suppliers and service providers. The implementing regulation specifies that entities must assess the security practices of their ICT vendors, including their exposure to interference by foreign governments. This is not an abstract requirement. The European Union Agency for Cybersecurity (ENISA) has published guidance explicitly noting that US-jurisdiction cloud and SaaS providers cannot guarantee immunity from US government data access demands — and that this exposure must be factored into supply chain risk assessments.
The jurisdictional exposure is bilateral. US cloud providers are subject to the CLOUD Act for criminal investigations and to FISA section 702 for national security surveillance. FISA 702 permits the US intelligence community to collect communications of non-US persons who are outside the US, targeting foreign-based servers used by foreign nationals for intelligence purposes. For a European energy grid operator or water utility using US-hosted AI tools for operational decision support, this creates a scenario in which sensitive operational intelligence — including infrastructure maps, load profiles, anomaly detection outputs — could be accessible to US intelligence agencies without the EU operator's knowledge or consent.
A fully EU-owned cloud provider with no US parent company, no US board members, and no US investors eliminates this exposure entirely. There is no mechanism by which a Dutch, German, or French cloud provider with no US corporate nexus can be compelled to respond to a US CLOUD Act request. This is not a compliance workaround — it is the actual structural requirement that NIS2's supply chain security provisions are pointing toward. A provider like Leaf Cloud — a Dutch company holding ISO 27001 and SOC 2 Type II certifications and actively pursuing HAVEN+ certification — represents the infrastructure model that NIS2 Article 21 compliance requires. Critically, a fully EU-owned provider also eliminates the need for Transfer Impact Assessments entirely, since there is no cross-jurisdictional data transfer risk to assess.
The EURO-3C initiative context: The EU's response to this structural dependency is now backed by significant institutional capital. EURO-3C — a €75M+ EU-Commission-backed federated cloud and AI initiative involving 70+ organisations including telecoms, technology companies, and SMEs — is specifically designed to build sovereign European AI infrastructure. The EU is simultaneously developing a 'cloud and AI development act' to establish a single EU-wide framework for assessing cloud and AI sovereignty. For regulated enterprises, these are signals that sovereign AI is not a niche procurement preference — it is the direction of EU regulatory travel.
EU AI Act high-risk provisions: where they intersect with DORA and NIS2
The EU AI Act introduces a tiered risk classification that has direct consequences for how financial institutions and critical infrastructure operators must govern their AI deployments. High-risk AI systems under Annex III include systems used in credit scoring and creditworthiness assessment, insurance underwriting, employment and HR management, biometric identification, and management of critical infrastructure including energy and water systems. For enterprises in these sectors, the EU AI Act's obligations do not replace NIS2 and DORA — they compound them.
For deployers of high-risk AI systems, the EU AI Act requires robust data governance frameworks (Article 10), technical documentation and logging sufficient for post-hoc audit (Article 12), human oversight mechanisms (Article 14), and accuracy and robustness standards (Article 15). For regulated financial institutions and critical infrastructure operators, these requirements apply on top of DORA's ICT risk management obligations and NIS2's supply chain security requirements. A bank deploying an AI-assisted credit decisioning system is simultaneously subject to all three regulatory frameworks — and must demonstrate compliance with each independently.
The enforcement regime amplifies the stakes. EU AI Act fines are tiered: up to €35 million or 7% of global annual turnover for prohibited AI practices; up to €15 million or 3% of turnover for violations of high-risk system obligations; and up to €7.5 million or 1.5% of turnover for providing incorrect information to authorities. Critically, the EU AI Act uses a separate enforcement structure from GDPR — national market surveillance authorities rather than data protection authorities handle AI Act enforcement. This creates dual regulatory exposure for any enterprise that has both GDPR and AI Act obligations, which in practice means every financial institution and critical infrastructure operator in the EU.
The extraterritorial scope of the EU AI Act creates an additional dimension. A US-headquartered AI vendor whose system is deployed by a European bank is within scope of the EU AI Act, regardless of where the vendor's infrastructure is located. But the bank, as deployer, carries primary enforcement exposure. If the vendor cannot provide the documentation, audit trails, and governance artifacts the EU AI Act requires — or if the vendor's US jurisdiction creates uncertainty about data access — the deployer bears the regulatory consequence.
The Transfer Impact Assessment dead end: why TIAs cannot save US-hosted deployments
Following the Schrems II judgment (Court of Justice of the EU, July 2020), EU data controllers transferring personal data to the US or other third countries must conduct Transfer Impact Assessments (TIAs) to evaluate whether the legal framework of the destination country provides equivalent protection to EU law. For transfers to US-based processors, TIAs are supposed to assess whether US surveillance laws — specifically FISA 702 and Executive Order 12333 — create a risk of access to EU personal data that is incompatible with GDPR.
In practice, TIAs for US cloud providers are a compliance fiction. The underlying legal conflict they are meant to assess cannot be resolved by contractual measures. The European Data Protection Board's guidance on TIAs acknowledges this directly: when a transfer is subject to US national security surveillance law, supplementary measures including encryption, pseudonymization, and contractual controls cannot fully eliminate the risk if the US provider has access to the plaintext data needed to provide the service. For AI tools that necessarily process data in plaintext — because they need to read and analyze it — no supplementary measure resolves the conflict.
The EU-US Data Privacy Framework (DPF), which replaced Privacy Shield in 2023, provides a legal basis for certain data transfers, but it does not exempt transfers from FISA 702 collection. The DPF created a Data Protection Review Court for EU individuals to seek redress for alleged surveillance violations, but it does not prevent US intelligence agencies from collecting EU data in the first place. For NIS2 and DORA compliance purposes, the practical question is not whether the DPF provides a legal transfer mechanism — it does — but whether it provides the operational security guarantees that supply chain security assessments require. It does not.
A 2025 survey found that 62% of EU companies pursuing sovereign AI do so due to geopolitical uncertainty — not solely regulatory obligation. That figure has almost certainly risen through 2026, as the geopolitical context for US-EU data relations has become less predictable. For regulated enterprises, geopolitical risk and regulatory risk are now pointing in the same direction: away from US-jurisdicted AI infrastructure and toward providers with full EU ownership, governance, and legal accountability.
Building a sovereign AI stack for regulated EU enterprises
A compliant sovereign AI stack for regulated EU enterprises is not a theoretical construct — it is a specific set of architectural decisions that address the jurisdictional, technical, and governance requirements imposed by NIS2, DORA, and the EU AI Act simultaneously.
Infrastructure layer: full EU ownership and jurisdiction
The infrastructure foundation must be a cloud provider with no US parent company, no US board members, and no US investors — the structural conditions that create CLOUD Act and FISA exposure. ISO 27001 certification establishes baseline information security management. SOC 2 Type II certification provides independent audit verification of security, availability, and confidentiality controls. HAVEN+ certification adds the Dutch government-aligned sovereign controls required for the most sensitive regulated workloads. Providers pursuing this certification profile provide the supply chain security baseline that NIS2 Article 21 assessments can confirm.
AI application layer: audit trail and documentation requirements
For high-risk AI systems under the EU AI Act, the application layer must maintain logging sufficient to reconstruct the inputs, parameters, and outputs of consequential decisions. This is not optional — Article 12 of the EU AI Act requires that high-risk AI systems be designed to automatically record events relevant to identifying risks and post-market monitoring. For DORA-regulated financial entities, this logging requirement aligns with ICT risk management obligations to maintain incident records and forensic capabilities. The practical implication is that sovereign AI tools must be deployed in an architecture where logs are stored in EU-jurisdicted infrastructure and are accessible to EU supervisory authorities on demand.
Governance layer: contractual and operational alignment
DORA's Article 30 contract minimum content requirements, NIS2's supply chain security assessment obligations, and the EU AI Act's deployer responsibilities must all be addressed in vendor contracts and internal governance frameworks. This means: contractual data residency commitments backed by infrastructure that has no foreign jurisdictional exposure; audit rights that are operationally exercisable, not merely contractually stated; exit strategy documentation that demonstrates operational resilience independent of any single vendor; and FRIA processes for any Annex III AI deployments in public sector or regulated private sector contexts.
See how Numi's approach to regulated EU enterprise deployments addresses these governance requirements in practice, including audit trail architecture and EU-sovereign infrastructure integration.
The 36% problem: moving from the minority to the standard
A 2025 study found that only 36% of EU AI initiatives explicitly require sovereign approaches for regulatory or data sensitivity reasons. For DORA-regulated financial institutions and NIS2-regulated critical infrastructure operators, that figure should approach 100% — but procurement inertia, existing vendor relationships, and the complexity of migration keep many enterprises in a non-compliant posture. The regulatory calendar is the forcing function: the EU AI Act reaches full applicability in August 2026, and supervisory authorities across the EU have signalled that AI governance will be a priority inspection theme in the 2026-2027 cycle. The window for proactive remediation is narrowing.
The combination of NIS2 supply chain risk obligations, DORA third-party ICT requirements, and EU AI Act high-risk system governance is not a compliance burden to be managed at the margins — it is an architectural requirement that determines which AI tools regulated enterprises can deploy without material regulatory exposure. Enterprises that address this now, by building sovereign AI stacks on EU-owned infrastructure with full audit trails and compliant governance frameworks, will be positioned as regulatory exemplars. Those that continue with US-hosted AI tools on the basis of contractual assurances and TIAs will face an increasingly difficult conversation with supervisory authorities — a conversation that, given the fines at stake, it is far better to have proactively than reactively.