AI Does Not Belong in OT. Yet It Is Already There.

Industrial environments were not designed for artificial intelligence.

Operational technology is built around predictability, availability, safety and long equipment lifecycles. A control system is expected to perform a defined function, within known tolerances, for many years. Changes are controlled because even a technically correct modification can have consequences for production or safety.

AI introduces a very different operating model. Its outputs may be probabilistic. Its behaviour depends on data, model versions and context. Some systems rely on external platforms or cloud services. Others continue to change through retraining, configuration updates or new integrations.

From a traditional OT and ICS security perspective, this is not a natural fit.

Nevertheless, AI is already moving onto the plant floor—not necessarily as one large, strategic “industrial AI” programme, but through individual tools that promise faster engineering, earlier fault detection, better quality control and lower operating costs.

The important question is therefore no longer whether AI belongs in OT. It is how AI is entering, what it can influence and whether the resulting risk is being assessed as part of the operational environment.

AI Is Entering Through the Side Door

Most plants will not begin their AI journey by allowing an autonomous model to control a production line. Adoption is happening through apparently limited and useful applications:

• predictive and condition-based maintenance;
• machine-vision quality inspection;
• anomaly detection across process and sensor data;
• energy and process optimisation;
• engineering copilots that generate or explain PLC code;
• maintenance assistants using manuals, alarms and asset histories;
• autonomous mobile robots and AI-supported logistics;
• edge analytics connected to machines and field devices.

Each use case can deliver legitimate operational value. But each also introduces a new relationship between data, software, people and physical processes.

That relationship is the real AI–OT convergence.

Industry is already moving in this direction. Siemens, for example, describes industrial copilots spanning engineering, operations and maintenance, including the generation of PLC code and the use of generative AI with predictive-maintenance systems. It is also connecting industrial edge environments with cloud-based AI and data services. These are not theoretical research scenarios; they reflect the direction of current industrial product development. Siemens Industrial Copilot and IT/OT integration for edge, cloud and AI

A Simple Example: Predictive Maintenance

Consider an AI-supported predictive-maintenance system for a critical pump.

Sensors collect vibration, temperature and operating data. That data is transferred to an edge or cloud platform. A model detects patterns associated with deterioration and predicts that the pump may fail. A maintenance copilot converts the model output into a recommendation, and a work order is created in the company’s maintenance-management system.

At first glance, the AI does not control the pump. It has no direct write access to a PLC and cannot change a process setpoint. It may therefore be classified as an IT analytics application rather than an OT component.

But the model’s output can change when the pump is inspected, whether production is interrupted, which replacement part is installed and whether an operator considers an alarm urgent. It has become part of an operational decision.

A real implementation at Sachsenmilch in Germany illustrates this development. An AI-supported predictive-maintenance system was used to identify the approaching end of service life of a pump. Further integration with SAP Plant Maintenance was planned so that maintenance notifications could be transferred automatically. The system starts with monitoring, but its output moves into the operational workflow. Siemens and Sachsenmilch predictive-maintenance case

This is where the security discussion must begin.

What happens if sensor data is incomplete, manipulated or simply no longer representative of current operating conditions? What if a model update changes the failure threshold? What if the generative assistant explains a valid warning incorrectly? What if an external service is unavailable during an incident? And what happens when a recommendation that was originally reviewed by an engineer is later converted into an automated action?

None of these questions requires the AI itself to be “malicious.” A security-relevant failure can result from compromised data, an incorrect model output, an integration error, excessive permissions, unrecognised operational drift or misplaced trust in a recommendation.

The Risk Is Not Just the Model

Industrial AI security is often reduced to model security: adversarial inputs, model theft, prompt injection or data poisoning. These are relevant, but they represent only part of the exposure.

The complete system includes:

• the sensors and industrial data sources;
• gateways, historians and edge platforms;
• data pipelines between OT, IT and cloud environments;
• the model and its supporting services;
• user identities and machine identities;
• engineering and maintenance applications;
• vendor access and update mechanisms;
• the people who interpret or approve the output;
• the physical process affected by the resulting decision.

