The EU AI Act, NIS2, and DORA: Why Regulated Workloads Are Being Forced Onto Self-Hosted Infrastructure

If you run infrastructure for a regulated EU business — fintech, healthcare, critical-infrastructure operator, or any organisation deploying AI in a high-risk context — you are simultaneously subject to three overlapping regulatory frameworks with infrastructure-level teeth. The Digital Operational Resilience Act (DORA — Regulation (EU) 2022/2554) entered full enforcement in January 2025. The Network and Information Security Directive 2 (NIS2 — Directive (EU) 2022/2555) has been enforceable since October 2024. The EU AI Act (Regulation (EU) 2024/1689) broad applicability deadline falls on August 2, 2026 — weeks away at the time of writing. Each framework is demanding. Together, they are not three checklists. They are one architecture constraint.

The standard industry response has been to treat each regulation as a compliance project: assign a team, buy a GRC tool, produce documentation. This is the wrong model. DORA's ICT third-party risk provisions, NIS2's supply-chain security mandate, and AI Act Article 12's audit logging requirements are not satisfied by contracts and policy documents when the underlying infrastructure cannot technically deliver what those documents promise. The legal guarantee is only as strong as the technical reality underneath it.

This article argues a specific, falsifiable claim: for certain workload categories, the legal perimeter of a US-parent hyperscaler makes compliance with all three frameworks structurally impossible at the infrastructure layer — achievable on paper, impossible in practice. We will work through each regulation's specific requirements, map them to infrastructure decisions, and show where the architecture must change. The conclusion is not ideological. It follows from the text of the regulations and the documented limitations of the deployment models.

The EU AI Act, NIS2, and DORA: One Infrastructure Constraint

It is tempting to read DORA, NIS2, and the AI Act as parallel tracks that happen to coexist on the EU legislative calendar. They are not. They are three angles on the same underlying concern: that digital systems serving EU residents and critical economic functions must be provably resilient, provably secure at the supply-chain level, and — where AI is involved — provably transparent in their operation. The entity types they target overlap heavily. A licensed payment institution running a fraud-detection model is subject to all three simultaneously.

Click to zoom

The infrastructure implication of this overlap is that you cannot optimise for one regulation and tolerate gaps in the others. A Kubernetes control plane architecture that satisfies DORA's third-party risk register but routes audit logs through a US-parent vendor's managed logging service fails the AI Act's Article 12 custodial requirement. A deployment that achieves GDPR data residency via contractual Standard Contractual Clauses but runs on infrastructure subject to the CLOUD Act fails NIS2's supply-chain security measures in ways that EU guidance is now beginning to make explicit. The frameworks demand coherence, not point solutions.

DORA: What ICT Third-Party Risk Actually Means for Your Kubernetes Control Plane

DORA's ICT third-party risk provisions — principally Articles 28 through 44 — are more operationally detailed than most compliance summaries suggest. Article 28 does not merely require that you have a contract with your cloud provider. It requires that you maintain a register of information covering all ICT third-party service arrangements, that you perform due diligence on critical providers proportionate to their role, that you test concentrations of risk, and — critically — that you document and test an exit strategy for every critical arrangement.

That last requirement is where most AWS EKS or GKE deployments fail on first examination. An exit strategy is not a theoretical migration plan that lives in a Confluence document. DORA's implementing technical standards (published by ESAs in January 2025) define what the register of information must contain: nature of the service, data classification of what is processed, geographic location of processing, sub-contractor chain, and the operational dependency assessment. For a managed Kubernetes control plane, the sub-contractor chain is opaque by design — the cloud provider does not disclose its own supply chain to you at the required granularity.

The exit strategy requirement is substantive. Article 28(8) requires that financial entities ensure they can exit the arrangement without undue disruption to critical operations, without degradation of service quality, and within defined recovery time objectives. For workloads built around managed control planes with proprietary APIs — GKE Autopilot, EKS Fargate, AKS node pools with Azure-specific addons — demonstrating this exit capability requires either maintaining parallel on-premises or portable infrastructure, or accepting that the exit strategy does not meet regulatory standards. The European Banking Authority has been explicit: a plan that says "we would migrate if required" is not an exit strategy. A tested, documented, runbook-backed capability is.

