Ask three vendors whether their AI is “local” and you can get three answers that all sound like yes. For example, one might mean the model runs on a machine in your building. Another might mean your data is stored in a cloud region in your country. A third might mean a dedicated instance in the vendor’s own data center, with a contract that says your data is not used for training. Words like “local,” “on-prem” and “private” carry a lot of weight in these conversations, and none of them has a fixed meaning. This post offers a more precise vocabulary: four questions that describe any setup, three common arrangements, and the questions worth asking before you sign.
Four questions instead of one word
“Local” is a summary. The details underneath it are what your security team, your auditors and your contracts actually care about. Four questions cover most of them.
- Where does the model run? On hardware inside your network, or on a vendor’s servers that your questions travel to?
- Where are documents stored and indexed? The index is the searchable map a system builds from your material. It can sit next to the model or somewhere else entirely.
- What crosses the network boundary day to day? Not in theory and not during setup: on an ordinary Tuesday, what leaves your network and what comes in?
- Who can reach the system after it is installed, and how does it change? Support access and updates are how a vendor keeps touching a system once it is running.
A setup where the model runs on site but the index lives in a vendor’s cloud is not the same as one where both sit in your building, even if both are sold as local. Answer the four questions and the label starts to matter less.
Connected: on site, with known doors
In a connected setup, the model runs on hardware at your site, and questions are answered there. Documents uploaded to the system are stored on it, and sources on your own network, such as file shares and databases, are read where they already live. The day-to-day work of answering a question does not need the internet.
The system still has a connection, and a few things use it. Updates arrive over it. If you connect a cloud-hosted source, such as a document library kept in a cloud service, the system reads that source over a connection to the service. If people sign in through a cloud identity provider, sign-in needs a connection to that provider. Support may use the connection too, depending on how the vendor provides support and who controls access.
None of that makes a connected system less local in the sense this post uses: the model and the index are in your building. It does mean “local” should come with a list of what crosses the boundary, when, and who decides.
Behind an air gap: no outside connection
An air gap means the system has no connection to outside networks. There is no network path in from the internet and no network path out. Some organizations need that for specific material or specific environments. Whether they do is decided by the rules the organization is held to and its own risk decisions, not by the vendor.
The trade-off is that everything a connected system gets over a connection has to arrive some other way. Updates are the obvious one: they have to reach the system without a network path. That route should be agreed and written down before the system is installed, not improvised the first time an update is due. Sources change too: a system with no outside connection can only read material stored on it or on the isolated network it sits in, and a cloud identity provider is off the table.
If a vendor says its product can run behind an air gap, the useful follow-up is simple. How do updates reach it, and what stops working?
In between: local processing, cloud by choice
Many deployments sit between those two. The model runs on site and questions are answered there, but the organization chooses to connect some things that live in the cloud. A team whose shared documents already sit in a cloud document service may want those documents in the answers. A company that already signs everyone in through a cloud identity provider may want the AI system to use the same sign-in.
Those are reasonable choices, and each one changes what crosses the boundary. Reading a cloud-hosted source means the system connects to that service to read it, as often as it is set to. Using a cloud identity provider means sign-in depends on a connection to that provider. The processing is still local. Some of the material, and the sign-in, are not.
No one arrangement is right for everyone. What matters is that each connection is something someone chose, knowing what it means, rather than a default nobody noticed.
Every connection should be a decision someone made, not a default nobody noticed.
Questions to ask any local AI vendor
These work whether the product is a box, software for your own servers, or a hosted service described as private. Ask for the answers in writing.
- Where are questions processed? On hardware in your network, or sent to a service somewhere else to be answered?
- Where is the index stored? If the model is local but the index is not, the searchable copy of your material lives somewhere else.
- Is anything sent out for answering or training, and who decides?
- What needs a connection? Ask for the whole list: updates, cloud-hosted sources, sign-in, support, and anything else.
- Who can reach the system for support, and who controls that access? Is it open all the time, or opened for a session by your own admin? Are sessions logged?
- How are updates applied? Who applies them, when, and by what route? What changes if the system has no outside connection?
- What stops working if the connection goes down? The answer tells you what actually depends on it.
A vendor that answers these plainly has filled in the four questions from the top of this post. A vendor that answers with the word “local” again has not.
Where Exalt local AI hardware sits
On Exalt local AI hardware, questions and answers are processed on the box, not sent to an outside AI service. Exalt support connects only when your admin opens access, and every session is logged. On a connected box, updates are applied during those sessions. Cloud-hosted sources and a cloud identity provider need a connection only if you choose them. The box can also run behind an air gap if you need it to, and how updates reach it is agreed for your deployment. The full list is on what crosses the wall, the models are on the models that run on the box, and a consultation is where your own network rules get mapped against both.