Cloud Reversibility by Design in 2026 — EU Data Act Switching, DORA/NIS2, and Agentic AI

A sovereignty-ready architecture pattern for European enterprises in 2026

For European CIOs in 2026, the decisive criterion is reversibility. The EU Data Act’s cloud switching regime is now applicable, DORA and NIS2 have tightened expectations on third‑party risk and incident governance, and the Commission’s Cloud Sovereignty Framework is increasingly reflected in procurement language. Architectures that cannot be unwound therefore translate into board-level exposure.

At the same time, agentic AI turns the enterprise AI platform into a strategic layer: governed agentic workflows require deep integration with proprietary data and domain semantics, strict identity propagation, policy enforcement, and end‑to‑end traceability. Implementing these capabilities inside provider-opinionated PaaS materially increases switching costs and constrains differentiated automation, and it also weakens the historical case for low-code/no-code by compressing the speed advantage of proprietary workflow abstractions.

At Polynom, we recommend a pragmatic direction for CIOs: industrialize on hyperscaler infrastructure, standardize on portable execution primitives, and use managed services selectively where they remain substitutable.

Executive takeaways for CIOs

1. Treat infrastructure as a commodity, not a constraint. Hyperscaler-grade compute, storage, and networking should be bought as industrial utilities, while avoiding provider-specific PaaS becoming the architectural center of gravity.
2. Portability is decided at the execution layer. Standardizing around containers, Kubernetes-class orchestration, Infrastructure-as-Code, and policy automation preserves runtime mobility even when infrastructure remains hyperscaler-based.
3. Lock-in is cumulative. Switching barriers rarely originate in a single product choice; they emerge from many small dependencies that, taken together, eliminate credible exit paths.
4. Reassess low-code/no-code assumptions. With agentic development tools (e.g., Claude Code–class environments), many workflows can be delivered quickly as versioned, testable code inside the standard SDLC, while proprietary low-code abstractions tend to add switching and governance friction.

Managed services are not the enemy

Managed services are often the right choice, particularly when they encapsulate mature open-source technologies behind standard interfaces. Typical examples include managed PostgreSQL, Kafka, Kubernetes, and ClickHouse; in each case, the enterprise delegates day-to-day operations while remaining aligned with widely adopted standards and ecosystems.

The structural risk is not outsourcing infrastructure operations. The risk is the progressive loss of architectural degrees of freedom as critical layers become dependent on constructs that cannot be reproduced elsewhere at reasonable cost.

Lock-in tends to increase when core layers rely on proprietary data formats or non-exportable metadata models, platform-specific governance and policy constructs, low-code abstractions that evolve into closed languages, identity and observability layers that cannot be exported, or tight coupling to provider-native APIs and workflow engines.

PaaS can accelerate delivery in the short term; over time, it can also externalize core capabilities, reduce internal engineering depth, and make strategic change expensive. The underlying issue is not consuming compute as a utility, but the gradual loss of reversibility in system design.

The architecture pattern emerging across resilient enterprises

A sovereignty-ready cloud architecture can be expressed as a simple principle:

Consume infrastructure as a commodity, while keeping execution environments and core software layers portable and structurally reversible.

The objective is not ideological independence from providers, but the preservation of architectural optionality. In practice, the pattern combines hyperscaler-grade foundational infrastructure, portable execution primitives (containers, orchestration, IaC), and managed components that remain substitutable over time because they are built on open engines, open formats, and portable APIs.

Three decision principles make this pattern operational.

1) Buy commodities — not constraints

Hyperscalers provide unmatched industrialization of foundational infrastructure: elastic compute, object storage, global networking, baseline IAM capabilities, and resilience engineering at scale. These layers are utilities, and rebuilding them internally is rarely efficient or strategically justified.

However, consuming these utilities does not require surrendering control over the layers where differentiation and long-term flexibility reside, including execution/runtime standards, the software delivery system (CI/CD, IaC, GitOps), data models and governance semantics, and the identity boundary together with auditability requirements.

2) Standardize execution on portable primitives

Portability is primarily determined at the execution layer. Enterprises preserve runtime mobility when they anchor their platform in containers for packaging, Kubernetes-class orchestration for scheduling and rollout control, Infrastructure-as-Code and GitOps for repeatability and drift management, and Policy-as-Code for security and compliance guardrails as versioned artifacts.

These primitives encapsulate dependencies and reduce coupling to any single provider. The goal is not performative multi-cloud; it is maintaining a credible and testable path to move, even if that path is never exercised.

