As the global digital landscape shifts, driven by geopolitical events, new regulations like the EU AI Act, and major market consolidation, the question of control has moved from a theoretical debate to an operational imperative for CIOs. It is no longer enough to simply store data locally; true digital sovereignty demands an architecture that guarantees control over data, operations, and AI in production. In this CIONET Trailblazer interview, we speak with Marty van de Korput, CTO & Technical Community Leader for IBM in Belgium and Luxembourg, who argues that organisations must move 'from cloud adoption to cloud optionality'. Marty shares his expert perspective on combating 'sovereignty washing,' why architecture is the ultimate lever for strategic independence, and how new solutions like IBM Sovereign Core are enabling CIOs to embed governance and compliance from day one.

We’re hearing more about “geopatriation”, the idea of bringing workloads back from global clouds to local or sovereign environments. Is this a fundamental shift in how we think about the cloud, or just a temporary reaction to global instability?

Geopatriation is not a short-term reaction. It reflects a fundamental shift in how we approach cloud strategy. The current geopolitical climate has highlighted how quickly dependencies can become risks. As a result, organisations are rethinking their reliance on singular, global environments.

That said, not every workload needs to be repatriated. Different workloads require different levels of control, depending on their sensitivity, regulatory requirements, and business criticality.

Geopatriation is therefore not about abandoning the cloud. It’s about reintroducing strategic control into a cloud strategy. The end state is not isolation, but fluidity, meaning the ability to operate across jurisdictions and providers, and to rebalance when circumstances change. In that sense, geopatriation is accelerating the shift from cloud adoption to cloud optionality.

Gartner used a provocative term: “sovereignty washing”. This suggests that many of the local cloud options CIOs are buying today are actually just “well-packaged dependencies” where the provider still maintains administrative access. How can a CIO tell if they are getting real control or just a legal illusion?

According to research from the IBM Institute for Business Value, 93% of executives say digital sovereignty must be factored into business strategy, yet fewer than one‑third can say with confidence what AI runs where in their organisation. This gap between intent and control is becoming more acute as AI scales — turning sovereignty from a policy discussion into an operational requirement.

The distinction comes down to visibility and control over dependencies. A sovereign solution is not defined by branding or location. It’s defined by who ultimately controls data, operations, and access. Many offerings still rely on external control planes, support channels, or update mechanisms that sit outside the authority and the visibility of the client.

Practically, CIOs should assess three layers:

• Data layer: Where is the data stored and processed?
• Control layer: Who operates and governs the platform?
• Dependency layer: What external services, software, or legal frameworks are involved?

True sovereignty is about understanding and managing these layers, not eliminating them entirely. Full independence is neither realistic nor economically viable. The real question is not whether dependencies exist, but whether they are within the CIO’s authority to manage and mitigate them when needed.

Recent market shifts, such as the VMware acquisition, have left many organisations feeling exposed to sudden changes in licensing and roadmaps. How does an architectural approach to sovereignty actually protect a CIO from being held hostage by a vendor’s corporate strategy?

Architecture is the primary lever for strategic independence. Every architectural decision today determines who holds authority over technology systems, data, operations, and AI. The difference is whether these decisions are intentional and managed, or accidental and constraining. Sovereignty is largely defined by choices, authority and visibility across technology systems, data, operations, and AI — supporting ongoing compliance and long-term independence.CIOs can protect themselves by embedding three principles into their architecture from day 1:

• Optionality: Use multiple vendors or compatible technologies where it matters.
• Abstraction: Decouple applications from provider-specific services where possible.
• Exit readiness: Define how, and how fast, you can move workloads if required.

This is where hybrid cloud comes into play. What’s changing now is that hybrid cloud is no longer just about deployment flexibility; it’s about mobility under stress conditions.

The key insight: resilience is not just about uptime within one cloud, but about continuity across clouds.

The conversation used to be just about where data “sits”. But you’ve argued that AI makes sovereignty a “runtime requirement”. Why does it matter so much where the actual AI inference happens?

In Belgium’s highly regulated and export‑driven economy, where EU rules, sector oversight and cross‑border operations intersect, CIOs are under growing pressure to demonstrate that control is not just promised contractually, but enforced operationally.

So, to support the opening statement: yes, for Belgian CIOs, digital sovereignty is no longer about where data sits, but about proving who controls AI, infrastructure, and operations in real time.

AI turns sovereignty from a design-time decision into a real-time operational dependency.​There are three critical dimensions:

• Latency and performance:
AI inference is often embedded in operational workflows: manufacturing lines, financial transactions, and customer interactions. These cannot tolerate latency from distant cloud regions.
• Operational resilience:
If access to an AI service is disrupted, even temporarily, the business impact can be immediate. In some industries, that means production downtime or service outages.
• Data control and model behaviour:
AI requires continuous data exchange. CIOs need to understand how that data is used, retained, and potentially reused. This introduces concerns beyond traditional data residency, into data lifecycle and model governance.

The conclusion is simple: AI must be deployable across environments, not tied to a single execution location.

One of your boldest claims is that a fully sovereign environment can be activated in as little as one day. To a CIO used to multi-year migrations, that sounds almost too good to be true. What is the technical secret behind that speed?

Claims of “one-day deployment” typically refer to activating a base platform, not a production-ready environment. Modern platforms, based on automation and standardisation, can deploy a baseline environment very quickly. That’s a genuine advancement.

