Air-Gapped AI: What It Is and Why Industrial Facilities Need It

The term “air-gapped AI” is showing up more in industrial conversations, and for good reason. Facilities that handle sensitive operational data — manufacturing plants, refineries, utilities, pharmaceutical sites — are being told that AI can make their teams faster, smarter, and more productive. And that’s probably true. But most AI products require sending your data to someone else’s servers, and for a lot of industrial operations, that’s a non-starter.

Air-gapped AI is the alternative: AI that runs entirely on hardware inside your facility, with no internet connection required and no data leaving your network.

What does “air-gapped” actually mean?

In network security, an air gap is a physical separation between a computer system and external networks. A system that is air-gapped has no wired or wireless connection to the internet or any other untrusted network. The only way data gets in or out is through deliberate, controlled physical transfer.

Air-gapped systems aren’t new. They’re standard in classified government facilities, nuclear power plants, military installations, and high-security financial infrastructure. What’s new is applying this concept to AI — running machine learning models, large language models, and inference engines on hardware that operates in complete network isolation.

Air-gapped AI means:

All inference happens locally. When someone asks the AI a question, the model processes it on hardware inside the building. No API call leaves the facility.
All data stays on-site. Training data, documents, query logs, and responses never touch an external server.
No internet dependency. The system operates identically whether your facility has internet access or not.
No vendor telemetry. The AI vendor has no visibility into what you’re asking, what data the system has ingested, or how your team is using it.

This is different from “on-premise AI” that still phones home for model updates, usage tracking, or license verification. A truly air-gapped system operates independently once deployed.

Why industrial facilities can’t use cloud AI

If you manage a facility that runs 24/7 process operations, you already know why cloud-based tools hit resistance. But the specific reasons matter, because they determine what an alternative needs to look like.

IT and OT security boundaries

Most industrial facilities maintain strict separation between their operational technology (OT) network and the corporate IT network. Adding a cloud-based AI tool that needs to read from OT systems — CMMS data, historian data, SCADA telemetry — means punching holes in that boundary. IT security teams at industrial facilities don’t approve this casually. Many won’t approve it at all.

This isn’t hypothetical. We hear it in almost every discovery conversation with industrial facilities. The operations team wants digital tools. IT says no to anything that sends data to an external cloud. The project dies in the gap between those two positions.

Proprietary process data

Manufacturing processes, equipment configurations, maintenance procedures, and operational parameters represent years of hard-won operational knowledge. For many facilities, this data is a competitive advantage. Sending it to a cloud AI provider — even one with strong encryption and access controls — creates a data sovereignty risk that legal and compliance teams are increasingly unwilling to accept.

Regulatory and compliance frameworks

Depending on the industry, facilities may need to comply with NIST ICS guidelines, IEC 62443 for industrial cybersecurity, NERC CIP for power generation, or various FDA regulations for pharmaceutical manufacturing. These frameworks increasingly require demonstrable control over where data is processed and stored. Cloud AI creates a compliance documentation burden that on-premise, air-gapped systems avoid entirely.

Connectivity and latency

Not every facility has reliable internet. Offshore platforms, remote mining operations, rural water treatment plants, and facilities in developing regions may have intermittent or no connectivity. Even facilities with good internet face latency considerations — when a technician needs an answer at a piece of equipment, a 2-3 second cloud round-trip is noticeable. Local inference on dedicated hardware responds in milliseconds.

Vendor lock-in and pricing risk

Cloud AI services charge per query, per token, or per user. For a facility where dozens of technicians are asking questions throughout every shift, those costs scale fast — and the vendor controls the pricing. If the model improves, the price goes up. If the vendor changes terms, you renegotiate or lose the tool. Air-gapped hardware that you own eliminates this entirely: after the initial investment, queries cost nothing.

What it takes to run AI on-premise

Running AI inside a facility isn’t as simple as downloading a model onto a laptop. Industrial-grade on-premise AI requires purpose-built hardware, deliberate system integration, and a deployment model designed for the constraints of an industrial environment.

Hardware

