Chapter 3 — The New Landscape of Digital Sovereignty: Architectural Autonomy in the Fragmented Enterprise

For the better part of two decades, the practical meaning of data sovereignty in enterprise architecture was both modest and stable. It meant, in most contexts, that data of a particular category should reside within a defined geographic territory: that a European bank’s customer records should be held in European data centres, that a public-sector agency’s citizen data should not be processed on infrastructure operated by foreign corporations, that a healthcare provider’s patient records should remain within the jurisdiction that its clinical governance framework specified. Compliance with these requirements was, in the main, a matter of geography and contract: choose the right cloud region, negotiate the right data processing agreement with the infrastructure provider, and the obligation was discharged.

This understanding of sovereignty — as a property of location, cured by contract — is no longer adequate. The regulatory, geopolitical, and technological developments of the mid-2020s have transformed digital sovereignty from a compliance checkbox into a structural architectural requirement. Sovereignty in 2026 is not simply about where data resides; it is about who controls the infrastructure on which data is processed, under whose legal authority the operators of that infrastructure are subject, whether encryption keys and identity credentials are managed within or outside the jurisdictional boundary, and whether AI systems that reason over sensitive data do so under the enterprise’s own governance framework or under conditions that the enterprise does not control. An enterprise that satisfies the geographic dimension of sovereignty requirements whilst failing to address these operational and algorithmic dimensions is not sovereign in any sense that the current regulatory environment recognises as meaningful.

This chapter examines the full contemporary landscape of digital sovereignty: the regulatory frameworks that define its requirements, the geopolitical dynamics that are accelerating its adoption, the architectural dimensions that must be addressed to achieve it in practice, and the role that Zero-Copy Integration plays as the foundational technical enabler of the sovereign enterprise. It examines the IBM Sovereign Core framework as a specific and significant architectural response to the sovereignty challenge, situating it within the broader competitive landscape of sovereign cloud offerings and assessing its distinctive characteristics relative to the infrastructure-centric approaches of the major hyperscalers.

3.1 The Regulatory Architecture of Sovereignty

The regulatory environment governing data sovereignty has undergone a qualitative change in recent years, not merely a quantitative one. The change is not simply that more regulations now exist, or that existing regulations have been tightened, though both of those statements are accurate. The more fundamental change is that the regulations that now govern data sovereignty have moved beyond the question of where data is stored to address the question of how data is governed — who has access to it, under what authority that access can be compelled, how the processing of data is supervised, and how accountability for failures of governance is attributed and enforced. This shift in regulatory ambition requires a corresponding shift in architectural response: from location management to what might properly be called operational sovereignty.

3.1.1 The European Regulatory Collision

The European regulatory landscape of 2026 presents enterprises with a challenge of a distinctive kind: not a single, coherent regulatory framework to which the architecture must conform, but an intersecting set of frameworks, each conceived for a somewhat different purpose, whose combined requirements are more demanding than any individual framework implies and whose interactions are still being worked out in practice by regulators and regulated enterprises alike.

The General Data Protection Regulation remains the foundational instrument, establishing the principle that personal data relating to EU residents carries regulatory obligations that travel with it regardless of where it is processed. GDPR’s requirements for data minimisation, purpose limitation, and the restriction of cross-border transfers to jurisdictions that provide adequate protection have shaped enterprise data architecture since 2018. But GDPR, for all its significance, addresses primarily the rights of data subjects and the obligations of data controllers and processors. It is a privacy framework, not an operational resilience framework, and it does not directly address the questions of systemic risk, critical infrastructure resilience, and AI governance that have become increasingly central to the regulatory agenda.

The Digital Operational Resilience Act, which became fully applicable to financial institutions across the European Union in early 2025, addresses operational resilience with a specificity that GDPR does not attempt. DORA requires financial institutions to demonstrate that their critical information and communication technology systems can withstand disruption — and specifically that the concentration of critical processing in the infrastructure of third-party cloud providers does not create systemic risk that the financial institution cannot manage within acceptable tolerances. Its requirements for the mapping and annual testing of ICT systems, for the maintenance of a register of material ICT third-party dependencies, and for the demonstration of recovery capabilities that meet defined recovery time and recovery point objectives have material architectural implications for any financial institution whose operational infrastructure is significantly dependent on cloud providers.

The NIS2 Directive, which entered into force in late 2024 with considerably broader scope than its predecessor, extends the cybersecurity and resilience obligations that DORA applies to financial institutions to a much wider range of sectors — energy, transport, health, digital infrastructure, water, public administration, and space — and introduces personal liability for senior management in cases where failures of governance are found to have contributed to significant security incidents. The interaction between NIS2 and DORA creates what might be described as a lex specialis complication that many organisations have not yet fully resolved: DORA takes precedence over NIS2 for financial institutions in matters of ICT risk management, but the broader governance, supply chain risk, and incident reporting requirements of NIS2 continue to apply to financial institutions in their capacity as operators of digital infrastructure, and there is as yet no definitive regulatory guidance on precisely where DORA’s domain ends and NIS2’s begins in cases where a financial institution is also an operator of infrastructure on which other regulated entities depend.

The EU AI Act introduces a third layer of obligation that intersects with both GDPR and DORA in ways that the architectural community is still working to fully understand. For AI systems classified as high-risk — which includes systems used in credit scoring, insurance risk assessment, employment decisions, critical infrastructure management, and a range of other applications that are common in large enterprises — the AI Act imposes requirements for transparency, human oversight, data governance, and technical documentation that have direct architectural implications. Specifically, the Act requires that high-risk AI systems be designed to enable human oversight, that their training and validation data meet defined quality and governance standards, and that logs of their operation be maintained with sufficient completeness to enable post-hoc assessment of their decisions. These requirements interact with GDPR’s data minimisation principle, with DORA’s operational resilience requirements, and with the data sovereignty requirements that restrict where training data can be held and where inference can be performed, in ways that make the compliance challenge for enterprises deploying AI at scale substantially more complex than any individual framework implies.

The practical consequence of this regulatory collision for enterprise architecture is that the technology leader who attempts to address each framework in isolation — designing GDPR compliance as a data management programme, DORA compliance as an ICT risk management programme, NIS2 compliance as a cybersecurity programme, and AI Act compliance as an AI governance programme — will find that the resulting architecture is neither coherent nor efficient. The frameworks overlap; their requirements interact; and the technical mechanisms that satisfy one framework frequently have implications for compliance with the others. An architecture that addresses the European regulatory collision effectively must address all of the frameworks together, through a unified technical governance model that satisfies their combined requirements rather than treating each as a discrete compliance exercise. Zero-Copy Integration, through its emphasis on governed, in-place data access, policy-as-code enforcement, and comprehensive lineage tracking, provides precisely that unified model, as this chapter will demonstrate.

