Changing where your data is stored isn’t enough to deliver sovereignty. You also need to implement the technologies that enforce real control. Local providers are keen to promise alternatives but US ones are making the effort to give customers more options without losing access to the depth of services they offer. Actually turning the promise of sovereign cloud regions into reality means dealing with encryption keys, access workflows and confidential computing, which also means more costs, dependencies, and operational responsibilities.

The obvious concern with using US cloud services is the CLOUD Act, which allows the US government to request access to customer data from a US-owned service, even if it’s held in the EU. Those requests are supposed to go through the criminal court system. “When it lands in Europe it headbutts with GPDR and you’re involved in legal wrangling as to whether or not that data can be released or not,” IDC research director Rahiel Nasir says.

He views the US Foreign Intelligence Surveillance Act (FISA) as more problematic because it doesn’t go through the normal criminal courts. “That’s an executive order,” he adds. “They’ll just take whatever they need.” The increasing number of sovereign public cloud regions promising data residency and local operations can’t help with that.

Controlling encryption keys

Under its EU Data Boundary, Microsoft stores and processes EU customer data and even support logs, at least for core cloud services, inside the EU. AWS has similar commitments for its European Sovereign Cloud, claiming no critical dependencies on infrastructure outside the EU. And like Salesforce, it employs EU-based support staff for its EU operating zone. Google and Oracle have similar dedicated sovereign regions in Europe, and some of the providers plan to offer similar models in other jurisdictions.

For admin and support, for example, most tasks are performed through automated, audited workflows, and Microsoft personnel don’t have standing or unrestricted access to customer content, says Douglas Phillips, president and CTO for Microsoft specialized clouds. When they do need access for a support issue, customers can approve or reject specific access requests to Microsoft 365, Azure, Dynamics 365, and Power Platform data. “Approved access is customer-controlled, limited, time-bound, and audited,” he says.

The new Data Guardian adds the option of having remote access by Microsoft engineers overseen by an EU partner, with EU-based staff. And tamper-evident records of that access, and any actions performed, are stored in a Production Touch Ledger, which is rolling out in the EU and EFTA.

But a US parent company is still subject to the CLOUD Act and can be forced to hand over data if they control the encryption keys rather than the customer. “The hyperscalers have made their key management capabilities easier for organizations to use as a direct result of their sovereign needs,” Nasir says. “Google, AWS, Microsoft, Oracle all say that you’re the data owner and we can tell you who’s accessing your data. Nobody accesses it without your permission. It’s encrypted and you manage the keys and hand them over as and when you’re ready.”

That relies on companies having the resources to manage those encryption keys rather than leaving them up to the cloud provider who could legally be required to use them to make data available. Nasir compares it to the familiar shared responsibility model of the cloud, but it requires investment. “If that’s important to you and you want to have that control, then you’re going to recruit the staff who can manage that task for you,” he says. “It’s down to the organization having the skill level to be able to do that.”

Private cloud on your own infrastructure, at the edge, or in data centers, might be part of the mix, too, if you want more control over operations and data handling, and Azure and AWS have options for running public cloud services locally in an intermittently connected or even fully disconnected fashion.

But running your own local infrastructure, especially with hardware security modules for encryption key storage, is even more demanding than managing cloud keys, Kiteworks EMEA GM Dario Perfettibile says.

“A government agency, defence contractor, or large, highly-regulated enterprises like financial services have their own security and infrastructure teams, and can afford those costs because it’s not a one-time project,” he says. “There are ongoing costs.”

What most companies need instead is the ability to control and revoke access to their most sensitive data independent of a cloud provider’s or vendor’s own staff,” Scality CMO Paul Speciale adds.

Getting more confidential

Even where data is encrypted, platform metadata usually isn’t because that’s operational information for the provider, and it might reveal details about your organization or operations, if not your customers.

The added cost and complexity of confidential computing, which protects data in use, has limited usage, but Gartner predicts that by 2029, more than 75% of operations on this kind of untrusted infrastructure will use it for security. Azure, AWS, Google, and IBM offer various levels of confidential computing, including VMs, application enclaves, and always-encrypted database services. And VAST has just launched a secure container runtime and attestation service for running AI workloads.

It’s an obvious fit for data sovereignty. “Confidential computing isolates data in use, while attestation lets customers verify approved code and environments before releasing sensitive data or secrets,” Phillips says.

