Why sovereignty matters
Every external dependency introduces risk. In the financial sector, DORA makes that explicit by defining ICT third-party risk as risk arising from the use of services provided by external ICT providers. It does not require financial institutions to eliminate providers; it requires them to understand and manage the dependency.
Even very mature providers fail. A community reconstruction of GitHub's public status history showed its uptime dipping below 85% in April 2026. Whether the cause is an attack, a bad deployment or an overloaded dependency, the architectural question is the same: what happens to us when something we depend on disappears?
Sovereignty matters because control gives us more answers to that question.
But maximum control is not necessarily the answer either.
The limits of sovereignty
A Kubernetes cluster assembled from second-hand server parts behind an OpenWRT router can provide an impressive amount of sovereignty.
I know because that setup works perfectly well as my personal homelab.
You control the network, storage, operating systems, machines and orchestration. If something breaks, you fix it. If you want to replace a component, nobody needs to approve the migration.
Then you try to apply the same architecture to the financial sector and regulation eats it alive.
A regulated workload has to care about much more than whether the machines work. Business continuity, ICT risk management, incident handling and third-party dependencies all become formal concerns under DORA. The CSSF additionally maintains requirements governing the use of ICT third-party services by entities subject to DORA.
A pair of redundant servers is less impressive if both disappear when the building loses power. Local storage is less reassuring if the entire physical site is the failure domain. Physical ownership also does not automatically answer questions around data residency, customer expectations or continuity of service.
At that point, pure self-hosting can increase control while decreasing resilience.
The goal becomes controlled dependency: selecting which systems are trusted, what they are trusted with, where they operate, and how failure is handled.
The best of both worlds
Our Kubernetes cluster is split between our own premises in Luxembourg and a local cloud provider.
The cloud side runs on x86. The on-premises workers are ARM-based NVIDIA DGX Sparks, which provide our AI inference capacity.
Rather than forcing one environment to do everything, we use each where it makes sense.
The DGX Sparks give us dedicated accelerator capacity that we own and can use without continuously renting cloud GPUs.
The local cloud environment gives us a separate physical failure domain, resilient storage, public ingress and the operational credibility of an established infrastructure provider within the same Luxembourg ecosystem in which we and our customers operate.
The cloud VM can also run at least one instance of every workload required to maintain a minimum level of service.
If our on-premises infrastructure disappears completely, service degrades instead of disappearing with it.
That is less sovereign than putting everything in our own building.
It is also considerably more useful.
Data in the cloud, compute on-prem
Sensitive persistent state does not live on the DGX Sparks.
Application data, embeddings and prompt caches remain in our Luxembourg cloud environment. When an inference workload needs them, the relevant state is transferred to the worker and loaded into its unified memory for computation.
The local NVMe storage on the Sparks primarily holds the OS and the weights of the open-source Qwen models.
That distinction is intentional.
Model weights are large, so keeping them beside the accelerators avoids unnecessary transfers. But they are reproducible. Losing a Spark means losing compute capacity and a local copy of the weights, not losing authoritative customer data.
The architecture therefore has a fairly simple division of responsibility:
The cloud side is the durable state and resilience layer.
The DGX Sparks are the accelerated compute layer.
This keeps inference economically attractive while preventing our on-premises hardware from becoming the only place where important business state exists.
It also means the cloud environment can keep a minimum application stack alive if the local site becomes unavailable.
Open source is not automatically sovereign
The same reasoning applies to software.
Open source is often presented as synonymous with sovereignty, but it still creates dependencies. We depend on maintainers, libraries, package repositories, hardware vendors and upstream projects.
What changes is the nature of the dependency.
Open-source software generally does not decide where we must run it or which provider must operate it. It is therefore closer to sovereignty-neutral than inherently sovereign.
Qwen is one example. We possess the model weights and decide where inference happens. We are not structurally required to send prompts or contextual data to an external AI API.
Our CRM is another, it’s open source and its original authentication model did not fit the identity architecture we wanted. So we maintain a patch that makes its authentication Keycloak-based.
That is the useful property of open source for us: when the application's assumptions conflict with our architecture, we can change the application rather than changing our trust model around the vendor.
The European Commission similarly presents open source as a way to improve control, interoperability and technological independence, rather than as sovereignty by definition.
What we actually optimise for
The resulting architecture is not completely sovereign.
We deliberately depend on another Luxembourg company for durable sensitive state, ingress and continuity. We deliberately keep expensive AI compute on hardware we own locally. And we use open-source software where doing so gives us control over deployment, modification and migration.
While we eliminated some dependencies. The real goal was to know which ones we accept, what we trust them with, where they operate, and whether we can replace them. In our case, that means keeping the architecture within Luxembourg while distributing responsibility between infrastructure we operate ourselves and infrastructure operated by a local provider where doing so gives us better resilience.