AI Data Sovereignty Requires Control Beyond the Cloud Perimeter
As AI workloads spread data across cloud, on-prem and model environments, enterprises face new challenges in ensuring compliance with data sovereignty requirements
Growing regulatory scrutiny is making data sovereignty a more complex challenge for enterprises deploying AI, forcing them to look beyond data residency and examine where data is processed and accessed across increasingly distributed infrastructure.
Enterprises may keep their data on premises or in a designated AWS region, but that does not necessarily mean they retain control of that data once AI model providers can process it.
Organizations operating in Europe, in particular, need to balance meeting regulatory requirements including the EU Data Act and the European Commission’s Sovereign Cloud Framework, while also removing dependency on US cloud frameworks such as the US Cloud Act.
According to analyst firm Gartner, worldwide sovereign cloud infrastructure as a service (IaaS) expenditure is set to rise to $80 billion in 2026, a 35.6% increase from 2025. Meanwhile, Gartner projects that European spending will climb by 83% to $12.6 billion in 2026, and then surpass North American spend in 2027, reaching $23.1 billion.
Ensuring compliance with data sovereignty requirements starts with establishing data retention policies.
Assessing Data Retention Before Moving to AWS
Those decisions around data retention before migration are among the key challenges of moving enterprise applications to the cloud, Srinivas Chippagiri, senior member of technical staff at Tableau, tells TechChannel.
“The second thing you have to be aware of with your cloud migration is what are your company policies? What sort of company proprietary data do you want to keep on-prem?” Chippagiri says. “What sort of company data do you want to take to the cloud, and once you go into the cloud, what sort of policies, what sort of security roles are you going to apply to those policies.”
Enterprise leaders need to be aware of the distinction between traditional cloud sovereignty and AI sovereignty. When employees or applications send queries to external AI models, the information may leave the organization’s controlled environment. This creates sovereignty concerns, particularly when customer data and internal documents are involved.
As Abhishek Gupta, co-founder and CTO of open-source workplace AI platform PipesHub, tells TechChannel, “If you look at the majority of companies, the data is very much unstructured. A lot of data lives in your PDF files, in your document files, and this data essentially could be your IP as well. … It’s possible that the AI model … can just read that PDF file and expose all that information to the outside world.”
Sending on-premises data to external API endpoints can undermine sovereignty, even when the original information remains within the enterprise’s own infrastructure.
Vendor lock-in to a particular AI model can also compromise an enterprise’s control over its data. “Once you get locked into a vendor ecosystem, it becomes very difficult for you to have any kind of sovereignty,” Gupta notes.
Keeping AI Close to Enterprise Data
Enterprises have two main options for keeping AI processing closer to their data, Gupta says. “One way is you use these cloud providers, AWS and others, to keep your AI model within the same virtual private cloud (VPC) environment, so no data leaves the VPC. The other, if you are using an on-premises solution, is you deploy open models within your on-premises stack so no data goes out of your private stack.”
Enterprises using AWS have access to managed services such as Amazon Bedrock, which offers a way to access AI models within the cloud environment, close to the data they need to process. This can reduce the need to transfer information between internal systems and external AI providers while making it easier to apply existing security, access management and governance controls.
Rather than viewing data as a monolith, enterprises can co-locate certain portions of data in different locations to meet sovereignty requirements, Jonathan LaCour, CTO at Mission Cloud (a CDW Company), tells TechChannel.
“Co-locating your compute with your data is a really good idea, and fragmenting your workloads is a good way to make sure that you do that well, so you don’t have to have all your data in one place.”
For example, an enterprise might locate European customer data in an AWS Region located in the EU.
“Maybe there’s data that you need in a region for a particular sovereignty reason. Particularly if you’re hosting workloads in the EU, there’s a lot of constraints,” LaCour says. “In Germany specifically, there’s a mountain of things you have to comply with, and simplifying that and reducing scope is a really good idea.”
The Cost of Sovereignty
Deciding where to locate data also has cost implications for traffic egress.
“The other thing to consider is regions don’t all cost the same,” LaCour says. “So, the resources you consume in some of these other places where costs are going to be way higher—that’s a factor you also have to consider.”
Organizations that need to meet regional data residency requirements may have to replicate models, inference databases, backups and logs across multiple locations. Each copy creates additional storage and data transfer costs, and moving information between on-premises systems, AWS regions and cloud services can increase networking charges.
“We see this all the time,” LaCour says. “Customers will have placed all of their infrastructure in US-East-1—sometimes it feels like they just randomly picked, like they rolled some dice and said they’ll take this one, or they’re taking sort of ‘default’ choices. Those are often not the right decisions. So, being thoughtful about that upfront is important, and it benefits you above and beyond just sovereignty. It benefits you from a cost perspective, performance, and high availability as well. You get a lot of value there.”
LaCour adds: “Everything that we’re talking about with cloud is busting apart big monolithic stuff into smaller components and pieces, putting them in the right location with the right kind of resource, and making sure the architecture exists to support maximizing what you get for the cost. And sovereignty is no different.”
Retaining Flexibility Without Compromising Control
Alternatively, organizations can deploy open-weight models within their own infrastructure, keeping the model and sensitive data under their direct control. This can be attractive where intellectual property or regulatory requirements make external processing less desirable, although it also means taking responsibility for the infrastructure, deployment and ongoing management of the models.
Enterprises can also combine approaches, selecting models and deployment locations according to the sensitivity of the information and the requirements of individual workloads.
Where an AI model runs is only part of the sovereignty equation. Compliance teams are becoming increasingly aware that enterprises need to reduce dependence on individual model providers and retain control over the enterprise context sent to AI systems. Separating models, data and access allows organizations to use different models for different tasks without handing over visibility into their entire information environment to one provider.
As Rishabh Gupta, Co-Founder and CEO at PipesHub, tells TechChannel, “You can separate out these three things: company information, the system that is retrieving it, the AI models and the applications that are using it, so that the whole understanding of the enterprise will not go to the LLM providers. That way you can keep your hybrid approach intact.”
In regulated industries such as financial services and healthcare, and in strategic manufacturing sectors, workloads involving highly confidential information or sensitive intellectual property may justify keeping models and data within the organization’s own infrastructure. For other applications, running models within AWS can offer a practical balance between control, scalability and integration with the organization’s governance policies.