Similarly, AWS Nitro Enclaves offer isolated compute in EC2. “AWS is powered by the Nitro System, which enforces access restrictions so nobody, including our own employees, can access customer data running in Amazon EC2,” AWS head of corporate comms Harry Staight says.

Getting too local

The downside of rigorous data sovereignty is the cost and the potential impact on productivity, especially for multinationals. “Sovereignty shouldn’t become so rigid that it creates unnecessary operational complexity or introduces new risks through systems difficult to manage,” says Kim Larsen, Group CISO at data recovery platform Keepit.

The most extreme approaches to sovereignty highlight how much flexibility you might lose. “The biggest use case of sovereign data in the world is FedRAMP,” says Artur Bergman, CTO at edge computing company Fastly. “To operate it, you have to be a US person on US soil.” The cost of that is up to a hundred times higher than similar commercial cloud services, and connectivity is extremely restricted. And while the Amazon CloudFront CDN has hundreds of points of presence globally, only two can be used for FedRAMP.

Few organizations will need such extreme restrictions but for an acceptable level of data sovereignty that strictly manages access to data by staff location, private companies will still pay a lot, which may not always make sense, says Bergman. Round-the-clock operation is common, and partly based on having staff in multiple locations. But the cost of delivering that with on-call staff significantly increases in places with heavily regulated working hours like Germany, or Sweden where shifts from midnight to 5am are banned unless the service is deemed essential to society, or union agreed.

This will be hard for most enterprises because they operate in all these jurisdictions, and they need to be able to talk about things internally.

“Restrictive models provide greater control and isolation, but shift responsibility for security, identity, resilience, maintenance, and lifecycle management to the customer,” Phillips says. “In some cases, highly restrictive approaches can complicate global collaboration, mobile workforces, or cross-border operations.”

Practical not political

The situation is unlikely to get simpler as more countries pass their own data residency laws. The EU is planning to implement the Cloud and AI Development Act (CADA), after concerns about not just the CLOUD Act but incidents like a Canadian court ordering OVHcloud to produce customer data held on servers in France. That’ll cover different levels of sovereignty, with more rigorous ones for defense and government services.

There are also questions about whether the EU will decide to annul the EU US Data Privacy Framework, which covers data transfers to the US without requiring every EU organization using US providers to make their own data protection impact assessments. But court decisions about that are likely to take months if not years. The framework has remained in effect despite being challenged many times, and Kiteworks’ Perfettibile cautions against waiting for any decision. “You have to build on what you have today, not think about what’s happening tomorrow, because security won’t wait until tomorrow.”

Nasir adds that what we need is real-world practical advice, not politics and emotions. The realistic approach starts with regulatory, operational, and risk requirements of each workload, identifying the threat model rather than applying the most restrictive model everywhere, and sacrificing agility and resilience, Phillips says. Rather than maximum isolation, organizations look for the right balance of control, security, compliance, operational effectiveness, and innovation.

Similarly, AWS says customers want control over the physical location of their data, granular restrictions on who can access it, the ability to encrypt it under their own keys, and resilience to sustain operations through disruption.

Making that work means understanding what data you have, where it is and how it flows across your organization — something that’s often left to individual users marking data as sensitive or non-sensitive. Tagging and metadata, which are now more routine for AI, are what make governance possible: you can’t control who accesses something you haven’t classified. After years of hoarding data, many companies have petabytes of storage with no clear idea what’s in it, who’s touching it, or if it’s still relevant. That’s a data management problem, not a location or sovereignty issue. But tackling it will help.

Microsoft and Google are joining a project to create an open specification for exchanging semantic models across data, analytics, and AI platforms. The project already has the backing of over 60 companies including Databricks, Informatica, Mistral AI, Nvidia, Oracle, Salesforce, and Snowflake.

Their support for Ossie makes it a little more likely that future analytics platforms will be interoperable, but is no guarantee that vendor lock-in will go away, analysts said.

The project began life as Open Semantic Interchange (OSI), then became Apache Ossie when it was accepted into the Apache Incubator in June. It uses JSON and YAML to represent semantic models, including datasets, fields, relationships, metrics and AI context, making them interoperable across platforms such as Snowflake, Databricks, Tableau, ThoughtSpot and Sigma.

