What Is Data Sovereignty? Definition, Requirements, and Implications for Cloud and AI

Data sovereignty generally refers to the control an organization or data owner retains over data, within the legal and jurisdictional conditions that apply to it. This includes how data is accessed, used, processed, stored, and moved. Current EU guidance similarly frames data sovereignty around maintaining control over data, including access and usage rights.

Data location is one part of sovereignty. It does not, by itself, establish control. In practice, organizations also assess who can access data, which technology providers the workload depends on, and whether data and workloads can be moved if legal, geopolitical, or operational conditions change.

Organizations can assess that control by asking:

• Where is our data stored and processed?
• Who can access it, and which jurisdictions apply?
• Which cloud, technology, or AI providers do our workloads depend on?
• Could we move the data or workload and continue operating if conditions changed?

BARC’s 2026 research shows why these questions have become a business priority.

In enterprise environments, data sovereignty spans legal jurisdiction, data governance, technical architecture, provider dependencies, and operational continuity.

What Is the Main Difference Between Data Sovereignty and Data Residency?

Data residency generally describes where data is stored. Data sovereignty concerns who retains control over the data and which legal or jurisdictional conditions apply to it. Control can include access rights, usage rules, and the ability to restrict or revoke access.

Storing data in a particular country does not automatically establish sovereignty. An organization may keep data in an approved region while still relying on external administrators, infrastructure providers, or services that affect how the data is accessed, processed, or controlled.

	Data sovereignty	Data residency
Main question	Who controls the data, and which jurisdictional conditions apply?	Where is the data stored?
Primary focus	Control, access, governance, and jurisdiction	Geographic location
Data processing	Can be part of the assessment	Not defined by storage location alone
Provider dependencies	Relevant when they affect control or operational independence	Not addressed by location alone
Operational access	Can be part of the assessment	Not addressed by location alone
Is location sufficient?	No	Location is the core consideration

For enterprises, data residency is one component of a broader sovereignty strategy. A sovereignty assessment can also examine access, processing locations, applicable jurisdictions, and dependencies that could limit control over the data or workload.

Data Sovereignty and Residency

Data residency can support a data sovereignty strategy by establishing where data is stored. It does not, by itself, determine who can access that data or which legal, operational, and governance conditions apply.

Residency answers where the data is stored. Sovereignty asks a broader question: who controls the data and under what conditions?

This distinction is particularly relevant in cloud and hybrid environments. Selecting an approved data region establishes location, but organizations may still need to assess administrative access, processing, provider dependencies, and applicable jurisdictions to understand their level of control.

Explaining the concept of data localization and its importance

Data localization generally refers to regulatory measures that require certain data to be stored or processed within a specified territory. The requirements vary. Some mandate local storage while allowing copies or processing elsewhere; stricter measures can require local storage and processing while restricting cross-border transfers.

Localization is different from simply choosing a data residency. Residency identifies location. Localization imposes requirements on location or processing.

A useful distinction is:

Data residency: Where is the data stored?
Data localization: Where must the data be stored or processed?
Data sovereignty: Who controls the data, and which jurisdictional conditions apply?

For organizations operating across countries, these distinctions can affect cloud-region selection, data transfers, backups, processing locations, and provider decisions. The requirements depend on the jurisdiction, sector, and type of data involved.

How Do Data Sovereignty Laws Impact International Data Management?

Laws and regulations that affect data sovereignty can determine where data may be stored and processed, how it can move across borders, who can access it, and which safeguards apply. For organizations operating across jurisdictions, data sovereignty and global compliance are closely connected because requirements around data transfers, access, privacy, and storage can differ between legal regimes.

Requirements vary by jurisdiction, industry, and type of data, which means international organizations may need different controls for different datasets and workloads.

The European Union’s General Data Protection Regulation (GDPR) illustrates the complexity of cross-border data management. When personal data is transferred outside the European Economic Area (EEA), GDPR protections continue to apply. Depending on the destination and circumstances, organizations can use mechanisms including adequacy decisions, standard contractual clauses, or binding corporate rules to support lawful transfers.

Other countries apply different rules to cross-border data flows. These can range from allowing transfers under defined safeguards to requiring certain data to be stored or processed locally. OECD research documents significant differences in national approaches to cross-border transfers and data localization.

For international data management, organizations may need visibility into:

• where primary data, backups, and replicas are stored;
• where data is processed;
• when data crosses national or regional borders;
• which providers and subprocessors handle it;
• who has administrative access;
• which jurisdictions apply; and
• how regulatory or geopolitical changes could affect access to data and workloads.

