For most of the past decade, data sovereignty was a legal and compliance problem. Someone in the legal department handled it. IT built the network and bought the tools. If regulators had questions about where data lived, that was someone else’s job.
That division of labor is breaking down—and honestly, it probably should have broken down a lot sooner. The combination of cloud adoption and shifting geopolitics, plus AI workloads that need to stay local, has changed things. Also, a wave of data residency regulations that are actually getting enforced has turned sovereignty into an infrastructure question. It’s now a strategic one. Most organizations are nowhere near ready for that conversation.
What’s Actually Driving This
GDPR has been around since 2018. Financial services regulators in the EU, UK, and across Asia-Pacific have had cross-border data rules for years. This isn’t new. However, what’s changed is that enforcement is getting real. The regulatory landscape is expanding—NIS2, DORA, various national GDPR adaptations—and the geopolitical environment has introduced a whole new category of risk. It’s a risk that nobody really planned for.
I don’t want to turn this into a geopolitical piece, but it’s hard to ignore. Not long ago, the concern was organizations in other countries not wanting to do business with Chinese vendors because of how China’s government can influence and access company data. That was a legitimate concern. Now other countries are applying similar scrutiny to US-based cloud providers. Honestly, given some of the policy shifts we’ve seen, you can understand why. I would certainly think twice about trusting the current US government. Similarly, I would hesitate to trust the US tech sector that is facilitating or capitulating to concerning overreach.
The practical result is that organizations—especially in regulated industries, defense, critical infrastructure, and government—are asking harder questions about what it actually means to store data “in country.” This is especially important when access to that data might still route through third-party infrastructure operating under foreign jurisdiction. That is where most current architectures have a real gap.
Here’s the thing a lot of organizations miss: you can store data in a certified, in-country data center. However, you could still route all access to that data through a cloud security provider that doesn’t meet the same sovereignty requirements. The data is sovereign. The network path to it is not. The EU is actively working on frameworks to close exactly that gap. It’s worth asking whether your architecture is ahead of that or behind it.
The Security Architecture Problem That Doesn’t Get Enough Attention
The dominant model for cloud-delivered security—Security Services Edge, or SSE—was designed primarily around outbound traffic. It supports users connecting to cloud applications. That’s what it optimizes for. The inbound direction, traffic coming into enterprise environments, typically still relies on on-premises firewalls. Those firewalls were built for a perimeter model that barely exists anymore.
That gap matters more in a sovereign context than most people realize. If you’re trying to maintain real jurisdictional control over your security posture, running two separate architectures—one cloud-delivered, one on-premises—creates challenges. These include complexity, coverage gaps, and more opportunities for data to move through infrastructure that doesn’t meet your actual requirements.
The organizations that have dealt with this the longest—defense agencies, large financial institutions, critical infrastructure operators—have generally solved it by building everything themselves. They deploy their own stack and operate it. They accept the operational overhead. That works if you have the budget and the team. However, most organizations don’t.
AI Is Changing the Calculus
Most of the enterprise AI security conversation right now is focused on access—how do you let employees use AI tools without accidentally exposing sensitive data? That’s a real problem. But it’s not the hardest one.
The harder problem is what happens as AI workloads move from cloud-based inference to local deployment. A retailer running fraud detection models locally in each store. A bank doing biometric analysis at branch locations. A manufacturer running predictive maintenance on edge hardware. These aren’t hypothetical. They’re decisions organizations are making right now.
Yes, I can go use ChatGPT. I can go use Claude. I can use Perplexity. That’s fine for a lot of things. But when you get down to it—when we’re talking about a retailer’s customer behavioral data or a bank’s transaction patterns—things change. Similarly, think about a manufacturer’s proprietary process data. In those cases, “just use a cloud LLM” isn’t the answer. You need your own thing. You need to make sure your data stays yours. All of that comes back to sovereignty.
The agentic AI layer adds another dimension on top of that. Traditional SASE and SSE architectures were designed for relatively predictable traffic patterns—users connecting to applications, north-south flows. However, agentic AI generates traffic in every direction. Agents communicate with each other, call external APIs, pull from local data stores, and connect to cloud services. Applying a consistent security policy to that is a genuinely different problem than what most enterprise security teams have had to solve before.
How One Vendor Is Approaching It
Versa announced what it’s calling Sovereign SASE-as-a-Service—a managed service built on its unified networking and security platform. This offering is designed for organizations that need cloud-delivered operations without routing data through third-party cloud infrastructure.
Versa has been around for years, but I’ll be honest, I wasn’t very familiar with the company. I sat down with CEO Kelly Ahuja, to talk about the news. What struck me was that sovereign deployments aren’t a new use case for them. They’re the dominant ones. “I was doing this analysis, that of our top 100 accounts over, I think 85 to 90% of them are all sovereign,” Ahuja told me. “Meaning, we give them software. They deploy their own environment, they operate it. We don’t even know what’s going on.”
The new offering extends that model to organizations that can’t staff and operate their own sovereign infrastructure. Versa delivers it primarily through a channel of service providers and telco partners—over 150 globally—who build managed services on top of the platform. Swisscom in Switzerland is the example Ahuja cited. It offers secure connectivity as a standard service tier with sovereignty built in, so smaller enterprises don’t have to evaluate and deploy enterprise SASE themselves. They buy internet from their carrier, and the security comes with it.
Questions Worth Asking Now
The compliance requirements are the easy starting point. GDPR, NIS2, DORA, whatever sector-specific frameworks apply to your industry—those set a floor. The harder question is whether meeting those requirements actually reflects your real risk posture. Or are you checking boxes against regulations that were written before the current threat environment existed?
A few things are worth pressure-testing. First, does the security layer that controls access to your sovereign data actually meet sovereignty requirements—or just the data itself? Second, what happens to your sovereignty posture when you start deploying AI workloads? If inference requests, training data, or telemetry are traversing infrastructure that doesn’t meet the same standards as your data layer, you have a gap. And you probably haven’t mapped it yet.
Third—and this is the one that tends to get deferred until it’s urgent—what does your sovereign architecture look like at scale? One jurisdiction is a project. Multiple jurisdictions, different regulatory frameworks, a distributed workforce, and an AI layer on top of all of it is a different order of complexity. The organizations that start thinking about this now will be ahead of the ones that wait for a compliance deadline. Or they may wait for an incident to force the issue.
The managed service model is one answer to the resourcing problem. It’s not the only answer, and the right approach depends on the organization’s size, risk tolerance, and regulatory environment. But the underlying challenge is real, and it’s not going away. If anything, it’s going to get more complicated before it gets easier.
- Remote Hiring Opened the Talent Pool — and the Fraud Surface - June 8, 2026
- CrowdStrike Turned an AI Wave Into Its Best Quarter Ever - June 5, 2026
- The OT Security Problem Nobody Wants to Own - June 3, 2026
