.png&w=384&q=75){kind=logo}
On-prem & air-gapped operation
We bring open LLMs with vLLM into your own infrastructure — even into environments fully cut off from the internet, where no external service is reachable.
Sovereign AI
Sovereign AI means your data stays in-house. We self-host open language, vision, and embedding models, wherever they need to run.
On-premises, in a sovereign cloud, or fully air-gapped. You get capable AI without your data ever leaving your control.
TRUSTED BY TEAMS AT:
What exactly is
Sovereign AI?
For many organisations the decisive question is not which model is best, but where it runs and where the data flows. Sovereign AI means you keep control of your data. We run open models with vLLM on your own infrastructure, whether on-premises, in a sovereign cloud, or in a fully sealed-off, air-gapped environment.
Data protection and information security are then part of the architecture rather than a later add-on, and capable AI becomes usable in sensitive areas too.
Sovereign cloud deployment
Operation on sovereign cloud infrastructure based in Germany or the EU, when your own data centres are not an option.
GDPR-compliant architecture
Data protection and information security are built into the design from the start, with access control, logging, and clear data flows in place from day one.
Sovereignty comes in degrees
Almost no organisation can run everything itself, and almost none needs to. The useful question is which part to keep sovereign, and for which data.
LEVEL 01
Public model, EU contract
You buy tokens from a provider with an EU data centre and a data-processing agreement. Quick to start, with little operational effort — the provider stays in the chain.
LEVEL 02
Open model, sovereign cloud
An open-weights model runs on German or European cloud infrastructure, operated by us or by you. No US provider in the data path, and no hardware of your own required.
LEVEL 03
Open model, your own data centre
Weights and inference sit on your hardware. You decide the version, the timing, and the access — and you carry procurement and operations.
LEVEL 04
Air-gapped
No network route out. Model updates arrive over a controlled physical-media path. For environments where this is the only permitted build.
The trade-offs of open models
Breadth without follow-up work — A frontier model is usable on many tasks without adaptation. An open model more often needs careful prompt design, targeted fine-tuning or a retrieval setup to reach the same quality.
Multimodality from a single model — Image, audio and text in one model is rarer in the open space. In practice we solve that with several specialised models — often cheaper and easier to audit.
How we measure it instead of asserting it — We build an eval set from your real cases and let the candidates compete on it. There is no general percentage — it depends on your use case.
What you do not give up — Version stability, control of your data, predictable cost, and the option to change provider without rebuilding the application.
What sovereign AI actually costs
- Compute
GPU hours instead of tokens. The maths turns on utilisation: constant load makes your own hardware cheap, sporadic use makes it expensive.
- Reserving instead of consuming
Inference you run yourself costs money even when nobody uses it. Buying tokens costs nothing then. This is the most common miscalculation.
- Redundancy and latency
A second node for failover doubles the hardware. Sub-second response times force capacity headroom that sits idle on average.
- Operations
Monitoring, model updates, security patches, capacity planning. That is staff effort, not a licence line, and it is missing from almost every comparison.
- Switching and exit cost
What does it cost to swap the model in two years? A setup with an OpenAI-compatible interface keeps this line small.
What about my
Microsoft 365?
If your contracts, minutes, and mailboxes already sit with a US provider, a sovereign language model can look pointless. The objection is fair, and the distinction still matters: a document in SharePoint sits there under contract, with defined access. Dropping that same document into a chatbot creates a second, uncontrolled data path.
So we don't start with the platform, we start with the data: which categories can go where. Often it's enough to process a clearly bounded part sovereignly, like HR, legal, or patient records, and leave the rest where it is. That is cheaper than a migration and faster than a matter-of-principle debate.
And if you switch later, we build against an OpenAI-compatible interface and keep prompts, tool definitions, and eval sets separate from the provider, testing function calling and structured output on both sides. Switching then stays a configuration question rather than a project.
How you prove it to your auditor
Read what the certificate covers — Ask every provider for the scope of the attestation, and whether the AI service you intend to use is inside it. An attestation often covers the classic cloud platform but not the new AI service on top.
The EU AI Act without drama — For most systems it comes down to sound MLOps: risk classification, technical documentation, logging, human oversight, and change management. We would build it that way without the regulation.
Disclose the operator stack — Who runs the hardware, who runs the platform, who runs the model, and who can reach the data in an incident? Those four answers belong in your documentation — we provide them in writing.
Evidence you can hand on — A data-flow diagram, a roles-and-permissions concept, a logging concept, model and version state, and test results. At the end of the project, that is a package you can hand over, not a pile of screenshots.
We apply this to ourselves: Homeport, our AI product for B2B sales, runs in Germany on T Cloud Public.
See HomeportHow sovereign operation comes about
- Step 01
Clarifying requirements and where it runs
We clarify which data is processed and whether on-premises, sovereign cloud, or an air-gapped environment is the right place for it.
- Step 02
Designing the architecture with data protection built in
Access control, logging, and data flows become part of the design instead of being bolted on afterwards.
- Step 03
Selecting and setting up models
We select open models to fit your use case and bring them onto your infrastructure with vLLM.
- Step 04
Operating and keeping it traceable
We operate the inference on your infrastructure and keep access control and logging traceable.
Our Work
Software DevelopmentContract Management System for Broadband ServicesThe development of a central, audit-proof contract management system for fibre rollout, including transparent document storage, deadline tracking and a KPI dashboard.Read the full case study
Software DevelopmentWeb-Based Order Management for Construction SitesThe transformation of an old desktop application into a modern web platform, including functional enhancements.Read the full case study
What we build with.
The stack these systems run on with us.
INFERENCE
- vLLM
- Open LLMs
- GPU cluster
OPERATIONS
- Kubernetes
- On-Premises
- Sovereign cloud
MODEL TYPES
- Embeddings
- Reranking
- Vision
- Speech-to-text
Let's talk about your requirements.
Start with a no-obligation project inquiry and let our team of experts in agile development and architecture provide you with comprehensive advice on your project.