Sovereign AI: Control Matters More Than Infrastructure

At a recent conference, I heard a story about an EU company that was building its own sovereign AI ecosystem. The company has an in-house software development team, its own automation processes, and a desire to maintain maximum control over its infrastructure. Against the backdrop of the EU AI Act and discussions about Europe’s technological independence, this approach seemed logical: GPU servers in a local data center, backup communication channels, a separate network segment, and no public cloud. They considered the issue of sovereignty to be practically settled.

I asked a few questions. Who will be responsible for maintaining the model in use 12 months from now? Is it possible to replace it without interrupting a key process? What happens if the vendor changes the license, the update policy, or the price? Is it possible to switch integrators without having to rewrite half the solution? After that, I stopped being a particularly interesting conversation partner, even though, in my opinion, this is exactly where a normal conversation about sovereign AI begins.

For me, when it comes to AI consulting and implementation, the main issue isn’t where the GPU is physically located. What’s more important is understanding what dependencies a company is creating around AI and whether it will be able to manage them when the market, business model, or vendor changes.

Sovereign AI Is Not a Data Center Location

Sovereignty is too often confused with infrastructure location. If the server is nearby, that means control is nearby, too. A local network can indeed address issues of data residency, security, access, and internal compliance requirements. But it doesn’t answer the owner’s key question: Who controls the dependency on which a significant part of the business will rely a year from now?

It is possible to physically own GPUs, servers, and a network while still having almost no control over the AI system. The dependency may lie in the model, the license, the update mechanism, fine-tuning capabilities, the embedding model, OCR, RAG, the vector database, or a third-party API. It may lie with the integrator, who is the only one who understands how it’s all put together and updated.

It is also important not to confuse sovereign AI with the EU AI Act. For general-purpose AI models, European regulations establish requirements regarding documentation, transparency, and copyright policy, while for models posing systemic risk, they impose additional requirements related to risk assessment, incident reporting, and cybersecurity. This does not imply a simple rule that a European company is required to use a European model specifically or to deploy it on-premise.

Sovereign AI Infrastructure Can Still Hide Dependencies

I know of a B2B project where a company was building an in-house AI assistant to handle contracts, invoices, and legal documents. The first phase cost about $300,000: servers, licenses, implementation, and integration. The architecture looked neat and was on-premises.

After some time, we gained real-world production experience, and it became clear that we needed a different model—one that was more robust and less resource-intensive. At the same time, it turned out that the entire update workflow was effectively reliant on a single small contractor and its proprietary tech stack. The system was working, but replacing a key component without the contractor turned out to be much more difficult than we had initially anticipated.

It later came to light that part of the RAG and embedding pipeline was still using a third-party subscription-based provider. Eliminating this dependency required approximately another $150,000 in modifications. The project cannot be called a failure: it solved the problem. But the owner did not buy independence; instead, they purchased a more expensive form of dependence with sovereignty on paper.

This problem is also familiar in the context of software modernization: a system may technically belong to the customer, but in reality depend on a single component, vendor, or person. In AI software modernization, this becomes apparent more quickly because models and tools evolve faster than traditional enterprise software.

Declared Architecture and Actual Data Flow Can Differ

There is another risk: the system owner does not always know the full path of their data. You might purchase a product featuring a specific AI brand on the interface without realizing which models, routers, and external services are actually involved in processing a particular request. The declared architecture and the actual data flow may differ.

In September 2026, Anthropic stated that, in certain scenarios, DeepSeek had redirected its users’ queries to Claude Opus without their knowledge. According to Anthropic, the forwarded queries included sensitive information belonging to companies and users. This is Anthropic’s own statement, not the result of an independent audit, but the scenario itself clearly illustrates the risk: a user may think they are interacting with one model, even though the actual processing chain involves another.

Therefore, the question “Where is my server located?” isn’t enough. You need to understand where the data actually goes, which components are involved in processing the request, who manages them, and what will happen if one of these components needs to be replaced. For complex AI systems, this is already a standard task for software integration services, albeit with an additional layer of dependency on models and AI providers.

We Already Live With Non-Sovereign IT

There’s a paradox here, though. We’ve been using Visual Studio or RAD Studio for decades and hardly ever ask ourselves whether we have full control over these development tools. No, we don’t. The vendor can change the license, the roadmap, or specific technologies, and this could theoretically create a serious dependency. We’ve simply learned to accept this risk.

The same thing happened with GitHub. A huge number of companies store their source code there and do not view this as an ongoing threat to their business, even though a critically important part of their infrastructure is hosted by an external provider. The risk hasn’t gone away—it’s just become clearer. Companies have learned to evaluate contracts, access rights, backup procedures, security policies, and exit strategies.

