ReplyFabric and SEAL-2 Data Sovereignty

A few months ago, at Viva Technology in Paris, a journalist from De Volkskrant asked me about sovereign AI. My answer was fairly straightforward: ReplyFabric synchronizes email from our customers, and most of those customers already use Microsoft 365. If they trust Microsoft with their email, surely ReplyFabric can work with Microsoft services too.

A few months later, I have to admit it is not that simple.

Since then I have been in Saudi Arabia, where conversations about data sovereignty start from a completely different perspective. For certain workloads, data simply cannot leave the country, and AI processing has to comply with strict requirements, including around retention. On top of that, I am now developing a new ReplyFabric offering for the Belgian public sector. When somebody there asks whether ReplyFabric is sovereign, I need to know what I am talking about.

So I started digging. I learned a lot, and the nice surprise is that we're not doing badly at all.

From the beginning, I deliberately chose European data residency for ReplyFabric, and that principle shaped how I selected processors and subprocessors. Customer data and AI processing for our European deployments are designed to remain within EU data centres. But data residency is only the first step. The more interesting question was how ReplyFabric performs when assessed against the European Commission's Cloud Sovereignty Framework.

After working through the framework, its sovereignty objectives and its SEAL levels, I'm rather proud of where we ended up: ReplyFabric is SEAL-2 ready. That doesn't mean we are certified, and it doesn't mean our architecture is identical to every other solution within SEAL-2. It means our architecture and controls are designed around the requirements associated with SEAL-2 Data Sovereignty and can be assessed against them. For a relatively young Belgian SaaS company, that gives me confidence that many of the choices we made early on were the right ones.

Sovereignty is not the same as data residency

One of the first things I learned is that keeping data in Europe is important, but it is only part of the story. The European Commission framework evaluates sovereignty across eight areas, including legal jurisdiction, data and AI, operations, supply chain, technology, security and strategic control.

That forces a much more serious discussion. A SaaS company can store data in Belgium or Germany and still depend heavily on technology controlled outside Europe. At the same time, using technology from an American company does not automatically mean European sovereignty requirements can't be met. The questions quickly become much more specific:

• Where is the data processed?
• Which laws apply?
• Can data leave Europe?
• Who can access it?
• Who controls the technology?
• How dependent is the service on non-European suppliers?
• What happens if one of those suppliers becomes unavailable?

What SEAL-2 actually means

The framework defines SEAL-2 as Data Sovereignty: EU law is applicable and enforceable, while material dependencies on non-EU technology providers can still exist.

That last part matters, because it reflects how much of European enterprise IT actually works today. A company doesn't need to pretend that every processor, cloud platform and software component was created in Europe. Instead, it needs to understand those dependencies and put appropriate controls around its data and services.

This is where ReplyFabric fits:

• We are a Belgian company.
• We control our own software and intellectual property.
• Our European environment is designed around EU data residency.
• We also use technology from global providers.

SEAL-2 gives us a much more useful language to explain that combination.

Proximus is an important benchmark, but not the same architecture

The European Commission has already applied its sovereignty framework in practice. In April 2026, it awarded contracts under its Sovereign Cloud procurement programme, and providers had to reach at least SEAL-2 to qualify. One of the selected offerings came from a consortium led by Proximus, using services from S3NS, Clarence and Mistral, and it reached SEAL-2.

At first sight that seems comparable to ReplyFabric, since Google technology is involved in both cases. But there is an important difference: the Proximus setup is much more isolated.

• Its Google Distributed Cloud environment can run fully disconnected in dedicated European datacentres.
• Google engineers do not need operational access to the customer environment.
• The platform can be operated by European entities without a live dependency on Google's public cloud.

That is not what ReplyFabric offers today. We run on public cloud infrastructure with EU data residency, EU processing and EU data boundary controls, but Google and Microsoft remain active technology providers in our architecture. It would be misleading to claim that because Proximus reached SEAL-2, our setup is automatically equivalent. It is not.

What the Proximus example does show is more useful: two architectures can both fit within SEAL-2 while offering very different degrees of technical and operational isolation. SEAL-2 is an assurance level, not a claim that every solution inside that level is identical.

Smals makes the risk-based approach even clearer

There is another example much closer to home. In June 2026, Smals, the ICT organisation serving Belgian public institutions, selected Google Cloud as part of its broader cloud strategy. That might sound contradictory at a time when sovereignty is becoming increasingly important, but Smals is not treating sovereignty as a binary choice. It is taking a risk-based approach:

• Workload-by-workload assessment based on criticality, data sensitivity and the impact of failure.
• A hybrid mix of public cloud, Smals' own infrastructure and the governmental community cloud.
• Portability as a principle, with applications that remain capable of running outside the public cloud and exit strategies built explicitly into the architecture.
• Open standards such as Kubernetes and open source to reduce unnecessary lock-in.
• The SEAL framework to determine the appropriate sovereignty level for each workload.

When somebody questioned why Smals would aim for SEAL-2 rather than SEAL-4, CTO Dirk Deridder's answer was simple:

"Risk based classification is applied. Higher seal levels go to the on premise community cloud under government control."