Other risks are becoming more prominent: 54 percent cited political developments in the United States, 49 percent cited cybersecurity incidents, and 46 percent cited dependency on public cloud offerings.

BARC recommends treating dependency and resilience risks as architecture inputs rather than addressing them later. This includes defining portability requirements, exit options, encryption and key-management models, workload-placement rules, and supplier-risk controls.

What are the key requirements for complying with data residency regulations?

There is no single global set of data residency requirements. Compliance starts with identifying the laws, regulations, contractual obligations, and internal policies that apply to a specific dataset and workload. Some rules address storage location, while others also affect processing or international transfers.

Depending on the applicable requirements, organizations may need to establish:

1. Required data locations: Identify where regulated data must be stored.
2. Locations of copies: Account for backups, replicas, archives, and disaster-recovery copies.
3. Processing locations: Determine whether applicable rules also restrict where data may be processed.
4. Cross-border transfers: Identify when data leaves the relevant jurisdiction and which transfer rules apply.
5. Third-party handling: Understand which providers and subprocessors store, process, or transfer the data.
6. Applicable jurisdictions: Determine which legal regimes govern the data and the organizations handling it.
7. Required controls and evidence: Implement and document the access, security, monitoring, and governance controls required by the applicable rules.

These are compliance questions. Broader data sovereignty planning goes further. It considers whether an organization can change providers, relocate workloads, or maintain access if regulatory, commercial, or geopolitical conditions change.

Why Is Data Sovereignty Becoming More Important?

Data sovereignty is becoming more important as organizations rely on data, cloud services, and AI for core business processes. Regulation remains a major driver, while cybersecurity, geopolitical developments, and provider dependency are increasing the need to understand where control and risk sit. These pressures are part of wider data sovereignty trends that are pushing infrastructure, cloud strategy, security, and provider choice higher on the enterprise agenda.

BARC’s Data Sovereignty 2026: Reality, Relevance, Roadmap study quantifies that shift. Eighty-nine percent of respondents consider data sovereignty very or rather important, and 76 percent expect its importance to increase further.

The growing use of AI is also changing the conversation. Sixty-two percent of respondents cited increased use of data and AI in core business processes as a reason data sovereignty has become more relevant. BARC also identified growing data sensitivity and dependence on specific technology or cloud providers among the leading internal drivers.

The full study examines how organizations are responding, where implementation gaps remain, and what BARC recommends for turning sovereignty goals into practice.

Explaining the Different Design Approaches for Sovereign Cloud Architectures

Cloud sovereignty is not determined by deployment model alone. Organizations can use regional public cloud, sovereign cloud services, hybrid architectures, private cloud, or on-premises infrastructure. The right approach depends on the workload’s legal, security, operational, and control requirements.

The European Commission’s Cloud Sovereignty Framework, developed for its cloud procurement, illustrates how broad that assessment can be. It evaluates providers across eight objectives: strategic, legal and jurisdictional, data and AI, operational, supply chain, technological, security and compliance, and environmental sustainability. It also uses Sovereignty Effectiveness Assurance Levels to assess different levels of sovereignty and resilience.

The framework is one assessment model, not a universal certification for sovereign cloud. It does, however, show why data location alone is not enough to assess control.

Regional public cloud

A regional public cloud lets customers select a geographic region for many cloud resources and data stores. This can support data residency requirements when the selected services and configuration keep the relevant data in the required location.

Organizations still need to examine how the service handles processing, administrative access, provider operations, and applicable jurisdictions. A regional deployment answers an important location question, but it does not answer every sovereignty question.

Sovereign cloud

Sovereign cloud offerings may add controls beyond regional data placement. Depending on the provider and service, these can address jurisdiction, operational control, personnel access, encryption and key management, supply-chain dependencies, and technological autonomy.

There is no single architecture behind the “sovereign cloud” label. The European Commission’s framework, for example, assesses multiple dimensions and levels of sovereignty rather than relying on the provider label itself.

Organizations should verify the specific controls an offering provides and which dependencies remain.

Hybrid cloud

A hybrid architecture combines different environments so workloads can be placed according to their requirements. For example, an organization may use a public cloud for one workload while placing sensitive or highly regulated data in an environment with more direct operational control.

BARC’s 2026 research supports this differentiated approach. The study argues that sovereignty does not mean avoiding cloud by default. It requires deliberate decisions about where data and workloads reside, which providers are trusted for particular use cases, and how dependencies can be reduced when risk becomes too high.

