Offline & Air-Gapped AI

Does an Offline AI Assistant Really Work
With No Internet Connection?

What actually keeps working with the network gone, what quietly stops, and the three-state test that separates a truly air-gapped deployment from one that merely tolerates being offline.

Built from real buyer questions in our sales meetings

Switch the network card off and ask your AI assistant a question. What happens next tells you almost everything about what you bought. A cloud assistant goes silent, because the intelligence was never on your machine; a genuinely local assistant keeps answering, because it was. AirgapAI is built for the second outcome, and executives evaluating it ask one question before almost any other: does it really work with no internet connection?

Direct Answer

Yes for answering; no for anything that needs fresh information. A genuinely local assistant keeps responding with the network adapter switched off, because everything inference needs — the model weights, the embedding step, the retrieval index — lives on the machine itself. Iternal builds AirgapAI to run 100% local on the laptop and keep working with the network card turned off.

The limit: nothing refreshes itself. With no network, the assistant cannot open a browser, cannot fetch a public document, and cannot answer about anything newer than the loaded model's training cut-off. Its data set has no way to know the source content changed. Keeping models and data sets current is work your team owns, and the first model load reaches the machine over a network or from removable media, because the installer does not bundle a model.

What leaves the machine is a short list you can verify. Inference never leaves the device. The one outbound behavior is an optional update check, which can be switched off entirely or pointed at a file server inside your own network. Licensing adds nothing to the wire: the license key AirgapAI issues is verified on the device itself, against a public key built into the application, so there is no activation server and no phone-home. Put each of those on your security questionnaire — Iternal answers the targeted questions below in writing.

Offline-tolerant and air-gapped are different standards. Offline-tolerant means the product survives losing the network; fully air-gapped means the machine never has a route out at any point in its lifecycle. AirgapAI is designed to operate either way, and what survives the loss of connectivity is set out below. For more information on where the software installs, visit the placement decision; for what happens to what you type, visit the data-retention page.

What Keeps Working When the Network Is Gone

The reason a local assistant survives losing the network is architectural, not a feature toggle. Everything inference needs — the language model's weights, the embedding step that turns your question into a vector, and the retrieval index built from your loaded data sets — lives on the device's own disk and runs on its own silicon. There is no round trip to score, so there is nothing for a dead connection to interrupt.

In practice that means the things people actually do day to day keep working: asking questions of the loaded model, searching and chatting against the data sets already on the machine, and running saved workflows. Iternal states it plainly: AirgapAI runs 100% local on the laptop and keeps working with the network card turned off — a claim you can reproduce on your own hardware during evaluation, and Iternal encourages exactly that test. Iternal originally designed AirgapAI for the U.S. military, where disconnected operation is the entry ticket.

Fully Air-Gapped, Offline-Tolerant or Cloud-Dependent: The Three-State Test

“Air-gapped” gets used loosely in AI marketing, and the looseness is where evaluations go wrong. Buyers ask whether the product can still touch the firm's own server, whether local installation alone keeps it walled off, and whether results can be moved out of a sealed environment. Each is a version of the same underlying question: which of three states is this deployment actually in? The table below separates the three and gives you the test that proves each one:

State What it means The test that proves it
Cloud-dependent Inference happens on someone else's machines. The app on your device is a window, not an engine. Disable the network: answering stops entirely.
Offline-tolerant Inference runs on the device, but the deployment expects to touch a network occasionally — the first model download, an optional update check. Disable the network after setup: everything already loaded keeps answering; nothing new arrives.
Fully air-gapped The machine never has a route out. Install files, models, data sets and updates all arrive by removable media or a file server inside your own network. Install, load a model, add a data set and take an update — with no route to the internet at any point in the lifecycle.

The last row is the demanding one, and it is the one to get in writing before you buy. A product can be genuinely local at inference time and still assume connectivity at install or update time — that makes it offline-tolerant, which is enough for a five-hour flight and not enough for a closed-loop classified network. AirgapAI operates in the fully air-gapped state — the license key it issues is verified offline against a public key baked into the application, and updates can be served from an internal file server. The first model load still has to reach the machine from somewhere, because the installer does not bundle a model: plan that transfer as part of deployment.

What Still Requires a Network — and What Does Not

Four things genuinely cannot happen on a machine with no route out:

  • The first model load. The model does not ship inside the installer — the right model depends on the user's device — so it reaches the machine over some network once, or by removable media.
  • Refreshing a data set when its source changed. Running offline, the app has no awareness that source content changed; a data set is rebuilt and re-loaded by a person.
  • Keeping local models current. Described as left to the customer; new model versions arrive the same way the first one did.
  • The application update check. An optional outbound call — the next section turns its exact behavior into questions Iternal answers in writing.

One thing conspicuously absent from that list: license activation. AirgapAI does issue a license key, and the application verifies it on the device against a public key baked into the build — so no activation server, no license check over the network and no phone-home is needed to keep the product running. Confirm the licensing mechanics in your contract when you buy.

