AI in OT Environments: What IEC 62443 and NIS2 Require When LLMs Touch Industrial Control Systems
Manufacturing OT environments now host AI tools for predictive maintenance, anomaly detection, work-instruction generation, quality inspection, and operator copilots. The AI calls cross zones that IEC 62443 was designed to segment and bring NIS2 incident reporting and supply chain obligations into the operational technology footprint. Most OT deployments use AI through cloud APIs that violate the segmentation assumptions of the IEC 62443 reference model. This piece walks through where AI sits in modern OT, what IEC 62443 and NIS2 require for the AI traffic, and the inspection architecture that produces records the regulator and the customer auditor will accept.

Manufacturing operations technology environments now host AI tools across maintenance, quality, scheduling, and operator assistance. The AI calls run from PLC-adjacent edge devices, from manufacturing execution systems (MES), from quality inspection stations, and from operator copilots in the SCADA layer. Each AI call originating in the OT zone and terminating at a cloud AI API crosses the boundaries that IEC 62443 was designed to segment. The Network and Information Security 2 Directive (NIS2) reaches the OT exposure when the AI traffic is part of an incident, when the AI provider is a critical ICT third party, or when the supply chain obligation pulls the AI provider into scope. Most OT deployments today have no inspection capability for the AI traffic crossing the segmentation boundary.
I want to walk through where AI sits in modern OT, what IEC 62443 and NIS2 actually require for the AI traffic, where the deployments are exposed, and the inspection architecture that closes the gap.
Where AI sits in modern manufacturing OT
The AI use cases in OT environments cluster into five workloads.
Predictive maintenance
Time-series data from sensors, drives, and motors feeds AI models that predict failure. The models may run on the edge gateway or in the cloud. Cloud-resident models receive sensor data, equipment identifiers, plant identifiers, and historical maintenance records over an API call.
Anomaly detection
Anomaly detection runs on telemetry to flag deviations. The models that perform the detection often run in the cloud or in a hybrid architecture with edge feature extraction and cloud inference. The traffic carries process data that is plant-specific and competitively sensitive.
Quality inspection
Computer vision models inspect parts at the line. The models run on cameras with edge GPUs or via cloud inference. Inspection calls send images of products, part identifiers, and process parameters. The images often contain identifiable patent-relevant geometry.
Work-instruction generation and operator copilots
LLMs draft work instructions, summarize SOPs, translate manuals, and answer operator questions. The prompts include process recipes, tolerances, and operating procedures. The responses are operator-facing and influence what the operator does next.
Scheduling, planning, and yield optimization
AI tools in the planning layer optimize batching, scheduling, and yield. The inputs include demand signals, inventory state, and capacity constraints. The outputs influence the operating plan.
Each workload originates traffic that crosses OT/IT and IT/cloud zones. The classical IEC 62443 reference model puts OT in lower zones than IT and assumes a controlled traversal through a DMZ. The AI traffic patterns do not fit cleanly into that model because the AI APIs are cloud-resident and the operational decisions depend on the round trip.
What IEC 62443 requires for the AI traffic
IEC 62443 specifies a zone-and-conduit model. The standard does not address AI explicitly. It does require that data flows across zones be authorized, monitored, and recorded. The AI traffic is a data flow that has to fit the zone-and-conduit policy.
Zone segmentation and conduits
IEC 62443-3-3 sets system requirements for the zone-and-conduit segmentation. A conduit between an OT zone and an IT or cloud zone has to be authorized. The authorization includes identification of the source, destination, protocol, and purpose. The conduit has to be monitored. Monitoring includes the ability to detect anomalous traffic and produce records on demand.
Identification and authentication
IEC 62443-3-3 SR 1.1 requires that all human users, software processes, and devices are identified and authenticated before accessing resources across the conduit. AI traffic that uses a shared API credential to call the cloud provider fails the granularity expected for SR 1.1.
Audit trail and logging
IEC 62443-3-3 SR 2.8 requires that the system generate audit records for security-relevant events. The records have to be readable, the storage has to be sufficient, and the records have to be protected from unauthorized modification. AI calls that produce no audit record on the OT side fail this requirement.
Supply chain considerations
IEC 62443-2-4 addresses supplier security capabilities. The AI provider is a supplier in the IEC 62443 sense. The supplier's security capabilities, including data handling, breach notification, and continuity, are within scope.
What NIS2 layers on top
The NIS2 Directive came into effect in October 2024. Member states have transposed it into national law on varying timelines. The directive applies to essential and important entities including manufacturing of certain critical product categories.
Incident reporting
NIS2 Article 23 sets incident reporting obligations. The entity has to issue an early warning within 24 hours of becoming aware of a significant incident, a notification within 72 hours, and a final report within one month. AI-related incidents that have a significant impact on the entity's services fall within the obligation.
Risk management measures
NIS2 Article 21 sets baseline risk management measures including supply chain security, vulnerability handling, and the use of cryptography. The supply chain provision reaches AI providers and the AI components in OT systems. Entities have to assess the security of their AI suppliers and demonstrate the assessment.
Personal accountability for management bodies
NIS2 holds management bodies personally responsible for compliance with the risk management measures. The accountability is enforced through national supervision and penalties that can include personal sanctions on directors.
Where OT deployments are exposed
The exposure shows up in three places consistently.
The first is unmonitored AI traffic across the IT/cloud boundary. OT teams add AI tools to specific workflows. The tools call cloud APIs. The conduit monitoring did not contemplate the AI traffic, and the AI traffic is not visible in the SCADA or MES security telemetry. The traffic is not recorded as AI traffic in the OT audit log.
The second is shared API credentials in OT integrations. The AI feature inside an MES module uses an API key issued to the integrator or to a service account. The credential is shared across plant sites and across users. The natural person whose action triggered the AI call cannot be identified from the audit trail.
The third is supply chain depth. The AI provider that the OT vendor uses is often subcontracted to a hyperscaler that uses its own AI infrastructure. The chain of providers obscures who handled the data and under what terms. The NIS2 supply chain assessment requires the entity to trace the chain.
DeepInspect
This is the gap DeepInspect closes for manufacturing OT environments running AI. DeepInspect sits at the AI request boundary as a stateless proxy between OT-originating applications and any LLM or cloud AI API. For every call, DeepInspect attaches the plant identifier, the operator's identity where the workflow involves a human, the workstation identifier, the OT zone of origin, and the data classification of the prompt content. It records the outcome with a cryptographic signature.
For IEC 62443, the inspection layer is the conduit's monitoring and audit point. For NIS2, the inspection layer produces the records the incident report will reference and the evidence the supply chain assessment will rely on. The architecture does not require changes to the SCADA stack or the PLC layer; the inspection happens at the AI traffic boundary.
If you are running a manufacturing OT environment with AI integrated across MES, predictive maintenance, or quality, and your IEC 62443 conduit monitoring does not cover the AI traffic, let's talk.
Frequently asked questions
- Does IEC 62443 explicitly mention AI?
No. IEC 62443 was written before AI in OT became common. The standard's zone-and-conduit model, identification and authentication requirements, and audit trail requirements apply to AI traffic as a data flow even without AI-specific language. ISA, IEC, and ISA99 working groups have signaled work on AI-specific guidance, but the binding requirements at the present time are the generic zone-and-conduit ones. Conformant deployments treat AI traffic as a regulated conduit and apply the existing requirements.
- Does NIS2 apply to a US manufacturer with an EU plant?
NIS2 applies to essential and important entities operating in the EU. A US manufacturer with an EU plant in a covered sector is in scope for the EU operations. The supply chain provisions of NIS2 reach back into the US headquarters where the AI providers, security tooling, and operational decisions are managed centrally. The personal accountability provisions can attach to management bodies of the EU subsidiary. US-based parents have to plan for the operational requirements at the EU plants.
- How do operator copilots interact with the human oversight expectations under EU AI Act Article 14?
Article 14 of the EU AI Act applies to high-risk AI systems and requires human oversight. Operator copilots are not automatically high-risk under Annex III, but specific workflows can fall into high-risk categories (employment-related decisions, safety components of critical infrastructure). The OT operator's reliance on copilot output for safety-relevant actions creates a human oversight footprint that the human oversight expectations have to address. The audit trail of which operator acted on which copilot output is the evidence that the oversight worked.
- What does the AI supply chain assessment under NIS2 actually require?
The assessment requires the entity to identify suppliers and service providers that the entity depends on for its security posture, evaluate their security capabilities, and document the assessment. For AI providers, the assessment covers data handling, training practices, incident response, breach notification, and operational continuity. Practical assessments review the provider's terms, the provider's certifications, the provider's incident history, and the provider's response to specific questions raised by the entity. The documentation has to be available for supervisory review.
- Can edge-deployed AI models avoid the cloud-AI exposure entirely?
Edge deployment reduces the cloud exposure but does not remove the IEC 62443 or NIS2 obligations. The edge model is a software component that has to be inventoried, patched, monitored, and audited. The model's training data and lifecycle are still subject to supply chain assessment. The edge inference still produces records that the conduit monitoring expects. Edge deployment is part of the architecture, not a replacement for it. The inspection layer for AI traffic exists at whichever boundary the AI calls cross, including edge-to-control-zone boundaries.