When people say an AI system is “local,” they usually mean something specific and physical: the machine is in the building. It sits on a desk, on a shelf, or in a closet next to the network switch, on the organization’s own power and its own network segment. Nothing about that sentence is metaphorical. It is a description of where a box is.
What “on site” actually means
Exalt local AI hardware is a physical appliance. It is ordered, set up on site or remotely, and connected to the organization’s internal network the same way a file server or a database server would be. It does not live behind a vendor’s login page, and it does not route requests out to a shared service running somewhere else. The system runs the same firewall rules, the same VLAN segmentation, and the same physical access controls as the rest of the organization’s infrastructure, because it is part of that infrastructure.
That has a direct consequence for who can reach it. Access to the appliance is governed by the organization’s own identity systems and network policy, not by a separate account with an outside company. If the building’s network goes down, so does the system. Day to day it does not depend on the public internet to answer. Updates need a connection, and so do any cloud-hosted sources or cloud sign-in the organization chooses to connect.
It also means the organization’s existing IT team is the one who decides who can log in, which internal groups can query which documents, and what gets logged when they do. Those are the same decisions that team already makes for its email system, its document store, and its financial software. Local hardware does not introduce a new category of decision — it puts the AI system inside the categories the IT team already has a process for.
What leaves the building, and what does not
Consider the ordinary case this is built for: an engineer needs an answer from a document the company already owns — a technical manual, a drawing set, a policy binder, a contract. In a cloud-hosted setup, answering that question means the document, or at minimum the relevant excerpts of it, travels somewhere else to be processed, and the question and the answer travel with it. Even with good contracts and good intentions on the vendor’s side, the data has left the building to get an answer.
With the appliance on site, that trip does not happen. The document is indexed on the machine in the building. The question is answered on that machine. The answer is returned on the internal network. When the sources are uploaded to the box or sit on the organization’s own network, no step in that path requires the source material, the question, or the answer to cross the organization’s own perimeter.
- Source documents are uploaded to the appliance or read where they already live, and indexed on the appliance, not sent to an external service to be processed.
- Questions asked of the assistant are processed on the appliance.
- Logs of what was asked and what was retrieved stay in the organization’s own systems, subject to its own retention and access rules.
Why this matters more for some material than others
Not every document is sensitive, and not every organization needs to think hard about where its AI runs. But a lot of the material that makes AI genuinely useful at work — engineering drawings, regulatory filings, unreleased product specifications, internal policy, anything covered by a client confidentiality obligation — is exactly the material an organization has spent years building controls around. Where that material can and cannot travel is usually already answered by an existing policy, a contract, or a regulation. Local hardware does not require rewriting that policy to make an exception for AI. It keeps the AI inside the boundary the policy already draws.
This is also why the question is rarely “is this vendor trustworthy.” It is a simpler, more mechanical question: which systems is this data allowed to touch. A system that runs inside the building, on the building’s own network, under the building’s own access control, is answering that question by construction rather than by policy exception.
It also removes a category of question that a cloud deployment always raises, whatever the answer turns out to be: which jurisdiction the data physically sits in, who else’s infrastructure it shares, and what happens to it if that vendor is acquired, breached, or simply changes its terms of service. None of those questions disappear because a contract addresses them well. They disappear because there is no second party’s infrastructure in the path of a day-to-day answer to ask the question about.
The system answers the access-control question by construction, not by policy exception.
What this does not mean
Local hardware is not a claim that nothing can ever go wrong on the organization’s own network — internal systems still need access control, patching, and monitoring like any other server. What it changes is the number of parties involved. Day to day, the document, the question, and the answer stay inside one boundary that the organization already manages, instead of also depending on a second party’s infrastructure, a second party’s uptime, and a second party’s handling of the data in between. Updates need a connection, and so do any cloud-hosted sources the organization chooses to connect.
Where this fits
The appliance is designed to be configured around a specific set of documents and a specific set of questions, not deployed as general-purpose infrastructure and left for teams to figure out. For the engineering and technical detail on what the hardware itself comprises, see the hardware overview, and for the specific access-control and audit-logging behavior, see how access control is enforced. For a look at how a locally hosted deployment differs in practice from a cloud one, see the models that run on the box.
The practical starting point is usually not a hardware specification at all. It is the list of documents an organization already has and is not comfortable sending outside its own walls. That list is what a consultation is for — working out which of those documents the system should be configured around first.