The model may be secure while the integration is not. The network path may be protected while the recommendation is unreliable. The AI may operate exactly as designed while the surrounding workflow gives it more authority than intended.

This is why an ordinary IT security review is insufficient. It may identify an exposed interface or weak access control, but miss the operational consequence of a wrong recommendation. Traditional OT security controls remain essential, but they were not designed to evaluate model behaviour, training-data relevance, probabilistic output or the gradual expansion of an AI system’s authority.

The gap is also becoming visible at framework level. NIST defines OT as systems that interact with the physical environment and emphasises their unique performance, reliability and safety requirements. Its AI Risk Management Framework addresses AI across the full lifecycle. In April 2026, NIST began developing a dedicated AI RMF profile for trustworthy AI in critical infrastructure—an indication that AI risk management and critical-infrastructure security can no longer be treated as separate disciplines. NIST SP 800-82 Rev. 3, NIST AI RMF and NIST Critical Infrastructure AI Profile

When Does AI Become Part of OT Risk?

Direct control of machinery is not the right threshold. AI should be treated as part of the OT risk environment when it does any of the following:

1. consumes live or historically sensitive OT data;
2. influences an operational, maintenance or safety-related decision;
3. generates code, configurations or instructions used in an industrial system;
4. creates a new connection between OT and an edge, cloud or vendor environment;
5. triggers a workflow that can change equipment or production conditions;
6. performs or initiates an action in the physical environment.

The degree of scrutiny should increase with the system’s operational influence.

Level	Role of AI	Typical example	Primary concern
0	Offline analysis	Analysis of exported historical data	Data handling and model validity
1	Live observation	Anomaly detection using live sensor feeds	Integrity, connectivity and false alarms
2	Recommendation	Maintenance or process advice	Human reliance and incorrect decisions
3	Workflow or engineering output	Work-order creation or PLC code generation	Approval, traceability and change control
4	Supervised action	Operator-approved adjustment	Authority, rollback and safe failure
5	Autonomous action	AI directly changes a physical process	Safety assurance, containment and independent control

This classification is deliberately simple. Its purpose is not to create another governance framework. It is to force one essential conversation: What can the AI influence if it is wrong, compromised or unavailable?

Securing the Convergence Point

An industrial AI assessment must examine the complete path from data source to physical consequence. At minimum, it should establish:

• which assets, processes and safety functions could be affected;
• exactly what data the AI receives and where that data travels;
• whether the system observes, recommends, generates or acts;
• how model and configuration changes are tested and approved;
• how outputs are validated before they enter an operational workflow;
• whether identities and permissions match the intended level of authority;
• how the system behaves when data, connectivity or external services fail;
• whether operators can recognise, reject and reverse an incorrect output;
• whether logs preserve the evidence needed for investigation;
• whether independent safety and control mechanisms remain effective.

Network segmentation, least privilege, controlled remote access and secure update processes remain fundamental. But industrial AI also requires monitoring for changes in model performance, validation against operating conditions, governance of training and contextual data, and explicit limits on what a model is permitted to influence.

Most importantly, increasing automation must not happen silently. A pilot that begins as read-only analytics can evolve into recommendations, automated tickets and eventually machine actions. Every increase in authority changes the risk and should trigger a new assessment.

The Discussion OT Security Teams Need to Start

AI will not replace the basic principles of OT and ICS security. Safety, availability, segmentation, deterministic control and disciplined change management remain essential. But those principles now have to be applied to systems that behave differently from conventional industrial software.

The danger is not simply that an attacker may use AI against a plant. It is that organisations may integrate AI into industrial decisions without recognising that the operational trust boundary has changed.

AI does not need write access to a PLC to become part of OT risk. It only needs enough influence to change what a person or system does next.

That is the convergence point—and it is where industrial AI security must begin.