Hybrid architecture can support that flexibility when workload placement, governance, and security controls are defined consistently across environments. An Exasol Virtual Schema can also support access to data across distributed environments without requiring every source to be consolidated into a single platform.

Private cloud or on-premises infrastructure

Private cloud and on-premises infrastructure can provide more direct control over where systems run, who administers them, and how data is accessed.

These models may suit workloads with strict legal, security, or operational requirements, but infrastructure ownership does not eliminate every external dependency. Software vendors, hardware suppliers, support services, identity systems, and other technology providers can still affect operational control.

The deployment decision should reflect the requirements and dependencies of the workload rather than assume that infrastructure location determines sovereignty.

Reversibility: can you actually move the workload?

Eric Trabold, Chief Commercial Officer at Exasol, uses reversibility as a practical test of sovereignty. The question is whether an organization can change direction if a provider, technology, or operating condition changes.

His assessment includes questions such as:

• Can you move the data to another environment?
• Can you move the workload with it?
• Can you maintain the required performance?
• Can you change an AI model provider?
• Can the workload operate across cloud and on-premises environments?
• Can you use open formats where portability matters?
• Have you tested the migration path?

Trabold’s point is practical: an exit plan has more value when the organization knows that the migration path works.

Reversibility extends the sovereignty discussion from where a workload runs today to whether the organization can change that decision tomorrow, including through cloud repatriation when workloads need to move from public cloud to on-premises, private cloud, or hybrid environments.

What are the main benefits of sovereign cloud solutions for businesses?

Sovereign cloud solutions can give organizations more control over sensitive cloud workloads while retaining access to cloud infrastructure and services. Depending on the offering, potential benefits include clearer jurisdictional alignment, tighter controls over data and administrative access, greater visibility into technology dependencies, and better alignment with regulatory or internal requirements.

Those benefits depend on the controls the service actually provides. Organizations should verify how data is stored and processed, who can access the environment, which dependencies remain, and how workloads can be moved if requirements change.

How does cloud sovereignty impact data security and compliance?

Cloud sovereignty can support security and compliance by making decisions about data location, access, jurisdiction, operational control, and provider dependencies explicit in the architecture.

It does not replace security or compliance requirements. Sovereign environments still need controls appropriate to the workload, which may include identity and access management, encryption, key management, monitoring, and audit processes.

Data residency is also only one part of compliance. Keeping data in a required location does not by itself satisfy every security, privacy, or sector-specific obligation.

A practical architecture should match the level of control to the workload’s requirements and define how the organization can move or replace the workload if those requirements change.

Sovereign AI and AI Sovereignty

Sovereign AI and AI sovereignty refer to the degree of control an organization retains over the data, computing infrastructure, models, access, and provider dependencies behind an AI workload. The terminology is still evolving, so the specific controls behind an AI deployment matter more than the label applied to it. Current EU policy is also formalizing sovereignty criteria specifically for cloud and AI computing services.

AI applications can introduce data flows beyond the system where information was originally stored. Depending on the architecture, documents, prompts, or other business data may be sent to a model service or external provider for processing. A sovereignty assessment should map those flows and identify where direct control is required. The relationship between data sovereignty and AI becomes especially important when sensitive or regulated data is used for model training, inference, or other AI-supported workflows.

Key questions include:

• Where does the source data reside?
• Where are data and prompts processed?
• Who can access the data and AI environment?
• What happens to the context provided to the model and the resulting outputs?
• Which model, cloud, and infrastructure providers does the workload depend on?
• Can the model, provider, or processing environment be changed if requirements change?

The European Commission’s 2026 technology-sovereignty agenda shows the wider context. The package covers semiconductors, cloud and AI capacity, open source, and digitalization of the energy system.

What is the concept of sovereign AI and how does it differ from regular AI?

Sovereign AI is not a distinct AI model architecture. The term describes the control conditions under which AI capabilities are developed, deployed, operated, and governed.

Two organizations could use the same underlying model while having very different sovereignty profiles. One organization might send sensitive business data to an externally hosted model API. Another might operate the same model in an environment where data location, processing, administrative access, and infrastructure are subject to tighter controls.

Model choice is one part of the assessment. Data flows, processing location, access, infrastructure dependencies, and exit options also determine how much control an organization retains.