What Leaves the Machine — and How to Pin It Down

Iternal's account of outbound traffic is short. Inference never leaves the device, and the application does not retrieve documents from the cloud. The one outbound behavior is an optional update check — a ping to Iternal's update server that can be switched off entirely, or pointed at a file server inside your own network so updates arrive without an internet route. Licensing adds nothing to the wire: the license key is verified offline on the device, with no activation server and no phone-home. The mark of a well-run evaluation — for any local-AI product, AirgapAI included — is turning each statement into a question answered in writing, and Iternal welcomes all four:

Pin it down: questions for your evaluation
  • Is the update check enabled in the build we will receive, and can we see it switched off before install?
    The one outbound behavior described for the product, confirmed as a setting rather than a promise.
  • Can application and model updates be staged from a file server inside our own network?
    Whether a sealed environment can stay current with no internet route at any point in the lifecycle.
  • Is there any activation, telemetry or usage-reporting traffic at any point in the product lifecycle?
    That the update check is the complete list of outbound behavior — in writing, on your security questionnaire.
  • During the pilot, can we image one machine and monitor its traffic from first startup?
    The answer on your own wire, which outranks any datasheet.

For more information visit the data-retention page.

Where People Actually Work Without a Connection

Disconnection is a working condition, not an edge case. Again and again, buyers described connectivity that drops — or was never there — exactly where their people do the work. In their own words: airplane connectivity is a problem a lot of the time, and airplane wi-fi “costs a lot of money and never works”; cloud coding assistants do not work on a five-hour flight; cellular coverage is weak at factories far from city centers; client environments do not always have ubiquitous connectivity.

Others described environments with no internet connection at all, where anything cloud is ruled out from the start: a grid operator that cannot run anything other than an offline system, closed-loop classified networks with no access to cloud services, critical-infrastructure supply chains that are completely sealed, and field engineers working in plants with no access to the outside world — where an engineer cannot even look up a switch command. For those buyers the question is not whether offline operation is convenient; it is the entry ticket.

What Disconnected Operation Rules Out

The other half of the answer. Offline:

  • No browser access from inside the assistant.
  • No retrieval of public documents — users download and package them into a data set manually.
  • No industry research or external sourcing pulled into a document it drafts.
  • No answers about recent events beyond what the loaded model was trained on.
  • A data set that does not update itself, because the app offline has no awareness the source content changed.

None of these are defects of a local architecture; they are what “no network” means. The evaluation mistake is expecting a sealed machine to behave like a connected one. The planning mistake is not assigning a person to the refresh loop — someone owns rebuilding data sets when source content changes, and moving new models onto the machines, because the software cannot do either for itself.

Answered elsewhere
FAQ

FAQ: Offline and Air-Gapped AI

The machine never has a route out at any point in the lifecycle — install, model load, data sets and updates all arrive by removable media or a file server inside your own network. That is stricter than running inference locally: a product can be fully local at answer time and still assume connectivity at install or update time, which makes it offline-tolerant, not air-gapped. The test: can you install, load a model, add a data set and take an update with no internet route at any point?

A local assistant does — the model, embeddings and retrieval index are on the device, so answering continues with no connection. Cloud assistants do not: buyers have told us that cloud coding assistants fail on a five-hour flight and that airplane wi-fi is expensive and unreliable. The limit travels with you, though: nothing on the machine refreshes itself until it is back on a network or fed by removable media.

Yes, if the model and the data sets they need are loaded before they go — that is the pattern buyers repeatedly described for factories with weak cellular coverage, plants with no outside access, and client sites without reliable connectivity. The operational requirement is a refresh loop: someone rebuilds and re-loads data sets when source content changes, because the app offline has no awareness anything changed.

No activation server is involved. AirgapAI does issue a license key, and the application verifies it on the device against a public key baked into the build, so nothing about licensing requires a network: no activation call, no license check over the wire, no phone-home. Confirm the current licensing mechanics in your contract when you buy.

Not inside the installer — the right model depends on the user's device, so AirgapAI does not bundle one. The first load reaches the machine over some network once, or by removable media; in a sealed environment, models and updates can be staged on a file server inside your own LAN. Plan that transfer as part of deployment, not as an afterthought.

Test It With the Network Card Off

Disconnected operation is checkable in an afternoon: install AirgapAI on one machine, load a model and a data set, switch the network card off, and work. What answers is real; what stops is the refresh loop you will need to own. If disconnected operation is your requirement, that one test tells you more than any datasheet.

John Byron Hanby IV
About the Author

John Byron Hanby IV

CEO & Founder, Iternal Technologies

John Byron Hanby IV is the founder and CEO of Iternal Technologies, a leading AI platform and consulting firm. He is the author of The AI Strategy Blueprint and The AI Partner Blueprint, the definitive playbooks for enterprise AI transformation and channel go-to-market. He advises Fortune 500 executives, federal agencies, and the world's largest systems integrators on AI strategy, governance, and deployment.