AI inference — especially running large language models — requires significant compute. The hardware needs GPU or specialized accelerator capacity for model inference, enough storage to hold the model weights plus the facility’s ingested documents and data, and enough memory to serve concurrent queries from multiple users across shifts.

This typically means a rack-mounted appliance, not a desktop machine. The hardware should be sized to the facility: a small plant with 50 assets and 15 technicians needs different compute than a refinery with 2,000 assets and 300 users.

Data ingestion and integration

The AI is only as useful as the data it can access. For industrial applications, that means connecting to:

CMMS / EAM systems — work order history, PM schedules, asset records (Maximo, SAP PM, Fiix, MaintainX, etc.)
Document repositories — maintenance manuals, SOPs, engineering drawings, P&IDs (often in SharePoint, file shares, or document management systems)
Process historians — time-series sensor data (OSIsoft PI, AVEVA PI)
Industrial protocols — OPC-UA and Modbus for live equipment data

Each of these connections needs to be explicit and auditable. The facility’s IT and operations teams should know exactly what the AI can see and what it can’t.

Model management without internet

Cloud AI gets model updates automatically. Air-gapped systems need a different approach. Model updates, security patches, and new capabilities are delivered on physical media or through a controlled, temporary network connection during scheduled maintenance windows. This is similar to how air-gapped systems in government and defense environments receive software updates — it’s a solved problem, just a different workflow than automatic cloud updates.

User interface

For industrial applications, the AI needs to be accessible where the work happens — at the equipment, on the floor, in the field. This usually means a mobile-friendly web interface that technicians can access from their phones without installing an app. Some systems use QR codes on equipment as the entry point: scan the tag, get a conversation with an AI that already knows which asset you’re looking at.

Air-gapped AI vs. self-hosted cloud AI

There’s an important distinction between air-gapped AI and self-hosted versions of cloud AI tools. Several vendors now offer “on-premise” or “private cloud” deployments of their AI products. These can run on your hardware or in your private cloud, but many still require:

Internet connectivity for license validation
Telemetry data sent back to the vendor
Cloud-based model update pipelines
Vendor API calls for certain features

These deployments solve the “data residency” problem but don’t solve the “air gap” problem. If your facility needs true network isolation — no data in, no data out — a self-hosted cloud AI product may not meet the requirement.

True air-gapped AI operates with zero external network dependencies. Once deployed, it runs independently. Model updates happen through controlled physical transfer, not over the network.

Who needs air-gapped AI?

Not every facility needs a full air gap. If your IT team is comfortable with a cloud solution and your data sensitivity allows it, cloud AI is simpler to deploy and maintain.

Air-gapped AI makes sense when:

IT/OT security policy prohibits cloud-connected tools on the OT network. This is the most common driver we see.
Regulatory frameworks require demonstrable data isolation. Pharmaceutical manufacturing, nuclear, defense-adjacent facilities.
Proprietary process data is a competitive asset. If your manufacturing process, formulations, or operational parameters are trade secrets, sending them to a cloud AI creates risk.
The facility has limited or no internet connectivity. Remote sites, offshore, or facilities where network isolation is a physical reality.
The organization wants to own the AI, not rent it. Capital investment vs. recurring subscription, with no vendor dependency after deployment.

What to evaluate when considering air-gapped AI

If you’re exploring on-premise AI for your facility, here’s what to look at:

True air-gap capability. Does the system operate with zero internet connection, or does it need periodic connectivity for licensing, updates, or telemetry? Ask specifically about what happens if the network cable is physically disconnected.
Integration depth. Can it connect to your specific CMMS, document systems, and data sources? Generic AI that can’t read your existing systems isn’t useful.
Hardware sizing. Is the hardware right-sized for your facility? Undersized hardware means slow responses and limited capacity. Oversized hardware means you’re paying for compute you don’t use.
Model update process. How do you get improvements to the AI model without an internet connection? What does the update workflow look like in practice?
Data control. Can you control exactly which systems and data the AI has access to? Granular, auditable permissions matter — the AI should only see what you’ve explicitly approved.
Total cost of ownership. Compare the one-time hardware investment plus annual support against the per-query or per-user cloud alternative. For facilities with high query volumes across multiple shifts, the math often favors owned hardware.