3) Choose substitutable managed components

Managed services remain valuable when they reduce operational burden without introducing proprietary dependence. In practice, this means favoring managed implementations of open-source engines, open data formats such as Parquet or ORC, standard semantics (notably SQL compatibility), and governance models whose core concepts can be exported and reconstituted elsewhere.

Lock-in risk increases materially when data models and metadata become proprietary, governance constructs are encoded in provider-specific policy languages, workflow orchestration becomes deeply tied to vendor-native services, or observability and identity are anchored in non-portable telemetry and control planes. Cloud exit is rarely blocked by infrastructure itself; it is constrained by accumulated architectural dependency.

Why CIOs must reclaim the “software producer” role

Many enterprises drift over time from being software producers to becoming integrators of external platforms. The shift is often rational in the short term—teams reduce time-to-delivery by assembling vendor capabilities—yet it changes the organization’s competitive position in a predictable way. Generic SaaS and platform offerings are engineered to standardize processes across customers; by construction, they struggle to encode firm-specific routines, tacit knowledge, proprietary decision frameworks, and differentiated risk controls that are essential in regulated, asset-heavy, or operationally complex environments.

When core systems materially influence cost structure, customer experience, product differentiation, or risk posture, architectural control becomes a strategic asset rather than an implementation detail. Retaining “software producer” capacity is also a governance issue: it is difficult to demonstrate control, auditability, and accountability when critical logic is embedded in opaque platform primitives.

Agentic AI intensifies this dynamic. As the marginal cost of producing and maintaining internal software decreases—through AI-augmented design, code generation, testing, and refactoring—the opportunity cost of “renting” the operating model inside closed platforms rises. In practice, the enterprises that will capture AI-driven productivity are those able to operationalize agentic workflows against their own data models, policies, and modular internal services, without having to reshape those capabilities to fit provider-opinionated abstractions.

How lock-in actually happens (and why it surprises teams)

Lock-in rarely results from a single architectural decision; it emerges through the incremental accumulation of dependencies that each look reasonable in isolation. Common mechanisms include proprietary SQL dialects and UDF ecosystems, provider-native workflow engines, governance models embedded in vendor-specific constructs, identity and access boundaries that cannot be exported, observability stacks tied to non-portable telemetry pipelines, and data pipelines optimized for one execution environment.

The surprise is usually not the existence of switching costs, but their shape: once a critical mass of dependencies is reached, substitutability collapses and exit timelines expand abruptly. Data gravity is part of the story, but so are less visible elements—metadata semantics, policy logic, lineage, audit artefacts, and operational runbooks—that determine whether systems can be reconstituted elsewhere without functional regression.

A useful simplification is to treat portability as two dimensions: application portability (can workloads be redeployed elsewhere without redesign?) and data portability (can data and the semantics required to use it correctly—schemas, metadata, governance tags, ACL meaning—be moved?). If either dimension is materially constrained, switching costs tend to increase non-linearly, and governance risk tends to rise in parallel because the organization becomes structurally dependent on a single control plane.

The “right zone” for most enterprises: IaaS + portable platform + substitutable data plane

A pragmatic sovereignty-ready architecture is not about purism; it is about credible reversibility, expressed as an exit path that is technically feasible, operationally credible, and defensible under scrutiny.

On the compute side, containerizing workloads and orchestrating them through Kubernetes (or an equivalent scheduler) keeps deployment and runtime concerns in a portable layer, while still allowing extensive use of hyperscaler infrastructure services where they do not create irreversible coupling. The practical test is whether the workload’s execution contract—packaging, configuration, secrets, rollout, policy controls—can be reproduced with comparable operational properties on an alternative provider.

On the data side, the data plane should privilege open storage formats and exportable table metadata, anchor transactional needs on engines with widely adopted semantics (for example, PostgreSQL), and use managed analytics services when data models and access interfaces remain portable. Just as importantly, the governance layer—catalog, lineage, access semantics, retention rules—should be designed so it can be reconstructed, not merely exported as raw files.

The requirement is not frictionless migration. It is migration that remains credible in a stressed scenario: under time pressure, under audit, and without a full redesign of business processes.

AI changes the build-versus-buy calculus

AI-assisted development has compressed delivery cycles and increased developer throughput, enabling smaller teams to deliver broader scope and iterate faster on internal platforms. This reduces the marginal cost of producing software internally and weakens the default argument for outsourcing core logic to generic SaaS—particularly when those platforms impose architectural constraints.