3.1.2 The Global Jurisdictional Landscape

Outside the European theatre, the landscape of data sovereignty regulation is simultaneously less integrated and no less demanding. The absence of a single overarching framework equivalent to the EU’s GDPR-DORA-NIS2 combination does not imply a less complex compliance environment; it implies a more fragmented one, in which the enterprise operating across multiple non-European jurisdictions must navigate a diverse array of national frameworks, each with its own scope, its own enforcement posture, and its own definition of what sovereignty requires.

In the United States, the regulatory environment for data sovereignty is predominantly sector-specific and, in the absence of a federal privacy framework comparable to GDPR, has evolved through a combination of industry regulation and state-level legislation. The Securities and Exchange Commission’s cybersecurity disclosure rules, which require listed companies to report material cybersecurity incidents within four business days and to provide annual disclosure of cybersecurity risk management practices, have established a cross-functional alignment requirement between security, finance, and legal functions that is broadly comparable in its organisational implications to DORA’s governance requirements for European financial institutions. The Committee on Foreign Investment in the United States has extended its scrutiny to data transactions involving US persons’ sensitive personal information, creating a sovereignty consideration for data-intensive acquisitions that did not exist in the previous decade. And the state of California’s Consumer Privacy Act, with its subsequent amendments and its status as a de facto national standard for consumer data rights in the absence of federal legislation, has introduced obligations for data controllers that, whilst less comprehensive than GDPR, are substantively similar in their implications for data architecture.

The Asia-Pacific region presents a particularly diverse sovereignty landscape. China’s Personal Information Protection Law and Data Security Law together establish a comprehensive framework for the governance of data held in or connected to China, with significant restrictions on the cross-border transfer of data that is classified as important or core national data, and an outbound data transfer security assessment requirement that applies to transfers above defined volume thresholds. The practical effect for multinational enterprises with operations in China is that the data generated by those operations cannot be integrated into the enterprise’s global data estate through the conventional mechanisms of centralised replication — the legal framework prevents it, and the Zero-Copy approach, which accesses data in place rather than transferring it, is architecturally consistent with the restrictions that the framework imposes. Singapore’s Personal Data Protection Act, whilst less restrictive in its approach to cross-border transfers, maintains a mandatory breach notification requirement and an accountability framework for data processors that requires governance structures comparable to those that GDPR demands. Australia’s Privacy Act, strengthened by the Privacy and Other Legislation Amendment Act of 2024, has introduced statutory tort remedies for serious privacy interferences and expanded the enforcement powers of the Office of the Australian Information Commissioner to a degree that makes non-compliance materially more costly than it was under the previous framework.

Gartner’s projection that global sovereign cloud spending will reach $80 billion in 2026, with the highest growth rates in the Middle East, Africa, and mature APAC regions, is not a forecast about a technology trend in the conventional sense; it is a forecast about the financial consequences of this regulatory fragmentation. Enterprises and governments are investing in sovereign cloud infrastructure because the regulatory environments of the jurisdictions in which they operate require them to maintain operational control over the data and systems that their activities generate, and because the conventional public cloud model — in which the provider operates the infrastructure and the customer manages only the applications and data that run on it — does not provide the degree of operational control that those requirements demand.

3.1.3 The Schrems Legacy and the Fragility of Contractual Sovereignty

No analysis of the current sovereignty landscape can be complete without a direct engagement with the structural fragility that the Schrems II decision of 2020 revealed in the contractual approach to cross-border data transfer. The decision, in which the Court of Justice of the European Union invalidated the EU-US Privacy Shield framework and confirmed that Standard Contractual Clauses could not in themselves guarantee an adequate level of protection for personal data transferred to jurisdictions where the intelligence services of the receiving state could access it without effective judicial remedy, demonstrated with clarity that the legal frameworks on which enterprises had built their cross-border integration architectures were not stable.

The immediate response of most enterprises to Schrems II was to conduct transfer impact assessments for their most significant cross-border data flows and to implement supplementary technical measures — additional encryption, access controls, pseudonymisation — where the transfer impact assessment identified risks that Standard Contractual Clauses alone did not adequately address. This response was legally reasonable; it was what the regulatory guidance of the period recommended. But it was, in architectural terms, a patch applied to a structure whose foundations had been revealed as insecure.

The deeper lesson of Schrems II — one that the subsequent adoption of the EU-US Data Privacy Framework in 2023 only partially addressed, given the legal challenges that the new framework has itself faced — is that contractual mechanisms for cross-border data transfer are inherently fragile. They depend on the continuation of the political and legal conditions that support them. They are vulnerable to judicial invalidation, regulatory reinterpretation, and geopolitical deterioration. An enterprise whose cross-border integration architecture depends on the continued validity of an adequacy decision or a standard contractual clause has an architecture that is robust under current conditions but brittle under foreseeable ones.

The architectural conclusion is not that cross-border data transfers should never occur, or that legal mechanisms for authorising them should be abandoned. It is that the enterprise whose sovereignty compliance depends primarily on legal mechanisms, rather than on an architecture that minimises the need for those mechanisms, has accepted a degree of fragility that is neither necessary nor appropriate given the alternatives that Zero-Copy Integration provides. An architecture that accesses data in place, rather than replicating it across borders, does not need to rely on adequacy decisions and standard contractual clauses for its compliance posture. Its compliance derives from the architectural fact that the data does not move, not from the legal fiction that the movement meets applicable standards.

3.2 The Dimensions of Modern Sovereignty

The regulatory analysis above reveals that sovereignty in 2026 is a multi-dimensional property, requiring architectural attention across dimensions that the simple model of geographic data residency does not address. Three dimensions merit separate analysis, though they are deeply interdependent in practice: identity sovereignty, data sovereignty in the operational sense, and algorithmic sovereignty.

3.2.1 Identity Sovereignty and the New Security Perimeter

