At Rise of AI 2026 in Berlin, Daniel Brilz of SVA argues that the usual cloud-versus-on-prem framing of AI sovereignty is wrong, because it forces a binary choice that produces suboptimal architecture. The real question, he says, is which dependencies are acceptable for which workload. He names four forces making sovereignty strategically relevant: regulation moving from theory to enforcement, geopolitics changing how companies view critical workloads, lock-in risk from AI platform choices, and Gen AI becoming core business infrastructure rather than an experiment. Sovereignty, in his definition, means practical control across three layers: technical, operational and contractual, covering access, encryption keys, governance and exit strategy. He presents a spectrum running from fully managed cloud/SaaS to air-gapped systems, argues dependency exists across the whole stack rather than just hosting location, and outlines a two-step decision framework: classify the workload's sensitivity and criticality, then weight architectural options on portability, assurance, resilience and economics. He closes with design patterns and a cost warning that sovereignty is never free.
Key takeaways
- Framing AI sovereignty as a binary cloud-or-on-prem choice produces suboptimal architecture; the real question is which dependencies are acceptable per workload.
- Sovereignty rests on three control layers: technical, operational and contractual, covering access, encryption keys, governance and exit strategy.
- Dependencies exist across the whole stack, not just hosting location; even EU-hosted platforms create their own dependencies.
- A two-step framework classifies workload sensitivity and criticality first, then weights architecture options on portability, assurance, resilience and economics.
- Hybrid architecture combining commodity, controlled and sovereign AI clusters is not indecision but the actual right choice for most organizations.
Detailed notes
Reframing cloud versus on-prem as a spectrum, not a binary
Brilz opens by saying the usual question organizations ask, cloud or on-prem, is framed wrong. A binary choice forces suboptimal architecture and suboptimal economics. The real question is which dependencies are acceptable for which workloads. This opens a spectrum of answers rather than a single either/or decision.
Four forces making sovereignty strategically relevant
He lists four drivers: regulation moving from theory into operational enforcement; geopolitics changing how companies think about critical workloads; the lock-in risk of AI platform choices, which exposes organizations to pricing volatility and policy changes with no exit strategy; and generative AI becoming core infrastructure and core business rather than an experiment.
Defining sovereignty as control across three layers
Sovereignty, Brilz says, does not mean nationalism or purity, it means practical control. He breaks this into a technical control layer, an operational control layer and a contractual control layer, covering access, encryption keys, governance, observability and exit strategy. He distinguishes sovereignty (more control) from independence (less lock-in) and resilience (better survivability). The spectrum runs from cloud/SaaS or API (fully managed, maximum convenience) to air-gapped systems (maximum control, maximum operational burden); most organizations need the right level of sovereignty, not the maximum.
Dependencies live across the whole stack
Brilz argues that dependency is not just about hosting location: even hosting in Europe leaves a company dependent on the platform it chooses. He maps dependencies across a business layer (platforms, data), a tech layer (identity, access, encryption keys, model runtime and hosting) and an enablement layer (tool chain and operating skills). He notes that operating on-prem GPU infrastructure requires a specialized, scarce skill pool.
A two-step decision framework and three architecture clusters
The framework has two steps: first classify the workload by data sensitivity, business criticality, regulatory exposure and threat model, and define non-negotiable hard constraints; second, weight architectural options on portability, assurance, resilience and economics to choose a position on the spectrum. This produces three clusters: commodity AI for low-risk production use, controlled AI for internal or enterprise copilots, and sovereign AI for the most critical workloads. Choosing more than one is not indecision but the actual architecture, since most organizations need more than one cluster. On the US-cloud-versus-EU-cloud debate, he says an EU cloud does not automatically mean sovereignty, only a different dependency model; the questions that matter are who can access data and under what conditions, who controls the encryption keys, whether access can be denied technically rather than only contractually, and how fast an organization can exit a platform without rebuilding its stack. He lists design patterns for sovereignty by design: retrieval-augmented generation before fine-tuning so data is not baked into a model, policy-based routing of workloads by criticality, a model abstraction layer that decouples applications from specific models (citing tools like LiteLLM), customer-managed encryption keys, egress control for autonomous AI agents, and a fallback model strategy prepared before it is needed. As a practical example he cites IBM watsonx Orchestrate as a control plane that can deploy on-prem, in the cloud or hybrid, with many connectors to different model providers and databases, and strong built-in governance, security and observability; he places it between the controlled AI and sovereign AI clusters. He closes the main talk stressing sovereignty is not free: it carries operational burden, GPU capacity planning and a talent shortage, while convenience carries its own costs in lock-in and pricing volatility. His three takeaways: sovereignty is a spectrum, not a binary choice, and each workload should be designed for the level it actually needs; start by gaining control of encryption keys, data and access; and hybrid architecture is itself the right choice, not indecision.
Q&A highlights
Asked how to justify time spent on fallback options to management when a fallback may never be used, Brilz says it should not be a separate process requiring its own budget discussion but built into the whole design process from the start. Asked how to identify an organization's non-negotiables, he says organizations usually already know what they do not want, such as not processing certain data in the cloud, and the task is asking the right questions and listening carefully; existing constraints should still be challenged, but companies usually have a reason for them. Asked about skepticism toward hyperscalers' own sovereign cloud offerings, such as AWS's sovereign cloud, he says such offerings still create dependencies, just different ones than EU sovereign solutions, and whether that is acceptable depends on the criticality of the specific workload rather than a general yes-or-no answer. Asked whether people frame sovereignty purely as a moral question, he says he mostly encounters technical and business framings rather than moral ones. Asked whether his framework is just business continuity management under a new name, he says it was not intentionally modeled on BCM, but classifying workloads by these criteria in practice helps organizations identify which workloads need different compute or dependencies.
Quotes
Sovereignty is not a binary choice, but it's a spectrum.
Daniel Brilz
Hybrid is not indecision, hybrid is actually the architecture.
Daniel Brilz
Questions answered in this talk
Is AI sovereignty just about choosing cloud or on-premise hosting?
According to Daniel Brilz at Rise of AI 2026, no: that binary framing is wrong and produces suboptimal architecture. The real question is which dependencies are acceptable for which workload, which spans a spectrum from fully managed cloud to air-gapped systems.
Does hosting AI infrastructure in the EU automatically make a company sovereign?
According to Daniel Brilz at Rise of AI 2026, no. Hosting in Europe still leaves a company dependent on the chosen platform; sovereignty depends on actual control over access, encryption keys and exit options, not on the hosting location label.
How should a company decide how much AI sovereignty it needs?
According to Daniel Brilz at Rise of AI 2026, use a two-step framework: classify each workload by data sensitivity, business criticality, regulatory exposure and threat model to define non-negotiable constraints, then weight architectural options on portability, assurance, resilience and economics to pick a position on the sovereignty spectrum.