Digital Sovereignty in Practice: What It Means for Enterprises Today

In our conversation with Ismail Ibrahim, General Manager, CEMEA at SUSE, we seek to understand the concept better along with his understanding of the industry and how enterprises in the UAE and Saudi Arabia can retain control in a rapidly evolving technology landscape.

What does “digital sovereignty” actually mean for an enterprise today, not in theory, but in day-to-day operations?

From an enterprise perspective, digital sovereignty becomes real the moment it changes what you do on a Monday morning. In practice, it means three things become operational requirements, not policy statements.

First, control over data. Not just where data is stored, but where it is processed, who can access it, and how you prove that in an audit. For many organizations in the UAE and Saudi Arabia, that is increasingly tied to sector rules, procurement requirements, and customer expectations.

You need the ability to keep sensitive workloads within national borders when required, but also to enable controlled data flows when innovation demands it. The important point is that sovereignty is not “ringfencing everything”. It is being deliberate about which data, which workloads and which dependencies must remain under your control.

Second, control over operations. Day-to-day, that looks like resilience and predictability: how quickly you can patch, how confidently you can recover, how consistently you can enforce policy across clusters, clouds and edge sites. This is where many enterprises discover that sovereignty is inseparable from operational excellence. If you cannot reliably manage your environments, you do not really control them.

Third, control over technology choices. This is where open source becomes practical, not ideological. When you build on open, enterprise-supported platforms, you are reducing dependency on opaque codebases and constraining the risk of being forced into a single vendor’s roadmap. Sovereignty is “choice by design”, because choice is what allows you to meet local requirements today and change course tomorrow.

That is why at SUSE we often frame sovereignty around pillars like control, choice and resilience, with autonomy as the long-term outcome. For enterprises, those pillars translate into everyday decisions: architecture, procurement, governance, patching, incident response and lifecycle management.

In the next three years, which will hurt enterprises more: security breaches, or being locked into the wrong technology stack?

It is not an either-or, because the two risks are increasingly connected.

A security breach is immediate and visible. It impacts customers, regulators, operations and reputation. But lock-in to the wrong stack can quietly increase breach risk over time, because it limits your ability to respond. If your architecture makes it hard to patch quickly, to segment workloads properly, to implement new controls, or to move sensitive workloads to a compliant environment, you have turned security into a dependency problem.

Over the next three years, I would say the most damaging scenario for many enterprises is not “breach versus lock-in”, but breach plus lock-in, where an organisation is under pressure and finds it cannot adapt fast enough.

This is exactly why sovereignty has moved into the C-suite and boardroom. Leaders are recognizing that digital sovereignty sits alongside cybersecurity and operational resilience as a strategic requirement. You need a risk-based approach to your data, workloads and support model, and you need the flexibility to change course.

Practically, in the UAE and Saudi Arabia, many CIOs are already building mixed environments across on-prem, sovereign cloud, hyperscalers and edge. The goal is not to avoid the cloud. The goal is to avoid a situation where strategic choices are dictated by a single vendor’s constraints. Open, enterprise-grade platforms help you keep the option to move, modernize or localize when needed, without rewriting everything from scratch.

As AI becomes embedded into infrastructure itself, do you believe enterprises are prepared to trust machines with operational decisions, or are we moving faster than governance allows?

In many cases, we are moving faster than governance, but that does not mean enterprises should slow down. It means they should modernize governance at the same pace as adoption.

The key is to separate hype from reality. “Trusting machines” does not mean handing over full autonomy overnight. For most enterprises, AI enters operations in stages.

Stage one is assistive intelligence, where AI helps surface insights, detect anomalies, recommend actions and reduce manual effort. This is where many organizations see quick operational value, especially in areas like observability, incident triage, capacity planning and security monitoring.

Stage two is bounded autonomy, where AI can execute actions within defined guardrails, such as automated scaling, routing, remediation playbooks, or policy-driven security responses. The governance requirement here is clear accountability: what is automated, under what conditions, with what approvals, and what audit trail.

Stage three is agentic operations, where more complex systems handle multi-step tasks across environments. This is the phase where governance must be mature, because the risk is not simply “wrong output”, it is unintended consequences across interconnected systems.

For the UAE and Saudi Arabia, readiness often depends on whether organisations have already done the foundations: standardised platforms, consistent policy enforcement, clean identity and access controls, and modern lifecycle management. If the foundation is fragmented, AI simply accelerates fragmentation.

This is why we are seeing strong interest in approaches that support governance by design, including the ability to run AI solutions in more controlled environments. In many regulated sectors, that includes air-gapped or restricted environments, where organizations want to adopt AI while keeping strict control of data movement and operational boundaries.

My view is that enterprises can absolutely trust AI in operations, but only when they treat trust as an engineering outcome: transparent systems, auditable controls, clear guardrails, and the ability to override. Governance is not a blocker. Governance is what makes adoption sustainable.

By 2030, will enterprises still control their infrastructure choices, or will hyperscalers and AI vendors effectively decide that for them?

Enterprises will control their choices if they design for control now. If they do not, the market will make the decision for them.

By 2030, the default buying motion will push organizations toward managed services, vertically integrated AI stacks, and increasingly opinionated platforms. That can deliver speed, but it can also compress choice, especially if your applications, data pipelines, security controls and operational tooling are tightly coupled to one vendor.

So the question is really about architecture and leverage. Enterprises that prioritise portability, standardization and open platforms will keep leverage. They can choose the right environment for each workload, based on performance, compliance, cost, and risk. Enterprises that ignore portability will find that “choice” exists on paper, but not in practice.

This is where digital sovereignty is often misunderstood. Sovereignty does not mean rejecting global technology. It means retaining the ability to make deliberate decisions about where workloads run and who controls the critical layers. Many leaders now talk about “glocal” strategies: using global innovation while maintaining local control and compliance where it matters.

At SUSE, our positioning has been consistent: open source supports sovereignty because it promotes transparency, portability and freedom from lock-in. That is not a slogan, it is a practical roadmap for keeping infrastructure choices in the hands of enterprises, not vendors.

If you had to offer one piece of advice to CIOs and policymakers in the UAE and Saudi Arabia navigating rapid digital transformation, what would it be?

My one piece of advice is this: treat sovereignty as an enabler of innovation, not a constraint, and build it into your operating model early.

For CIOs, that means starting with a clear map of your critical workloads and dependencies. Decide what must remain under national control, what can run on hyperscalers, what needs sovereign cloud options, and what requires special governance. Then standardize your foundations so you can enforce policy consistently. When sovereignty is engineered into the platform layer, transformation becomes faster, because you are not negotiating compliance from scratch every time you modernize an application.

For policymakers, it means continuing to create frameworks that encourage both innovation and trust. The UAE has taken a pragmatic approach in showing that openness and sovereignty do not have to conflict. When the policy environment supports clear requirements and predictable compliance expectations, enterprises can innovate with confidence.

And for both, there is a shared point: invest in skills and ecosystem capability. Sovereign outcomes are not delivered by policy alone, they are delivered by people, platforms, and partnerships. When you develop local talent, strengthen the partner ecosystem, and support enterprise-grade open source, you build resilience and long-term autonomy without slowing innovation.