The dissolution of the network perimeter as the primary security boundary of enterprise systems — a development driven by cloud adoption, remote working, and the proliferation of API-based integrations with external services — has elevated identity and access management to the role that the network perimeter once played. This shift is widely recognised in the security architecture literature and has given rise to the Zero Trust architectural model, which treats every access request as potentially hostile and requires its authentication and authorisation regardless of the network from which it originates.

What is less widely recognised is that identity management itself has become a sovereignty consideration. The authentication and authorisation decisions that determine who can access what data, and under what conditions, are made by identity management infrastructure. If that infrastructure is operated by an external provider — including a cloud provider’s managed identity service — the enterprise’s ability to guarantee that those decisions are made exclusively under its own authority and within its own jurisdictional boundary is constrained by the provider’s operational practices, its legal obligations, and the jurisdiction in which it operates. A cloud provider operating under US law may be subject to legal process that compels it to provide access to authentication records, identity tokens, or encryption keys managed on its infrastructure, regardless of the contractual commitments it has given to its customers about the confidentiality of those records.

Identity sovereignty addresses this risk by requiring that the infrastructure through which authentication and authorisation decisions are made, and through which the cryptographic keys that secure data at rest and in transit are generated and managed, operates within the enterprise’s own jurisdictional boundary under the enterprise’s own operational authority. In practice, this means deploying identity providers, key management services, and hardware security modules in environments where the enterprise — not its cloud provider — controls the operational staff, the physical access, and the legal exposure. For the most sensitive environments — national security agencies, critical financial infrastructure, sovereign wealth funds — this may require fully on-premises identity infrastructure. For most regulated enterprises, it requires at minimum that the key management and identity services are operated on infrastructure within the relevant jurisdiction by operators who are legally subject to that jurisdiction’s authority, not that of the cloud provider’s home jurisdiction.

IBM’s Hyper Protect platform addresses this requirement through hardware-based confidential computing capabilities that provide cryptographic assurance that the operating environment for key management and identity infrastructure has not been tampered with, even by the infrastructure operator. The Hyper Protect Crypto Services offering provides a cloud-hosted Hardware Security Module managed by the customer with IBM operating in an “in-boundary” capacity — effectively as a managed services provider subject to the governance controls of the regulated enterprise rather than as an infrastructure provider with operational authority over the service it provides. This technical and contractual model represents a more sophisticated response to the identity sovereignty requirement than the conventional cloud model provides, and it is directly relevant to the governance obligations that DORA, NIS2, and the AI Act collectively impose on regulated enterprises.

3.2.2 Data Sovereignty in Operation: Beyond Residency to Processing Control

The processing dimension of data sovereignty — the requirement that data not merely reside within a defined territory but be processed only by infrastructure and operators subject to that territory’s authority — has moved from a theoretical compliance concern to an operational engineering challenge. Several regulatory developments have made this shift concrete.

DORA’s requirements for the mapping of material ICT third-party dependencies and for the assessment of concentration risk in those dependencies create an explicit audit trail of the processing infrastructure on which critical data and systems depend. An enterprise that cannot demonstrate where its critical data is processed, by which systems, operated by whom, and under whose legal authority, cannot satisfy DORA’s documentation and reporting requirements. This is not a data residency requirement in the geographic sense — it is a processing transparency requirement that demands a level of operational visibility into the supply chain of data processing that many enterprises do not currently possess.

The processing dimension of sovereignty is also directly addressed by the emerging capability of confidential computing: the use of hardware- enforced execution environments — Trusted Execution Environments — that provide cryptographic assurance that computation is occurring in an isolated environment that cannot be observed by the host operating system, the hypervisor, or the infrastructure provider, even if those parties have full physical access to the hardware on which the environment runs. Confidential computing does not change where data is processed; it changes who can observe that processing. In a confidential computing environment, the only entity that can observe the data being processed is the entity that controls the application running within the Trusted Execution Environment — which, in a correctly designed sovereign architecture, is the regulated enterprise or its designated, in-boundary operator.

IBM’s LinuxONE platform and the Secure Execution capability of the IBM Z mainframe represent the most mature implementations of confidential computing in enterprise production environments. Secure Execution provides hardware-based isolation for complete virtual machine workloads, not merely for specific application components, ensuring that the entirety of a sensitive workload’s execution is protected against observation by the infrastructure operator. This capability is particularly significant for mainframe-hosted transaction processing systems — the core banking platforms, payment processing engines, and insurance policy administration systems that hold the most sensitive and commercially valuable data in the financial services and insurance sectors — because it allows those systems to continue operating in their existing mainframe environment whilst providing the processing sovereignty guarantees that regulatory requirements increasingly demand.

3.2.3 Algorithmic Sovereignty: Governing AI Within the Boundary

The integration of artificial intelligence into operational enterprise processes has introduced a third dimension of sovereignty that did not exist in the previous decade. AI systems, in their modern form, are not passive data processors; they are active reasoners that generate new information, make or recommend decisions, and increasingly act autonomously in response to operational conditions. The data on which they reason, the models through which they reason, and the decisions they reach are all, in principle, subject to the governance obligations that apply to the enterprise’s data and decision-making processes more broadly. In practice, the governance of AI systems has lagged significantly behind the governance of conventional data processing, and the regulatory frameworks that are now being applied to AI — principally the EU AI Act and the emerging AI governance standards of national regulators across multiple jurisdictions — are addressing this lag with an urgency that reflects the degree to which AI has already become embedded in consequential enterprise processes.

Algorithmic sovereignty is the requirement that AI systems operating on sensitive, regulated, or commercially critical data do so under the enterprise’s own governance framework, without exposing that data to external AI providers, and with the transparency and auditability of their decisions that regulatory frameworks require. This requirement has several architectural implications that are not addressed by conventional approaches to AI deployment.

The first implication is that AI inference — the use of trained models to generate outputs from input data — must, for regulated use cases, occur within the enterprise’s own governance boundary. The conventional model of AI-as-a-service, in which the enterprise submits data to an external provider’s API and receives model outputs in return, involves the transmission of potentially sensitive data to an external environment whose governance the enterprise does not control, whose security the enterprise cannot verify, and whose jurisdiction may differ from that of the enterprise’s own operations. For use cases involving customer personal data, financial transaction data, health information, or proprietary business intelligence, this model is either legally precluded by data sovereignty requirements or creates a compliance exposure that the enterprise’s governance function should assess as unacceptable.

