Most AI products work by sending your material to somebody else’s computer. For a lot of organisations that is a perfectly reasonable trade. For a lot of others it is not a trade they are allowed to make at all, and for the rest it is a trade they make without quite noticing what they are handing over. We build for the second and third groups, which means we build for on-premise first and treat the cloud as an option rather than the default.
The promise that can be undone by a config change
Every hosted AI vendor will tell you your data is safe. Most of them mean it. The problem is not the sincerity of the promise; it is the kind of promise it is. A policy is a decision that somebody made and that somebody else can unmake — in a retention setting, a subprocessor change, a new terms update that arrives by email on a Tuesday. You do not get a vote.
A system with nowhere to send your data is a different kind of promise. It is not that the vendor has agreed not to look. It is that the wire is not there. We think of this as private by architecture rather than private by policy, and it is the reason the products on this site are built to run on a machine in your building, with a model installed on it, and no outbound call in the path.
What you actually hand over when you use hosted AI
The conversation about data privacy usually starts with regulation and personal data, and those matter. India’s data protection law, and its equivalents elsewhere, put real obligations on anyone processing personal information, and “we sent it to an API” is not a defence.
But the larger exposure for most enterprises is not personal data. It is the material that makes them a business: contracts, pricing, correspondence with customers, the internal know-how that lives in email threads and shared drives. An assistant that reads your inbox to draft replies has read your inbox. An assistant that answers questions about your documents has your documents. Whether that is acceptable depends entirely on whose machine it is running on.
What on-premise costs you, honestly
It would be dishonest to present this as a free choice. It is not.
- The strongest hosted models are usually a step ahead of the strongest open ones. Some tasks will be done slightly less well on your own hardware than they would be through a frontier API. For most enterprise work — summarising, drafting, retrieving, classifying — the gap is not the deciding factor, but it exists.
- You own the hardware and the upkeep. A GPU workstation or a rack is a capital cost and somebody has to look after it. Against that, there is no per-token bill and nobody can deprecate the model you built your process around.
- Getting started is slower. A hosted API is an afternoon. A private deployment is a project. We size models to the hardware you actually have rather than the hardware a vendor would like to sell you, and the toolkit we use for video enhancement runs on a single GPU laptop, but it is still more work than pasting a key into a config file.
For an organisation whose data cannot leave, none of that is a trade-off, because the alternative is not available. For everyone else, it is a judgement about what the data is worth, and we would rather you made it with the costs in view.
What we do about it
Everything we build deploys on infrastructure you control. The email assistant runs on your server against your own storage. The document and video search runs against your own backend. The news archive agent runs inside the newsroom. Where the environment is strict enough, the whole thing runs against a locally hosted model with no external network dependency at all — the configuration we describe as a private AI box.
You also get the deployment itself: the documentation, the ability to inspect what the system does, and a team that knows how to keep it running. We build to hand over rather than to create a dependency, because a dependency is just another kind of policy you cannot vote on.