When it comes to AI, we’re still at a different stage. Companies are much more concerned about what happens to a request after it is sent to the model—whether the data is stored, whether it can be used for training, and who actually has access to it. These concerns are well-founded, but there is another reason: the market has not yet matured.

AI Vendor Lock-In Feels Different Because the Market Has Not Stabilized

Today, we’re building architectures around models that may no longer be the optimal choice a year from now. Another model might emerge—one that’s smarter, cheaper, faster, or requires significantly fewer GPUs. Prices, licensing models, and the very approach to building AI systems will change. That’s why AI vendor lock-in is now perceived as a bigger problem than dependence on a mature development toolchain.

We don’t yet know where this market will level off at a relatively stable plateau. This raises the question: Isn’t it too early for us to try to build a fully sovereign AI based on technologies that are themselves set to undergo significant changes several more times? Perhaps in five years, some of today’s fears will be viewed in much the same way as our current reliance on Visual Studio, GitHub, or cloud providers.

But we can’t wait five years either. Competitors are implementing AI, employees are starting to use it on their own, customers are expecting new capabilities, and the information landscape is constantly pushing management to take action. Doing nothing is also a decision—and it comes at a cost.

Therefore, the question isn’t whether or not to implement AI. The question is how tightly to tie the business to the current state of the market.

We Still Do Not Know What Sovereign AI Will Mean

I think that in a few years, the very definition of “sovereign AI” will look different. Let’s say a European company or government agency decides to use only models that meet certain European requirements. That could be a perfectly normal policy. But if the organization has only one acceptable model and it’s technically impossible to switch to another, to what extent is such a system truly sovereign?

The model may be European, the server may be located in the EU, and the data may never leave the perimeter. But if the model cannot be replaced, the dependency remains. Conversely, the mere fact that a model is American, European, or Chinese says nothing about the actual level of control.

If I can connect a Chinese model, how do I know it won’t compromise my clients’ privacy? What exactly does the provider store? Is my data used for training? Which subprocessors are involved in the processing? Where does the inference take place? You should ask the same questions of an American or European provider. The model’s country of origin does not replace an understanding of data flow and contractual controls.

Here again, we encounter a paradox compared to traditional IT. We have no qualms about storing source code with an external GitHub provider, but we’re much more concerned when a snippet of code is sent to an LLM. Perhaps this is justified. Perhaps, over time, the market will develop clear rules, and our attitude toward AI providers will become as pragmatic as it is toward the cloud, source control, or development tools. That hasn’t happened yet.

AI Model Portability May Matter More Than Ownership

That’s why I wouldn’t aim for complete control over the entire AI stack. Most companies simply don’t need it. It’s much more important to understand where the critical dependencies lie and what would happen if one of them had to be replaced.

Is it possible to change the model without rewriting the system? Will the data, knowledge base, prompts, evaluations, and business logic remain usable? Can the integration provider be replaced? Does anyone other than him understand the architecture? Can we do without the external API? What will happen if the vendor suddenly changes the price, license, or update policies?

To me, this is a much more practical definition of AI sovereignty. You don’t necessarily have to own everything—you need to be able to walk away. That’s why AI model portability and a well-thought-out exit strategy are sometimes more important than having your own GPU cluster.

For the board, this is no longer just a technical issue. If AI begins to impact sales, risk management, customer service, or key operational processes, that dependency affects the cost of changes, the company’s negotiating position, and its freedom of action. It makes sense to address such issues during the IT consulting phase, rather than after the AI system has become mission-critical.

Sovereign AI May Be a Level of Control, Not a Final State

The more I look at projects like this, the less I like the idea of sovereign AI as an end state: buy a GPU, deploy the model locally, and call it a day. Any modern IT system consists of external dependencies—operating systems, processors, frameworks, libraries, development tools, open-source components, and cloud services. We don’t try to control them all. We determine which dependencies are acceptable, which are critical, and what we’ll do if one of them no longer meets our needs.

Perhaps the same approach should apply to AI. For a non-critical task, it’s perfectly acceptable to use an external API and accept a dependency on the provider. If AI affects a key business process, the requirements should be different. But even in that case, I wouldn’t start by asking who owns the GPU.

I would ask a different question: If tomorrow your current model, vendor, or integrator no longer meets your needs, would you be able to replace them without having to restructure half your business around it? If the answer is no, the server’s location doesn’t make much of a difference.

Perhaps in a few years, we’ll have a much clearer understanding of what sovereign AI is. While the market is still taking shape, I wouldn’t try to buy sovereignty as a ready-made product. I would design the architecture so that the business retains the right to change the decision.