A self-hosted Kubernetes cluster — whether on bare-metal colocation, private cloud, or a certified EU sovereign cloud provider — gives you something a managed platform cannot: a complete, auditable bill of materials for your control plane. You chose the etcd version. You chose the kubelet binary. You control the admission webhooks. The entire supply chain from OS package to Kubernetes API server is under your attestation, not your vendor's. For DORA Article 28 purposes, this is not a sovereignty preference. It is the difference between being able to produce the required documentation and not being able to.

NIS2: Supply Chain Security as a Hard Audit Requirement

NIS2 (Directive (EU) 2022/2555) Article 21 mandates that essential and important entities implement risk management measures covering, explicitly, supply chain security — including security aspects of relationships with direct suppliers and service providers. ENISA's technical guidance documents the expectation as a continuous control, not a periodic assessment. For a Kubernetes-based workload, the supply chain is: the container images you run, the Helm charts and operators you deploy, the OS on your nodes, the CNI and CSI plugins in your cluster, and the managed services your workloads call at runtime.

Running a managed Kubernetes service means accepting a supply chain you do not control and cannot fully inspect. When a critical CVE hits containerd or the cloud provider's custom node images, your exposure window is determined by the vendor's patch cadence, not yours. For NIS2 essential entities, Article 23's incident reporting requirements (significant incident notification within 24 hours, full report within 72 hours) create an acute problem: if you do not have full visibility into your node OS and control-plane components, you cannot accurately assess whether a disclosed CVE constitutes a significant incident under your reporting obligation. The legal risk of missing a mandatory notification is not trivial.

Supply chain security under NIS2 also encompasses the software you build and deploy. Article 21(2)(d) covers security in acquisition, development, and maintenance — which maps directly to your CI/CD pipeline, your image signing posture, and your admission control configuration. SBOM generation, Sigstore-based image signing, and Kyverno or OPA admission enforcement are not just security engineering best practices in this context. They are the technical implementation of a mandatory legal requirement. An audit finding that your cluster admits unsigned images from untrusted registries is a NIS2 Article 21 compliance gap, not merely a security recommendation. This supply-chain posture is strongest when the CI runner itself sits inside your perimeter: self-hosted GitHub Actions runners on Kubernetes with ARC keep signing keys, build artefacts, and build logs entirely within your jurisdiction.

# NIS2-aligned supply-chain admission policy (Kyverno)
# Enforces: only signed images from the internal registry are admitted.
# This is the technical control that makes Article 21(2)(d) auditable.
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
  annotations:
    nis2-control: "Art.21(2)(d) supply-chain security"
    audit-evidence: "kyverno-policy-report"
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: check-image-signature
      match:
        any:
          - resources:
              kinds: ["Pod"]
              namespaces: ["production", "staging"]
      verifyImages:
        - imageReferences:
            - "registry.internal.example.com/*"
          attestors:
            - count: 1
              entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      <your-cosign-public-key>
                      -----END PUBLIC KEY-----
                    signatureAlgorithm: sha256

EU AI Act Article 12: Why Audit Logs Must Stay Inside Your Legal Perimeter

The EU AI Act's Article 12 requires that high-risk AI systems be designed and built to automatically record events — logs — throughout their operational lifetime. The required log contents are specific: events relevant to identifying risks to health, safety, and fundamental rights; reference data, input data where technically feasible; the identity of the persons who used the system; and the results of the AI system's operation. Article 12(2) further specifies that the level of traceability must correspond to the purpose and context of use, and that logs must be retained for the periods specified by applicable sector regulation — typically a minimum of five years for financial services under DORA alignment.