Agentic AI also expands the scope of what can be automated. Enterprises are increasingly able to redesign and continuously optimize processes by embedding reasoning systems directly into their operational stack, which makes the design of the surrounding platform—identity, policy, audit, and data integration—as important as the models themselves.

One practical implication is that low-code and no-code have lost much of their original rationale. These platforms were historically justified by developer scarcity and by the cost of translating process intent into production-grade software. Agentic development environments (for example, tools in the Claude Code class) materially change that equation: when a workflow can be expressed at a high level and compiled into versioned, reviewable, and testable code inside the existing repository and delivery pipeline, the marginal speed advantage of low-code contracts.

What does not contract are the structural disadvantages: opaque runtime semantics, limited engineering rigor in CI/CD and testing, constrained observability, and proprietary workflow languages that are difficult to export or reconstitute. For agentic workflows, the gap widens further, because production agents typically require explicit tool contracts, state management, secrets and network controls, and replayable traces. Low-code abstractions tend to hide these concerns behind provider-specific primitives, which makes governance and portability harder precisely as oversight requirements increase.

Why the AI platform itself raises the bar on sovereignty and reversibility

For many CIOs, the next strategic build is not a single application but an enterprise AI platform: a shared capability that connects proprietary data, model lifecycle management, secure inference, evaluation, and orchestration of agentic workflows. This platform typically has strong, enterprise-specific requirements that generic SaaS seldom satisfies cleanly, including deep integration with internal data planes and domain semantics, identity propagation and least-privilege access across tools, auditability of prompts, traces, decisions, and outputs, controllable routing across models under cost/latency/sovereignty constraints, and governance of retrieval sources, safety guardrails, and policy enforcement.

Agentic workflows amplify these needs because operating agents in production often looks closer to distributed systems engineering than to shipping a “chat feature”: long-running stateful orchestration, secure tool calling with secrets management and network segmentation, traceability and replayability of multi-step decisions, and deterministic versioning of prompts, tools, and policies across environments.

If these layers are implemented inside provider-opinionated low-code environments or closed orchestration engines, the enterprise’s ability to embed differentiated intelligence—and to evidence control to regulators and boards—becomes structurally constrained. In Europe, this is not theoretical: expectations around residency, operational transparency, and portability increasingly apply not only to datasets, but also to agent traces, governance metadata, evaluation artefacts, and decision logs.

In this landscape, portability and architectural control function not only as defensive safeguards, but as preconditions for capturing the productivity potential of agentic AI while keeping the AI platform governable, auditable, and geopolitically resilient.

A practical CIO decision framework for PaaS adoption

Before adopting any PaaS component, it is useful to evaluate five dimensions explicitly.

1) Technical substitutability

• Are there at least two credible alternatives, including managed open-source equivalents?
• Can the component be replaced without redesigning the surrounding platform?

2) Data portability

• Can data and metadata be exported (schemas, lineage, governance tags, ACL semantics)?
• Are formats open and widely supported across vendors?

3) Application portability

• Is the execution model portable (containers, Kubernetes, IaC) rather than provider-prescriptive?
• Are workflows encoded in a transferable tooling model?

4) Retained internal capability

• What knowledge becomes implicit in the provider platform?
• What engineering competencies risk being externalized over time?

5) Realistic exit cost

• What is the concrete migration path, including the operational risk envelope?
• What is the time-to-exit under realistic constraints?

A discipline that pays back quickly is to require an exit design for every strategic platform decision, even when the organization has no intention of exercising it. For low-code/no-code specifically, the burden of proof should be higher: insist on exportability into your standard SDLC (version control, testing, deployment), and treat proprietary workflow languages as a first-order switching risk rather than a convenience feature.

What to do next: a 90-day sovereignty and reversibility plan

1. Map your dependency surface by identifying where data formats, identity boundaries, policy models, and workflow engines are provider-specific.
2. Define sovereignty objectives that translate legal and jurisdictional exposure into concrete architectural requirements for auditability, segmentation, and control.
3. Standardize the execution layer by converging on containers, orchestration, IaC/GitOps, and policy automation.
4. Rationalize the data plane by privileging open formats, portable semantics, and exportable governance.
5. Codify an exit playbook by documenting migration paths and running at least one controlled portability drill on a non-critical workload.

This is not about planning an exit; it is about ensuring that an exit remains credible.

The right deal with hyperscalers

Hyperscalers remain essential providers of industrial scale, resilience, and foundational infrastructure. The strategic issue is not whether to rely on them, but how to structure that reliance so that the provider supplies industrial utilities—compute, storage, networking, baseline security controls—while the enterprise retains control over the layers that determine long-term freedom of action.

