Choosing an open source LLM does not make your deployment private. Privacy comes from where the model runs and what surrounds it. Open weights let you host a model yourself, which is the precondition - but data still leaves through hosted inference, hosted embeddings, tooling telemetry and third-party databases unless each one is closed deliberately.
Open weights and privacy are two different things
The most common misunderstanding in this whole topic is treating "open source model" and "private deployment" as the same statement. They are not related in the way people assume. An open model is one whose weights you can download and run. Privacy is a property of the system you build with it: which machines process the data, which networks it crosses, and who can read the logs afterwards.
You can run an open model through a hosted API and send every prompt to a third party. You can also run a closed vendor's model inside a private cloud tenancy with contractual guarantees. Neither arrangement matches the slogan. Open weights simply give you the option of hosting it yourself, and it is that option - not the licence - that does the privacy work. Our guide to the best open-source LLMs for business covers picking the model; this page is about the system around it.
What an open source licence does and does not cover
Licences govern use, redistribution and modification. They say nothing about your data, because your data was never the licensor's to make promises about. A permissive licence does not mean data is safe, and a restrictive one does not mean it is at risk. Terms also vary between releases from the same vendor and can change between versions, so read the licence text published for the exact release you intend to run and get anything commercially load-bearing confirmed in writing.
The separate question worth asking is what the model was trained on, because that affects output risk rather than input privacy - whether it can reproduce material you would rather it did not. Keep the two apart when you brief a security review, or the conversation collapses into the wrong argument.
The four places data still leaves
In practice, almost every "private" deployment that turns out not to be private leaks at one of four points. Walk them in order.
Hosted inference of an open model. Plenty of providers serve open models through an API. That is a legitimate and often sensible choice, but the prompt goes to their infrastructure. Whether it is retained, logged or used for anything else is a contractual question, not a property of the model being open.
Hosted embeddings. This is the quiet one. To make documents searchable, every passage is converted by an embedding model. If that step calls a hosted API while the language model runs locally, your entire document set has already left the network before anyone asks a question. We cover the document side of this in running a local LLM over confidential documents.
Telemetry in the tooling. Serving frameworks, UI layers, agent libraries and observability tools often ship with analytics, crash reporting or update checks enabled by default. Most are harmless metadata; some include prompt content. Read the configuration rather than assuming.
Third-party stores and monitoring. A managed vector database, a hosted logging service or a prompt-tracing tool can hold the same content as the documents themselves. Treat every one of them as part of the privacy boundary.
Want to know whether your AI setup is actually private?
We trace the whole path - inference, embeddings, tooling telemetry and any third-party store - and give you a plain list of what leaves your network and what it would take to stop it.
Talk to an On-Premise AI SpecialistPrompts and logs are the data nobody budgets for
Once the pipeline is closed, the remaining exposure is usually internal. Prompts quote the documents they are about, so a log of prompts is as sensitive as the source material, and the default in most tooling is to keep them indefinitely. Answers carry the same content back out. Anyone who can read the logs can read the underlying material without ever touching the file store or its permissions.
Decide three things explicitly before go-live: how long prompts and answers are retained, who may read them, and what happens to indexed content when the source document is deleted. If the answer to the third is "nothing", you have built a system that can quote a document you believe you removed. Teams under European data protection rules will find the documentation side of this covered in our notes on GDPR-compliant AI deployment.
Self hosted LLM privacy checklist
The short version, in the order it is worth checking. Where does inference run, on whose hardware? Where do embeddings run? What telemetry is enabled in every component, by default? Which third-party services hold prompts, documents or vectors? How long are prompts, answers and traces kept, and who can read them? Who is allowed to query which documents, and is that enforced at retrieval rather than in the interface? Does deleting a source document remove it from the index?
Seven questions, and a vendor or internal team that cannot answer all seven without checking is telling you something useful. The on-premise AI page explains how a fully self-hosted deployment is run and maintained, and self-hosted LLMs for business covers the operational side.
Who can ask what, and what the model can say back
Two exposures survive a perfectly closed network, and both are about people rather than infrastructure. The first is retrieval permissions. A search system considers whatever is in its index, so if documents are indexed without carrying their source permissions across, everyone with access to the chat box effectively has read access to everything in it. That has to be enforced when the question is asked, filtering candidate passages before they reach the model, rather than hidden in the interface.
The second is what the model is allowed to do with what it finds. An agent that can read a system is one design decision away from being able to write to it, email from it, or summarise restricted material into a channel where the restriction no longer applies. Scope the permissions of the agent itself as carefully as those of a new employee, and log its actions the same way. Privacy work that stops at the network boundary leaves both of these open.
When hosting it yourself is the wrong call
Self-hosting is not automatically the responsible choice. It moves the risk rather than removing it: patching, access control, backups and physical security become yours. A small team running an under-maintained server with broad internal access is not more private than a well-governed hosted arrangement with a proper data processing agreement - it just feels like it.
The deciding factor is usually whether the data is genuinely restricted and whether you have someone to own the infrastructure. If both are true, self-hosting is the honest answer. If only the first is, a private tenancy with contractual guarantees may serve you better while you build the capability. Our comparison of ChatGPT Enterprise versus an on-premise LLM sets out that trade-off, and the on-premise versus cloud AI cost comparison covers the money.
Getting started
Draw the data path before choosing a model. One diagram, every hop, and a note against each saying whose machine it is. The hops that leave your network are your decision list; the model is a detail you can change later. Close inference and embeddings first, then telemetry, then logging and retention.
Inwizards has been building software since 2009 and deploys self-hosted AI systems from teams in the US, UAE and India. The on-premise AI page covers private deployment, AI agent development covers what gets built on top, and AI agents explains the workflows this infrastructure usually ends up serving.