The second implication is that the decisions made by AI systems must be auditable in the sense required by the EU AI Act and by the operational resilience frameworks that apply to financial institutions and other regulated enterprises. Auditability requires that the inputs to each AI decision, the model version used to process those inputs, and the output generated by the model are all recorded with sufficient completeness to enable post-hoc assessment of the decision. This requirement has direct implications for the data architecture: the lineage infrastructure that records AI decision inputs and outputs must be integrated with the broader data governance framework, and the retention of AI decision records must comply with the data retention requirements of the applicable regulatory frameworks.

The third implication — and the one that connects algorithmic sovereignty most directly to the Zero-Copy Integration architecture — is that the data on which AI systems are trained and against which they reason must be current, authoritative, and subject to the same access controls that apply to the underlying data assets. An AI agent that reasons over replicated, potentially stale data produces conclusions that are accurate as of the time of the last replication but may be incorrect at the time of the decision. An AI agent that has access to unauthorised data — because the access controls on a replicated dataset are less rigorous than those on the source — creates a governance failure that is difficult to detect and potentially significant in its consequences. The Zero-Copy architecture, by providing AI agents with governed, in-place access to current, authoritative data through the same access control framework that governs human access, addresses both the currency and the governance dimensions of this requirement.

3.3 IBM Sovereign Core: Sovereignty as a Software Property

Against this background of evolving regulatory requirements and multi-dimensional sovereignty challenges, IBM’s introduction of the Sovereign Core framework in early 2026 represents a significant and architecturally coherent response. Sovereign Core is not a sovereign cloud in the sense of a dedicated physical infrastructure — a private region or a government cloud deployment model. It is a software stack: a set of platform capabilities that together make sovereignty an inherent property of the software environment in which workloads execute, regardless of the physical or cloud infrastructure on which that environment runs. This distinction is fundamental, and it represents a different architectural philosophy from the infrastructure-centric sovereign cloud models that the major hyperscalers have pursued.

3.3.1 The Architectural Philosophy of Software-Defined Sovereignty

The conventional hyperscaler approach to sovereign cloud is to provide a physically or logically isolated version of the provider’s existing cloud infrastructure, operated under enhanced governance controls, in a location that satisfies the geographic residency requirements of the target jurisdiction. This approach has genuine merits: it leverages the provider’s existing investment in cloud infrastructure and operational tooling, it is familiar to enterprises that already operate workloads on the provider’s platform, and it satisfies the geographic dimension of sovereignty requirements as a matter of contract with the provider.

Its limitations, however, are structural. A sovereign cloud that is a variant of the provider’s standard platform is, ultimately, a cloud that the provider operates. The governance controls applied to it are the provider’s governance controls, implemented according to the provider’s operational procedures, verified by the provider’s auditors. The enterprise that operates workloads in a hyperscaler sovereign cloud region has contracted for geographic isolation and enhanced governance commitments; it has not achieved the operational independence that the more demanding sovereignty requirements — those of DORA’s operational resilience framework, of the most sensitive public sector applications, of critical national infrastructure operators — require.

IBM’s Sovereign Core framework addresses this limitation by treating sovereignty as a property of the software stack rather than a property of the infrastructure. The core insight is that if the software environment in which workloads execute provides, as inherent properties of its design, the isolation, auditability, key management, and operational control that sovereignty requires, then the physical infrastructure on which that environment runs need not itself be sovereign in the infrastructure-provider sense. The enterprise can run Sovereign Core on its own on-premises hardware, on a cloud provider’s infrastructure in an appropriate region, or on a combination of both, and achieve the same sovereignty properties in each case — because those properties derive from the software, not from the infrastructure.

3.3.2 The Technical Architecture of Sovereign Core

Sovereign Core is built on a foundation of Red Hat OpenShift, IBM’s enterprise Kubernetes platform, which provides the container orchestration and application runtime capabilities on which the platform’s higher-level sovereignty capabilities are built. The OpenShift foundation is significant for two reasons. First, it is open source at its core, built on the upstream Kubernetes project, which means that the enterprise’s investment in the platform is not hostage to IBM’s proprietary decisions about its evolution. Second, it is portable: an OpenShift cluster runs consistently on IBM Cloud, on AWS, on Azure, on Google Cloud, or on on-premises hardware, which means that the sovereignty properties that Sovereign Core provides through OpenShift are available in any environment that the enterprise needs to operate in, without requiring the enterprise to depend on a specific infrastructure provider’s sovereign offering.

Above the OpenShift foundation, Sovereign Core provides several layers of capability that together constitute the sovereignty property of the platform.

The customer-operated control plane is the most architecturally significant element. In a conventional cloud model, the control plane — the layer of infrastructure that manages the deployment, scaling, networking, and operational monitoring of the workloads running on the platform — is operated by the cloud provider. The provider’s operational staff have administrative access to the control plane; their tools, processes, and logging infrastructure shape how the platform behaves; and their jurisdiction governs the legal exposure of the operational functions they perform. In Sovereign Core, the control plane is transferred entirely to the enterprise or to a designated in-boundary operator: an entity that operates under the governance framework of the regulated enterprise, is legally subject to the jurisdiction in which the enterprise operates, and provides the operational functions of platform management without creating the out-of-boundary administrative access that the conventional provider-operated model involves. The operational tooling through which the control plane is managed is IBM’s, as is the software that the control plane runs; but the operational authority — the ability to make administrative changes to the platform’s configuration, to access its logs and telemetry, and to determine how it responds to operational events — rests with the customer-designated operator, not with IBM.

The always-on automated controls layer enforces sovereignty requirements architecturally rather than contractually. Where a conventional sovereign cloud model relies on contractual commitments from the provider — commitments that the enterprise must monitor through audit and that cannot be verified in real time — Sovereign Core embeds the sovereignty requirements in the platform’s technical controls. Configurations that would violate sovereignty requirements — the routing of audit logs to out-of-boundary storage, the creation of administrative access for out-of-boundary operators, the transmission of sensitive telemetry to provider-managed monitoring services — are prevented by automated controls that cannot be overridden without the enterprise’s knowledge and consent. This shift from contractual to technical sovereignty enforcement is what makes Sovereign Core’s compliance posture genuinely defensible rather than merely asserted.