In practice, the “right deal” is architectural and contractual. Architecturally, it means keeping the execution contract portable (containers, orchestration, IaC, policy automation), minimizing dependence on proprietary workflow and governance languages, and ensuring that identity, observability, and data semantics are not locked inside a single control plane. Contractually, it means negotiating explicit portability and reversibility terms that align with the EU’s 2026 context: clear exit assistance, data and metadata export commitments, transparent service dependencies, and verifiable controls around residency, access, and operational transparency.

This framing matters even more when the enterprise is building an AI platform. Agentic workflows increase the importance of traceability, policy enforcement, and deterministic versioning of prompts, tools, and guardrails; these capabilities should remain auditable and reproducible outside provider-opinionated PaaS and low-code environments. Engineering capability, architectural freedom, business-logic ownership, and reversibility are long-lived assets. Enterprises that combine sovereignty-ready architecture with strong internal software production will be better positioned to capture AI-driven productivity without inheriting structural constraints that are costly to unwind under regulatory or geopolitical stress.

Conclusion

In 2026, EU regulation makes reversibility non‑negotiable—but productivity cannot slow down. The strategic objective is to achieve both.

Industrializing agentic pipelines on portable execution layers allows enterprises to encode proprietary workflows faster while preserving auditability and credible exit paths. As agentic development reduces the cost of producing versioned, testable code, the case for embedding core logic inside opaque PaaS or low‑code abstractions weakens.

The winning pattern is disciplined: buy hyperscaler utilities, standardize execution, keep data and governance exportable, and operationalize AI on foundations you control. This is how CIOs gain sovereignty and productivity simultaneously.

At Polynom, we help translate this into execution—designing portable AI platforms, hardening agentic pipelines, and validating reversibility in practice—so productivity gains do not create tomorrow’s constraints.

Selected references and further reading

Standards and public frameworks

• NIST Special Publication 500-292, NIST Cloud Computing Reference Architecture. — A vendor-neutral reference model to locate where PaaS constraints typically appear (execution environments, supported libraries, governance boundaries).
• ISO/IEC 19941:2017, Cloud computing — Interoperability and portability. — A standard framing interoperability/portability requirements, useful for turning “reversibility” into testable architectural criteria.
• Regulation (EU) 2023/2854 (Data Act), especially provisions on switching between data processing services. — The EU legal baseline for cloud switching and portability expectations, shaping 2026 procurement and exit clauses.
• European Commission (DG for Digital Services), Cloud Sovereignty Framework, Version 1.2.1 (Oct 2025). — A shared European vocabulary for sovereignty objectives and assurance criteria increasingly reused in RFPs and supplier due diligence.
• CIGREF, Trusted Cloud Referential, Version 2 (2022). — A widely cited French enterprise CIO reference for evaluating trusted cloud postures and contractual/operational controls.

Recent research and policy analysis

• Frontiers in Political Science (2025), The politics of digital sovereignty and the European Union’s …. — An academic lens on sovereignty as a governance project, clarifying why technical dependency quickly becomes political and regulatory exposure.
• Information, Communication & Society (2025), European ambitions captured by American clouds: digital sovereignty and the Gaia‑X initiative. — A detailed analysis of Europe’s sovereignty ambitions and the structural obstacles created by platform concentration.
• Springer / SN Applied Sciences (2025), Building a modern data platform … focusing on openness, portability, and averting vendor lock‑in. — A practitioner-oriented research piece on designing data platforms around open formats and portable execution to reduce switching friction.
• European Commission (DG RTD) / EOSC Steering Board (Dec 2025), Opinion paper on data sovereignty for research. — A recent EU policy perspective on sovereignty requirements beyond residency, including governance, access controls, and reusability constraints.
• IE Center for Governance in Change (2025), Competitive Cloud Ecosystems. — Market-structure analysis of contestability and switching frictions, useful for board-level framing of concentration risk.
• EuroStack (2025), EuroStack: A European alternative for technological sovereignty. — A policy/industry proposal articulating a European stack narrative, relevant for strategic alignment and ecosystem signalling.

Highly recognized independent voices

• Bruce Schneier, Schneier on Security. — Long-running security governance commentary that helps frame cloud dependency as a systemic risk and incentives problem.
• Cory Doctorow (platform power, lock-in dynamics, and interoperability as a governance lever). — Influential writing on how lock-in is engineered and why interoperability/exit rights matter as strategic counterweights