"The Architecture Follows the Workload. Not the Partnership."

What the EU decision of April 17, '26 actually means — and why so many cloud decisions are currently stalling, especially in the public sector. An interview with Florian Rieger, Practice Lead Data & Analytics at M2.

Context and decision

When the European Commission awarded a €180 million cloud framework contract to four European-led providers and consortia on April 17, the media interpretation was fixed within hours: the EU had turned its back on the US hyperscalers. AWS, Microsoft, and Google were said to be out of the race, and sovereignty now meant purely European.

The Commission's own press release says something different. It explicitly states that non-European technologies remain permissible under sovereignty conditions. Between the headline and the document lies a gap — and inside that gap, German public administrations are currently doing the opposite of what the headlines suggest. Not rapid migration to European providers, but standstill.

We're having this conversation for two reasons. First, because over the past few weeks we've observed, in public-sector projects, how the shortened interpretation is becoming an obstacle to decision-making. Second, because as an AWS Advanced Tier Partner, we're in a position where staying quiet would be easier than speaking clearly. Florian Rieger leads M2's Data & Analytics practice and has more than ten years of experience building cloud and data architectures for complex data landscapes across corporations, mid-sized businesses, and public administration. The conversation was conducted on April 20 with Robert Schneider, Marketing Lead at M2.

Florian, the EU Commission is awarding €180 million to four European consortia, and the headlines are calling it a rejection of AWS and Microsoft. What exactly is wrong with that?

The decision itself is correct. The framework contract has been awarded, the consortia are named, the volume is accurate. What's wrong is the generalization. This contract applies to the EU institutions — the Commission itself, its agencies, its bodies. It is not a market order for European companies and administrations. And the Commission's press release contains a sentence that almost no one has quoted: non-European technologies can meet the required minimum level of sovereignty if they are operated within a strict and appropriate framework.¹

It's also important that the Commission didn't simply rate providers as "European versus non-European," but according to a tiered model: the Sovereignty Effectiveness Assurance Levels, or SEAL. The purpose of this model is to classify sovereign cloud offerings for procurement procedures, define minimum requirements, and make dependencies on non-EU providers measurable. The scale runs from SEAL-0 — effectively no sovereignty — to SEAL-4, meaning full European control and independence from non-EU laws.

Most European providers currently sit in the SEAL-2 to SEAL-3 range, often in cooperation with one another or with non-EU technology. The Luxembourg-French partnership of OVHcloud and CleverCloud, the French provider Scaleway, and the German provider STACKIT have reached SEAL-3. The Belgian consortium Proximus uses Google Cloud services and reaches SEAL-2. Further partnerships will follow, as will independent European developments. At the same time, Microsoft and AWS are bringing their own sovereign offerings to market — AWS European Sovereign Cloud and Microsoft Cloud for Sovereignty — which are operated in Europe and are likewise measured against the SEAL requirements.

Through the award and the SEAL framework, the EU is setting standards for sensitive government data. That makes sense wherever the level of protection requires it. At the same time, the model itself makes clear: not every workload needs the highest level. Uncritical applications, open-data portals, or simple citizen services generally don't require strict sovereignty obligations — and this is exactly where established hyperscalers often remain the economically superior path. That is the real European line, and it's not a footnote: the dividing line doesn't run between Europe and the US, but between workloads that genuinely need sovereignty and workloads where it plays no role.

Why does this misinterpretation of the EU decision take hold so quickly?

Because sovereignty is an emotional word. Headlines are short, press releases are not. That determines reach. And decision-makers under stress look for a simple criterion. Geography is a simple criterion — European or not. Governance architecture is harder — who operates the thing, who holds the keys, who can request which data under which legal jurisdiction. The second point is the one that matters. But the first gets asked because it's faster to answer.

Can you explain the difference technically — what exactly makes an offering "sovereign" if it's based on US technology?

Take AWS European Sovereign Cloud as an example. It's not just another European region of the general AWS cloud — it's a separate cloud partition. Operated through European, respectively German, legal entities, with operational controls, support, and operating models within the EU, along with a gradual transition to staffing exclusively with EU citizens based in the EU.² That's a different construction from a region in Frankfurt, Paris, Stockholm, or Ireland that is administered by the US parent and managed globally.

With Delos, S3NS, and Bleu, you see variations on the same basic pattern: hyperscaler technology is transferred into more sovereign environments through local, legally and operationally separated operating models. However, the degree of maturity and certification differs by provider. S3NS has received SecNumCloud 3.2 qualification. Bleu is also targeting SecNumCloud 3.2. Delos is a different model for the German public sector, run through an SAP subsidiary.³

