Private AI
Private and offline AI deployment
AI that never leaves your building, and keeps working when the connection does not.
- Sector
- Services
- What you get
- 7
Our approach
Private and offline AI deployment
Most AI advice assumes three things: that your data may be sent to someone else’s cloud, that there is a reliable internet connection, and that you are comfortable with both. For a great many organisations in Africa none of those hold, which is why so much AI ambition stalls before it starts.
We deploy ready-made models on hardware you own, inside your perimeter. The system can run with the network cable physically removed: no external calls, no telemetry, no outbound traffic to explain to an auditor. It is tuned on your documents, your terminology and your workflows, so it answers in the language your staff already use.
This is a productised deployment, not a research project. A known architecture installed in weeks, with the evaluation and monitoring that keep it honest. A smaller model chosen deliberately, because it is accurate enough for the task and runs on hardware you already have.
What you get
Artefacts you own and can hand to any engineer or auditor.
- Hardware sizing and specification for your workload
- Model selection, quantisation and installation on your premises
- Air-gapped deployment with no outbound network path
- Fine-tuning on your documents, terminology and workflows
- Retrieval over your own governed corpus
- Operator interface for the teams who will use it
- Evaluation harness, monitoring and update procedure
Outcomes you should expect
Outcomes you should expect
- AI in production without your data leaving the building
- A capability that works where connectivity cannot be relied on
- No per-seat or per-token cost that grows with adoption
- A defensible answer to data-sovereignty and audit questions
Tools and platforms
Tools and platforms
- Open-weight models (Llama, Mistral, Qwen)
- vLLM and llama.cpp
- Quantisation and ONNX Runtime
- GPU and CPU-only inference
- pgvector and Qdrant
- Docker on your own hardware
How we work
How we deliver
Best-practice process and development methodology, applied methodically.
- 01
Planning
We collect the relevant information from you and your stakeholders, including the constraints you have not written down.
- 02
Defining
We document the software needs, agree acceptance criteria, and write down what is out of scope.
- 03
Designing
System and interface documents are prepared against the specification: architecture, data model and stack.
- 04
Building
We implement in short cycles, with a working increment and a visible demonstration at the end of each.
- 05
Testing
We evaluate quality to find and fix defects: automated where possible, exploratory where judgement matters more.
- 06
Deployment
Release runs through an automated pipeline, checked for deployment issues, with a rehearsed rollback.
- 07
Maintenance
We keep the system current, secure and monitored, so you hear about problems from us first.
Questions
Frequently asked
Is an offline model as good as a hosted one?
Not for everything, and we will say so. For extraction, classification, summarisation and retrieval over your own documents, a well-tuned smaller model is often indistinguishable in practice, and it never sends your data anywhere.
What hardware does it need?
It depends on the model and the volume. Some workloads run on a single workstation-class machine; larger ones need a GPU server. We size it before you buy anything.
Can it be genuinely air-gapped?
Yes. It can be installed and updated with no outbound network path at all, including offline model and security updates delivered physically.
How long does deployment take?
Typically a few weeks for a standard deployment, longer if the fine-tuning corpus needs work.
Related services
Related services
Let’s talk
Let’s engineer your next advantage.
Tell us what you are trying to achieve. You will speak to an engineer, not a call centre.
Monday to Friday, 08:00 to 18:00 East Africa Time (GMT+3). Urgent support by arrangement.