Nearly every route into AI asks a business to post its work to someone else’s computer. For plenty of companies that is a perfectly reasonable trade. For the ones holding client confidences, unreleased material, personal data, case files or anything sitting under an NDA, it is the single reason they are not using any of this at all — and the reason a quiet half of their staff are pasting it into consumer chatbots anyway.
A private AI server removes the question rather than managing it. The model runs on hardware the company owns, on a network it controls.
What we built
Each one is specified against the organisation rather than sold as a box. A small practice might need a single GPU workstation serving a handful of people. A mid-sized company runs a server for several departments. A large or regulated organisation takes a multi-GPU rack, sometimes fully air-gapped with no outbound route whatsoever.
On it sits a self-hosted model stack — open-weight models served locally, an OpenAI-compatible endpoint so existing tools can be pointed at it without rewriting them, and a chat interface staff will actually use rather than tolerate.
The part that makes it worth owning is the training. A general model knows the world; it does not know your pricing, your contracts, your clients, your past projects or the way your company phrases things. Documents, catalogues, transcripts and history are indexed into retrieval, with fine-tuning on top where tone and format matter. Answers cite the source document they came from, so staff can verify instead of trusting.
Around that sits the governance that makes it approvable: single sign-on, per-department permissions so finance material is not answerable to the whole company, and an audit log of who asked what.
How it is engineered
The inference layer is built to be replaceable, because the models will be. Weights sit behind a stable internal endpoint, so swapping to a better model is a change of engine rather than a rebuild of everything pointing at it.
Retrieval is the heart of the build rather than a feature bolted on. Material is chunked and embedded with attention paid to document structure, permissions are enforced at the retrieval layer rather than filtered afterwards, and every answer carries citations back to source. An assistant that cannot show its working gets used twice and then abandoned.
The default build has no outbound path for prompts or documents at all. Where a client wants the option of escalating the hardest questions to a frontier model, that is a deliberate, separately approved route with its own logging — never a quiet default.
What it took
The honest finding is that most of the useful work needs a far smaller model than anyone expects. Teams arrive asking for the largest thing that will fit in the rack, and the pilot usually shows that document Q&A, drafting, extraction and summarising run well on something considerably cheaper. That conversation saves more money than any hardware negotiation.
The second is that the data work is the project. Hardware arrives in a week; getting a company’s material into a state where a model can answer from it reliably is the long part, and pretending otherwise sets up a pilot to fail.
And we say plainly where local models lose. For hard, open-ended reasoning the frontier models are larger than anything most companies will rack, and we would rather name that up front than let someone discover it after signing.
This case study describes work in active development.