The pattern is structurally the same everywhere. Anyone who doesn't see that is comparing apples to oranges.

Honesty matters here in the debate. True sovereignty, in the sense of complete technological independence from the US or China, doesn't exist. Certification bodies, identity providers, development platforms like GitHub, most open-source libraries, and the hardware layer itself are predominantly non-European. In practice, sovereignty doesn't mean isolation — it means controlled dependency with clear fallback layers.

What are you currently observing in your public-sector projects?

The opposite of what the headlines suggest. Instead of accelerated migration to European providers, we're mainly seeing standstill in the public sector. Decision-makers don't dare to move. They're asking themselves two questions, and neither leads to an answer — both lead to a pause: Am I even allowed to go to the cloud, or to AWS, or is ESC really sovereign enough?

These questions are understandable, but they're strategically unproductive. While administrations mull them over, legacy systems keep running, operating costs rise, and the skills shortage makes things worse. Standstill is also a decision — just one nobody consciously made.

In the commercial sector, the pattern is different. There, resistance comes less from management and more from IT security. In the projects we accompany, that's not a major problem — we find ways to support both security and business requirements. The real challenge lies in the public sector.

What's the flawed reasoning behind this standstill in public administrations?

The assumption that the cloud has to meet every requirement across the board. A typical picture from public-sector conversations: decision-makers think through the cloud starting from the strictest conceivable requirement. Not just data protection and security, but immediately the highest protection level and, when in doubt, VS-NfD — classified information for official use only. Viewed through that lens, every cloud option looks insufficient. So it gets buried before it's even been assessed. That's the most expensive form of risk management there is: not deciding at all, out of caution.

How should an administration make its cloud decision instead?

You'd need to ask: what is the actual use case? On one side are internal administrative processes involving sensitive personal data, or core matters like tax processing and personnel files. On the other side are applications with low protection requirements despite high usage — such as open data with interactive infographics, or citizen information applications.

This distinction sounds trivial, but in practice it makes the difference between years of standstill and an architecture that goes live in months. An open-data portal doesn't need VS-NfD infrastructure. Tax processing might. Anyone who rates both in the same sovereignty category makes both unaffordable — or simply doesn't do them at all.

You have to name the trade-off that's rarely spoken openly in the public debate: more sovereignty always means more effort. If you want affordable, flexible, lean solutions and processes, there's currently no way around the hyperscalers. This isn't hyperscaler apologetics. It's a statement about the current state of the European provider landscape, which is developing but not yet on par with US providers in terms of service catalog, scalability, and time-to-value. Anyone who ignores that pays twice — once in euros, once in lost time.

What role does AI play in this cloud decision?

The cloud decision is now, at the same time, always an AI decision. Whoever sets their cloud architecture today is also determining where their data sits, who can access it, how inference runs, and how model training can be audited. As soon as you start using your most important data for AI — citizen data, administrative records, files, lab data, test data, whatever your core business is — the cloud architecture becomes the AI architecture. A sovereign cloud partition where AI services are missing or only run in a limited way is just as much a problem as a non-sovereign cloud where your sensitive data gets used for the provider's model training or for third-party models.

That shifts the use-case logic retroactively. A workload rated today by its sensitivity can, in eighteen months, land in a category it would never have reached without AI. Anyone who doesn't factor that in is making their cloud decision on outdated assumptions.

Gartner published figures on this in April that I find striking. Organizations that rate their AI initiatives as successful invest up to four times more — measured as a share of revenue — in data and analytics foundations than organizations with weak AI outcomes. At the same time, only 39% of technology leaders are confident that their current AI investments will have a positive impact on financial performance.⁴

What do these Gartner figures tell you about confidence in AI?

Above all, they show structural uncertainty: many decision-makers still can't reliably assess the financial benefit of their current AI investments. And they show that the difference between success and failure doesn't lie in the models, but in the foundation. Gartner calls this the ContextLayer — the governed, semantically enriched data base on which AI agents can actually work in a meaningful way. In our projects, we repeatedly see that plenty of data is available and can quickly be made usable in AI models, but that a lack of even the simplest semantic information, explanations, and definitions means no usable decisions can be made. But that's only half the problem.

What's missing?

Gartner treats context as a data issue. That falls short. Even a perfectly governed context layer doesn't solve the actual question of trust. Because what matters isn't just which data the AI agent sees, but how it arrives at answers based on that data — and whether those answers can be traced, reproduced, and verified.

