Infrastructure Your hardware Your network No per-token bill

On-premise AI.
It never leaves.

An on-premise deployment puts the model on hardware you own, on your network, behind your firewall. The reason it resolves so many conversations at once is simple: there is no egress path for the data to take, so a whole category of question stops needing an answer.

WHAT CHANGES WHEN THERE IS NO EGRESS

A hosted AI service is, in most configurations, a processor you have sent your data to. That is workable — the paperwork exists and is routine — but it puts a permanent set of obligations in place: a transfer assessment, a sub-processor list, a retention position, a deletion path, and an annual review of all of them. Each is a conversation, and each recurs.

On-premise removes the premise rather than the paperwork. If the model runs on a server in your building and the network has no route from it to the internet, then there is no transfer, no third-party processor in the AI path, no sub-processor list to maintain, and no retention question about somebody else's logs — for the AI component; the rest of your processing record is unchanged. The security review changes from can we trust this vendor with our data to is this server configured correctly, which is a question your team already knows how to answer.

The second change is economic and it compounds. A hosted API charges per token forever. Hardware is bought once and then costs electricity. That means a workload that is uneconomic to automate at API prices — reviewing every document rather than a sample, embedding an entire archive, running an agent over the whole backlog — frequently becomes economic the moment marginal cost approaches zero. In our experience the most valuable consequence of going on-premise is not the saving on existing usage. It is the work you start doing because it no longer costs anything per unit.

THE BUSINESS BENEFITS, PLAINLY

Confidentiality that is structural

Not a contractual promise from a vendor but a property of the network topology. Legal, M&A, R&D, HR and board material can go into an AI system when the system cannot transmit them anywhere. For a great many organisations this is the difference between using AI on their real work and using it on the safe subset.

Marginal cost near zero

Once the hardware is paid for, an extra million documents costs electricity. Budgets stop being usage-linked, which removes the quiet organisational pressure to use the system less — a pressure that silently caps the value of every per-token deployment.

No deprecation risk

You run the model version you chose, for as long as you choose. Nobody retires it, reprices it or changes its behaviour underneath a system you have validated. For anything that went through a formal qualification, this is worth more than a capability point.

Latency you control

No internet round trip, no shared queue, no noisy-neighbour variance. For interactive features the difference is felt directly by users, and it is stable rather than dependent on somebody else's traffic that afternoon.

It works when the line is down

A factory, a hospital, a ship, a site office. If the AI is load-bearing in an operational process, a dependency on an internet connection is a dependency you may not be able to accept.

A defensible answer

“The data does not leave our premises” is a sentence that answers a large part of a customer security questionnaire, a regulator's line of questioning and an internal risk objection. Nothing else in this field is as easy to explain to people who are not technical.

WHAT IT ACTUALLY INVOLVES

ON-PREMISE STACK

GPU node

sized to model + concurrency
Serving layer

vLLM · batching · KV cache
Retrieval

pgvector on your DB
Application

your systems, your auth
Observability

traces · cost · drift
Frontier escalation

optional, gated, redacted

Solid: everything on your hardware Dashed: the optional gated exception

Every component runs inside your perimeter. The escalation branch is optional and, where it exists, is the only path out.

WHERE WE WOULD TELL YOU NOT TO

Low or spiky volume. Hardware you have bought is expensive when it is idle. If your usage is a few thousand requests a month, a hosted API is cheaper by a wide margin and will remain so. We would rather say that at the first meeting than at the retrospective.

Nobody to operate it. This is a running commitment: patching, monitoring, capacity, upgrades, someone reachable when a GPU fails at three in the morning. If there is no team and no appetite to buy that as a service, an on-premise deployment will degrade, and a degraded AI system is worse than none because people stop trusting it in ways that persist.

The hardest agentic workloads only. If every request needs the absolute frontier of capability and none of your data is sensitive, you are paying for control you do not need at a capability cost you will feel. Hybrid routing exists for exactly the common middle case where that is true of some requests and not others.

If any of those describe you, the right recommendation is one of the other four deployment models, and we will make it. A client with the wrong infrastructure is a support problem for years.

QUESTIONS

QUESTIONS — 5

It depends on the model size and how many people use it at once, and both are knowable in advance. A single well-specified GPU server handles a mid-size open model for a substantial number of internal users; larger models or higher concurrency need more memory rather than fundamentally different infrastructure. We size it from your workload before you procure anything — see GPU sizing and cost for the arithmetic.

Any open-weight family whose licence permits your use — DeepSeek, Llama, Mistral, Qwen and the small models; the licences differ per model, so read the one you intend to deploy. The leading closed models are generally not available for self-hosting, and where a vendor offers a private deployment it is under contract and at a price most organisations will not pay. For most production workloads the open families are close enough that the difference should be measured rather than assumed.

We scope four to ten weeks to a working pilot on your hardware, with the range driven mostly by procurement and network access rather than by the build. If the hardware already exists, the shorter end is realistic. That is a design target we plan to, not a measured client outcome.

Yes, and it is often the sensible order — prove the use case on an API, then move it in-house once the volume justifies the hardware. It only works if the system is built for it from the start, with the model behind an interface and no dependency on a provider-specific feature. We build that way by default because retrofitting it is genuinely painful.

Yes. The hardware and the code remain yours; we operate it under a support arrangement, or hand over with runbooks if you would rather your own team ran it. There is no component only we can maintain, which is the property that makes the choice reversible.

Keep reading

Air-Gapped Deployment

→

30-minute technical call · no deck