What sovereignty looks like: Gysho's EU sovereign stack
True EU sovereignty is not a data-centre pin on a map. It is an architectural decision covering European data, European compute, European models and zero extraterritorial legal exposure. Without control at every layer, the claim of sovereignty is incomplete, and potentially misleading.
Many providers currently market EU residency while quietly routing inference through US-hosted frontier models. This leaves sensitive data within reach of US extraterritorial law, regardless of where the initial server is located. The gap between residency and sovereignty exposes organisations to legal risk they often don't see until it's too late.
This is not hypothetical. In May 2026, the Dutch outlet Vrij Nederland reported that Microsoft had shared the names of civil servants at two Dutch regulators (the Authority for Consumers and Markets and the Data Protection Authority) with the US House of Representatives, with the names left unredacted in emails and meeting documents. The officials were reportedly working on enforcing the EU's Digital Services Act. Microsoft is accused rather than proven to have acted improperly, and the agencies are investigating, but the Dutch government took it seriously enough that the State Secretary for Digital Economy and Sovereignty raised it directly with the US ambassador. It is the residency-versus-jurisdiction gap this series is about, playing out with a named provider and a government's own regulators.
The mechanism behind it is the US CLOUD Act, enacted in 2018 (Public Law 115-141, codified at 18 U.S.C. §2713), which compels US-headquartered providers to produce data they control in response to valid US legal process, wherever that data physically sits. We covered how that plays out across the stack in Part 1. This article shows how we engineered our way out of it, one step at a time, building technical and legal realities directly into the stack.
Our current foundation
Our production deployments ran across European Azure regions, including the UK, Ireland, Sweden and France. Clients specify their residency requirements, and we honour those specifications without exception; this geographic containment is the baseline of our architecture. Client data is contractually isolated by design: per-client databases that are never co-mingled and never used for model training. Client-data IP and Gysho software IP are explicitly separated in every agreement we sign, so ownership boundaries stay clear and enforceable. Governance and compliance are embedded from day one: GDPR, ISO 27001 and SOC 2 standards (official certification on the roadmap). Our contractual stance is absolute:
Your data and knowledge remains yours: no sharing, no risk.
That vision presented us with a question: how do we keep our guarantee and achieve full sovereignty, if our clients choose that route?
Optional full sovereignty
Research and study
We spent the first phase mapping the difference between marketed sovereignty and structural sovereignty. The market is moving fast. Gartner forecasts European sovereign-cloud IaaS spending will surge 83% in 2026, from $6.9B to $12.6B, and nearly double again to $23.1B by 2027. But while spending is a good indicator of market development, it does not indicate true sovereignty. As The Register reported in February 2026, even dedicated European subsidiaries of US hyperscalers remain 100% owned by their US parents, which still leaves them under US jurisdiction. So any viable option had to be 100% locally owned, with no parents further up the chain.
- Inference: traditional LLM providers like OpenAI and Anthropic are US-owned, so any mainstream provider was out. We landed on a small group of European inference providers hosting the leading edge of open-weight models. The distinction that matters for sovereignty isn't where a model's weights were created, but where the model runs and who controls that hardware. An open-weight model on European-operated infrastructure keeps inference outside any third country's legal reach. We accept a small performance decline versus true frontier models and gain sovereignty in return, and they often cost far less.
- Infrastructure: we found providers that suited our needs, some EU-only, others extending globally to serve our international footprint. Some are already struggling with capacity, so choose carefully. Our shortlisted vendors hold every certification needed to guarantee compliance.
- Day-to-day business: we run our CRM, marketing and project management on our own internal software. That's not true for our productivity suite, and with limited options available, self-hosting was the way forward.
Decision time
The study proved sovereignty was possible, and that the effort (while not negligible) was not prohibitive either. With the market moving in this direction, we decided that setting up a sovereign alternative stack was worth doing now. We made two decisions. First, our internal compute, inference and apps would go completely sovereign, because it lets us offer a guarantee to EU customers, and because this was our lowest-risk area to make the transition. Second, we offer clients the choice to migrate, but we don't force it; Azure is a reliable, fast stack with many benefits, so going sovereign should always be optional.
The criteria are strict: data must be stored under European legal jurisdiction; compute must be operated by entities not subject to extraterritorial compulsion; model inference must be routable outside US-controlled pipelines; and the productivity layer must be free of third-country legal process.
Step 1 · LLM independence (the Balancer)
The inference layer is where most "sovereign" stacks quietly fall under the CLOUD Act: hyperscalers store data in an EU region, or process requests across borders, bringing any inputs under the direct influence of the legislation. We tackled this step first. We built LLM Balancer to eliminate that exposure: an in-house inference router that sits between our applications and any backend model. It normalises requests using the OpenAI v1 API structure, then translates them for whatever backend the workload requires: whether a commercial frontier model or an open-weight model such as DeepSeek or Kimi running on European infrastructure. Switching backends is instant from the application's perspective, with no code changes and no rewrites.
The sovereignty-critical feature is routing flexibility. LLM Balancer can send traffic to external inference providers, but it can also route to local devices operating as a private inference pool. For the highest-sensitivity workloads (legal strategy, medical data, board-level communications) the prompt never leaves hardware the client controls. The model runs on their premises, their network and their legal jurisdiction.
Step 2 · Sovereign office productivity
AI sovereignty is meaningless if the board's deliberations are still sitting in a US-controlled collaboration suite. Microsoft 365, Teams and SharePoint carry the same CLOUD Act exposure as Azure infrastructure. Our second step was a productivity layer matching our infrastructure principles. We evaluated the emerging European open-source ecosystem and aligned with Nextcloud as the collaboration backbone: a conscious decision not to build everything ourselves; others have built solutions far better than we could, and they maintain the security around them. What we controlled is where our productivity suite sits: solidly inside the EU, with no external ownership.
For our full-sovereignty clients, this replaces the environment where sensitive contracts, project correspondence, designs and strategic planning documents live: stored on European-operated infrastructure, edited with European-controlled software, and transmitted through European networks. This step's transition was arguably the most painful, because it involves the team learning a completely new piece of software and migrating years of data. Our automated systems ensured the migration went without a hitch, but the human change is still ongoing.
Step 3 · Migrate applications
The final step was a viable alternate hosting infrastructure for our internal and client apps. The migration follows a simple rule: we migrate ourselves first. Gysho's internal portal, LLM Balancer and our operational tools were the test case. We ran them on the sovereign stack, found the integration friction, fixed it and documented the pattern. Only then did we offer the same migration path to client stacks. The approach is workload-by-workload, not a catastrophic rip-and-replace. Gartner expects sovereignty pressure to shift around 20% of current workloads from the global hyperscalers to local providers; we're engineering for that transition now, rather than waiting for an enforcement deadline to force a panic migration. Client databases remain isolated per client; what changes is the legal jurisdiction governing the operator and the physical location of the compute. The architecture pattern is identical, which keeps the migration predictable.
Three lessons
- The integration tax is real. A sovereign stack requires more assembly than a hyperscaler turnkey. You trade convenience against legal certainty, and that costs engineering hours. The price wasn't prohibitive, though, and we achieved similar levels of automation.
- Sooner beats later. We designed our own software to be vendor-agnostic, but we rely heavily on inference and infrastructure, and the more you integrate with a specific vendor, the harder the move. If you have any sovereign ambitions, move now, before all your agentic solutions live inside a stack you cannot leave.
- The payoff shows up where you didn't expect it. Our inference layer now routes internal requests to other models and providers that produce high-quality outputs at less than 10% of the cost. Going sovereign opened our eyes to cost benefits and new innovation paths.
Conclusion: why this matters
We expect that sovereignty, in Europe and beyond, will become more important as time progresses. Even if it doesn't become a legal requirement, we expect companies to develop a preference for it; markets and legislation are already indicating the shift. The EU is no longer negotiating: the Tech Sovereignty Package, built around the Cloud and AI Development Act and presented on 3 June 2026, explicitly names the CLOUD Act as the structural legal problem and proposes barring US hyperscalers from processing sensitive government data. The EU Data Act, in force since September 2025, imposes obligations that directly conflict with the CLOUD Act. Organisations caught between those two regimes will face penalties they cannot appeal their way out of.
IDC predicts that by 2028, 60% of organisations with digital-sovereignty requirements will migrate sensitive workloads to new cloud environments. Gartner predicts that by 2030, over 75% of companies in Europe and the Middle East will relocate data and workloads to reduce geopolitical risk. These are not marginal shifts. They represent a structural reordering of the European cloud market. We built the sovereign Gysho stack as a cost-equivalent option for our clients: no extra charge, the same guarantees you'd get on Azure, so the decision comes down to what your context actually needs. Some workloads belong on a hyperscaler; some should never leave European jurisdiction. The point of the architecture is that you choose, workload by workload, and can change your mind later without a rebuild.