The localised telemetry and audit capability ensures that all operational data generated by the platform — logs, metrics, traces, and audit records — are maintained within the sovereign boundary and managed under the enterprise’s own governance framework. This addresses a frequently overlooked dimension of the sovereignty requirement: even if the workload data itself never leaves the jurisdictional boundary, the telemetry generated by the platform that runs the workload may contain sensitive information about system behaviour, access patterns, and operational events that is itself subject to the data governance requirements of the relevant jurisdiction. Sovereign Core’s approach to telemetry — routing it to in-boundary storage and monitoring infrastructure rather than to provider-managed observability services — ensures that this secondary data sovereignty requirement is satisfied as a structural property of the platform, not as an afterthought.

3.3.3 Sovereign Core and the Zero-Copy Integration Architecture

The relationship between IBM Sovereign Core and Zero-Copy Integration is not incidental; it is architecturally constitutive. Sovereign Core provides the governance and operational sovereignty layer within which Zero-Copy Integration’s data access, event streaming, and API governance capabilities operate. Together, they form the complete sovereignty architecture that the current regulatory environment requires: Sovereign Core ensures that the platform on which data access is governed is itself sovereign in its operational characteristics; Zero-Copy Integration ensures that the data accessed through that platform does not leave the sovereign environment unnecessarily and is subject to the governance controls that sovereignty requires.

Specifically, the IBM Knowledge Catalog — the data catalogue and governance engine that provides the metadata, classification, and policy enforcement infrastructure of the Zero-Copy Control Plane — is deployed within the Sovereign Core environment. Its governance decisions — which data assets are classified at which sensitivity level, which users are authorised to access which datasets under which conditions, which cross-boundary data flows are permitted and on what legal basis — are made by software running under the operational authority of the enterprise, not the infrastructure provider. The lineage records that the Knowledge Catalog maintains — the provenance of every data access, every transformation, every AI inference — are held in in-boundary storage, managed under in-boundary governance, and available to the enterprise’s compliance function without requiring disclosure to or processing by an out-of-boundary provider.

IBM API Connect, the API management platform that governs access to data assets through the API layer of the Zero-Copy architecture, and IBM DataPower Gateway, the policy enforcement runtime for API traffic, are similarly deployed within the Sovereign Core environment. This means that the access controls governing who can retrieve which data through the API façades of the Zero-Copy architecture are enforced by infrastructure that the enterprise controls, with audit records of every access maintained in in-boundary storage. The governance posture that results — governed access to data in place, with comprehensive audit trail, on infrastructure that the enterprise controls operationally — is the fullest practical realisation of the sovereignty requirements that the current regulatory landscape demands.

3.4 The Competitive Landscape of Sovereign Cloud

IBM’s Sovereign Core approach should be assessed in the context of the competitive landscape it inhabits. The major hyperscalers have each developed sovereign cloud offerings, and those offerings have genuine capabilities that represent meaningful options for enterprises whose sovereignty requirements can be met within the frameworks the hyperscalers provide. An honest assessment of the competitive landscape requires both recognition of those capabilities and clarity about their limitations relative to the more demanding sovereignty requirements that the Sovereign Core model addresses.

3.4.1 AWS: Infrastructure Isolation as Sovereignty

The AWS European Sovereign Cloud is the hyperscaler offering that most directly addresses the European regulatory requirements that have driven much of the recent demand for sovereign cloud capabilities. It is a physically and logically separate cloud environment located entirely within the European Union, operated exclusively by EU residents, with all customer metadata held within EU borders and the management of the environment insulated from AWS’s global operational infrastructure. The primary sovereignty mechanism is infrastructure isolation: the environment is separate enough from AWS’s global infrastructure that the legal exposure of the global infrastructure to non-EU regulatory process does not, in AWS’s assessment, extend to the sovereign environment.

This is a credible model for the geographic dimension of sovereignty requirements, and for enterprises whose primary sovereignty concern is data residency and the exclusion of non-EU administrative access. Its limitation is that it remains a provider-operated environment: AWS operates the control plane of the European Sovereign Cloud, and the enterprise’s sovereignty derives from contractual commitments about how AWS operates it, not from the enterprise’s own operational authority. For the most demanding sovereignty requirements — those of systemically important financial institutions under DORA, of critical national infrastructure operators under NIS2, of government agencies with classified information handling requirements — contractual sovereignty of this kind may not be sufficient.

3.4.2 Microsoft: Policy-Driven Sovereignty

Microsoft’s approach to sovereign cloud is built around what it terms sovereign landing zones: policy-driven governance configurations applied to Azure infrastructure that enforce data residency, restrict administrative access, and provide customer control over encryption keys through Azure Key Vault and Managed Hardware Security Module. The Microsoft Cloud for Sovereignty offering provides a framework for implementing these configurations consistently, with policy templates designed to align with the requirements of specific regulatory frameworks including DORA and NIS2.

The strength of the Microsoft approach is its comprehensiveness: the sovereign landing zone framework covers the full range of Azure services, and the policy templates provide a structured starting point for compliance with the major European regulatory frameworks. Its limitation is similar to that of the AWS model: the governance controls are Microsoft’s controls, applied to Microsoft’s infrastructure, under Microsoft’s operational authority. The enterprise has significant configuration control and encryption key custody through Key Vault, but the underlying control plane remains Microsoft-operated. For enterprises that require full operational independence from their cloud provider, this falls short of the requirement.

3.4.3 Google Cloud: Modular and Partner-Operated Sovereignty

Google’s sovereign cloud strategy is the most architecturally diverse of the three major hyperscalers, offering a spectrum of sovereignty options from data boundary controls — configurable policy restrictions on where data is stored and processed within Google’s infrastructure — through partner-operated sovereign clouds, in which a local operator deploys and operates Google Cloud infrastructure within a specific jurisdiction, to fully air-gapped deployments that operate without any connectivity to Google-managed services.

The partner-operated model is architecturally closer to the Sovereign Core model than the standard hyperscaler sovereign cloud, in that it introduces a local operator into the operational chain and reduces the direct operational role of the global provider. Its limitation is consistency: the capabilities available in a partner-operated sovereign cloud depend on the specific partner and may differ significantly from those available in Google’s standard cloud environment, creating operational and architectural inconsistency for enterprises that operate across both partner-operated and standard Google Cloud environments.

3.4.4 The Distinctive Contribution of the Sovereign Core Model