The custodial question is not addressed by Article 12 in abstract terms, but it is settled in practice: for a high-risk AI system deployed by a regulated entity, the audit logs are evidence in a regulatory enforcement context. The entity responsible for compliance must be able to produce them on demand, demonstrate they have not been tampered with, and demonstrate the chain of custody. If your AI inference infrastructure runs on a hyperscaler's managed platform and the logs are written to that provider's managed logging service, you do not have custody — you have contractual access, which is a materially different thing.

The practical architecture for Article 12 compliance is not complicated, but it requires self-hosted infrastructure or certified sovereign cloud. Logs must be generated at the model serving layer (recording input hashes, output tokens, model version, requesting identity, risk classification), written to an immutable append-only log store within your legal perimeter, with cryptographic integrity protection (hash chaining or a transparency log), and subject to access controls that prevent even your own administrators from deleting records within retention periods. None of this is achievable when the inference endpoint is a third-party API call to an externally hosted model.

# AI Act Article 12 — audit log retention via Kubernetes policy
# Enforces immutable log PVC with retention annotations for compliance tooling
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ai-audit-log-store
  namespace: ai-inference
  annotations:
    compliance/regulation: "eu-ai-act-art12"
    compliance/retention-days: "1825"   # 5 years (DORA alignment)
    compliance/immutable: "true"
    compliance/custodian: "[email protected]"
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: ceph-block-immutable
  resources:
    requests:
      storage: 500Gi
---
# NetworkPolicy: audit log store is write-only from inference pods,
# read-only from compliance tooling, unreachable from all else.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ai-audit-log-isolation
  namespace: ai-inference
spec:
  podSelector:
    matchLabels:
      app: ai-audit-store
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: ai-inference
      ports:
        - port: 9000   # write endpoint
    - from:
        - podSelector:
            matchLabels:
              role: compliance-exporter
      ports:
        - port: 9001   # read endpoint

The CLOUD Act Problem: Why Data Residency Without Sovereignty Is a Paper Guarantee

The US Clarifying Lawful Overseas Use of Data Act (CLOUD Act, 2018) permits US law enforcement to compel US-domiciled cloud providers to disclose data stored anywhere in the world — including data physically located in EU data centres — without triggering the Mutual Legal Assistance Treaty process. The provider's obligation under the CLOUD Act coexists with GDPR obligations on the provider, creating a legal tension that has not been resolved by any court or bilateral agreement as of mid-2026. The EU-US Data Privacy Framework addresses *commercial* data transfer, not US government access. They are different instruments solving different problems.

The practical consequence for a regulated EU entity is that contractual data residency guarantees from a US-parent cloud provider do not constitute legal sovereignty. You may have a contract stating your data resides in eu-west-1. That contract does not prevent the provider from responding to a CLOUD Act order that compels access to that data. The provider's terms of service generally reserve the right to comply with legal process. You will not be notified. Your regulators — who are asking you under NIS2 and DORA to demonstrate control over your information assets — will not accept "our provider has a data residency contract" as a demonstration of the required control.

Some EU-based cloud providers — IONOS, OVHcloud, Hetzner, Deutsche Telekom's Open Telekom Cloud — are EU-incorporated and not subject to the CLOUD Act. These providers offer a partial solution: the legal-layer sovereignty problem is addressed, but the control-layer problem (who manages the Kubernetes control plane, who holds the encryption keys) remains, depending on the service tier. Only a self-managed control plane where you hold the keys, run the etcd, and operate the API server fully resolves the control-layer exposure. There is a spectrum of architectures, and the right choice depends on workload classification and risk tolerance — but the spectrum must be understood clearly.

Technical Sovereignty in Three Layers: Data, Control, Legal

Sovereignty is not a binary state. It is three independent guarantees, each of which must be independently verified. Understanding the three layers clarifies why partial solutions fail and what a complete architecture looks like. The sovereignty thesis we operate from makes this distinction explicit: you can have data residency without control-layer sovereignty, and control-layer sovereignty without legal-layer sovereignty. Each gap is a regulatory exposure.

Click to zoom

