insight

Sovereign AI in regulated EU enterprises

Jens Østergaard4 min read

Software architect and consultant. Works with business-led product development, distributed systems, operational AI, and production software delivery.

Answer first

Data residency and modern AI are not mutually exclusive. A governed model gateway and on-premises deployment let regulated organizations use AI on their terms.

For regulated organizations in Denmark and across the EU, the question is rarely whether AI could help. It is whether AI can be used without sending sensitive data somewhere it should not go, and without losing control or auditability. Sovereign AI is the architecture that answers yes.

The difficulty in practice is that sovereignty tends to be stated once and satisfied in a single place. A model is deployed inside the organization's own network, the requirement is marked as met, and the rest of the system carries the same content past the same boundary through indexes, logs, and telemetry. Sovereignty holds at the weakest point in the request path, so it has to be designed along the whole of it.

What sovereign AI means in practice

Sovereign AI keeps data, processing, and control within boundaries the organization governs. In practice that means on-premises or in-region deployment of models, retrieval that respects existing access controls, and a clear record of what was asked, what was retrieved, and what was answered.

  • On-premises or EU-region model deployment for sensitive workloads
  • A governed model gateway that routes between local and external models under policy
  • Provider abstraction so models can be changed without rewriting applications
  • Role-aware retrieval mapped to existing identity groups
  • Audit and traceability built into the request path, not bolted on afterwards

Where the boundary actually sits

Most of the sensitive content in an AI system never passes through the model. It sits in the retrieval index, the embedding store, the prompt and response logs, evaluation sets assembled from real cases, and the traces a platform team keeps to debug latency. Each holds a copy of the material the residency requirement was written to protect, so the discipline worth adopting is to draw the request path and establish the residency and jurisdiction of every component on it separately. Organizations that do this usually find a service that was never part of the sovereignty conversation, because it was procured as search or monitoring rather than as AI.

The model gateway pattern

A single governance layer, a model gateway, gives the organization one place to enforce policy: which data may reach which model, when an external provider is acceptable, and how every request is logged. Because applications talk to the gateway rather than to a specific provider, the organization preserves strategic optionality: models and providers can change as the market moves, without disruptive rewrites.

The layer also settles a question that otherwise recurs in every project, which is who decides. Without a central point of enforcement, each team forms its own view of which material may reach which provider, and that view exists only in code. With one, the policy is written once, reviewed by the people accountable for it, and applied whichever team ships next.

Traceability as a design property

Audit questions about AI systems arrive in a consistent shape: what did this system tell a citizen or a customer on a given date, what material did it base the answer on, and who was permitted to see that material. Answering requires the question, the retrieved context, the model and its version, and the response to have been recorded together at the time. None of it can be reconstructed from a store that kept only the final text.

Recording along the request path brings its own obligations. Logs of this kind contain the same sensitive content as the source systems, and they inherit the same rules on storage location, access, and deletion. A log store outside the governed boundary quietly undoes the architecture it was built to evidence.

What the position costs

Keeping inference local means owning accelerator capacity, an inference stack, and the evaluation work a hosted provider would otherwise absorb. Those costs are permanent and land on a platform team, which makes them worth paying for material that genuinely cannot leave and hard to justify for everything else. Very few organizations end up with a single answer, and the boundary moves as legal reviews complete.

Data residency and modern AI are not opposing constraints. The right architecture lets you have both.

What we recommend

State the requirement as properties rather than as a deployment model, so that a legal need does not quietly become an architectural one. Put the gateway in place before the second production workload. Run sensitive inference locally where the constraint is real, route the rest to hosted models under written policy, and hold the logs inside the same boundary as the data they describe. Sovereignty requirements tend to tighten over time, and the systems that make that expensive are the ones with a provider interface compiled into the application.

Putting the gateway in place before the second production workload is a sequencing decision, and sequencing decisions are the ones organisations get wrong when nobody owns them past the first launch. That ownership question is where a platform engineering engagement starts: who runs this in eighteen months, not who built it this quarter.

Can regulated organizations use large language models without sending data to external providers?
Yes. On-premises or in-region deployment keeps sensitive data within governed boundaries, and a model gateway can route only permitted, non-sensitive requests to external models under explicit policy. Sensitive workloads stay local.
What is a model gateway and why does it matter for sovereign AI?
A model gateway is a single governance layer that all applications call instead of talking to a model provider directly. It enforces which data may reach which model, logs every request for audit, and abstracts the provider, so models can change without rewriting applications and control stays centralized.
Does sovereign AI require everything to run on-premises?
No. Local inference is the right answer for material that law or contract keeps inside the organization. Most organizations hold a mixture, and a gateway lets the restricted workloads run locally while the remainder use hosted models under an explicit policy that can be changed as legal reviews complete.

Newsletter

Occasional notes on building systems that hold up

A short email when we publish something worth your time. Architecture, integration, and operational AI in regulated organizations. No cadence promises, no forwarding your address.

explore further

Related insights

  • What sovereign AI actually means

    The term covers four separable properties, and vendors tend to sell the cheapest one. Which of them you actually need depends on what you are protecting against.

  • On-premises vs hosted LLM: how to choose

    The choice is usually settled by data residency and contracts, not by cost or model quality. Here is what each option costs you in practice.

  • The EU AI Act: what it asks of deployers

    Most organizations buying or building on AI are deployers rather than providers. That distinction decides which obligations land on you, and most of them are architectural.

Capabilities

  • Operational AI

    AI systems that integrate with existing platforms and workflows, with control, traceability, and operational reliability.

  • Platform Engineering

    Reliable and maintainable platform foundations that support development and operations at scale.

Related cases

  • Sovereign AI Gateway

    A unified gateway that centralizes model routing, policy enforcement, and auditability.

  • Category Blueprint

    A category blueprint that turns AI governance into a practical operating design for scalable transformation.