Patient records, claims files, personnel data. The contract says where they may go, and a cloud API is not on the list. And the per-token bill grows with every user.
Patient records, claims files, personnel data, tender documents. Your legal team has already said where they may go, and a cloud API is not on the list.
Per-token pricing looks cheap in a pilot. At a thousand users and a document per call, it is a line item nobody forecast.
Models are retired, prices change, a region moves. Your assistant changes with them, on their schedule.
An open model, installed on your servers or your private cloud, tuned for your hardware and connected to your systems. You choose the model, the version and the day it changes.
Three parts: the model and hardware, the serving layer, and the connections.
The right open model for your tasks and your GPUs.
The model as a service inside your network.
The assistant your teams use, on the local model.
Four phases from a list of tasks to a model serving your teams.
The tasks, the data rules, the hardware you have.
Candidates tested on your tasks, on your machine.
Serving, security, monitoring.
Your team runs it.
Compliance by construction, a cost you can forecast, and control of the calendar.
No prompt or document crosses the perimeter. The compliance argument is the network diagram.
After the machine is paid for, a call costs electricity. Heavy use gets cheaper per call, the opposite of an API.
You pick the model version and the day it changes. Retirements, price changes and region moves happen to other people.
| Side by side | Cloud API | Local model |
|---|---|---|
| Where the data goes | To the vendor, under their agreement | Nowhere; it stays on your network |
| Cost | Per token, grows with use | The hardware, then electricity |
| Model changes | On the vendor's schedule | On yours |
| Customisation | Prompting, some fine-tuning | Any tuning, any version, any quantisation |
| Compliance evidence | A contract and a region setting | The network diagram |
It depends on the model size and the number of users at peak. A capable open model for a team can run on one server with a modern GPU; a company-wide assistant needs more. We size it in discovery from your tasks and your expected load, and test on the target machine before you buy anything.
On general tasks, the largest cloud models still score higher. On your tasks, with retrieval from your documents and sometimes a fine-tune, a well-chosen open model reaches the quality your teams need. We measure this on your work in the selection phase, and report the numbers before you commit.
Yes. A local model can be tuned on your examples inside the same perimeter, and served by the same infrastructure. See Fine-tuning AI Models for how that runs.
Open models improve every few months. The serving layer is built so a new version can be tested beside the current one on your tasks, and swapped on a day you choose, with a roll-back. We agree a review cadence at handover.
We are a small team of senior specialists. We pick the right model and the right layer, and we build the least machinery that does the job. You get a call with an engineer, not a sales deck.
