Part 1: Lessons From Building EU Native Enterprise AI Stacks

Over the last twelve months we’ve been implementing sovereign AI environments for governments, regulated enterprises, financial institutions and operators of critical infrastructure across Europe.

Almost every conversation starts in the same place: model evaluations, benchmarks, context windows and capability comparisons. Almost none of them end there.

The moment AI moves from experimentation into environments that matter, the discussion changes. Suddenly the concern isn’t whether one model scores marginally better than another. It’s whether the capability can be moved, governed, audited, contained and ultimately controlled. 

The centre of gravity shifts from intelligence to infrastructure surprisingly quickly. The recent suspension of Mythos provided maybe the most visceral example yet of why this is the case.

The Model

For most deployments we standardised on Mistral / a Mistral model purpose built for the penultimate use case. The rationale here is fairly straightforward. It is European-developed, self-hostable, operationally efficient and performs well in the environments we care about. More importantly, it can run entirely within infrastructure controlled by the organisation.

But in truth Mistral is an answer, it is not THE answer.

Designing around any single model is increasingly shortsighted. Models will continue to improve. New providers will emerge. Existing providers will change direction. Organisations will naturally want the flexibility to adopt better options as they appear. The objective is model independence rather than model selection.

Kubernetes

That same thinking led us toward Kubernetes. Beyond becoming the dominant platform for modern infrastructure, Kubernetes has also emerged as the default operating environment for production AI workloads. Recent CNCF research found that roughly three quarters of organisations running AI and machine learning workloads are doing so on Kubernetes. 

The same characteristics that made Kubernetes successful for cloud-native applications—portability, scalability, ecosystem maturity and operational consistency—become even more valuable as AI moves from experimentation into operational environments.

The deeper we went into these deployments, the clearer it became that sovereignty is ultimately an infrastructure problem.

Another lesson emerged once AI systems began moving beyond demonstrations and into operational environments.

Traditional applications tend to operate within relatively predictable boundaries. They communicate with known systems, perform defined tasks and operate under reasonably constrained assumptions. Useful AI systems behave differently. As they become valuable, they accumulate access. Documents lead to repositories. Repositories lead to ticketing systems. Ticketing systems lead to databases, internal applications and communications platforms.

Before long, the AI system has become one of the most privileged systems inside the organisation.

Containment

At that point, self-hosting a model is only one small piece of the problem. Governance becomes the harder challenge. Policy enforcement, compartmentalisation, identity, secrets management, communications controls, auditability, telemetry and revocation all become foundational requirements rather than nice-to-haves.

Most organisations already operate some combination of technologies such as Kyverno, Istio, Cilium, Vault, Falco, OpenTelemetry, ArgoCD, Keycloak, Prometheus and Grafana. The challenge is rarely the individual projects. The challenge is composing them into a coherent operational posture that can support AI workloads safely. That challenge is the same challenge that ultimately led us to build ACRA.

ACRA does not introduce new primitives, it operationalises a posture built around containment, ownership and command - often integrating a number of systems you already run. AI systems operating in high-consequence environments require a stronger set of assumptions than traditional enterprise software. The architecture needs to reflect that reality.

The final lesson was perhaps the most interesting.

Achieving Organisational Intelligence

Going into these projects, we assumed the model would become the centre of gravity. In practice, the durable asset turned out to be organisational understanding.

Many organisations begin by ingesting everything they can find. Every document, repository, email archive and file share is loaded into the system with the expectation that more information will produce better outcomes. Our experience has generally been the opposite.

The strongest results have come from starting with the highest signal information available. Strategy documents. Architecture decisions. Operating principles. Policies. Standards. Institutional facts. The materials that explain how the organisation thinks rather than simply what the organisation has produced.

Building organisational intelligence turns out to be surprisingly similar to onboarding a senior executive. The objective is not to expose them to every artifact that exists. The objective is to help them understand what matters.

This observation ultimately led us to Valarie - a layer we have never talked about publicly, and you will learn more about in coming posts.

Valarie (currently powered by Mistral as well) serves as ACRA’s intelligence layer - sitting above the infrastructure, control and model layers. It provides organisational memory, ontology management, knowledge fusion and policy-aware intelligence. It maintains context around relationships between people, systems, policies, projects and information assets. It assists with classification and governance, including the identification of regulated information and personally identifiable information that may be subject to GDPR or other compliance requirements. Most importantly, it creates organisational understanding that remains portable, even if you decide to shift models.

Models can change. Cloud providers can change. Infrastructure can change. The intelligence should not.

Beyond Self Hosting

One final observation emerged repeatedly throughout these deployments. Many organisations initially equate sovereignty with self-hosting. Self-hosting is certainly important, but it is only one part of the equation.

Data residency requirements, cross-border transfers, government access requests, regulatory obligations and legal frameworks such as the US CLOUD Act are increasingly influencing infrastructure decisions. Organisations are not simply asking where a model runs. They are asking who ultimately has authority over the systems, the data, the telemetry and the outcomes.

A sovereign AI architecture therefore needs to be more than self-hosted. It needs to be cloud agnostic, model agnostic, infrastructure portable and jurisdictionally controllable. The objective is not simply privacy. The objective is retaining authority as technology, providers and regulations continue to evolve.

The discussion around AI often gravitates toward which model is smartest. After spending the last year implementing these environments, that feels increasingly like the wrong question.

The organisations likely to navigate the next decade successfully will not be those that happened to choose the right model in 2026. They will be the organisations that built architectures capable of adapting as everything else changes.

Over the coming weeks we’ll share more of what we’ve learned, including why AI demands a different security posture than traditional workloads, how we approach organisational memory and ontology design, more on Valarie and the practical lessons that are emerging from deploying sovereign AI environments across Europe.