Genuinely air-gapped compliance software must satisfy four things: it makes no outbound connection of any kind (enforced inside the software itself); its licensing does not phone home; it does not depend on a hosted AI service for correctness; and the evidence it produces can be verified with no network at all, years later. Most GRC platforms fail at least two of these, usually licensing and evidence, because their commercial model requires a connection. The right test is not to read the datasheet — it is to run the software on an isolated machine and watch what it tries to do.
Why air-gapped is its own category
There is a persistent assumption in software procurement that on-premise deployment is a legacy preference held by conservative buyers who will eventually come round. For a substantial set of organisations that is simply wrong. A defence supplier operating under contractual isolation requirements, a government body handling classified material, or a financial institution whose data residency is fixed by regulation or group policy is not expressing a preference. Those organisations cannot install a cloud tool at all, whatever assurances accompany it.
This creates an odd market condition. The organisations with the heaviest compliance obligations are frequently the ones least able to buy compliance tooling — because the tooling assumes it may upload the very data whose movement is the thing being regulated.
The four tests
1. Does it make outbound connections — and how do you know?
The claim that matters is not "no telemetry is enabled by default." It is that reaching the network is not a setting anyone can flip, forget, or ship a regression into. Look for an enforced offline mode: something the software does at startup that constrains what it may contact, rather than a configuration checkbox. Then look for whether refusals are recorded. A system that silently drops an outbound attempt tells you nothing; a system that writes every blocked attempt into an audit record lets your security team read what it tried to do.
"Show me the software attempting a network call and being refused, and then show me where that refusal is recorded." A vendor with a genuine egress control can demonstrate this in minutes. A vendor relying on your firewall will change the subject to their security policy.
2. Does the licensing phone home?
This is the test most vendors fail, and it fails quietly — everything works during the trial and then a licence check fails eighteen months later on a machine that has never had a route to the internet. Ask directly how entitlement is verified. The only answer that works on an isolated network is a signed licence file verified locally against a key embedded in the software, with no activation call and no periodic re-validation. Anything involving a licence server, a seat check or a heartbeat is not air-gapped software, regardless of how the rest of it is deployed.
3. Does correctness depend on a hosted model?
Compliance tools increasingly use language models to read documents, which is a reasonable use of them. The question is what happens to the tool's guarantees when that service is unreachable. If the vendor's validation logic is a prompt, then offline the product does not degrade — it stops being trustworthy. What you want is a clean separation: models used for extraction and drafting, and deterministic code for anything that decides whether a filing is correct. Then offline mode costs you convenience rather than assurance.
4. Can the evidence be verified with no network?
This is the test people forget, and it is the one that matters longest. Compliance evidence has a life measured in years, and it is examined at the worst possible moment — during a supervisory review, an incident investigation, or a dispute. If verifying your audit trail requires logging into a vendor's portal, then your evidence has a dependency on that vendor's continued existence, your continued subscription, and your network reaching them at the moment of examination.
Evidence that verifies offline usually means hash chaining: each record's hash covers the previous record's hash plus the record's own canonical content, so altering any historical entry breaks every hash after it. The property that makes this valuable is that checking it is pure arithmetic — anyone with the files and a hashing tool can do it, on any machine, forever, with no service involved.
Why most platforms cannot follow
It is worth understanding why this gap persists rather than assuming vendors are simply not trying. A SaaS company's delivery model, billing model and product telemetry all assume a connection. Usage-based pricing needs a meter the vendor can read. Continuous delivery assumes the vendor controls the running version. Support assumes access to logs. Removing the connection does not remove a feature — it invalidates several of the business's core mechanics at once. That is why the capability tends to come from companies that designed for it early rather than from incumbents adding a deployment option.
It also explains a pricing difference you should expect: air-gapped editions are usually licensed by capacity per year rather than metered per outcome, because metering requires the connection that has just been removed.
What you give up, honestly
An air-gapped deployment is not free of trade-offs, and a vendor who claims otherwise is selling rather than explaining.
- Updates are your logistics. New versions arrive through your transfer process and are verified by hash. There is no automatic update, which is the point, but it does mean patching is a process you own.
- Document-reading convenience drops. Where a connected deployment can use a model to read unstructured contracts, an offline one leans on structured inputs and more of your team's reading.
- Anything that is genuinely an online act stays online. Submitting to a tax authority over an API cannot happen from an isolated machine. Good software prepares and validates the submission offline and is honest that the transmission itself occurs elsewhere.
- Support is slower. Your vendor cannot look at your logs. Expect to exchange evidence bundles rather than grant access.
A short procurement checklist
- Run it on an isolated machine during evaluation. Do not accept a hosted demo as evidence of offline behaviour.
- Ask your network team to monitor it during a full run and report what it attempted.
- Verify the published hash of the delivered binary before it executes.
- Confirm entitlement is a locally verified file, and ask what happens at renewal.
- Take an evidence bundle away and verify it on a machine that has never touched the vendor's software.
- Ask what the sub-processor list is. For a true air-gapped edition the honest answer is that there is none.
- Ask what happens to your evidence if the vendor ceases trading — and whether source escrow is available.
How Qgentic approaches it
The Qgentic air-gapped edition is the same engine as our connected editions with its network reach removed rather than a reduced build. Started in air-gapped mode it forces deterministic processing and arms an in-process egress guard that refuses every outbound request except your own configured data feed, writing each refusal to an audit chain. Entitlement is an Ed25519-signed licence file verified against a public key compiled into the binary — no activation server, no heartbeat. Every action lands in a SHA-256 hash chain your auditor can re-verify offline, on their own machine, with no Qgentic service involved. And a named person in your organisation approves every filing, on this edition exactly as on the others.
We would rather your security team tested all of that than believed it, which is why the evaluation starts by running the software on your hardware.
Verify the hash, read the allowlist, watch the silence, re-verify the chains. Then decide.
The air-gapped edition Security & evidence