What separates this from a general tool
A general-purpose tool knows the average of the world; it does not know your business. It does not know your pricing policy, your contract template, the decisions in your past projects or your client's specific requirements — and where it does not know, it invents.
A private model closes that gap: it answers from the organisation's own documents, shows its source, and says so when it does not know.
The second difference, decisive for most organisations, is data sovereignty. Contracts, personnel files or patient records never travel to a third party's servers.
Two deployment routes — which one fits
Connect to a knowledge base. The model stays as it is; the organisation's documents become a searchable knowledge base and the model answers from it. Fast to deploy, inexpensive, updates the moment a document changes. For the large majority of organisations this is the right answer.
Train the model on your data. The model is adjusted to the organisation's language, format and decision logic. Expensive, slow, and repeated whenever the data changes. It only makes sense where the organisation has a genuinely distinctive voice or decision pattern that the first route cannot reach.
Most vendors prefer to sell the second route because it is expensive. We try the first route first, and move to the second only where the first proves insufficient.
A small model is usually the right answer
Gartner projects that by 2027 enterprises will deploy task-specific small language models three times more often than general-purpose large models. The reason is simple: a small model costs less to run, answers faster, and is more accurate within a narrow domain.
Its second advantage is security: because it can run on the organisation's own server or private cloud, the data stays inside.
The assumption that "the biggest model is the best model" is wrong for most enterprise tasks, and expensive.
Air-gapped and public sector deployment
In public institutions and in regulated sectors such as defence, health and finance, a deployment with no internet connection at all is often required. This is technically achievable and is one of our standard modes of work.
In an air-gapped install the real issue is not the model but the update and maintenance regime: if the system never reaches the internet, how do updates arrive, who carries them, and through which approval.
In the Gulf, data residency is not a preference but a redline; in Saudi Arabia, Oman and Egypt sensitive data is expected to remain in country. We design the deployment accordingly.
Where these projects fail
Starting before the data is ready. Scattered, duplicated, contradictory documents do not produce good answers. The real work is usually in document order, not in the model.
Not measuring accuracy. "It gives nice answers" is not a criterion. Before starting we write down which questions must be answered correctly, and we measure the result against that.
Leaving it unowned. Documents keep changing after handover. A system without an update regime loses its reliability within six months.
The two routes side by side
| Knowledge base | Training on your data | |
|---|---|---|
| Deployment time | Short | Long |
| Cost | Low | High |
| When a document changes | Updates immediately | Requires retraining |
| Citing sources | Does it naturally | Needs extra machinery |
| Organisation-specific voice | Limited | Strong |
| When it is the right choice | Most organisations | Distinctive decision pattern |