Is Digital Sovereignty reshaping the cloud native landscape?
Three days at KubeCon confirmed something I’ve been sensing for months in conversations with engineering teams: the cloud is no longer synonymous with freedom. For many organizations, it has become synonymous with dependency.
I came back from Amsterdam, where I was at the KubeCon EU, the CNCF conference, with a clear impression. Not a single talk, not a product announcement, but a diffuse feeling, cutting across booths and sessions: the industry is shifting its center of gravity.
For years, the cloud native conversation has revolved around an implicit question: “how do we scale better?” Speed, elasticity, cost per request. Public cloud as an axiom. Kubernetes as the de facto standard of modern infrastructure.
At KubeCon 2026, that question hasn’t disappeared. But a new one has emerged alongside it, more urgent, more politically charged: “who controls our data, and who should?”
The weak signal that became noise
Digital sovereignty is not a new concept. It lives in European regulatory frameworks, in corporate policy documents, in quiet conversations between CTOs and Legal teams. But at KubeCon I noticed something different: it was no longer background noise. It was the theme. There was even an entire keynote on day 2 dedicated to it.
Three converging signals confirmed it.
The first: a proliferation of architectures designed to run AI models on-premise or on private infrastructure. Not primarily for cost reasons, the public cloud is often still cheaper, but for reasons of control. No one wants their core business data feeding a shared provider’s model, potentially enriching a competitor downstream.
The second: Kubernetes on the edge. Not just in data centers anymore. The principle is straightforward: data should be processed where it’s generated, not shipped thousands of miles to a hyperscaler before a local decision can be made.
The third: the governance of AI agents and AI-generated code. When an agent writes code, executes pipelines, interacts with third-party APIs, who is accountable? And more fundamentally: where does that accountability sit, legally and operationally?
Three apparently distinct signals. In reality, the same question wearing different clothes.
Sovereignty doesn’t mean isolation
Digital sovereignty ≠ on-prem at all costs.
Digital sovereignty is the capacity to consciously choose where data lives, who processes it, and under which jurisdiction. It’s a strategic posture, not a binary technology decision.
A digitally sovereign organization can absolutely use public cloud, but with deliberate boundaries, intentionally designed hybrid architectures, and the technical capability to move if conditions change. Dependency only becomes a risk when it’s involuntary.
In engineering terms: it’s the difference between a system with a single point of failure and one designed with redundancy and fault isolation. The goal isn’t to avoid the cloud. It’s to avoid being locked into it.
And there's one more dimension worth naming honestly: the legal and geopolitical one. Frameworks like the US CLOUD Act mean that data hosted by American providers isn't fully shielded by geography alone: jurisdiction follows the provider. Combined with evolving EU regulations, this is quietly pushing sovereignty from a compliance checkbox onto the engineering roadmap. It's not about taking political sides. It's about understanding that where your data lives is now also a legal architecture decision, and one that deserves the same deliberate thinking as any other.
AI amplifies the problem and the urgency
Artificial intelligence has transformed digital sovereignty from a compliance topic into a question of strategic survival.
The reason is structural: AI models learn from data. And the most valuable data, the kind that defines a company’s competitive advantage, is precisely the data you cannot (or should not) hand over to third parties without consequences.
I observed this pattern clearly in the sessions on Observability and FinOps applied to AI: teams are starting to treat tokens as a scarce resource to monitor, optimize, and govern. But beneath that technical conversation was a deeper question: what data are we actually sending to that model? What is it learning? Who else benefits from what it learns?
The same dynamic applies to SRE in the age of autonomous agents. When an AI agent decides to scale a service, roll back a deployment, or reallocate resources, it does so on the basis of sensitive operational data. Defining the perimeter of that process is a matter of organizational and legal control.
The governance of AI agents, one of the most recurring themes at KubeCon, is essentially this: how do we design the boundaries within which an autonomous system is allowed to act? Digital sovereignty is the context that gives that question meaning.
Platform Engineering as the silent answer
There’s a third actor in this story that I felt everywhere at KubeCon, yet nobody talked about it explicitly. As if it had become so foundational it was simply taken for granted.
Platform Engineering.
Every solution discussed, private LLMs, edge Kubernetes, agent governance, presupposes a solid internal infrastructure layer: an abstraction that gives product teams the tools to operate autonomously without reinventing the wheel every time.
In other words: digital sovereignty isn’t free. It has a construction and maintenance cost. And that cost is only sustainable if a well-designed internal platform distributes it across teams, reduces cognitive load for developers, and transforms complex architectural decisions into walkable golden paths, providing guardrails and rules that must be followed.
Nobody at KubeCon gave a talk titled “Platform Engineering something bla bla” But hearing all the voices, Platform Engineering has become the implicit infrastructure of the reasoning, like the electrical grid in a conversation about renewable energy.
What matters
If you’re an engineering leader or a product manager at a company that runs on cloud and is exploring AI, the operational question becomes: where do I start?
Three areas where I’ve seen the most advanced teams working with real concreteness:
Data dependency mapping. “Where does sensitive data live and who processes it.” This map often doesn’t exist, or is fragmented across Legal, Engineering, and Security with no clear owner.
Design for portability. Architectures built around portable abstractions, Kubernetes, containers, standard APIs, are far easier to migrate if conditions change: regulatory, economic, geopolitical.
Governance as a product. Policies written in documents govern nothing. Governance of AI agents, generated code, and data in transit only works when it’s embedded in the workflow: in automated guardrails, pipeline gates, and internal platform abstractions. It has to be part of the system.
Closing the loop
There’s something ironic about the fact that the cloud, born as a promise of freedom from infrastructure, is now generating a serious conversation about the need to bring part of that control back in-house.
This isn’t a step backward. It’s a system iterating on itself, correcting its own drift. A feedback loop at industrial scale.
The question for the coming years, in my opinion, will be: “what architecture allows us to remain sovereign over our own decisions?”
And the answer, I’m increasingly convinced, is not a technology choice. It’s an organizational and cultural one. It requires teams capable of holding together the how and the why. Engineering and product. Speed and control.
And yes, Amsterdam always offer sweet spots to take some picture!
