EU AI Act, NIS2 and DORA: Moving Workloads Self-Hosted

If you run infrastructure for a regulated EU business — fintech, healthcare, critical infrastructure, or high-risk AI — you sit under three overlapping frameworks with infrastructure-level teeth. DORA (Regulation (EU) 2022/2554) has been fully enforceable, directly and uniformly across member states, since January 2025 — it is a regulation, not a directive. NIS2 (Directive (EU) 2022/2555) is a different legal instrument: Article 41 set 17 October 2024 as the deadline for member states to transpose it into national law, but a directive only binds through that national transposition, and it has been uneven — most member states have transposing legislation in force, while a handful were still finalising theirs well into 2026. Check the transposition status, and the competent authority, in the specific member state you operate in before treating NIS2 as uniformly live. The AI Act (Regulation (EU) 2024/1689) still has general application on 2 August 2026, but Regulation (EU) 2026/1744 of 8 July 2026 — the Digital Omnibus on AI (EP approval 16 June 2026; Council 29 June 2026; OJ L 2026/1744, 24.7.2026; in force 27.7.2026) — amends Article 113 so stand-alone Annex III high-risk obligations (including Article 12 logging) apply from 2 December 2027, and Annex I embedded high-risk from 2 August 2028. Article 50 transparency largely still tracks 2 August 2026 (Art. 50(2) machine-readable marking for systems already on the market before that date has until 2 December 2026). Together the three are one architecture constraint, not three checklists.

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 credit-scoring model (Annex III point 5(b)) 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 high-risk AI audit logs through a US-parent vendor's managed logging service fails the practical evidence-production test for Article 12: the statute requires automatic recording of events, not a named custodial duty, but enforcement still expects those logs to be producible with integrity from infrastructure you control — managed-vendor access is contractual access, not chain of custody. A deployment that achieves GDPR data residency via contractual Standard Contractual Clauses but runs on infrastructure subject to the CLOUD Act still fails control and supply-chain expectations regulators now treat as technical, not contractual. The frameworks demand coherent architecture, not point solutions. All three of these regimes regulate you as an *operator* of network and information systems; the Cyber Resilience Act is the next EU regime to land on engineering, and it attaches instead to *supplying* a product with digital elements — a different trigger, a different obligated person, and a scope test worth running separately.

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. See also the engineering playbook for repatriating the workloads this implies. 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. A cross-site mesh VPN coordinator is no exception: if a SaaS product holds the device registry and ACL policy binding your sites together, it is an ICT third-party service supporting a critical function, carrying the same concentration and exit-strategy obligations as any other critical provider.

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. Commission Implementing Regulation (EU) 2024/2956, published in the Official Journal on 2 December 2024, sets the standard templates for the register of information: 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. A vendor's SOC 2 report is often waved at that gap, but a carve-out report describes the vendor's own controls, not the subservice organisations underneath it — inheriting it as proof of the full chain is a misreading of what the report attests.

The exit strategy requirement is substantive. Article 28(8) requires exit without disruption to business activities, without limiting regulatory compliance, and without detriment to continuity and quality of client services, plus exit plans that are comprehensive, documented, sufficiently tested and periodically reviewed under Article 4(2). 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. Under Article 28(8)'s tested-and-documented exit-plan requirement, a plan that only says "we would migrate if required" does not suffice.

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 reporting cascade (early warning within 24 hours, incident notification within 72 hours, and a final report not later than one month after the incident notification) creates 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)(e) covers security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure — which maps directly to your CI/CD pipeline, your image signing posture, and your admission control configuration — while Article 21(2)(d) separately requires supply-chain security for direct suppliers and service providers. 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 (Kyverno)
# (1) internal registry only; (2) cosign signature required on those images.
# Art. 21(2)(d) third-party/image provenance + (e) acquisition/admission controls.
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
  annotations:
    nis2-control: "Art.21(2)(d)+(e) supply-chain and acquisition/development"
    audit-evidence: "kyverno-policy-report"
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: only-internal-registry
      match:
        any:
          - resources:
              kinds: ["Pod"]
              namespaces: ["production", "staging"]
      validate:
        message: "Images must be pulled from registry.internal.example.com"
        pattern:
          spec:
            containers:
              - image: "registry.internal.example.com/*"
            =(initContainers):
              - image: "registry.internal.example.com/*"
            =(ephemeralContainers):
              - image: "registry.internal.example.com/*"
    - 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: Automatic Logging and Evidence You Can Produce

