Some plants will never let a camera feed touch the internet. A defense supplier, a pharmaceutical fill line, a food plant with a proprietary process, a water utility — each has its own reasons, and each is usually told that AI inspection and monitoring need the cloud. They don’t. Inference, storage, dashboards, the model registry and even retraining can all run inside the fence. The hard part is not running a model without a connection; it is changing one — getting patches, new models and configuration across a gap that exists precisely to stop things crossing it.
This article covers why plants choose isolation, what has to live on site, how updates and retraining work without a permanent link, and what you give up.
Why plants keep AI off the internet
The reasons we hear fall into four groups, and most sites have more than one.
- Intellectual property. Images from an inspection cell show the product, the tooling, the process window and, in the defect gallery, a running record of where the process struggles. For many manufacturers that is more sensitive than the drawings.
- Regulated data. Validated production systems where every change goes through change control, contracts that restrict where technical data may be stored, and export-control rules all turn “we’ll send it to a cloud region” into a long conversation that often ends in no.
- Network reliability. A reject gate cannot wait for a WAN link. Plants with a single internet circuit, or in places where connectivity is poor, need the line to keep running when the link is down. An isolated design treats “no connection” as the normal state, not a fault.
- Latency. An inspection decision has to reach the reject gate in tens of milliseconds, every time. A local gateway delivers that predictably; a round trip to a data center adds delay that varies with traffic you don’t control.
Air-gapped is a spectrum
“Air-gapped” gets used for several different designs. Be precise about which one your site means, because the update process depends on it.
| Level of isolation | What crosses the boundary | Typical use |
|---|---|---|
| Fully isolated | Nothing over a network; data moves on controlled removable media | Defense work, some validated pharma areas |
| One-way out | Reports and telemetry leave through a unidirectional gateway; nothing comes in | Sites that want central reporting with no inbound path |
| Scheduled windows | Outbound-only connections, opened from inside for a fixed time and logged | Updates and remote support on an agreed schedule |
| Brokered, always on | A persistent connection through a DMZ | Most connected plants — not an air gap |
Many sites that describe themselves as air-gapped are really in the third row. That is a perfectly good place to be, and it makes everything below easier.
What has to live on site
If nothing reaches the cloud, everything the cloud would have done needs a home inside the plant. The list is longer than most people expect.
- Inference. Models, runtimes and pre- and post-processing run on the edge gateway beside the line. Check that nothing in the software stack needs to reach a license server or telemetry endpoint to start; some commercial software quietly does.
- Storage. Reject images, a sample of good parts for retraining, time-series data and logs. Size it deliberately. In a hypothetical cell with four cameras at 200 parts per minute, keeping every reject (1%) plus one good part in a hundred, at about 1 MB per image, comes to roughly 23 GB a day — around 2 TB for 90 days of retention.
- A model registry. Every model version, its model card, its validation results, who approved it and which devices run it. Without a vendor portal, this registry is the only record of what is deciding pass and fail on your line.
- Dashboards and alerting. Live views, trends and alerts served from a site server, with alerts routed through an on-premise email relay, stack lights and the plant’s own CMMS.
- Identity and time. Single sign-on against the plant’s directory, a local certificate authority and a trustworthy time source. Certificates and signed updates have validity periods, and logs are useless in an investigation if every device disagrees about the time.
- An update depot. A place where incoming updates wait, are checked and are staged before they reach production devices.
That list is the design brief for Perflens Console. It runs on the Gatepoint gateway, an on-premise site server or both, with no internet connection required; the model registry, model cards and drift monitor live in its Models module, and device health, updates and certificates in its Fleet module. Whatever software you choose, insist on the same property: disconnection is a supported configuration, not a degraded one.
Getting updates across the gap
An isolated system still needs security patches, firmware fixes, new models and configuration changes. The principle that makes this safe is simple: trust the signature, not the transport. Whether a bundle arrives on a USB drive, through a staging gateway or over a short outbound window, every device should verify it cryptographically before installing anything.
Signed offline update bundles
A well-formed update bundle contains:
- The payload: operating system or firmware image, application containers, model files with their model cards, and configuration.
- A manifest listing every file with its cryptographic hash.
- A signature over the manifest, made with a signing key the supplier keeps offline.
- A version number and a minimum-version rule, so an old, vulnerable bundle cannot be replayed to roll a device back.
- A software bill of materials and release notes, so your security team can see exactly what changed.
On the device, verification should be anchored in hardware — a secure boot chain and a key held in a TPM — so the device decides what it trusts, not the person holding the USB stick. Gatepoint gateways follow this pattern with TPM 2.0, secure boot and A/B updates: a new image installs to the inactive partition, and the previous one stays available to fall back to.
A staging gateway
Do not take a bundle straight from media to production. Keep one gateway, identical to the production hardware, in a separate update zone inside the plant. Each bundle lands there first:
- Media is scanned on a dedicated kiosk before anything is copied.
- The staging gateway verifies the signature and installs the update.
- A regression run replays a fixed set of recorded images — a golden set — and confirms that decisions match the expected results.
- Only then is the bundle released to production devices, in waves, with the previous bundle kept for rollback.
Controlled outbound windows
If your policy allows any connection at all, a scheduled outbound window is the most practical middle ground. It is initiated from inside, goes to a fixed destination, lasts a fixed time, is approved by a named person and is logged. Use it to pull bundles to the staging gateway, never directly to production devices, and close it when the job is done. The same signature checks apply.
Retraining without a permanent connection
Isolation does not stop drift. Light, material and equipment change on a disconnected line exactly as they do on a connected one — see why inspection models get worse in July. Drift monitoring is cheap to run on site: confidence distributions and image statistics computed on the gateway and reviewed in the local dashboard. The question is where retraining happens.
- On site. A site server with a suitable GPU trains candidate models from images that never leave the building. You need the compute, and someone qualified to label and validate — your own engineer or a visiting one.
- Reviewed export. Quality and security staff select a curated subset — usually borderline and misclassified images, sometimes cropped to the defect region — which leaves on encrypted media under a written data-transfer agreement. The retrained model comes back as a signed bundle, and the exported images are deleted on an agreed schedule.
Either way, the candidate model is validated against the original validation set and a set from current conditions, runs in shadow mode on the staging gateway, and is recorded in the site registry with an updated model card before it is promoted. Retraining becomes lumpier than on a connected system, so tie it to your update windows and plan it like any other maintenance job.
The trade-offs, honestly
Isolation is a legitimate engineering choice, not a free one.
- Patching is slower. Fixes for newly disclosed vulnerabilities reach your devices at the pace of your update process. Compensate with a small attack surface and tight segmentation; our Edge & OT Security work starts there, and our IEC 62443 hardening checklist covers the device side.
- Expert help is slower. Any service that depends on a remote analyst seeing your data — verifying an alert at 2 a.m., for example — needs a path for that data. Without one, the work falls to your own team or to a scheduled visit. Decide this before go-live and write it into the support agreement.
- You own more infrastructure. Site servers, storage, backups, a time source and a certificate authority are now yours to run. Expired certificates are a classic cause of outages on isolated networks; put renewal dates in the maintenance calendar.
- Fleet visibility takes work. Comparing performance across sites needs one-way exports or someone carrying reports between them.
- Process carries the load. An update is only as safe as the procedure behind it. Write it down, name who approves each step, and rehearse it on the staging gateway before you need it in a hurry.
What you get in return is real: a line that does not care whether the internet is up, data that never leaves your control, and an attack surface you can describe on one page.
If your policy allows a scheduled outbound window, use it; it keeps almost all of the benefits and removes most of the friction. If it does not, a true air gap is entirely workable — provided you budget for the process as carefully as for the hardware.