Data sovereignty has always been on the table. But the conversation has ended the same way almost every time: everyone agrees it matters, and nobody has a budget for it. European AI and data regulations are changing that. AI rules are becoming enforceable; compliance money is moving through architecture teams, and companies have a reason to fund controls that previously struggled to get prioritized. The question is how to make that money buy more than a passed audit.
Compliance and Sovereignty Are Two Different Games
2. Decide Where Your Data Goes
Compliance and Sovereignty Are Two Different Games
Before diving deeper, let’s talk about definitions. Compliance means proving to someone else that you follow their rules. The rules are external, the deadlines are fixed, and you either pass the audit or fail it.
Sovereignty is a different story. It’s about keeping control when someone else changes their rules. A vendor changes its terms. The government changes its laws.
Here’s the problem with sovereignty: if you don’t get a timeline, you rarely have allocated funding. Few companies have a budget line called “sovereignty.” Without a deadline, it rarely wins the prioritization meeting.
Compliance, on the other hand, comes with hard deadlines, making it much easier to secure funding. And this creates an opportunity: the same budget companies allocate to meet regulatory requirements can also help them gain greater control over their technology and data.
We’ve identified five key items through our work on Sigma Software’s AI Sovereignty Framework. Each addresses a regulatory obligation while building a capability that gives the organization more control over its technology and data.
1. Know What You Run
Organizations need to know which AI systems, models, and vendors they run, including AI hiding inside their tools and products.
For compliance, a spreadsheet that lists your AI systems and vendors may be enough. But a spreadsheet is often outdated almost as soon as it’s completed. More importantly, it tells you what was in use at a particular moment, not what your organization depends on today.
For sovereignty, you need a living register that automatically tracks the AI systems and services you use, including AI features built into existing software tools. It should show who owns each system, which version is running, where it’s hosted, and what risks are associated with it. This helps teams identify critical dependencies and decide where additional monitoring or fallback options are needed.
The register should also connect to the systems that enforce your policies, so changes can be managed automatically rather than through manual checks.
As a result, you keep the dependency map. On a bad day, when a model gets deprecated or a vendor gets breached, you know what’s affected in minutes, not weeks.
2. Decide Where Your Data Goes
When companies use external AI models, information may be sent to providers outside their own infrastructure and sometimes outside the EU. If that information includes personal data, cross-border transfer requirements may apply.
For compliance, organizations need to identify these transfers and demonstrate that appropriate safeguards are in place. But documenting where data goes is not the same as controlling where it can go.
That gateway can check where information is being sent, apply the organization’s policies, and detect sensitive information before it leaves. It can also automatically maintain records of relevant data transfers, rather than leaving teams to reconstruct them later.
The difference becomes especially important when the rules change. If a particular destination or transfer arrangement is no longer acceptable, the organization can update its policies centrally instead of searching through individual applications and integrations.
Ultimately, what you keep is jurisdictional control: the ability to decide where your data is allowed to go and enforce that decision through your own architecture.
3. Hold Your Own Keys
Contracts are not always enough. Depending on the data and the transfer risks, technical protection may be needed too.
Compliance may rely on contractual safeguards and encryption provided by cloud vendors. But there is an important question behind those arrangements: who actually controls the keys that protect the data?
One of the strongest measures is almost old-fashioned: hold your own keys. The idea is to keep the master encryption keys in an EU-based security system operated by the customer. The provider stores the encrypted data, while the customer retains control of the keys.
This also means deciding who can authorize key operations, being able to revoke access centrally, and maintaining an independent record of how the keys are used.
Not every dataset needs this level of protection. Starting with sensitive data allows organizations to gain greater control without introducing unnecessary complexity across all systems. The choice depends on the criticality of the data and the requirements of the AI workload, an approach we explore in more detail in Who Do You Trust? Rethinking AI Sovereignty.
Of course, holding the keys doesn’t automatically prevent access to data during processing. That depends on how the complete system is designed. But it changes an important part of the relationship with the provider. Instead of relying entirely on contractual promises and provider-managed protection, the organization controls a critical element of its own data security.
4. Own Your Data Map
For compliance, organizations need evidence of where their data originated, how it was processed, and what quality checks were performed. The temptation is to treat this as documentation to prepare for an audit.
From a sovereignty perspective, the better approach is to make that evidence part of normal data operations. Record where datasets come from, track how they change, and preserve the results of quality checks as the work happens. Then connect those records to the regulatory requirements they help demonstrate.
What you keep is a vendor-independent map of your data estate. It remains useful when you investigate a problem, assess the impact of a change, or move to another technology provider.
And unlike audit documents assembled at the last minute, that history cannot simply be recreated later. The sooner you start collecting it, the more complete it becomes.
5. Keep the Exit Open
The EU Data Act is intended to make it easier for companies to switch from one cloud or data-processing provider to another, rather than remain locked into a particular service.
But the right you can’t exercise is worth exactly nothing.
For compliance, an organization may have the contractual right to switch providers and a documented exit plan. But sovereignty raises a different question: can it actually leave without rebuilding everything from scratch?
Two decisions make a difference.
The first is to avoid tying your data and business logic too closely to one provider. Open data formats, such as Iceberg or Delta, allow different processing engines to work with the same data. Keeping business logic as independent as possible from a particular engine or reporting tool can further reduce the effort of switching.
The second is to test the exit rather than just document it.
Estimate what it would cost to move each workload, including transferring data and rebuilding any functionality that depends on the current provider. Then run an annual test with an alternative engine to see whether the essential workflows still operate.
What you keep is exit power. It gives you leverage during contract renewals and a tested alternative if a provider raises prices, changes its conditions, or leaves the market.
What Does the Backlog Buy You?
Remember the deal from the start: the compliance budget may be the only budget sovereignty ever gets. Spend it twice.
So, what business value can these five backlog items bring?
You win the security review. In our engagements, due-diligence reviews have gone from weeks to days once the register and evidence matrix were in place. RFP sovereignty questionnaires can be answered using information the organization already maintains.
You ship AI earlier. For one of our clients, approval stopped being a long chain of meetings and became a lookup. When the necessary information is already available, release gates can clear faster.
You survive the bad day. A dependency map helps identify affected systems when a vendor cuts off access. Data controls and an exit strategy reduce the risk of being left without options.
You are better prepared for the next regulation. The same register, lineage, and logging capabilities can support requirements under DORA, NIS2, and other frameworks. Each regulation still needs its own assessment, but the technical foundation can be reused instead of built from scratch.
And there is the cost of waiting. Building these capabilities under deadline pressure can be considerably more expensive than designing them into the architecture from the start. The earlier the controls are built, the more opportunities there are to reuse them.
Planning your AI compliance roadmap and need help with turning regulatory requirements into practical capabilities that improve governance, control, and resilience?
Use the Deadline
Nobody will ever give you a deadline for sovereignty.
Compliance has deadlines, and those deadlines create an opportunity to fund technical capabilities that otherwise might never make it through prioritization.
A living register instead of a spreadsheet. A gateway that controls transfers instead of merely documenting them. Evidence collected while pipelines run. Encryption keys you control. An exit that has actually been tested.
These are not separate investments in compliance and sovereignty. They are architecture decisions that can serve both.
The regulation just gave sovereignty a deadline. Use it.
