EU Data Sovereignty: The Full Stack Is Exposed (part 1)
True EU sovereignty is not a data-center 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 practice leaves sensitive data within reach of US extraterritorial law, regardless of where the initial server is located. The gap between residency and sovereignty exposes organizations to legal risk they often do not see until it is 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 Clarifying Lawful Overseas Use of Data Act, the CLOUD Act, enacted in 2018 (Public Law 115-141, codified at 18 U.S.C. section 2713). It 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.
Status Quo | Gysho's Current Foundation
Our production deployments ran across European Azure regions, including the UK, Ireland, Sweden, and France. Clients specify their residency requirements, and we honor those specifications without exception. This geographic containment is the baseline of our architecture, as required to deliver compliant services.
Client data is contractually isolated by design. We maintain 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, ensuring that ownership boundaries remain clear and enforceable.
Governance and compliance are embedded from day one. Our operations adhere to 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 the question: how are we going to keep our guarantee and achieve full sovereignty, if our clients choose that route?
Next Gen | 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.9 billion to $12.6 billion, and nearly double again to $23.1 billion 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: The traditional LLM providers like OpenAI and Anthropic are US owned, so any mainstream provider was not an option. We landed on a small group of European inference providers that host the leading edge of open-weight models. The distinction that matters for sovereignty is not where a model's weights were created, but where the model runs and who controls that hardware. An open-weight model hosted 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. Added benefit: they often cost far less.
Infrastructure: We found a selection of providers that suited our needs, some focusing solely on the EU market, others extending into the global market to serve our international footprint. Some are already struggling with capacity, so choose carefully. Per our conditions, our shortlisted vendors hold every certification needed to guarantee compliance.
Day-to-Day Business: We have the benefit that we run our CRM, marketing, and project management on our own internal software. That is not true for our productivity suite, and with limited options available, self-hosting was the way forward.
DECISION TIME
The study proved that sovereignty was possible, and that the effort, while not negligible, was not prohibitive either. We expected results similar to our Azure setup, and with the market moving in this direction, we decided that setting up a sovereign alternative stack was worth doing now.
We made two decisions:
Our internal compute, inference, and apps would go completely sovereign. First, because this means we can offer a guarantee to EU customers, and second, because this was our lowest-risk area to make the transition.
We offer clients the choice to migrate, but we don't force it. Azure is a reliable and fast stack with many benefits. The choice to go 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 (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 decided to tackle this step first.
We built LLM Balancer to eliminate that exposure. LLM Balancer is an in-house inference router that sits between our applications and any backend model. It normalizes requests using the OpenAI V1 API structure, then translates them for whatever backend the client or workload requires, whether that is 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, such as legal strategy, medical data, and 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 are subject to the same CLOUD Act exposure as Azure infrastructure. Our second step was to introduce a productivity layer that matched our infrastructure principles.
We evaluated the emerging European open-source ecosystem and aligned with Nextcloud as the collaboration backbone. We made a conscious decision not to build everything ourselves: others have built solutions far better than what we could achieve, and they maintain the security around them. What we did control 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. The data is stored on European-operated infrastructure, edited with European-controlled software, and transmitted through European networks.
The transition of this step 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 to create a viable alternate hosting infrastructure for our internal and client apps. This 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 are 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.
3 Lessons | What We Learned
Three lessons have emerged from the build.
First, the integration tax is real. A sovereign stack requires more assembly than a hyperscaler turnkey. You are trading convenience against legal certainty, and that trade costs engineering hours. The price was not prohibitive, though, and we managed to achieve similar levels of automation.
Second, going sovereign is better done sooner rather than 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 becomes. So if you have any sovereign ambitions, move now, before all your agentic solutions live inside a stack you cannot leave.
Third, the payoff shows up in areas beyond what you expected. Our inference layer now routes internal requests to other models and providers that turn out to produce high-quality outputs at less than 10% of the cost. Going sovereign has 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 does not become a legal requirement, we expect companies to develop a preference for it. Markets and legislation are already indicating this shift.
The EU is no longer negotiating. The Tech Sovereignty Package, built around the Cloud and AI Development Act and presented on June 3, 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. Organizations caught between those two regimes will face penalties they cannot appeal their way out of.
IDC predicts that by 2028, 60% of organizations 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.
WHERE GYSHO FITS
Part 1 made the case that sovereignty is an architectural problem, not a procurement checkbox. This is us solving it for ourselves first, which is the only honest way to offer it to anyone else.
We built the sovereign Gysho stack as a cost-equivalent option for our clients. There is no extra charge, and you get the same guarantees you would on Azure, so the decision comes down to what your context actually needs rather than what it costs. 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.
If you are weighing whether sovereign is the right path for you, that is worth a conversation now. The one piece of advice that holds for everyone: if sovereignty is likely to be a future requirement, move before all your agentic solutions live inside a stack you cannot leave.
