Service / Private
Private & sovereign cloud
Run capable models where your data is allowed to be, and prove to an auditor that it stayed there.
Some data is never allowed to leave
For a hospital, a bank, a law firm or a defence contractor, 'we send it to a model API' is not a design — it is the end of the conversation. The constraint is not a preference to be negotiated. It is a regulator, a contract, or a classification.
The good news is that open-weight models are now genuinely capable, and the gap that made private deployment a sacrifice has narrowed considerably. What remains is engineering: making it fast enough, operable by your team, and evidenced well enough to sign off.
Capabilities
What this covers.
Deployment topology
On-prem, VPC-isolated, sovereign region or fully air-gapped, chosen against the actual regulatory requirement rather than the strictest reading of it.
Data residency
Where inference happens, where logs land, where caches live, and where backups go — mapped and enforced rather than assumed.
Air-gapped operation
Model delivery, updates and observability with no egress, including how you get a new checkpoint in and telemetry out.
Hardware sizing
GPU selection, procurement reality and rack planning for on-prem, including the lead times nobody costs into the timeline.
Compliance evidence
The artefacts SOC 2, HIPAA, GDPR and the EU AI Act actually ask for, produced as part of the build rather than reconstructed afterwards.
PII handling
Redaction, tokenisation and retention at the inference boundary, with the guarantees stated plainly enough to put in a contract.
Access control
RBAC, per-tenant isolation and audit logging over model access, because 'who asked the model what' is a question you will be asked.
Model provenance
Licence review, weight integrity and supply-chain attestation for every open model you run, so you can answer where it came from.
Operability
Handover to a team that may have no prior GPU experience, with the documentation and training to make that stick.
Deliverables
What you're left with.
- A deployment topology mapped to your specific regulatory obligations
- A running private deployment, in your environment, under your controls
- A data-flow map and the compliance artefacts to support an audit
- Hardware sizing and procurement guidance where on-prem is in scope
- Operator training and runbooks for the team inheriting it
Stack
What we work in.
- vLLM
- Llama / Qwen / Mistral
- OpenShift
- Kubernetes
- NVIDIA NIM
- HashiCorp Vault
- Terraform
- Sigstore
Tools follow the problem. If your team already runs something that works, we would rather extend it than replace it.
Questions
Asked often.
Are open models good enough to replace a frontier API?
For a well-scoped task, frequently yes — and the honest test is your evaluation harness, not a benchmark table. For open-ended reasoning at the frontier, there is still a real gap. We would rather show you the measurement than sell you the conclusion.
Do you do the compliance paperwork?
We produce the technical evidence — data-flow maps, control descriptions, audit logging, architecture documentation — and work alongside your compliance function or auditor. We are engineers, not your assessor, and we will not pretend otherwise.
Can this run genuinely air-gapped?
Yes. It changes how updates, observability and support work, and those mechanics need designing up front rather than discovering at go-live. It is the most constrained version of this work and it is well-trodden.