Part 2 of four. Each briefing in this series takes one of the four sovereignty questions from our full guide, Making Sense of Sovereign AI, and makes it usable on its own.
Question 2: How Is Your Data at Rest Protected – and Who Controls the Keys?
What this actually means
“Data at rest” refers to data that is stored rather than moving:
databases, data lakes, backups, model artifacts, embeddings, and intermediate training outputs.
Most modern platforms encrypt this data by default. That often creates a false sense of closure: “Our data is encrypted, so we’re safe.”
From a sovereignty perspective, encryption alone is not the decisive factor.
The real question is: who controls the encryption keys?
Encryption works by scrambling data using cryptographic keys. Whoever controls those keys can, in principle, unlock and read the data. This means sovereignty over data at rest is not about whether data is encrypted, but about where control ultimately sits – technically and legally.
Why leaders should care
From a compliance perspective, encryption at rest is usually mandatory for sensitive data. Regulators expect strong protection against unauthorized access, breaches, and insider risk. For many use cases, provider-managed encryption satisfies this requirement.
From a choice perspective, key ownership becomes strategic. Organizations may decide that even compliant setups expose too much risk – particularly if data represents core intellectual property, critical infrastructure knowledge, or long-term competitive advantage.
From a cost perspective, taking control of encryption keys is not trivial. It introduces operational risk, governance overhead, and the uncomfortable reality that losing keys can mean losing access to your own data.
This is not a purely technical decision. It is a question of how much control you want – and how much responsibility you are willing to carry.
A more vivid, end-to-end example
Encryption Is Easy. Control Is Not.
Imagine a global industrial company building AI models to optimize how its factories operate.
1. The default setup: compliant and convenient
The company stores sensor data, maintenance logs, and production metrics in a major cloud platform. Data is encrypted at rest using the provider’s built-in key management service. Access controls are well configured. Audits pass.
From a compliance standpoint, everything looks solid.
Leadership is reassured: “Our data is encrypted and secure.”
2. The strategic realization
Over time, the AI models trained on this data begin to outperform competitors. They capture subtle relationships between machine behavior, failure modes, and process tuning. These models don’t just support operations—they encode how the company runs its most profitable plants.
At this point, leadership asks a different question:
“If someone could access this data or these models, what would that expose about how we operate?”
They realize that while the data is encrypted, the cloud provider controls the keys. That means:
- The provider can technically decrypt the data
- The provider may be legally compelled to do so under certain jurisdictions
- The company’s most valuable operational knowledge is protected—but not fully under its own control
3. A deliberate shift: choosing control
For its most critical factories, the company changes approach.
It introduces customer-managed encryption keys stored in dedicated hardware security modules under its own control. The cloud provider still hosts the infrastructure, but cannot decrypt the data without explicit cooperation.
This materially changes the control boundary:
- Even if infrastructure is compromised, the data remains unreadable
- Even if a provider receives a legal access request, it cannot comply unilaterally
- The company – not the platform – becomes the final authority over access
4. The cost becomes visible
This choice is not free.
Key management now requires:
- Specialized security expertise
- Strong governance and access procedures
- Disaster recovery plans that include key availability
- Acceptance of real operational risk if keys are mishandled or lost
Integration with other services becomes slower. Some managed features are no longer available. Troubleshooting becomes more complex.
Leadership accepts these trade-offs—but only for the subset of data and models that truly represent the company’s competitive core.
For less sensitive datasets – training materials, generic analytics, non-differentiating workloads – the company keeps provider-managed keys. Sovereignty is placed selectively, not universally.
The practical insight for leaders
The key lesson is this:
- Encryption at rest is necessary but not sufficient
- Key ownership defines real control
- Control brings responsibility, cost, and risk
For business leaders, the right question is not:
“Is our data encrypted?”
But:
“Which of our data and models are so critical that we cannot afford someone else holding the keys—even in theory?”
Answering that honestly allows organizations to:
- Meet compliance without over-engineering
- Invest in sovereignty where it protects long-term value
- Avoid paying for control that offers little real benefit
As with data location, sovereignty over data at rest is not an all-or-nothing stance. It is a targeted investment decision, best made with clarity before architectures harden and dependencies accumulate.
Next in the series: Question 3 — how is your data in transit handled?