The dimension along which the IBM Sovereign Core model is most distinctively positioned relative to the hyperscaler sovereign cloud offerings is the software-defined nature of its sovereignty. Hyperscaler sovereign cloud offerings provide sovereignty through infrastructure: a dedicated, isolated set of data centres, operated under enhanced governance controls, in a specific geographic location. The sovereignty properties of these offerings are therefore tied to the specific infrastructure they provide; they cannot be extended to the enterprise’s on-premises environment, to a different cloud provider’s infrastructure, or to an edge computing environment without the hyperscaler’s involvement.

Sovereign Core’s sovereignty properties, being derived from the software stack rather than the infrastructure, are portable in a way that infrastructure-based sovereignty cannot be. An enterprise that has deployed Sovereign Core in its on-premises data centre and in one cloud provider’s infrastructure can extend the same sovereignty properties to a second cloud provider, to an edge location, or to a third-party data centre operated by a sovereign colocation provider, without rebuilding its governance and compliance framework. The sovereignty travels with the software, not with the infrastructure on which the software happens to run. This portability is strategically significant for multinational enterprises operating across multiple jurisdictions with different regulatory requirements and different preferred cloud providers, because it means that the governance investment made in Sovereign Core is available across the enterprise’s entire infrastructure estate, not merely in the specific environments where a particular hyperscaler’s sovereign offering happens to be available.

3.5 Zero-Copy Integration as the Technical Enabler of Sovereignty

The regulatory and architectural analysis above establishes what sovereignty requires; the remainder of this chapter examines how Zero-Copy Integration provides the technical mechanisms through which those requirements are satisfied in practice.

3.5.1 Sovereignty Through Data Minimisation

The most fundamental technical contribution of Zero-Copy Integration to the sovereignty architecture is the reduction of the data that moves across jurisdictional boundaries to the minimum necessary for legitimate operational and analytical purposes. The principle is directly analogous to GDPR’s data minimisation principle — which requires that personal data be limited to what is necessary in relation to the purposes for which it is processed — but extends it to the integration architecture more broadly. In a Zero-Copy architecture, the data minimisation principle applies not only to the storage of personal data but to its movement: data is moved across boundaries only when there is a specific, justified reason for the movement, and the volume moved is limited to what the specific purpose requires.

This architectural data minimisation has direct sovereignty benefits. Fewer cross-boundary data flows means fewer legal bases required to authorise those flows, fewer transfer impact assessments to conduct and maintain, and fewer points at which regulatory scrutiny of cross-boundary data transfers may be triggered. The governance burden of managing the cross-boundary flows that remain — because some cross- boundary movement is always legitimate and necessary — is reduced to a manageable scope, amenable to the kind of rigorous individual assessment that flows of high regulatory sensitivity require.

3.5.2 The Open Table Format as Sovereignty Infrastructure

Apache Iceberg, the open-source table format that has emerged as the de facto standard for open lakehouse architectures, plays a specific and important role in the sovereignty architecture that deserves explicit recognition. Iceberg’s design — a table format that maintains metadata about the location and structure of data files independently of any specific query engine — enables multiple query engines to operate on the same data without requiring it to be replicated into engine-specific formats. A dataset stored in Iceberg format can be queried by IBM watsonx.data’s Presto engine, by Apache Spark, by Trino, by Snowflake (through its zero-copy sharing capability), and by other compliant engines, using only the metadata pointer to locate the data and the query protocol to retrieve the results.

The sovereignty implication of this multi-engine access capability is significant. In a conventional analytical architecture, the need to serve multiple analytical tools typically requires the data to be replicated into the format that each tool expects — a separate copy for the SQL analytics platform, another for the machine learning framework, another for the visualisation tool. Each replication is an additional copy that must be governed, secured, and potentially assessed as a cross-boundary transfer. In an Iceberg-based architecture, the same data file serves all of those consumers, with each consumer reading it directly through its own query engine but without any physical replication. The sovereignty compliance burden of one governed dataset is vastly lower than the sovereignty compliance burden of ten replicated copies of the same dataset.

The IBM-Salesforce partnership, which enables Salesforce Data Cloud to query data held in IBM watsonx.data’s lakehouse through the Iceberg table format, illustrates the practical reach of this principle. Customer behavioural data held in an IBM watsonx.data environment within a regulated jurisdiction can be queried by Salesforce’s analytical engine without leaving the IBM environment: the query travels to the data, the data does not travel to Salesforce. The result — the analytical output that Salesforce needs to personalise the customer experience — may legitimately cross the boundary between the IBM and Salesforce environments, because it is an analytical output rather than a copy of the underlying regulated data. This is precisely the architectural pattern that data sovereignty regulation is designed to encourage, and the open table format is the technical mechanism that makes it feasible at the scale of enterprise data estates.

3.5.3 Policy-as-Code and the Governance Fabric

The governance dimension of sovereignty — the requirement that access to data within the sovereign boundary be controlled, monitored, and auditable — is implemented in the Zero-Copy architecture through the policy-as-code capabilities of the Control Plane. Open Policy Agent, the Cloud Native Computing Foundation’s policy enforcement framework, provides the mechanism through which access policies are expressed as code, version-controlled, tested, and deployed consistently across the enterprise’s integration estate, enforced at every point at which data is accessed rather than relying on configuration-level access controls that may be inconsistently applied or difficult to audit.

IBM Knowledge Catalog extends this policy-as-code capability with the data classification metadata that makes the policies meaningful: each data asset registered in the catalogue carries a classification that determines the access policies applicable to it, the jurisdictional constraints on its movement, and the retention and audit requirements that govern its lifecycle. When a federated query is submitted against a classified dataset, the Knowledge Catalog’s policy engine evaluates the requestor’s authorisation profile against the dataset’s classification, determines whether the access is permitted under the applicable policies, applies any required data masking or field-level access restrictions, and records the access in the lineage system — all before any data is returned to the requestor. The governance is not a retrospective audit of what data was accessed; it is a real-time enforcement of the policies that determine what data can be accessed, by whom, and under what conditions.

3.5.4 Resilience Within the Sovereign Boundary

The operational resilience dimension of sovereignty — the requirement that the enterprise’s critical systems and data can continue to operate without dependency on out-of-boundary services when those services become unavailable — connects the sovereignty discussion directly to the resilience architecture that Chapter 12 examines in detail. The connection is not incidental: DORA’s operational resilience requirements apply specifically to the ICT systems on which critical financial services functions depend, and they require that those systems be designed to withstand failure scenarios that include the unavailability of third-party cloud infrastructure.