The data layer covers where your data physically resides and who can read it: prompts, completions, training data, PII, model weights. Data residency in an EU data centre addresses the data layer partially — physical location is necessary but not sufficient. Encryption key custody matters: if the provider manages your keys (AWS KMS, Azure Key Vault in a managed tier), the provider can access the plaintext under legal compulsion. The data layer is only sovereign when you hold the encryption keys in a hardware security module you control. The same logic extends to the analytical copy of that data: a self-hosted ClickHouse and Iceberg lakehouse keeps the aggregated, queryable view inside the same legal perimeter — a data warehouse is still data.

The control layer covers who manages the infrastructure your data runs on: the Kubernetes control plane, the node OS, the network fabric, the CI/CD pipeline, the PKI. A managed Kubernetes service is by definition a control-layer exposure: you have agreed to let the provider manage the components that govern all workloads running on the platform. For NIS2 and DORA audit evidence purposes, this means your supply-chain attestations are limited to the workloads you deploy, not the infrastructure they run on. The control layer is only sovereign when you operate the control plane yourself.

The legal layer covers which legal jurisdiction governs the entity that operates your infrastructure. A US-incorporated cloud provider with EU data centres occupies both US and EU legal jurisdictions simultaneously. EU data protection law applies to the data. US law (CLOUD Act, FISA 702) applies to the provider as an entity. Legal-layer sovereignty requires that the operating entity be incorporated in and subject to EU law only — or that the workload runs on infrastructure operated by such an entity. This is the dimension that eliminates the CLOUD Act exposure entirely, and it cannot be achieved by contract with a US-parent provider.

What Compliant Architecture Looks Like: Self-Hosted vs. Sovereign Cloud vs. Hyperscaler

The three deployment models — full hyperscaler, certified EU sovereign cloud, and self-hosted on-premises or colocation — satisfy different subsets of the combined NIS2/DORA/AI Act requirements by design. The compliance gap map is not a subjective assessment of risk appetite. It is an objective analysis of what each architecture can and cannot technically deliver for each specific regulatory requirement.

Click to zoom

The full hyperscaler model (EKS, GKE, AKS with managed AI services) can satisfy data residency contractually, can provide DORA-compliant contractual SLAs, and can generate incident logs. It cannot satisfy the control-layer components of DORA Article 28's third-party risk register at full granularity; it cannot satisfy NIS2's supply-chain provenance requirement for the control plane and node OS; and it is structurally exposed to CLOUD Act access. For workloads that fall under all three regulations — regulated fintech using AI, healthcare SaaS — these gaps are not acceptable in a strict interpretation of the regulatory requirements.

The EU sovereign cloud tier (OVHcloud SecNumCloud, IONOS Sovereign Cloud, Deutsche Telekom Open Telekom Cloud) resolves the legal-layer exposure and provides stronger contractual guarantees backed by EU-incorporated entities. Control-layer sovereignty depends on the service tier: a managed Kubernetes offering from an EU sovereign cloud still leaves the control plane in the provider's hands. Data-layer sovereignty is stronger when key management is customer-controlled (BYOK/HYOK with HSMs). For many regulated entities, a well-configured EU sovereign cloud IaaS tier — where you run your own Kubernetes control plane on EU-incorporated, EU-regulated compute — is the pragmatic balance between operational complexity and regulatory completeness.

Self-hosted on-premises or colocation infrastructure — your own hardware, your own Kubernetes, your own network — achieves all three sovereignty layers simultaneously and provides the fullest possible compliance posture for all three regulations. The trade-off is operational: you carry the burden of the control plane, hardware lifecycle, and network operations. For organisations with the engineering capability, the economics favour self-hosting for workload volumes that justify the capital expenditure. A regulated fintech cloud exit that we supported demonstrated that for a payment processor handling 50 million daily transactions, the compliance evidence available from self-hosted infrastructure was qualitatively different from what their previous hyperscaler deployment could produce — and that the operational cost was within 15% of the managed service bill at that volume.

Practical Migration Path for Regulated Workloads Already on Hyperscalers

