Sovereign AI Platforms
AI platforms that run where your data lives
We build the platform layer underneath your AI: model serving, retrieval, guardrails, evaluation, and audit trails, on European infrastructure, on open source, positioned for the EU AI Act from the first architecture decision.
The problem
The pilot works. It is the deployment that does not.
Enterprise AI initiatives stall in two places, and neither is the model.
The first is the platform gap. A pilot built by a data science team on a notebook and a provider API has no serving layer, no evaluation harness, no observability, no cost control, and no operational owner. Turning it into something a business depends on is a platform engineering project, and it is usually discovered at the point where the pilot is declared a success.
The second is the compliance wall. The use case is sound, the value is real, and then it reaches data protection, and stops. There is no answer to where the data goes, who can technically access it, which jurisdiction the model runs in, how a decision is logged, or what obligations follow from the system’s risk classification. In regulated European organizations this is where the majority of promising AI work goes to wait.
Both problems have the same root: the platform underneath was never built, and the governance was treated as a review step rather than an architectural requirement.
What we do
What we build
Model serving on infrastructure you control
Self-hosted open-weight models where your data classification requires it, European providers where they fit, and sovereign offerings of major providers where that is the right answer. The decision is made against your data classification and documented, rather than defaulting to whichever API was easiest to get a key for.
Retrieval that respects your access controls
The failure mode nobody demos: a retrieval layer that flattens source-system permissions and lets a user retrieve what they could never otherwise read. We propagate access controls into retrieval, because a RAG system that leaks across permission boundaries is a data breach with a chat interface.
Guardrails that are part of the architecture
Input validation, prompt injection mitigation, output filtering, PII detection and handling, and human oversight where the risk classification requires it. Enforced at the platform layer so every application inherits them rather than each team reimplementing them differently.
Evaluation, so you can tell whether it is working
A golden dataset built with your domain experts, automated evaluation runs, and regression detection. This is the piece pilots skip, and it is why so many teams cannot answer whether last month’s change made the system better or worse.
Audit trails and observability
Every request, retrieval, and model interaction traceable and attributable, with cost accounted per team and use case, in the observability stack you already run.
Governed model access at scale
An AI gateway giving every team one governed path to every model: routing by use case and data classification, policy enforcement, cost control, failover, and a single audit trail. Usually the highest-value first investment once AI usage has spread across more than a few teams.
AI Act positioning from the start
Risk classification for the system, the obligations that follow, and the technical documentation begun during the build rather than reconstructed afterwards, which is both cheaper and considerably more accurate.
Our offerings
How we engage
AI platform assessment and architecture
Where your AI initiatives are, what platform layer they need, and what the sovereignty and regulatory constraints actually require.
Outcome
An architecture and a roadmap grounded in your constraints.
AI gateway
A single governed entry point to every model: routing, policy, cost accounting, audit, failover.
Outcome
Governed AI adoption without slowing any team down.
Sovereign AI landing zone
The platform foundation for AI workloads on your sovereign target: GPU infrastructure, model serving, data and retrieval layer, observability, guardrails.
Outcome
A foundation your second and third use case reuse for a fraction of the cost of the first.
Use case delivery
RAG systems, agent workflows, and extraction or classification pipelines, built on the platform, against your real data.
Outcome
A working system with an evaluation baseline and a cost model.
AI governance engineering
Risk classification, guardrail design, evaluation frameworks, audit trail architecture, and technical documentation structured for AI Act obligations.
Outcome
A compliance position built into the system rather than argued afterwards.
AI platform operations
Day-2 operations for AI workloads: model lifecycle, evaluation monitoring, cost management, incident response.
Outcome
AI systems that stay reliable and stay affordable.
How we work
How we work
Platform engineers who work on AI, not the other way round
The hard problems in enterprise AI right now are serving, retrieval, access control, observability, cost, and lifecycle. Those are platform engineering problems, and that is what we are.
Open source and yours
Everything runs on open source, on your infrastructure, in your repositories. There is no proprietary platform layer between you and your models, which means you can change model provider, move jurisdiction, or take the whole thing in-house without a migration project. Several suppliers in this market offer a proprietary suite instead. That is a legitimate model, and it is a different trade, and you should know which one you are buying.
Governance from week one
Risk classification happens during architecture, not during review. It is significantly cheaper and it produces documentation that is accurate rather than reconstructed.
Measured, not asserted
Every system we build ships with an evaluation harness and a cost model. “It seems better” is not a basis for a production decision and it is not a basis for a budget conversation either.
Honest about what AI will not fix
Some use cases do not justify their cost, some data is not ready, and some problems are better solved without a model. We would rather tell you in week two than build it and let you find out in month nine.
What you get
Result driven outcomes you can expect
Architecture with the model and target decisions documented, including the alternatives rejected and why
The running platform, on your infrastructure, as code, in your repositories
Model serving with the routing and policy layer
Retrieval layer with access controls propagated from source systems
Guardrails: input and output filtering, injection mitigation, PII handling
Evaluation harness with a golden dataset you own
Full observability: tracing, quality metrics, and cost per team and use case
Audit trail meeting your retention and evidence requirements
AI Act risk classification and technical documentation, structured for continuation
Runbook and enablement for your team
Where this sits in the stack
Why the layers below decide what is possible here
AI is the workload where every constraint below it becomes binding at once. Data residency, model jurisdiction, access control, auditability, and regulatory classification all apply simultaneously, and they apply to a system whose behaviour is probabilistic.
Organizations that already have a sovereign substrate and a working platform layer can deploy AI, because the hard questions were answered before the AI question arrived. Organizations that do not are the ones with a portfolio of successful pilots and nothing in production.
Packaged offers
Start with a defined step
9 weeks
Sovereign AI Platform Proof of Value
Nine weeks from a validated use case to a working AI application running on European infrastructure, with the governance, guardrails, and evidence your compliance function will ask for.
6 weeks
AI Gateway Blueprint for model routing and policy control
Six weeks to a single, governed, observable entry point for every AI model your organization uses, with routing, policy, cost control, and an audit trail.
FAQ
Questions we get asked
Do we need to self-host models?
Often not. Self-hosting makes sense when data classification prohibits sending data to a provider, when volume makes it cheaper, or when you need version stability a provider will not guarantee. For a great many enterprise use cases a European provider API is appropriate and considerably simpler. The right answer is per use case, driven by data classification, and a gateway makes it a routing decision rather than an architectural commitment.
How is this different from the AI platforms the large integrators offer?
Those are largely proprietary suites: fast to start, and they become the layer between you and your models. Ours is built from open source components on your infrastructure, in your repositories. You can operate it, change it, and leave it. That is a real trade-off rather than a marketing distinction: their suites offer more out of the box, and ours offers control and exit. Which is right depends on how much this matters to your risk position.
What does the EU AI Act actually require of us?
It depends on your system’s risk classification, and the classification depends on purpose and context rather than on the technology. We do the technical classification with reasoning documented, map the obligations that follow, and build the technical documentation during development. Your legal function owns the determination. Anyone offering you AI Act compliance as a product is selling you something that does not exist.
Our data is not ready. Should we wait?
Usually no, but you should scope accordingly. Data readiness is discovered rather than assessed in the abstract, and a narrow first use case will tell you more about your data in six weeks than a data quality programme will in six months. What you should not do is scope a broad use case on data nobody has examined.
How much does running AI infrastructure cost?
GPU infrastructure and model API consumption are the dominant costs and both are highly use-case dependent. We build a cost model per request and at projected production volume during every engagement, because the cost question is usually what decides whether a use case industrializes, and it is much better answered in week seven than in month seven.
What is blocking your AI initiative?
In our experience it is one of three things: no platform underneath, no answer for compliance, or no way to tell whether the system is any good. All three are solvable, and all three are cheaper to solve before the second use case arrives.