What Production AI Looks Like Inside an Air-Gapped Semiconductor Fab

A semiconductor fab is one of the most demanding environments for production AI. Process recipes are core intellectual property, operating data is highly sensitive, and parts of the fab operate on deliberately isolated networks, with only local compute and data available to run the AI.

In an air-gapped environment, the network boundary sets the deployment architecture before the model is even chosen. It determines where the AI runs, which models are available, how releases move into production, how models and context are updated, and which signals can cross the boundary.

The examples below come from several deployments in semiconductor fabs and equipment factories where process data, equipment telemetry and fault histories stay inside the facility.

Everything runs inside, on hardware that fits on a factory floor

On an air-gapped fab floor, the full runtime sits inside the customer network. For the technician-facing application used to diagnose a down tool, that includes the model, the fab-specific context it reasons over, connections into equipment and maintenance systems, the technician interface, and the monitoring used to measure whether its recommendations are working.

That puts a hard ceiling on compute. In these deployments, models are compressed to run on a single accelerator card in a rack unit. The compute has to fit within the rack space and physical constraints available on the fab floor.

The same deployment has to run on more than one model

Within the same site, different network zones can make different models available.

In the enterprise IT environment, an approved cloud model runs through an internal proxy under the company's enterprise agreement, with a usage quota shared across the organization. The application has to operate within that shared capacity. Another network zone may require an internal model mandated company-wide after security review. On the isolated floor, the model runs locally.

The fab-specific context, workflow logic and monitoring all have to carry across whichever model is available in each location. Model portability has to be part of the architecture from the beginning.

Every update costs a full security review

The security review continues after go-live.

Every production update goes through cybersecurity review. Any tuning of the model on customer data happens after installation, inside the network. In one of our deployments, the customer controlled every production release. Each change moved through the customer's own release process before it could go live.

That has a direct effect on release cadence. A one-line configuration change carries the same review cost as a full rebuild. Changes are bundled into larger, well-tested releases and moved through review as planned increments.

For teams designing an air-gapped deployment, the release model is part of the architecture. Model tuning, context updates and configuration changes move in larger, controlled increments because every production change carries the same review burden.

The feedback loop has to run inside the facility

Once the application is deployed, the fab keeps changing. Equipment populations change, firmware is updated, new failure modes appear, and a model tuned to last year's service history can gradually lose accuracy. In an isolated deployment, the vendor has no live view into that drift.

The feedback loop comes from the service work already recorded inside the facility. The completed work record shows whether a technician followed the recommendation or took a different action, without adding another task to the repair process. That gives the feedback loop a direct signal from what was actually done at the tool.

Recurrence supplies another signal. If the same fault returns on the same machine after the recommended fix, the original diagnosis likely missed part of the cause. A rising rate of unanswered or low-value responses surfaces unfamiliar tools and new failure modes the model does not yet have the context to diagnose.

Each facility gets its own baseline during commissioning, so thresholds reflect normal local behavior. When a threshold is breached, the monitoring assembles a diagnostic package: which measure moved, by how much, over what period, which fault codes were involved, and which technician corrections were recorded since the last contact.

Performance signals go out. Process IP stays in.

That package is what can leave the site: a constrained set of performance signals and anonymized operational metadata about the application's performance. Process data, equipment telemetry and fault histories remain inside the facility. The security review is field-level: exactly which fields leave, on what trigger, and which stay inside.

Coming back the other way, the update targets the local model running inside the isolated fab network. Any enterprise model standardized elsewhere remains unchanged. The correction is measured in tens of megabytes, while a full model replacement would be several gigabytes.

That size matters because the update still has to travel by whatever route the site permits: a scheduled maintenance window, a relay through the controlled zone between networks, or a drive carried in by hand. The same cryptographic verification is applied to the file whichever route is used.

Three design checks for an air-gapped deployment

Start by separating sites and zones by what can actually be reached. Within the same semiconductor operation, connectivity can range from a fully isolated fab floor to an enterprise IT environment with controlled outbound access and field operations with unreliable connectivity. That reachability map feeds directly into compute, model choice, release, feedback and update design.

Then ask what actually runs on-premise. Vendors often support an on-premise edition, but the useful questions are which functions still depend on the vendor cloud, what hardware footprint it requires, and whether the model has actually run compressed on a single card in production.

Finally, ask for the field list. The field list makes the data boundary explicit: what leaves the site, when it leaves, and what remains inside.

The network boundary is an architectural input. It sets the compute footprint, available models, release cadence, feedback loop and update path. In an air-gapped fab, those decisions are coupled from the start.