That sentence says a lot. The objective is not to push every workload towards the highest possible SEAL level, but to determine how sovereign a particular workload actually needs to be. For some workloads, SEAL-2 Data Sovereignty may be entirely appropriate. For more sensitive ones, higher sovereignty levels may justify moving to infrastructure with substantially more European or government control. That is a far more practical approach than treating sovereignty as a badge.

The highest SEAL level is not always the goal

It is tempting to look at SEAL-4 and assume that every organisation should automatically try to reach it. But sovereignty has a cost. Greater isolation can mean:

• fewer cloud services and managed capabilities,
• more operational responsibility,
• potentially higher infrastructure costs.

For some workloads that trade-off is justified, for others it is not. Smals makes this explicit by treating a highly sensitive government application differently from a lower-risk workload, and the same logic applies to enterprise software. The right question is not "How do we get everything to SEAL-4?" but "What level of sovereignty does this workload require?"

From EU residency to an EU Data Boundary

Our European deployments were already designed around EU data residency and processing, but during this assessment I wanted to go one step further. We have prepared a Google Cloud Assured Workloads environment using the EU Data Boundary control package.

That distinction matters to me. Saying "we configured our resources in Europe" is quite different from saying "we have an environment with technical guardrails designed to enforce an EU data boundary." The second turns an architectural intention into a control that can be monitored, and that gives us something much stronger to build on.

We still use global technology providers

I also want to be transparent here. ReplyFabric uses technology from global providers, and we are not going to put a "100 percent European AI" label on the website and pretend otherwise. Google and Microsoft provide mature infrastructure and technology that would be unrealistic for a company like ReplyFabric to recreate.

SEAL-2 allows material non-EU dependencies to remain, but it also forces us to understand them. That is one of the main reasons we would not position our standard architecture as SEAL-3 or SEAL-4: our dependencies on global cloud and technology providers are still material. That does not mean customer data needs to leave Europe. It means technological sovereignty and data sovereignty are not the same thing.

Sovereignty goes far beyond the cloud region

Another thing I learned is that selecting an EU region in a cloud console is nowhere near enough. A proper sovereignty assessment forces you to look at the complete architecture, including:

• AI processing
• Backups and disaster recovery
• Logs and monitoring
• Support access
• Encryption controls
• Processors and subprocessors
• Software ownership
• Portability
• Incident management
• Security governance

This is where work we had already done for other reasons suddenly became relevant. ReplyFabric operates with ISO 27001 and SOC 2 Type 2 controls alongside GDPR requirements and our internal security governance. We did not build those controls because of SEAL-2, but when somebody asks us to demonstrate sovereignty rather than simply claim it, they become part of the evidence.

We are SEAL-2 ready

SEAL is not another certification badge that we can buy, pass an audit for and put in our footer. Under the European Commission framework, a contracting authority assesses a service against the requirements of a procurement, evaluating the answers, evidence and documentation to determine whether the required assurance level has been reached.

So I prefer to be precise: ReplyFabric is designed to meet SEAL-2 Data Sovereignty requirements and is ready to be assessed against them. That statement should not be confused with offering the same sovereign architecture as Proximus, whose disconnected environment provides a much stronger level of operational isolation from Google than our public cloud architecture does. Our SEAL-2 readiness comes from our own combination of:

• EU data residency and EU processing
• EU data boundary controls
• European ownership of ReplyFabric
• The way we manage our remaining global technology dependencies

Different architecture, same framework, potentially the same minimum assurance level. That is exactly why the framework is useful.

A very different answer than I gave at VivaTech

If that journalist from De Volkskrant asked me the same question today, I would no longer say "Our customers use Microsoft, so we can use Microsoft too." That wasn't completely wrong, it was just incomplete. Today I would say that sovereignty is about understanding the risk and control requirements of a workload, and then choosing an architecture that can demonstrate the appropriate sovereignty level. Sometimes that can include technology from global providers. Sometimes it cannot.

Each step of this journey taught me something different:

• Saudi Arabia taught me that geography can become a hard architectural boundary.
• The European Commission framework taught me that sovereignty itself has several dimensions.
• Proximus showed me that even within the same SEAL level, architectures can differ substantially.
• Smals taught me perhaps the most practical lesson of all: you do not need the maximum sovereignty level for every workload, you need the right sovereignty level for the risk involved.

From compliance topic to product architecture

For me, sovereignty has moved out of the compliance folder and become an architectural consideration. It affects which subprocessors we select, where AI processing happens, how we approach disaster recovery and portability, and which cloud services we choose. Above all, it affects what we need to be able to demonstrate before a government organisation or regulated enterprise entrusts us with a sensitive shared mailbox.

The Proximus example shows what a much more isolated SEAL-2 architecture can look like, and the Smals approach shows how sovereignty can be applied based on workload risk rather than as a one-size-fits-all requirement. Our own assessment gives us a clear direction: for our standard European architecture, ReplyFabric is SEAL-2 ready, with EU data and AI processing, EU data boundary controls, European ownership and governance, transparent dependencies on global technology providers, and an architecture that can be assessed against an objective European framework.

A few months ago, I thought sovereign AI was mostly a question of where your cloud provider came from. I don't anymore. And after doing the work, I am happy with where ReplyFabric stands. We're not doing badly after all.

---

📥 Download the EU Sovereignty Framework: EU Sovereignty Framework