A concrete example: you ask a standard AI agent the same question about your financial figures on three different days and get three different answers. All plausible, all numerically close together, but none identical. The context was the same in all three cases. The difference lies in the layer above it — in the way the agent works. For compliance, for financial figures, for regulated decisions, that's not an acceptable state of affairs.

Research shows that ungrounded LLM outputs, in open fact-finding, research, and domain-specific QA settings, can reach relevant error or hallucination rates roughly in the range of twenty to fifty percent, depending on the model, task, and benchmark; in high-risk domains such as law or medicine, documented figures are sometimes higher.⁵ It's worth pausing on what that order of magnitude means once the output flows into a board report, a regulatory filing, or a credit decision.

And how do you solve that?

Over the past two years at M2, we've worked intensively on this layer and have come to the conclusion that it takes four principles that go beyond the context layer.

First: figures are calculated as executable code, not interpreted by the language model. Executable code makes calculations reproducible and auditable — but it doesn't replace validating the logic, the data basis, and the parameters.

Second: every statement is grounded against a deterministic source — a database, a document, a knowledge graph. What can't be grounded doesn't get answered. Better no answer than a plausible but wrong one.

Third: validation is separated from generation. The agent that produces the answer doesn't check it itself. A different agent does that, with different review criteria. This increases redundancy, depth of review, and error detection — but doesn't replace a deterministic verification path.

Fourth: every step is logged. What the agent did can be forensically reconstructed afterward — not just the result, but the path that led to it. This supports auditability and the ability to review decisions retrospectively, and is also highly valuable for further development and error analysis.

We call this approach Cognitive Architectures. Apply these four principles to a sovereign cloud architecture, and you get something that actually holds up in regulated environments. Don't apply them, and you have a nice data collection from which every agent still does whatever it wants.

We at M2 are an AWS Advanced Tier Partner and, more recently, also a STACKIT partner. How credible can we be advising on this topic in a vendor-neutral way?

The honest answer: our credibility doesn't come from having no partners. It comes from being transparent about which partners we have, and from documenting in projects when we recommend other solutions. We've been in the market since 2009, we've delivered well over 200 projects, we're an AWS Advanced Tier Partner, we're the first Tableau partner in Germany, and we work with Snowflake, Databricks, T-Systems' T Cloud Public, and STACKIT. That breadth isn't an accident, and it's not a claim to completeness. It's the precondition for letting the architecture follow the workload, not the partnership.

If all you have is a hammer, everything looks like a nail. If you have three partners, you can also say: none of them fits here.

We took on STACKIT deliberately — because of the political development, our existing network, and the potential we see in European cloud providers. And we're open about it: AWS is the market leader and, in many cases, the provider of choice when it comes to building complex solutions with dedicated, technologically cutting-edge services. European providers like STACKIT are developing quickly, but aren't yet at the same maturity level as the major hyperscalers in their managed-service portfolios — though for certain architectures and particularly sensitive workflows, they're the better fit.

The fact that this differentiation is necessary is already visible in the communication around the EU award itself. STACKIT described the award in a press release as "definitive proof" of the end of one-sided dependencies and as "final evidence" of the credibility of European solutions. That's understandable communication from a provider that just won one of the most important European contracts — AWS, Microsoft, or the other three winners would frame such a decision no differently in their own press releases. Our job as consultants isn't to comment on press releases, but to put them into the full context in client conversations — especially when they come from one of our own partners. STACKIT is the right partner for certain architectures. Not for others. The same applies to each of the four winners, and to every hyperscaler.

That's why our recommendation in day-to-day project work is always driven by requirements, never by partnership. When a client asks whether AWS is the right platform, we answer based on their architecture, their regulatory situation, and their operating model — and if a different cloud, a European provider, or simply on-premise is the better fit, that's exactly what we recommend. Being a partner of both AWS and STACKIT isn't a conflict for that — it's a precondition. Only someone who knows and builds with multiple options can credibly say which one fits a specific workload.

What's your concrete advice to an administrative leader or CDO reading this week about what the EU decided?

Don't panic-launch a new project. But don't wait around either. Instead, run a half-day workload assessment. Sit down with your IT leadership and go through your use cases — ideally not all of them, but the critical fifty to a hundred. For each use case, answer three questions: What data is involved here, and what protection level actually applies? What regulation applies? Who may access it, in case of doubt?

By the end of the half day, you'll have a matrix showing three clusters emerging: use cases with genuine sovereignty requirements — in the public sector, often those involving VS-NfD-relevant data or critical administrative infrastructure. Use cases where sovereignty is optional. And use cases where it plays no role at all — such as open-data portals or citizen-information applications.

