Vendors in this market have learned to say on-premise, because buyers ask for it. The word covers two very different architectures. In one, the application runs on your hardware and the analytical work is done by a model reached over the internet. In the other, everything that touches evidence runs inside your perimeter, including the models, and the deployment functions with no route out at all.
Only the second survives contact with a genuinely sensitive environment, and it is a materially harder engineering problem. Understanding where the difficulty sits is what allows a buyer to tell a real air-gapped product from a hosted one with a local front end.
The question that separates the two
There is a single test, and it takes one sentence to administer: disconnect the network and show me the workflow.
A platform built for air-gapped operation behaves identically. Ingestion runs, transcription runs, correlation runs, the graph builds, the analyst queries it in natural language and gets an answer. A platform that depends on external inference degrades immediately, usually in the parts a demo made look most impressive. The transcript stops arriving. The plain-language query returns nothing. The document summary that appeared instantly during the sales call now hangs.
Most evaluations never run this test, because it is inconvenient to arrange and because the demo environment is always connected. It is worth insisting on. Every other question about sovereignty, data transfer, and model provenance is downstream of the answer.
What the constraint costs, honestly
Running everything locally is not free, and a vendor who claims otherwise is not being straight. Three costs are real.
The first is hardware. Language models, vision models, speech recognition, face and voice comparison all want GPU, and the sizing depends on the volume the unit actually processes rather than on a generic recommendation. An agency ingesting a handful of devices a week has different requirements from a national unit processing hundreds of terabytes a year. Any credible proposal states what hardware the deployment assumes and what throughput that hardware delivers, in the units the buyer cares about: hours per device, not tokens per second.
The second is model capability. The frontier models available through an API are larger than anything that will run on a rack in a police facility, and on some tasks the difference is visible. The honest position is that this matters much less than it sounds for investigative work, because the tasks are narrow and grounded. Extracting entities from a bank statement, transcribing a call, matching a face across two images, resolving whether two account references are the same account: these are bounded problems where a well-chosen local model, tuned to the document types and languages of the deployment, performs at or above a general-purpose remote one. The tasks where scale wins are open-ended generation, which is not what a case file needs.
The third is upgrades. An air-gapped system cannot pull a new model version, so improvements arrive as physical media or through a controlled transfer, on the agency's schedule and with the agency's testing. This is a genuine operational burden. It is also, for most units in this space, a feature: nothing about the analytical behaviour of the system changes underneath a live case without someone deciding it should.
Reproducibility becomes a legal property
The reason the upgrade question is not merely operational is that a case can take two years to reach court, and the analyst may be asked to explain a finding produced eighteen months earlier.
If the model that produced it was a remote endpoint, the version behind that endpoint has almost certainly changed. Re-running the same input will not necessarily reproduce the same output, and nobody at the agency can say what changed or when. That is an awkward position to be in under cross-examination, and it is structurally unfixable by the agency because the thing that moved was not theirs.
A local deployment can pin the model, record which version produced which finding, and reproduce that finding on demand years later. Model version becomes part of the evidential record in the same way that tool version has always been in digital forensics. This is not a theoretical advantage. It is the difference between answering the reproducibility question and conceding it.
Evaluating on your own data, in your own room
None of this can be established from a specification sheet, which is why the pilot design matters more than the product comparison.
Run it on real case material, inside the environment where it would actually live, on hardware comparable to what would be bought. Use messy sources rather than clean ones: the device extraction with a corrupted section, the scanned bank statement, the call recording with two speakers over background noise, the document in a language the model was not obviously built for. Time the full ingestion of a realistic case, not a curated file. Then ask an analyst who was not part of the procurement to find something in it and watch where they get stuck.
Ask, too, what the system does when it is unsure. A platform that returns a confident answer to a question the evidence cannot support is a liability regardless of where it runs. The behaviour to look for is a system that says the evidence does not establish this, and shows what it does establish. That property is independent of deployment model, but an air-gapped evaluation is the only setting where a buyer sees it on their own material rather than on a vendor's.
The agencies that get the most out of this technology are not the ones that picked the biggest model. They are the ones that verified, on their own evidence and with the network unplugged, that the workflow holds together.