The commodity illusion and the new geopolitics of compute

There’s a temptation in software engineering to view the infrastructure layers beneath our application logic as eventual commodities. We saw this with operating systems, we saw it with virtualization, and, for a long time, we convinced ourselves that the cloud had followed the same path. But as the industry undergoes a massive structural shift toward integrated artificial intelligence, we’re discovering that compute isn’t a passive utility; it’s an assertive, highly concentrated geopolitical lever.

In a recent gathering of technology leaders at The Future of Software Engineering Retreat in Engelberg, Switzerland, a tension emerged that mirrors the ‘repatriation of the cloud’ debates of the last decade, yet carries far higher stakes. The core question facing modern enterprises is no longer just about optimizing operational expenditure; it’s about architectural and organizational sovereignty. Are we built to adapt, or have we outsourced our very capacity to evolve?

The architecture of sovereignty: Beyond the cost curve

For years, the default motion for deploying AI has been simple: pay a frontier model provider per token, build a wrapper and scale. It’s highly convenient, but it accelerates a massive aggregation of power into a handful of U.S.-based tech companies. For organizations operating globally — particularly within Europe or India — this is no longer just a procurement risk, but an existential one too.

Consider the geopolitical reality. As some technologists noted during the session, nations like India are actively engineering their own critical digital public infrastructure, such as national payment systems, explicitly to bypass the strategic vulnerabilities inherent in relying on foreign financial rails like Visa or Mastercard. In Europe, the momentum behind regional options like Mistral or initiatives like EuroStack represents a desperate bid to maintain a vivid, localized digital ecosystem.

But sovereignty isn’t merely a macroeconomic or regulatory concern. It exists sharply at the organizational level. When you default entirely to external hosted models, you aren't just renting compute, you are, in fact, outsourcing your organization's ability to learn. As one participant said, “when you give another company your ability to learn, you are giving them control over your ability to change. And as software becomes more integrated into everything we do, our inability to change the software means our ability to evolve as a company is radically limited."

If your core workflows break because an external provider shifts an API boundary, rotates a model version, or escalates token pricing, your agility is an illusion. Hybrid approaches, where various vendor offerings may be combined with self-hosting today look like the way around today’s lock-in risks, enabling organizations to grant themselves the right to transform in the future.

The performance engineering trap: Private cloud 2.0?

Faced with these sovereignty concerns, the instinct for many mature enterprises is to pull the stack in-house. However, we need to look history square in the eye. The industry is littered with the carcasses of failed ‘private cloud’ initiatives from the 2010s. Enterprises spent millions trying to build their own AWS or OpenStack environments, only to discover they couldn't run them reliably. The only thing they learned was that operating a distributed cloud is incredibly hard. Is self-hosting an LLM destined for the same fate?

There’s a critical structural difference this time. Building a full-spectrum private cloud requires managing hundreds of disparate, loosely coupled services. In contrast, a modern ‘neocloud’ or an in-house AI infrastructure cluster is highly purposeful: it does one thing exceptionally well, which is to rent out or manage dense GPU capacity.

However, it’s important to not mistake simpler architecture for easy operations. Managing self-hosted models at true enterprise scale introduces an entirely different flavor of sophistication. When you run an autoregressive model on your own hardware, you swap a variable token bill for a fixed infrastructure cost. The game then changes completely from software engineering to performance engineering.

Your unit economics are governed entirely by how many tokens you can cram through a fixed hardware pipe. This demands deep, specialized expertise in low-level hardware characteristics, memory allocation and physical layout. Distributed inference over multiple cards, like splitting an open-weight model across clusters to compete with state-of-the-art benchmarks, means you’re suddenly dealing with bandwidth bottlenecks, physical rack affinities and supply-chain procurement nightmares.

The harsh reality is that the talent capable of executing this hyper-specialized optimization has largely been hoovered up by the frontier providers and hyperscalers themselves. If your organization lacks the stomach for low-level systems engineering, hand-rolling your own AI infrastructure will quickly feel like building a data center in 2005.

Data gravity, agentic routing and new security risks

If the physical infrastructure layer doesn't break you, the data architecture might. A distinct anti-pattern has emerged in early enterprise AI deployments: the decoupling of data from execution context.

The Model Context Protocol (MCP), for example, has proved extremely powerful for connecting models and enterprise systems, but deployed improperly it can be inefficient and create further issues for teams: when models are constantly querying remote systems via middleware, latency spikes, costs skyrocket, complexity and security risks increase and performance degrades.

You should, according to conventional wisdom around the challenges of 'data gravity', move the processing to the data, not the data to the processing. Achieving this with LLMs, though, may terrify security professionals. If you centralize data access to make it performant for autonomous agents, you inadvertently build a highly consolidated, easily exploitable attack surface.

The path forward isn't to build one massive, generalized internal model that knows everything. That’s a fast track to financial ruin. The future belongs to architected efficiency and pragmatic semantic routing. High-performing organizations are building orchestration layers that intercept user requests and route them dynamically based on the complexity of the task:

1. The commodity tier: Standard, high-volume tasks (such as code completions or routine queries) can be shunted to highly optimized, small open-weight models running locally or on office-wide hardware networks.

2. The sovereign tier: Highly sensitive, proprietary data operations are processed within a tightly controlled, self-hosted perimeter.

3. The frontier tier: Exceptionally complex reasoning tasks are selectively passed to external frontier APIs, accepting the variable token cost only when the ROI justifies it.

The strategic imperative: Optimize for change

The industry needs to guard against over-indexing on raw technical metrics. Yes, it’s deeply satisfying for engineering teams to optimize a model's throughput or swap an older card cluster for cutting-edge hardware, but in the vast majority of enterprises, there are so many legacy friction layers between code commit and production deployment that doubling your raw token velocity offers zero visible impact to the end customer.

The ultimate lesson we can extract from the cloud era is that nobody guesses the right architecture from day one. The technology is moving too fast; the models coming out of global ecosystems are evolving on a weekly basis. The winning strategy isn’t to declare a dogmatic allegiance to total self-hosting or absolute cloud dependence. The winning strategy is to design for mobility and structural agility.

Build your abstractions so that you can swap an external API for an internal model overnight. Train your engineering teams to design deterministic workflows rather than throwing raw, expensive generalized compute at every problem. Keep your data secure, your routing intelligent and your infrastructure flexible. 

The organizations that thrive will not be those that built the biggest GPU clusters, but those that preserved their fundamental capability to learn, adapt and switch rails without breaking a stride.