Current EU policy makes a related distinction. The Commission’s 2026 proposal for the Cloud and AI Development Act introduces sovereignty criteria for cloud and AI computing services. The accompanying impact assessment explicitly states that AI systems themselves are outside that sovereignty measure because they are already governed by the AI Act.

The data question becomes especially important when AI applications use internal or sensitive company information. Trabold gives the example of employees uploading confidential documents to cloud-based AI tools without first understanding where that data goes or what happens after access is granted.

BARC recommends treating AI and data used in core business processes as an operational test for sovereignty, with particular attention to access, auditability, and data and model lineage.

What are the main challenges in developing and regulating sovereign AI?

Common challenges span data control, technology dependencies, portability, governance, and regulation.

• Data control: AI workflows can send sensitive information outside the systems where it was originally governed.
• Model dependency: Heavy reliance on one provider can make changing models more difficult when technical, commercial, or regulatory requirements change.
• Infrastructure dependency: AI workloads can depend on specific cloud services, computing infrastructure, APIs, or proprietary technology.
• Governance and traceability: Organizations need to know which data an AI application uses, who can access it, and how data and model lineage are managed.
• Portability: Moving an AI workload may require changes to models, infrastructure, data pipelines, or application logic.
• Regulation: Legal obligations depend on the applicable jurisdiction, sector, data, and AI use case.

At a national or regional level, AI sovereignty also depends on access to critical technology. The EU’s current technology-sovereignty package links its AI ambitions with semiconductor capacity, cloud infrastructure, open source, and reduced strategic dependency.

These considerations don’t mean an organization must build its own AI models or run every AI workload on-premises. A practical sovereignty assessment determines which controls each use case requires and whether the organization has a realistic exit path.

Reversibility is part of that assessment. Eric Trabold specifically asks whether an organization can change an AI model provider, move its data and workload, and operate across cloud and on-premises environments if circumstances change.

Data Sovereignty Requirements

There is no universal set of data sovereignty requirements. The controls an organization needs depend on the applicable jurisdictions, industry, data, workloads, technology dependencies, and risk profile.

For enterprises, BARC recommends organizing sovereignty around three connected areas: strategic alignment, governance and security controls, and technical architecture.

Strategic alignment

Data sovereignty needs a defined scope, clear ownership, and a business purpose. A practical assessment starts by identifying:

• Which data and workloads are business-critical?
• Which legal, security, and operational requirements apply?
• Which technology or provider dependencies create material risk?
• Who owns sovereignty decisions and exceptions?
• What level of control does each workload require?

This helps organizations avoid applying the same controls and architecture to workloads with very different requirements.

Governance and security controls

Governance turns sovereignty objectives into controls teams can apply. Depending on the workload, these can cover data storage and processing, access, data sharing, AI use, encryption and key management, monitoring, and decision rights. BARC recommends standardizing control requirements and reusable security patterns rather than redesigning them for each project.

For AI workloads, BARC also recommends defining which data AI can use, what auditability is required, how data and model lineage are tracked, and how access is controlled across environments.

Technical architecture

Technical architecture determines how sovereignty controls are implemented in practice. Relevant decisions include where data and workloads reside, which providers they depend on, how encryption and key management work, whether workloads are portable, and which exit options are available.

BARC recommends treating portability, workload placement, supplier risk, and exit options as design decisions early in the architecture process.

A practical way to classify workloads

Eric Trabold, Chief Commercial Officer at Exasol, uses a Green, Amber, Red framework to classify workloads by sensitivity and the level of control they may require. This is Trabold’s practical framework; it is not an industry standard.

Classification	Trabold’s framing	Practical implication
Green	Data is not highly sensitive.	Standard cloud services may be appropriate if the workload’s other requirements are met.
Amber	Data is sensitive but manageable with strong controls.	Define the required access, security, processing, and provider controls before placement.
Red	Data is critical, regulated, highly sensitive, or strategically differentiating.	Assess whether the workload requires a sovereign or more directly controlled environment.

Trabold then recommends deciding where each workload should run, such as a public cloud, sovereign environment, or infrastructure under greater direct control.

The framework gives teams a practical way to match sovereignty controls to workload risk instead of treating every workload the same way.

What Challenges Do Organizations Face When Implementing Data Sovereignty?

The challenge with data sovereignty is often turning policy into something that works across real systems, teams, and workloads. Legal and governance requirements have to translate into decisions about architecture, access, data placement, and technology dependencies.

That becomes harder in established environments, where existing platforms and processes were not necessarily designed with sovereignty requirements in mind.