Ossie uses a hub-and-spoke model for interoperability, serving as the common semantic format while converters translate between it and individual vendors’ semantic implementations. This means an enterprise could move a semantic model between compatible platforms without requiring a separate point-to-point converter for every pair of vendors.

Microsoft’s support for Ossie includes developing a two-way converter between Power BI semantic models and Ossie, allowing semantic context defined in Power BI to be represented in the common format and Ossie models to be converted back into Power BI, the company wrote in a blog post.

It is also pushing for the Ossie specification to include more support for its ontologies, and for Ossie’s recognized query languages to include DAX, the expression language used by Power BI for defining calculations and business metrics.

That means enterprises could carry the calculation logic that gives their semantic models business meaning alongside the underlying model when moving between platforms that support Ossie, it wrote.

Google, meanwhile, is in the process of joining Apache Ossie, a company representative said via email response. The company has not yet provided details on what it plans to contribute or has already contributed.

The Ossie specification lists BigQuery/GoogleSQL as a supported dialect, a result of “early community contributions that recognize BigQuery’s footprint across enterprise data stacks,”the representative said.

Microsoft, Google backing could reduce engineering work

Support for the project from the two technology giants could reduce the burden of repeated semantic engineering for enterprise teams moving analytics workloads between platforms, said Aditya Ranjan, senior data engineer at supermarket giant H-E-B.

That reduced engineering overhead could also help avoid metric drift, which is often the consequence of recreating and maintaining the same business definitions across platforms, according to Ashish Chaturvedi, executive research leader at HFS Research. With Ossie, developers can instead define a metric once and treat it as a versioned, reviewable code artifact, rather than rebuilding and maintaining it separately for each platform, he said.

Another potential benefit, said Ranjan, is that productivity could improve if developers spend less time translating and validating semantic definitions for each platform when onboarding new analytics tools or deploying new analytics or AI applications.

It can also make it easier for developers to build agentic applications with consistent business context, since maintaining one definition of a metric across platforms could reduce the risk of different agents interpreting the same metric differently, said Stephanie Walter, practice leader of AI stack at HyperFrame Research. That could give CIOs greater confidence to scale agentic deployments, she added.

Portability

For Michael Leone, principal analyst at Moor Strategy and Insights, the bigger advantage of Microsoft and Google supporting Ossie is that it gives enterprises more ownership of their semantic models by making them more portable.

That portability gives buyers more leverage, said Walter, since changing a BI or data platform would no longer require rebuilding the semantic layer from scratch.

However, portability does not necessarily mean complete interoperability, as the degree to which enterprises can move semantic models between platforms will depend on how much vendor-specific logic and functionality Ossie can represent and how accurately the destination platform can interpret it, Walter said.

“A portable structure does not guarantee equivalent behavior. A metric may survive conversion syntactically but still produce a different result because the destination interprets joins, nulls, time calculations, or filters differently.”

That challenge is particularly relevant for Power BI, as its time-intelligence functions, calculation groups, and context transitions in DAX do not always map cleanly to ANSI SQL, meaning a sophisticated Power BI model could lose some of its behavior in translation, Chaturvedi said.

CIOs, therefore, will still need to validate whether converted models preserve the intended calculations, business logic and results before putting them into production, especially for complex ones, Ranjan advised.

There are gaps around governance as well, Chaturvedi said: “The core specification covers datasets, relationships, fields, and metrics, but doesn’t mention row-level security, access policies, or certification status as first-class elements.”

That means enterprises have to set them up again on each platform.

Moreover, Ossie’s stability and long-term adoption remain open questions. The project is still “incubating”, meaning that it isn’t a full Apache Software Foundation project and has yet to prove it meets community norms. The current specification version, 0.2,is explicitly labeled a development draft, meaning the schema and capabilities could still change as it evolves, giving CIOs less certainty about its suitability as a long-term interoperability layer, Walter said.

“The current draft also removes the earlier document structure and does not yet define bundles or cross-model references, which are capabilities that large enterprises with interconnected models are likely to need,” said Chaturvedi.

Ossie could shift rather than eliminate vendor lock-in

Even if Ossie becomes widely adopted, it is unlikely to eliminate vendor lock-in entirely.

“New forms of lock-in are likely to emerge. Execution engines will retain proprietary behavior that no interchange format captures and vendor extensions will carry increasingly valuable features,” Chaturvedi said.

For enterprises, that means the definitions become portable while the behavior around them stays platform-specific, he added.