Can AI run inside an OT network under IEC 62443?

Yes. AI can run inside an OT network under IEC 62443, provided it is deployed the way any other OT workload is deployed: as a local process inside a defined zone, or in a higher-level zone fed one way from the process network. What IEC 62443 does not accommodate is an undeclared dataflow: an AI service that needs a persistent outbound internet path from an OT zone creates a conduit that has to be defined, risk assessed and justified, and that justification is extremely hard to sustain against the zone model.

The question is current in 2026 because manufacturers and infrastructure operators want AI on maintenance and telemetry data at the same time as NIS2 obligations on essential and important entities harden expectations around segmentation and incident evidence.

What does IEC 62443 zoning actually require?

IEC 62443 organises an industrial network into zones, groups of assets sharing common security requirements, connected only through defined conduits engineered to a stated security level. The model exists to make dataflows explicit and deliberate. Any new communication path must be identified as a conduit, risk assessed and built to the level the connected zones demand. Nothing in the standard prohibits computation inside a zone. What it disciplines is communication between zones and, above all, communication that leaves the industrial estate.

Why is a cloud AI service a conduit by definition?

Because it moves process data across zone boundaries to the outside world. Calling a cloud AI service from an OT zone creates a persistent outbound path from the most protected part of the network to infrastructure outside the organisation entirely. Under the zone and conduit model that path is a conduit and must be treated as one: assessed, secured to a defined level and continuously justified. In practice, an outbound internet conduit from a process zone contradicts the segmentation the rest of the architecture exists to defend. Most OT security teams reject it on sight, and the logic of the standard supports them.

Where should an AI workload sit in the zone model?

Two placements work. The first puts the model inside the zone, on operator-owned hardware racked beside the assets it serves, so inference happens where the data already lives. The second puts it in a higher-level zone, such as the site operations layer, fed through a one-way path from the process network, for example a data diode or an equivalently constrained conduit. Both keep telemetry inside the estate. A short test resolves most proposals:

• Does the AI workload run on hardware the operator owns and patches?
• Can it operate indefinitely with every outbound internet path removed?
• Is each dataflow it introduces documented as a zone-internal flow or a defined conduit?
• Does telemetry ever leave the industrial estate? If the answer is yes, the design fails.

How does predictive maintenance work without telemetry leaving?

Predictive maintenance is the concrete case. Vibration, temperature and cycle data flow from the process network into the historian as they always have. A sovereign model runs on operator hardware beside that historian, learns normal behaviour for each asset class and flags the drift that precedes failure. Work orders are raised locally. Nothing in the loop requires a packet to leave the site.

The half that is usually missed is evidence. When a model recommends pulling a pump offline, the maintenance engineer needs to show why the intervention happened. In our architecture every recommendation is sealed to an audit record: the model version, the inputs considered and the output produced are signed into an append-only ledger, so the justification survives staff turnover and audit cycles.

What does NIS2 change for manufacturers?

NIS2 brings many manufacturers and infrastructure operators into scope as essential or important entities, with obligations around risk management, supply chain security and incident reporting. It does not mandate any AI architecture. What it does is raise the cost of unexplained dataflows and undocumented third party dependencies. An AI deployment that keeps telemetry inside the estate and produces its own verifiable records fits that direction of travel. One that exports process data to a cloud service adds a dependency the operator must then assess, contract for and defend.

How does Mickai implement the in-zone pattern?

Mickai is a Sovereign Intelligence Operating System, a SIOS, built to run offline on operator-owned hardware, which is the deployment shape OT zoning demands. Its perimeter is zero-egress by design: model updates and detection content arrive as signed artefacts through a controlled inbound path, and nothing inside the zone initiates outbound connections. Every model and agent action carries a per-action identity, bound to hardware-attested identity and sealed into a post-quantum signed audit ledger under FIPS 204, so a recommendation made inside a zone can be verified years later without any external dependency.

“If an AI deployment needs an outbound internet path from an OT zone, the deployment is wrong, not the standard.”

How the zone-friendly architecture fits together end to end is set out at /sovereign-ai, and the film at /film shows the interface in operation.

Frequently asked questions

Can I use a cloud AI service in my OT network if it goes through a DMZ?

A DMZ changes the path, not the destination. Process data still leaves the estate and lands on infrastructure the operator does not control, so the outbound conduit still exists and still needs justification against the zone model. Most OT security programmes find that justification hard to sustain when a local workload can do the same job.

Does IEC 62443 ban AI in industrial networks?

No. IEC 62443 is silent on AI as such. It disciplines zones, conduits and security levels. An AI workload deployed as a zone-internal process, or fed one way into a higher-level zone, is architecturally no different from a historian or an engineering workstation. The pressure of the standard falls on new outbound dataflows, not on computation.

How do I run predictive maintenance without sending telemetry to a vendor?

Run the model beside the historian on hardware the operator owns. Telemetry flows to it inside the estate, inferences and work orders stay local, and model updates arrive as signed artefacts through a controlled inbound path. The vendor never needs the data; the site needs the model.

What evidence should an AI maintenance recommendation carry?

The model version, the input window considered, the output produced and the time it was produced, sealed into an append-only audit record. With that record an engineer can show an auditor or an insurer why an intervention happened long after the fact, without relying on anyone's memory.

Does NIS2 require on-premise AI?

No regulation names an AI architecture. NIS2 requires essential and important entities to manage risk, control supply chain dependencies and report incidents. Keeping AI processing inside the estate reduces the dependency surface those duties cover, which is why segmented, sovereign deployments are the path of least resistance under the directive.