BARC’s 2026 research illustrates this shift from policy to implementation. Technical hurdles were cited by 43 percent of respondents, up from 26 percent in 2025.

For organizations, the practical question is whether sovereignty requirements can be applied without creating unnecessary complexity or making critical workloads harder to operate.

Does Data Sovereignty Limit Innovation?

Data sovereignty can create friction when requirements are unclear, controls are added late, or teams have to resolve the same governance questions for every new project. Clear rules and reusable architecture patterns can reduce that uncertainty and give teams defined boundaries for experimentation.

BARC’s 2026 research challenges the assumption that stronger sovereignty automatically slows innovation. Forty-six percent of respondents reported a positive impact of data sovereignty initiatives on their organization’s innovation capabilities.

The practical difference lies in implementation. When teams know which data they can use, where workloads can run, which controls apply, and who can approve exceptions, they can make decisions earlier in a project. BARC argues that clear controls, governance patterns, and architectural boundaries can reduce uncertainty and make experimentation safer to scale.

For organizations building data and AI products, the goal is to make sovereignty requirements clear enough to guide innovation without turning every new use case into a separate governance exercise.

What Should Organizations Look for in a Data Platform for Data Sovereignty?

A data platform can support data sovereignty by helping organizations control workload placement and data access, understand technology dependencies, and preserve options to move workloads when requirements change.

When evaluating an analytics database for data sovereignty, organizations should assess whether its deployment model, connectivity, access controls, and portability align with the requirements of each workload.

When evaluating a platform, organizations should assess:

• Deployment flexibility: Can the platform run in the environments required for different workloads, such as cloud, hybrid, private cloud, or on-premises infrastructure?
• Data access and control: Can teams define and enforce who can access data and how that access is managed?
• Portability and dependencies: Can data and workloads move between environments, and which proprietary services, formats, or provider dependencies could restrict that movement?
• Exit options: Is there a credible path to change infrastructure or providers if legal, operational, or business requirements change?
• Integration: Can the platform fit the organization’s existing data, analytics, security, and AI architecture across the environments it uses?
• AI data control: Can the organization understand and control how AI applications access and process its data?

BARC recommends treating portability requirements, exit options, workload placement, and supplier risk as architecture decisions from the start.

Eric Trabold also connects data-platform selection with AI sovereignty. In the BARC podcast, he explains that AI increases the importance of the data platform because its role extends beyond storing and querying data to helping organizations maintain control as data is accessed and used in new ways.

For data sovereignty, platform selection should account for control, dependency visibility, portability, and a credible path to change deployment or providers when requirements change.

How Exasol Supports Data Sovereignty for Analytics

Exasol supports data sovereignty for analytics through deployment flexibility, open connectivity, and controls for governed analytical workloads.

The Exasol deployment options include customer-managed cloud, on-premises, and hybrid, and SaaS environments. This gives organizations options for aligning analytical workload placement with their data residency, governance, operational, and infrastructure requirements.

Exasol also supports standards-based SQL, JDBC, ODBC, native connectors, and integration with BI, ETL, orchestration, and data science tools. These capabilities allow Exasol to coexist with existing data warehouses, data lakes, lakehouses, and other analytics environments during migration or modernization.

For advanced analytics and AI/ML workloads, Exasol supports in-database execution of Python, R, Java, and Lua functions close to governed enterprise data. Exasol AI extends this approach to AI assistants, RAG workflows, and agentic use cases that need governed access to enterprise data. Current product capabilities also include role-based access, encryption, auditing, and authentication to support governed analytical environments.

These capabilities can support a data sovereignty strategy, but deployment choice alone does not establish regulatory compliance or guarantee that all data remains within a particular jurisdiction. Organizations still need to assess the complete architecture, data flows, integrations, operational model, and applicable legal requirements.

The Exasol 2026.1 release extends Exasol’s direction around governed AI and sovereign analytics while retaining deployment flexibility across existing enterprise environments.

A Simple Data Sovereignty Test

Eric Trabold’s practical approach can be reduced to three questions:

• Do we know which data and workloads are critical?
• Do we understand our dependencies across cloud, data, and AI providers?
• Could we change direction while maintaining access to the data and workloads the business needs?

Research Methodology and Disclosure

BARC conducted the Data Sovereignty 2026: Reality, Relevance, Roadmap study through a worldwide quantitative online survey in February and March 2026. After data cleansing, 320 responses remained for analysis. Exasol was one of the study sponsors.