In our project experience, often only fifteen to thirty percent of use cases fall into the first category. That's an important piece of information, because it clarifies the scale of the task. You don't have to make your entire IT sovereign. You need to know which part has to be how sovereign, and build an architecture for that part that factors in reversibility.

Why is reversibility as an architectural principle so important?

Because regulatory requirements keep evolving. DORA has applied since January 17, 2025, the EU Data Act since September 12, 2025. NIS2 has been implemented in Germany since December 6, 2025. Under the AI Act, key high-risk obligations currently take effect from August 2026 and August 2027 respectively; however, shifts are being discussed in the Digital Omnibus process.

Each of these regulations can tighten requirements. Anyone who builds an architecture today that can only be adapted five years from now with massive effort has a structural problem. Anyone who plans from the start for interchangeable components, portable data layers, and clear exit paths pays more upfront and less over the lifecycle. That's not a hypothetical calculation. It's the lesson from the last decade of cloud migration.

A sentence that will still hold true in twelve months?

Sovereignty is an architecture and process decision with effects that last for years. Whoever postpones it makes it anyway — just worse.

Thank you for the conversation. The direction is foreseeable — the opportunity now lies in acting early and deliberately using the room to maneuver you still have.

Why now is the right time to decide

This interview was conducted in the days after April 17 — at a stage where the direction is already becoming clear, but many decisions are still open. The trend is clear: regulatory requirements are becoming more binding, sovereign cloud offerings are maturing, and AI is becoming the defining dimension of every cloud architecture. The decisive course is being set now — not later.

Whoever decides in a structured way today creates room to maneuver. Whoever waits decides under pressure. If you'd like to clearly categorize your workloads, we invite you to a short conversation: 30–45 minutes, concrete use cases, a clear assessment. No product pitch — the goal is a well-founded decision on which sovereignty requirements actually apply to your workloads.

Florian Rieger is Practice Lead Data & Analytics at M2 and has been with the company for more than ten years. Before that, he worked as a business analyst at Siemens. His conviction: architectural decisions with effects lasting for years must not be made based on headlines. He consistently advises from the use case outward — and sees partnerships as the foundation of honest advice, not its limit.

M2 has been building data architectures since 2009 that enable decisions organizations can rely on — for more than two hundred clients, from DAX-listed corporations to public administration. The next stage is Cognitive Architectures: AI systems that operate in an auditable, reproducible, and vendor-independent way. Not a black box, but architecture that is traceable and builds trust.

Context: terms that shape the debate

Many discussions about sovereign cloud fail because of imprecise terminology. A clear distinction between the central concepts is essential:

A workload describes the specific use case — such as tax data or open data — and defines the actual requirements for security and sovereignty.

Data residency refers to the physical storage location of data. Relevant, but not a sufficient criterion on its own. What matters is the control layered on top of it.

That control is described as data sovereignty: who may access data — and under which legal jurisdiction?

The operating model determines who runs and controls a cloud. It's one of the central levers for genuine sovereignty.

In contrast stand hyperscalers like Amazon Web Services, Microsoft, or Google — powerful, but not inherently sovereign.

Models such as the sovereign cloud partition attempt to close this gap by shifting operation and control into a defined legal zone.

SecNumCloud is one example of a regulatory requirement that specifically safeguards this separation.

Regardless of provider, access control remains central: it governs who gets access, when, and under what conditions.

Against the backdrop of growing regulation, reversibility becomes decisive — the ability to adapt or switch architectures without lock-in.

With AI comes another layer: Cognitive Architectures — how we describe systems that enable traceable, reproducible decisions instead of black-box behavior.

^Sources

^{¹ European Commission, Commission awards €180 million tender for sovereign cloud to four European providers, press release, 2026}

^{² Amazon Web Services, AWS European Sovereign Cloud, product documentation, 2026}

^{³ Microsoft; SAP; Delos Cloud; S3NS; Bleu, Cloud sovereignty offerings and operating models (Microsoft Cloud for Sovereignty, Delos Cloud, S3NS, Bleu), product and corporate information, 2026}

^{⁴ Gartner, Organizations with Successful AI Initiatives Invest Up to Four Times More in Data and Analytics Foundations, press release, 2026}

^{⁵ Dahl et al., Large Legal Fictions: Profiling Legal Hallucinations in Large Language Models, Journal of Legal Analysis, 2024; Magesh et al., Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools, Journal of Empirical Legal Studies, 2025; Omar et al., Evaluating the Reliability of Large Language Models in Medical Applications, Communications Medicine, 2025}