Article 12 requires that high-risk AI systems automatically record events throughout their lifetime. For all high-risk systems, Article 12(2) requires logging capabilities for events relevant to Art. 79(1) risk or substantial modification, Art. 72 post-market monitoring, and Art. 26(5) operational monitoring. Article 12(3) adds minimum fields only for Annex III point 1(a) remote biometric identification: period of each use; reference database checked; matched input data; and natural persons who verified results under Article 14(5) — not a general duty to log every end-user identity. Retention is separate: Article 19(1) (providers) and Article 26(6) (deployers) require at least six months unless Union or national law requires longer. Article 19(2) (and Art. 26(6) for financial-institution deployers) folds financial-institution logs into documentation kept under applicable financial-services law — which can mean e.g. five years under MiFID II Article 16, not a DORA-specific five-year AI-log rule.

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 automatic recording plus enforceable evidence is not complicated, but it is hard on managed SaaS: it wants self-hosted infrastructure or certified sovereign cloud. Logs must be generated at the model serving layer — and, for systems that ground their answers against a self-hosted vector store, at the retrieval layer too — with engineering fields chosen to evidence the Art. 12(2) event categories (e.g. input hashes, model version, risk class — recommendations for operational traceability, not Art. 12(2)-prescribed contents; end-user identity only where Art. 12(3)/Annex III point 1(a) or other law requires it), written to an 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. The perimeter and integrity controls are evidence architecture under enforcement pressure; Article 12 itself states the automatic-recording duty. None of this is achievable when the inference endpoint is a third-party API call to an externally hosted model.

# AI Act Art.12 — PVC metadata for compliance tooling (not WORM enforcement)
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ai-audit-log-store
  namespace: ai-inference
  annotations:
    compliance/regulation: "eu-ai-act-art12"
    compliance/retention-days: "1825"   # e.g. MiFID II Art.16 via AI Act Art.19(2)/26(6)
    compliance/immutable: "true"
    compliance/custodian: "platform-team@example.com"
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: ceph-rbd  # class name is not a Ceph WORM parameter
  resources:
    requests:
      storage: 500Gi
---
# L3/L4 allow-list (Ingress + Egress). Write/read separation is store authz on 9000/9001.
# Egress deny-by-default once listed; allow DNS only. compliance-exporter pulls via ingress :9001.
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", "Egress"]
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: ai-inference
      ports:
        - port: 9000   # write endpoint
    - from:
        - podSelector:
            matchLabels:
              role: compliance-exporter
      ports:
        - port: 9001   # read endpoint (exporter is client; pull model)
  egress:
    - to:
        - namespaceSelector: {}
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

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 this practice operates 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 — for example a licensed payment institution's credit-scoring model (Annex III point 5(b)), or healthcare AI that is high-risk under Article 6(1)/Annex I or Annex III points 5(a)/5(d) — 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: at meaningful transaction volume, the compliance evidence available from self-hosted infrastructure is qualitatively different from what a managed hyperscaler deployment can produce, and the operational premium narrows as volume grows.

Practical Migration Path for Regulated Workloads Already on Hyperscalers

Article 113's 2 August 2026 general application date still binds for Article 50 transparency (with the Omnibus Art. 50(2) marking grace to 2 December 2026 for systems already on the market before 2 August 2026) and the residual baseline calendar; the Digital Omnibus on AI (Regulation (EU) 2026/1744) defers stand-alone Annex III high-risk obligations to 2 December 2027 and Annex I embedded high-risk to 2 August 2028. Neither calendar requires that every workload be migrated by one day — it requires that the technical measures applicable to systems in scope are in place. 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 licensed payment institution's credit-scoring model under Annex III point 5(b) is a clear triple-scope case; a fraud-detection-only model at the same institution is not automatically high-risk under that point. A batch analytics workload may be NIS2- or DORA-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 high-risk logging and evidence gap first: Article 12 automatic recording is the most falsifiable high-risk AI Act control once those duties apply — do not wait for the 2 December 2027 Annex III high-risk application date before ensuring logs can be produced with integrity. For triple-scope workloads, move audit log storage to infrastructure within your legal perimeter immediately — even before migrating the inference layer. That perimeter choice is evidence architecture under enforcement pressure, not a separate Article 12 custody clause. 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 high-risk healthcare AI under both NIS2 and the AI Act — systems that clear Annex III points 5(a)/5(d) or Article 6(1)/Annex I MDR/IVDR — the sequencing above is not theoretical. The audit logging gap is the most acute because it is the most directly falsifiable: either you can produce integrity-protected logs from infrastructure you control, or you cannot. The supply-chain and exit-strategy gaps are real but involve more interpretive latitude. Address the falsifiable gaps first.

# DORA ICT register — namespace annotations for automated 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.