The Zero-Copy architecture contributes to sovereign resilience through its elimination of the cross-boundary dependencies that create single points of failure in the integration estate. When data is accessed in place, rather than replicated across boundaries, the availability of the integration capability is dependent on the availability of the data at its source — which is typically within the sovereign boundary — rather than on the availability of the network connection between the source and a replica in a different environment. If that network connection becomes unavailable, the data at source remains available and the integration capability continues to function. This resilience property — the ability to continue operating from locally-available data when cross-boundary connectivity is degraded — is a direct consequence of the Zero-Copy architecture’s design, not an additional capability that must be engineered separately.

3.6 Sovereignty Standards and the Emerging Data Space Ecosystem

No treatment of digital sovereignty in 2026 can be complete without addressing the ecosystem of standards and inter-organisational frameworks that are providing the shared governance infrastructure for sovereign data exchange across organisational and jurisdictional boundaries. Two initiatives — the International Data Spaces Association and Gaia-X — are particularly significant for enterprises whose sovereign data strategy extends beyond the management of their own internal data estate to encompass data sharing with external partners, regulators, and ecosystems.

The International Data Spaces Association provides the Dataspace Protocol: an interoperability specification for the control plane of data space deployments, defining the mechanisms through which participants in a data space establish trust, negotiate data usage policies, and exchange data under governance frameworks that both parties have agreed to. The IDSA Reference Architecture Model describes the components of a compliant data space connector — the piece of software that each participant operates to interact with the data space — and the governance rules that bind participants to the terms of the data space. For an enterprise implementing Zero-Copy Integration, the IDSA connector model is a natural extension of the API façade pattern: the connector presents the enterprise’s data to the data space through a governed interface, enforcing the data usage policies that the enterprise has committed to without requiring the underlying data to be replicated into a shared repository.

Gaia-X, the European initiative for a federated and trustworthy data and infrastructure ecosystem, provides a framework within which data spaces can be established, governed, and interoperated in a manner that aligns with European values of openness, sovereignty, and transparency. Gaia-X is not a cloud platform; it is a certification and standards framework that defines the rules under which participants in the ecosystem can trust each other’s governance claims. An enterprise that has aligned its data governance architecture with Gaia-X’s standards — including its requirements for federated identity management, data usage policy enforcement, and audit trail maintenance — has taken a significant step toward the kind of trusted, sovereign data exchange that the emerging regulatory environment will increasingly require.

Both IDSA and Gaia-X are in an active phase of maturation in 2026, with implementations moving from pilot projects and proofs of concept into production deployments across regulated industries. The enterprise that engages with these standards now — aligning its governance architecture with the emerging interoperability specifications rather than waiting for the standards to stabilise fully — will be in a materially stronger position when cross-industry data spaces become a regulatory expectation rather than a competitive differentiator.

3.7 Case Study: EuroInsure and the Logical Customer 360

The experience of EuroInsure, a pan-European insurance group operating across eight EU member states as well as the United Kingdom and Switzerland, provides a concrete illustration of how the sovereignty requirements described in this chapter manifest in practice and how the Zero-Copy architecture addresses them.

EuroInsure’s strategic aspiration was a group-level Customer 360 capability: a unified view of each customer’s policy holdings, claims history, and service interactions across all national operations, to support risk modelling, personalised service, and cross-border product development. The commercial case was compelling. The initial architectural instinct was to consolidate all relevant customer data into a central data lake hosted in a core EU jurisdiction, from which the Customer 360 queries could be executed. This was the pattern that the enterprise’s existing data warehousing and analytics infrastructure had used for domestic customer data, and the obvious extension of that pattern to the group-level requirement.

The legal analysis that preceded any detailed design work identified the fundamental flaw in this architecture. The data localisation requirements of three of the eight EU member states in which EuroInsure operated — requirements that derived from national data protection legislation that supplemented GDPR’s baseline under Article 9’s special categories provisions for insurance data — prohibited the transfer of customer claims and policy data to repositories hosted outside the national territory, regardless of whether those repositories were within the EU. EuroInsure’s legal function determined that no standard contractual mechanism could cure this prohibition: it was statutory and non-derogable. The three national operations generated approximately 40 per cent of EuroInsure’s group customer base; a Customer 360 that excluded them would have been commercially meaningless.

The zero-copy architecture that replaced the failed centralisation concept implements Customer 360 as a governed, federated query across sovereign national data nodes. Each national operation maintains its customer data — policy records, claims history, interaction logs — within the national territory, registered in a central governance catalogue managed on IBM Knowledge Catalog infrastructure hosted within the EEA but without holding copies of the customer data from any national operation. IBM watsonx.data’s federated query capability — regional Presto clusters deployed within each national jurisdiction on Red Hat OpenShift, coordinated through the central metadata catalogue — executes Customer 360 queries as distributed workloads, collecting the data elements required from each national operation, applying the access controls and data masking mandated by each jurisdiction’s requirements for the specific requesting user, and assembling the unified Customer 360 view dynamically.

The customer data does not leave the national territory in which it originates. The Customer 360 view is a logical construct, assembled at query time from the governed data interfaces of the national operations, not a physical dataset held in a central repository. EuroInsure’s legal function assessed this architecture as compliant with the data localisation requirements of all eight EU member states. The group analytics function received a Customer 360 capability that, while architecturally more sophisticated than a centralised data lake, proved in practice to be more flexible — because any change to the data classification or access control requirements of a specific national jurisdiction could be implemented through a configuration change to that jurisdiction’s governance policies, without requiring any change to the central Customer 360 query layer.

The lessons that EuroInsure’s experience offers to enterprises facing comparable sovereignty requirements are clear. The instinct to centralise — to consolidate data into a single repository for ease of analytical access — must be critically examined against the sovereignty constraints of the jurisdictions in which the enterprise operates. Where those constraints prohibit centralisation, the Zero-Copy architecture provides an alternative that satisfies the analytical requirement without violating the sovereignty constraint. And the investment in the governance infrastructure — the data catalogue, the federated query layer, the jurisdiction-aware access controls — that makes the federated Customer 360 possible is not merely a compliance cost; it is the foundation of an analytical capability that is more flexible, more governable, and more resilient than the centralised alternative it replaces.

3.8 The AI Accountability Imperative

The EU AI Act’s requirements for the transparency and auditability of high-risk AI systems introduce a dimension of accountability to the sovereignty architecture that deserves specific treatment, because it connects the governance infrastructure of the Zero-Copy architecture directly to the AI governance requirements that enterprises deploying AI at scale are beginning to encounter in regulatory practice.

