When a software vendor tells you your data is private, they usually mean it is encrypted and permission-gated on their servers. That is a security posture, not a location. The difference decides who can ultimately read your files, and what happens to your records when the vendor changes hands.
Three parts, in plain words
A private deployment has three components, and none of them are exotic.
A model endpoint is a program on a server that takes text in and returns text — the same category of thing you talk to when you use ChatGPT. Openly available models have become good enough that this program can run on a single machine in your building, or on a server rented in your company's own name.
A document index is your files converted into a searchable form. Every contract, manual, price sheet, and job record gets read once, cut into passages, and stored so a question can be matched against the passages that bear on it in a fraction of a second. Think of a filing cabinet staffed by a clerk who has actually read everything in it.
An ingest pipeline is what keeps the index current. When a new document lands in a watched folder, it gets read into the index the same way the originals were.
When all three run on hardware you control, the question "where does my data physically sit" has a literal answer: an address. A machine in the office closet. A rack in a data center under your own lease. A cloud server inside your company's own account. Not a shrug, and not a paragraph about industry-standard encryption.
Follow one question through the building
Say your office manager asks the system whether a service agreement covers a compressor replacement on a unit that's past its parts warranty. The question travels across your local network to the endpoint. The index pulls the two or three passages — from the agreement and from the warranty — that actually bear on it. The model reads those passages and writes an answer that cites them, page and section.
At no point did the question, the agreement, or the answer cross your internet connection. That is not a figure of speech: you could unplug the router first and get the same answer. That test, run in front of you on your own documents, is the cleanest working definition of private this page can offer, and it's a test worth demanding from anyone who uses the word.
The one question that sorts vendors
Ask any vendor — us included — this: "Where does my data physically sit, and who besides my own staff can read it?"
A straight answer names a place and lists people. "On a server in your office." Or: "In our cloud account, in a named region, accessible to these roles under these conditions, and here is the list of other companies our service passes data through." An evasive answer talks about encryption. Encryption in transit and at rest is table stakes — every serious vendor has it — and it tells you nothing about who holds the keys or how many copies of your documents exist. A vendor who cannot answer with a place has, in a sense, answered.
What private does not mean
It does not automatically mean safer. A server in a closet with a default password and two years of missed updates is a worse home for your records than a competent cloud vendor's infrastructure. Private moves responsibility onto your side of the wall; it does not shrink it. Backups become your problem, and so do updates. The lock on the server-closet door is now part of your security model. An honest deployment settles, in writing, who owns each of those jobs — your own staff, or a maintenance arrangement you pay for with eyes open.
It also costs more up front. Cloud tools spread their cost into a monthly seat fee; a private deployment concentrates it into hardware or a dedicated rental, plus the build itself. For some businesses that trade is obviously right. For plenty of others it isn't, and the next section is about them.
When cloud is honestly the right call
If the documents involved are already public, or would be harmless in a leak — marketing drafts, published price sheets, the spec sheets any customer can request — cloud tools are cheaper and entirely adequate. If nobody in the business will own a server, and there's no appetite to pay someone who will, then a private box becomes a liability on a shelf, quietly missing updates. And some vendors' written terms really are acceptable for some kinds of data. The point of this page is not that cloud is bad. It's that the decision should come from the terms and the location, read plainly, rather than from the word "private" in a headline.
If your records have rules attached
For medical, dental, and legal practices, one thing has to be said carefully. Keeping records on infrastructure you control is a strong starting point for a compliance conversation, because it makes the basic questions — where do records live, who can touch them — answerable in plain terms. It is not a substitute for that conversation. No architecture makes a practice compliant with anything by itself, and anyone who implies otherwise should worry you. Before regulated records move into any system, ours included, your compliance officer or your counsel belongs in the room.
Where to start
Write down the five documents you would least want sitting on someone else's server. If nothing comes to mind, you probably don't need any of this — pick a cloud tool whose terms you've actually read and move on. If the list writes itself, bring it to the first conversation you have with anyone, because those five documents are what the whole architecture should be designed around.