What sits under the hood regardless of the deployment model
Before comparing the options, it is worth establishing what does not change. An assistant built on company knowledge runs in a repeatable cycle. First you upload material: PDF documents, DOCX files, plain texts, pages, question and answer lists, procedures. The system splits them into fragments, because a model answers better from excerpts than from a hundred-and-something-page document taken whole. Those fragments are turned into a form that can be searched by meaning, that is by the sense of the question rather than by matching words. When somebody asks something, the system finds the matching fragments and builds an answer out of them, citing the source.
That last part matters more than it seems during a first demo. An answer built solely from uploaded material, with a pointer to where it came from, is verifiable. An employee can click the source and see that the assistant did not make anything up, it quoted a two-year-old procedure that needs updating. Without a source, every answer has to be taken on faith, and faith in a system that is occasionally wrong runs out quickly.
The second shared element is the knowledge maintenance loop. Questions the assistant found no answer for do not disappear, they land on a list of gaps, grouped by topic together with a repetition counter. This is the most practical report such a system produces, because it shows precisely what your documentation is missing and what people ask about most often. Closing a gap means writing one knowledge page, with the assistant drafting a proposal based on the collected phrasings of the question, and the page keeps a version history and flags itself for review when related material changes or a set period passes.
Where the real boundary between the options runs
The difference between a hosted deployment and an on-premise one comes down to a single question: where the language model runs and what passes through it.
In the hosted variant everything sits on our side and the model is an OpenAI service. User questions and the knowledge fragments needed to build an answer pass through that service. In the on-premise variant the whole setup sits on the company’s own servers, language model included, and nothing leaves that infrastructure.
Every other difference follows from that one. Answer quality in the hosted version is consistently high, because the vendor’s models are large and maintained by them. In the on-premise version it scales with the hardware you have: on a strong server with an accelerator the difference can be invisible to users, on a modest one it can hurt. Time to launch in the cloud counts from the decision, not from a hardware delivery. Maintenance in the hosted version is on us, in the on-premise one it is on the client’s team, with support when it is needed.
It is worth noting what is not on that list. There is no difference in features, in how the panel looks or in how you work with knowledge. Choosing a variant is not choosing between a full version and a cut-down one.
When the answer is: your own servers
The on-premise variant gets chosen for reasons you can write down on a sheet of paper, not out of a general feeling that it is safer that way.
The first is the nature of the data in the knowledge base. Medical records, case files, personal data inside procedures, test results, technical documentation covered by a confidentiality agreement with a partner: if that is going into the assistant, the question of where the model runs stops being technical. Note that this concerns data in the knowledge base, not data in the company at large. Very often it turns out the assistant is meant to answer questions about internal procedures and the offer only, that is about material you hand to clients anyway.
The second is industry regulation and contract terms. The public sector, finance, healthcare and part of industrial contracting impose requirements under which the discussion about a deployment model ends before it begins. If your largest client’s contract forbids processing their documentation outside a named infrastructure, that is a decision, not an argument in a conversation.
The third is an internal policy you take seriously. If the company has a rule that data does not leave the building, and enforces it in other systems, making an exception for the assistant is a worse idea than running it locally.
When the answer is: the cloud
The hosted variant has one advantage that usually settles the matter in practice: it lets you start before every decision has been made. It requires no hardware purchase, nobody assigned to maintain a model and no capacity planning. If the material feeding the assistant is your offer, price list, product descriptions, user manuals and complaint procedures, that is things you send to customers anyway, then in most cases there is nothing to protect from the model vendor.
There is also an argument that is rarely made out loud. A first assistant deployment almost always changes a company’s idea of what it is actually for. The gap list after two months shows questions nobody predicted in the pre-launch workshop. Learning that on a variant which launches quickly is cheaper than learning it after buying a server.
What no variant changes
A few things are not settled by where the model runs, and they are worth remembering whatever you decide.
Permissions have to be thought through the same way in both cases. An assistant that answers according to the asker’s role needs per-document access set up, split between team and customer and between specific employee groups. Without that, your purchase price list will eventually surface in an answer to a customer, and whose server it happened on will not matter in the slightest.
The same goes for content uploaded into the knowledge base. A document from outside may contain an instruction trying to hijack the model’s behaviour, so material has to be disarmed before it is allowed into an answer. The risk is identical locally and in the cloud.
And finally, documentation quality. The assistant answers from what it was given. A company with scattered, outdated documentation will get an assistant that fluently quotes outdated documentation, only faster than a human would. That is actually good news, because the gap list turns the problem into a concrete task list, but the deployment itself does not fix it.
How to make this decision in practice
Instead of starting from a comparison of the options, write down the material meant to go into the knowledge base in the first stage. Then ask one question about each item: could this document go to a customer or an external contractor. If the answer is yes for every line, the hosted variant is the natural choice and will save you months. If it is no for any of them, work out whether that item can be left out of the first stage, and only then consider running the whole thing locally.
A full description of both models, with terms and pricing, is on the AI assistant page, and everyday work with the panel is shown in the screenshot gallery. If you would like to talk through your own case, get in touch: we start from the list of material, because that is what settles the choice, not the other way round.