The August 2, 2026 AI Act applicability date does not require that every workload be migrated by that date. It requires that entities subject to the Act have implemented the required technical measures for their high-risk AI systems. For organisations currently running regulated workloads on hyperscalers, the question is not "how do we exit by August 2" but "which workloads have the highest compliance exposure and what is the migration sequence that addresses them in order of regulatory risk."

The classification framework has three dimensions. First, regulatory exposure: is this workload within scope of all three frameworks, two, or one? A customer-facing AI decision system at a licensed payment institution is triple-scope. A batch analytics workload at the same institution may be NIS2-scope only. Second, data classification: does the workload process personal data, sensitive data, AI-generated decisions affecting individuals? Higher classification means higher evidentiary requirements and more urgency. Third, control-plane coupling: how deeply does the workload depend on provider-managed components? A containerised application that runs on EKS but uses only standard Kubernetes APIs is more portable than one built on Lambda, DynamoDB, and SageMaker endpoints.

1. Inventory and classify: Map all workloads against the three regulatory frameworks. Identify which are triple-scope. Assess current control-plane coupling depth per workload.
2. Prioritise by exposure, not by size: A small AI scoring service used in lending decisions at a bank is higher priority than a large batch ETL job that processes non-PII data. Regulatory exposure, not compute volume, drives sequencing.
3. Resolve the AI Act Article 12 gap first: The August 2026 deadline is for AI Act compliance. For triple-scope workloads, move audit log storage to infrastructure within your legal perimeter immediately — even before migrating the inference layer. This can often be done with an aggregation sidecar that ships logs from the managed AI API to your on-premise log store, pending a fuller migration.
4. Establish DORA register of information for all critical ICT arrangements now: This is already enforceable. Your register must include the sub-contractor chain to the extent you can obtain it. Document the gaps where the provider cannot supply the required detail — this creates an audit trail showing you identified the exposure.
5. Build a portable control plane baseline in parallel: Start with a reference Kubernetes cluster architecture on either EU sovereign cloud IaaS or your own colocation that you can demonstrate is compliant. Run non-critical workloads on it first to develop operational confidence before migrating critical systems.
6. Test exit strategies under DORA Article 28: Exercise the documented exit procedure at least annually, and produce test evidence. A runbook that has never been executed is not a tested exit strategy.

For organisations running healthcare AI under both NIS2 and the AI Act — a combination we have worked through in a healthcare SaaS sovereign AI migration — the sequencing above is not theoretical. The audit logging gap is the most acute because it is the most directly falsifiable: either your logs are in infrastructure you control, or they are not. The supply-chain and exit-strategy gaps are real but involve more interpretive latitude. Address the falsifiable gaps first.

# DORA ICT Third-Party Register — Kubernetes annotation convention
# Applied to every namespace that houses a critical workload.
# Feeds into an automated register-of-information exporter (CronJob).
apiVersion: v1
kind: Namespace
metadata:
  name: payment-processing
  annotations:
    dora/ict-register-entry: "true"
    dora/service-category: "critical"          # critical | important | standard
    dora/third-party-provider: "self-hosted"   # or: "ionos-sovereign" / "ovhcloud"
    dora/data-classification: "payment-pii"
    dora/processing-location: "de-fra-colo-01" # physical location ref
    dora/sub-contractor-chain: "hardware:supermicro,os:talos-v1.8,k8s:1.31"
    dora/exit-strategy-ref: "runbooks/payment-exit-strategy-v3.md"
    dora/exit-strategy-tested: "2026-03-15"
    dora/register-last-verified: "2026-06-01"

The convergence of NIS2, DORA, and the EU AI Act is not a regulatory accident. It reflects a coherent EU policy position: that digital infrastructure serving critical economic functions must be built to a standard that can be technically verified, not just contractually promised. For engineering leaders at regulated organisations, the honest read of these three frameworks is that they are collectively specifying an infrastructure architecture. The architecture they specify is self-operated, auditable, supply-chain-attested, and legally bounded within EU jurisdiction. That is the architecture we build for — not because it feels good, but because the regulations demand it and the evidence is now available to prove the case.