However, what matters to a CIO is not only activation, but production readiness. That’s when the real work starts.

It includes:

• Integration into enterprise networks and identity systems.
• Alignment with security and compliance frameworks.
• Operational integration (monitoring, support, lifecycle management).
• Certification and risk validation.

These steps still require time and coordination. The real takeaway is not “one day deployment”, but that time to value is significantly reduced through standardisation, open standards, open architectures and automation.

The advantage of standardised sovereign platforms is not just speed, but that governance, compliance, and operational controls are embedded from the start, rather than bolted on later.

Everyone loves the idea of portability, the freedom to move workloads between clouds. But in reality, it is often expensive and technically exhausting. Is the “freedom to leave” worth the upfront investment, or is it a luxury most businesses cannot afford?

Portability should not be seen as an all-or-nothing decision. Not every workload requires the same level of flexibility. Through a well-designed hybrid strategy, organisations can achieve meaningful portability without excessive cost. First, not everything needs the same level of portability or optionality. Secondly, portability does not always need to be instantaneous. In many cases, a planned migration over weeks or months is sufficient.

This is where the concept of Portability Time Objective (PTO) becomes powerful. It reframes portability as a business-aligned metric, rather than a purely technical ambition. This helps as a guide to the correct choices to ensure operation in every circumstance.

Even when data stays local, the “control planes”, the brains of the platform, often still live outside the country. Is it even possible to claim sovereignty if someone else, under a different set of laws, still controls the “on/off” switch?

If the control plane is not under your control, what you have is data residency, not full sovereignty.

If you don’t control, or at least have strong governance over the control plane, you are dependent on an external entity for:

• Platform availability.
• Updates and changes.
• Administrative access.

For critical workloads, you either control the control plane or you should design around it with multi-environment resilience.

A practical illustration of this principle can be seen in Belgium.

Cegeka, a leading European service provider from Belgium, is collaborating with IBM as one of the first European launch partners for IBM Sovereign Core. In Belgium and the Netherlands, Cegeka is using the platform to help organisations run AI‑ready cloud workloads under full operational control, within locally governed environments. By combining IBM Sovereign Core with Cegeka’s in‑country cloud and data-centre infrastructure, customers can modernise and scale AI while keeping control over data, operations, identity, and compliance firmly within their chosen jurisdiction. This partnership illustrates how digital sovereignty does not require retreating from innovation, but instead relies on architectures where governance, transparency, and operational authority are built in from the start.

With strict new rules like the EU AI Act, proving compliance is becoming a full-time job for IT teams. Can a platform actually automate evidence collection, or is the CIO always going to be stuck with a manual reporting nightmare?

Yes, automated evidence collection is possible if compliance is built into the platform by design rather than added afterwards. Modern cloud platforms can automate:

• Deployment standardisation via infrastructure-as-code.
• Evidence generation (e.g., software bill of materials).
• Continuous compliance checks against frameworks like NIST or SOC2.
• Vulnerability tracking and impact analysis.

This transforms compliance from a periodic audit exercise into a continuous control system. However, technical automation only covers part of the picture.

Where technical compliance can be automated, organisational compliance (policies, processes and governance) still requires human oversight. The most mature organisations integrate both into an overall compliance framework.

Our newly announced product “IBM Sovereign Core” enables enterprises, governments and service providers to deploy and operate AI-ready sovereign environments with full customer control over data, operations and governance.

Your strategy leans heavily on open-source foundations to ensure independence. However, we have seen open-source projects change their licenses overnight. Is open source still a reliable way to guarantee long-term independence?

Open source software provides transparent, freely accessible source code that anyone can inspect, modify, and enhance. It brings benefits like significant cost reduction, unmatched customisation, robust security through peer review, and the freedom to avoid vendor lock-in. It is not a “silver bullet”, though.

Its real value lies in:

• Transparency: You can inspect and understand the technology.
• Portability: You are not tied to a single vendor implementation.
• Fallback options: You can switch providers or self-operate if needed.

However, these benefits only materialise if you actively manage the ecosystem.CIOs need to ensure licensing risks are monitored, communities are vibrant and active, and internal skills exist to operate or adapt the software if needed. 

Let’s be honest about the stakes: what is the “innovation tax” for absolute control? If a CIO prioritises sovereignty above all else, what cutting-edge cloud features or “bleeding-edge” capabilities are they potentially leaving on the table?

Sovereignty does not have to come at the expense of innovation. It is not a binary trade-off. Most enterprise workloads do not require cutting-edge features. They require stability, resilience, and predictability. A smart strategy separates:

• Innovation domains: Where you leverage hyperscalers and advanced capabilities.
• Core domains: Where you prioritise control, portability, and resilience.

The real risk is not missing out on innovation; it’s becoming dependent on capabilities you cannot access when it matters.CIOs should not choose between innovation and sovereignty; they should architect for both innovation at the edge and control at the core.

The real risk lies in over-dependence on capabilities that can be withdrawn or become inaccessible.

A balanced approach, combining innovation with optionality, ensures both competitiveness and long-term stability. 

Ultimately, Marty van de Korput's insights reveal that digital sovereignty is not a defensive retreat but an offensive architectural strategy. By shifting the focus from mere cloud adoption to cloud optionality, CIOs can ensure long-term independence, resilience, and the capacity to innovate on their own terms.
 --