During GITEX Europe in Berlin, I spent several days talking to startups, enterprise customers, and technology partners about AI adoption. One pattern emerged surprisingly often: “We use OpenAI. Sovereignty isn’t really something we need to think about.”
AI sovereignty is becoming a business question across industries
Defense is the first sector people associate with AI sovereignty. And for good reason. If a defense organization wants to use generative AI for critical workloads such as software engineering, it will usually expect the solution to run on infrastructure it controls, using open-weight models rather than public AI services.
Financial institutions face a different driver: regulation. Frameworks such as DORA and C5 are pushing organizations toward greater control over their AI environments. In areas like wealth management, organizations often do not want sensitive customer data to be accessible outside their controlled environment. In some cases, they don’t even want their own employees to have unrestricted access to it.
Healthcare and pharmaceutical companies operate under similarly strict regulatory requirements. Given the sensitivity of the data they process, questions around control, access, and jurisdiction become an essential part of AI system design.
And there are also startups. As they begin working with enterprise customers, technical discussions quickly expand beyond product capabilities. Potential customers want to understand where the AI runs, which countries may have access to the data, and how much the solution depends on a particular AI provider. If a company cannot provide clear answers, it may negatively affect an enterprise deal.
Before going further, let’s distinguish between two concepts that are often confused.
AI sovereignty and AI confidentiality solve different problems
A simple analogy helps explain the difference.
Imagine staying in a hotel in another country. The hotel provides everything you need. The room is comfortable, breakfast is included, and someone else takes care of the infrastructure. But the hotel still has the key to your room.
This is how many AI workloads operate today. They run on infrastructure owned and operated by someone else. It is convenient and scalable, but ultimately, someone else controls the environment in which your AI operates.
AI sovereignty is about that control. When we discuss AI sovereignty with customers, we usually look at four dimensions: where the data physically resides, who has operational control over the infrastructure, under which laws and jurisdictions the system operates, and how dependent the solution is on a particular provider.
AI confidentiality answers a different question.
Imagine storing your valuables in a safe deposit box at a bank. The bank owns the building and protects the vault, but it cannot access your individual safe.
Confidential AI follows the same principle. AI workloads run inside trusted execution environments, allowing cloud or hardware providers to host the infrastructure without being able to see what is actually being processed.
So the question becomes very simple: Who do you trust?
If you trust the organization operating your AI infrastructure, sovereignty may be enough. If you don’t, confidentiality becomes part of the solution.
A practical framework for evaluating AI sovereignty
Its first dimension is data criticality — the potential business impact if the data processed by the AI system were exposed to a third party.
The second is the required AI capability. Some workloads require access to the most capable models available today. Others can be solved with much simpler models or standard AI assistants.
Together, these two dimensions help narrow down the available options:
- If a workload processes non-critical data and does not require advanced AI capabilities, there is little reason to introduce additional complexity. In that case, solutions like ChatGPT may be enough.
- As data sensitivity and capability requirements increase, organizations may move to sovereign AI platforms or ready-made solutions from providers such as NVIDIA, Near AI, and others.
- When requirements go beyond off-the-shelf solutions, this is where we help customers design architectures tailored to their specific workloads.
Making the decision is one thing. Running it is another
You’ve made a decision. You’ve chosen the models you want to run. Now you actually have to run them. You need MLOps. You need observability, security, compliance, and efficient hardware utilization. What initially looked like a technology decision quickly becomes an operational one. Once customers see everything that’s involved, the reaction is often the same: “Okay, I give up.”
However, you don’t have to build and operate the entire sovereign AI stack yourself. You can keep the level of control you need while relying on a partner to take responsibility for part of the infrastructure and operational complexity.
But for some workloads, sovereignty alone is not enough, and confidentiality becomes the third dimension. In this case, the same question still applies: Who do you trust?
As the level of trust moves closer to zero, confidentiality becomes increasingly important.
Just like sovereignty, confidentiality is not binary. Some organizations choose providers that combine confidential computing technologies from AMD, Intel, and NVIDIA with an additional confidentiality layer delivered as a managed service. Others choose to go one step further and run their own trusted execution environments to maintain complete control over confidential workloads.
At this point, the framework may seem even more complex. In practice, the opposite is true.
Once you break the problem into smaller decisions, it becomes much easier to manage
This is how you can approach AI sovereignty.
- Sovereignty should be workload-specific.
A company doesn’t have to become “AI sovereign.” Different AI workloads have different requirements. Looking at sovereignty at the workload level makes the decisions much smaller and much easier than trying to transform the whole organization at once.
- Sovereignty is not binary.
It is not a choice between being fully sovereign or not sovereign at all. There are different levels of sovereignty, and organizations can choose the level that fits a particular workload based on data criticality, AI capability requirements, and, where necessary, confidentiality.
- Complexity can be managed.
Today, AI-as-a-service makes it easy to switch between five or ten different models depending on the task. In sovereign AI environments, that flexibility comes at a cost.Whenever possible, we encourage customers to standardize on one model—or, at most, a small number of models. Operating one or two models is significantly simpler than operating five or ten.
- Regulatory requirements should shape the architecture from the beginning.
Whether it’s GDPR, CRA, DORA, C5, or other regulatory frameworks, compliance should become part of the AI design process from day one. It is much easier to build sovereignty around regulatory requirements than to retrofit compliance later.
To sum up…
Not every workload needs sovereignty.
Not every workload needs confidentiality.
And not every organization needs to build and operate everything itself.
The key is understanding what each workload actually requires. Once that’s clear, choosing the right architecture becomes much easier.
The goal is not to maximize sovereignty. The goal is to apply the right level of sovereignty — and, where needed, confidentiality — to the workloads where it actually matters.
Inside Telecom provides you with an extensive list of content covering all aspects of the Tech industry. Keep an eye on our Press Releases section to stay informed and updated with our daily articles.