The Act’s requirements for high-risk AI systems include the maintenance of logs that enable, for each AI system output, the reconstruction of the inputs that generated it, the model version used, and the operational context in which it was generated. This is a lineage requirement: the enterprise must be able to trace the provenance of each AI decision to the data that informed it and the model that processed it. For AI systems that operate on data accessed through the Zero-Copy architecture, this lineage requirement is satisfied as a structural property of the governance infrastructure: IBM Knowledge Catalog’s lineage tracking records every data access that contributes to an AI system’s inputs, and the integration of that lineage record with the AI system’s own decision logging provides the complete audit trail that the Act requires.

The governance infrastructure that Zero-Copy Integration provides is therefore not merely useful for AI accountability; it is the enabling condition for the responsible deployment of AI in regulated enterprise environments. Enterprises that have invested in a robust Zero-Copy governance architecture before they begin deploying AI at scale will find that the AI accountability requirements of the EU AI Act — and of the equivalent frameworks that other jurisdictions are developing — can be satisfied within the existing governance infrastructure, rather than requiring a separate and potentially duplicative AI governance system to be built alongside the data governance infrastructure.

3.9 The Sovereign Maturity Model

For technology leaders assessing their organisation’s current position and planning its trajectory towards genuine architectural sovereignty, a maturity model provides the structured framework for diagnosis and prioritisation. The following four-stage model, which informs the more comprehensive treatment in Chapter 15, describes the characteristic features of each maturity level and the principal architectural and organisational changes that mark the transition between levels.

An enterprise at the first stage of sovereignty maturity is characterised by copy-heavy integration, heavy reliance on nightly batch ETL processes, and an absence of systematic governance over the data copies that those processes create. Sovereignty compliance, to the extent it is addressed at all, is managed through geographic choice of cloud region and standard contractual clauses with cloud providers. The enterprise is in the sovereign cost trap described in Chapter 2: paying compliance costs without achieving genuine sovereignty.

The second stage is characterised by distribution without coherence. Workloads have been distributed across cloud and on-premises environments, but the integration between them remains primarily replication-based. Point-to-point replication flows exist between environments, creating data gravity problems that compound over time. Some governance tooling has been deployed, but it is not consistently applied across the estate, and the lineage visibility it provides is incomplete. Shadow integration — undocumented data flows created by project teams outside the governance framework — is prevalent.

The third stage is characterised by federation and policy-driven governance. The enterprise has deployed Zero-Copy integration patterns for its highest-priority data assets, replacing the most costly replication flows with federated access. Policy-as-code is applied consistently through the integration estate, with OPA or equivalent enforcing access controls at query and API level. The data catalogue is the authoritative register of data assets and their sovereignty classification. Lineage tracking covers the majority of significant data flows. The enterprise can demonstrate, to regulatory satisfaction, that its cross-boundary data flows are documented, assessed, and governed.

The fourth stage is full architectural sovereignty. Sovereignty is an inherent property of the software stack, not a compliance overlay on an existing architecture. The enterprise controls its own control plane, manages its own keys and identities within the sovereign boundary, executes AI inference under its own governance framework, and can demonstrate compliance with the full range of applicable sovereignty requirements through automated, real-time governance evidence rather than periodic manual audit. Operations are designed to survive full-region failures without dependency on out-of-boundary services.

Most large regulated enterprises in 2026 are positioned at stage two or early stage three. The transition from stage two to stage three — the adoption of Zero-Copy integration patterns and systematic policy-as-code governance — is the priority architectural investment that this book provides the framework for making. The transition from stage three to stage four — the achievement of full architectural sovereignty through the deployment of the Sovereign Core model or an equivalent — is the medium-term architectural direction that the regulatory trajectory of the next five years will make increasingly necessary.

3.10 Summary and Architectural Imperatives

This chapter has examined digital sovereignty as the multi-dimensional architectural requirement that the regulatory environment of 2026 demands, rather than the geographic compliance checkbox that it represented a decade ago. The European regulatory collision — the intersection of GDPR, DORA, NIS2, and the EU AI Act — requires a unified architectural response that addresses data residency, processing control, operational resilience, and AI governance simultaneously. The global jurisdictional landscape adds further complexity and urgency. The structural fragility of contractual sovereignty, demonstrated most powerfully by Schrems II, establishes the architectural imperative for sovereignty that is grounded in technical properties rather than legal agreements.

IBM’s Sovereign Core framework represents a significant architectural response to these requirements: a software-defined sovereignty model that makes sovereignty an inherent property of the platform rather than a characteristic of the infrastructure on which it runs. Its portability across cloud and on-premises environments, its customer-operated control plane, and its always-on automated sovereignty controls represent capabilities that the infrastructure- centric sovereign cloud offerings of the major hyperscalers do not fully replicate.

Zero-Copy Integration is the technical mechanism through which sovereignty requirements are satisfied at the data layer: through data minimisation that reduces the cross-boundary flows requiring legal authorisation, through the open table format capabilities that enable multi-engine access without replication, through policy-as-code governance that enforces sovereignty requirements at the point of access, and through resilient architecture that eliminates the cross-boundary dependencies that create single points of failure in the integration estate.

For the technology leader responsible for translating these architectural principles into organisational action, three imperatives emerge from this chapter’s analysis. The first is to assess the enterprise’s current sovereignty posture with the rigour that the regulatory environment now demands: not merely where data is stored, but where it is processed, under whose operational authority, with what access controls, and with what auditability. The second is to identify the cross-boundary data flows that represent the greatest sovereignty risk — the highest-volume flows, those involving the most sensitive data categories, those with the most fragile legal basis — and prioritise their replacement with Zero-Copy integration patterns. The third is to engage with the Sovereign Core model, or an equivalent software-defined sovereignty architecture, as the medium-term direction for the enterprise’s platform investment, rather than accepting the constraints of infrastructure-centric sovereign cloud offerings as the ceiling of what is achievable.

The following chapter examines the three integration planes — Data, Event, and Control — through which the Zero-Copy architecture implements these sovereignty principles in the operational integration estate of the enterprise.

---

If you are finding this content useful, please consider supporting the author's efforts by purchasing a complete digital or hard-copy version.

Zero-Copy Integration: Architecture for the Fragmented Enterprise © 2026 by Alan Hamilton is licensed under CC BY-SA 4.0