Every technology that has ever been oversold has also had a legitimate use case. The discipline is knowing which is which — and being willing to say so out loud.
The hype problem, stated plainly
Artificial intelligence is being sold to energy operators right now. It is being sold by SCADA vendors embedding “AI-powered anomaly detection” into their platforms. It is being sold by cloud hyperscalers promising that their machine learning pipelines will transform operational data into predictive insight. It is being sold by consultancies with slide decks that place AI at the centre of the energy transition narrative. And it is being sold, in some cases, by people who do not fully understand what they are selling, to buyers who do not fully understand what they are buying, for deployment in environments where a poorly understood system making a poorly understood decision can have consequences that are neither digital nor reversible.
I want to be direct about where I stand before I make the case for AI in OT environments, because the case I am going to make is a narrow one and it will be misread if I do not set the frame clearly:
Machine learning has legitimate, valuable, well-understood applications in operational technology environments. Those applications are specific, bounded, and well-separated from the control plane. They operate on data, not on processes. They inform human decisions, they do not make operational decisions autonomously. They are deployed with the same rigour, perhaps more rigour, that any other change to an OT environment demands.
Outside those bounds, AI in OT is not a security or operational improvement. It is an attack surface expansion dressed in the language of digital transformation. And the energy sector, which is operating infrastructure that nation-state adversaries are actively targeting, cannot afford to expand its attack surface in ways it does not understand.
This post is an attempt to draw that line precisely: where machine learning earns its place in industrial environments, where it does not, and what the architectural and governance requirements are for deploying it responsibly in either case.
Part 1: Why OT is a uniquely difficult environment for AI deployment
To understand why the case for AI in OT must be narrow, you first need to understand what makes OT environments fundamentally different from the enterprise IT contexts where most AI/ML tooling was developed and validated.
The consequence profile is asymmetric. In enterprise IT, an AI system that produces a false positive : flagging a benign event as malicious, blocking a legitimate transaction, misclassifying a document, causes inconvenience. The cost is measurable and recoverable. In OT, a false positive in an AI-driven control or protection system can cause a process shutdown that takes hours or days to recover from, with economic consequences that dwarf the cost of the false alarm. More critically, a false negative, failing to detect an actual process anomaly or security even, can allow a dangerous condition to develop undetected. The asymmetry of consequences demands a higher standard of validation than enterprise AI deployments typically receive.
The training data is scarce and unrepresentative. Machine learning models require training data that is representative of the operational environment they will operate in. In enterprise IT, training data is abundant: years of log data, millions of user events, diverse attack samples from shared threat intelligence. In OT, training data is constrained in every dimension. Process historians may have years of time-series data for normal operations, but attack data is extremely scarce; most operators have never experienced a successful OT cyberattack, and those that have are understandably reluctant to publish detailed data about it. The result is that OT anomaly detection models trained on normal operations data are being asked to detect attack conditions they have never seen examples of. This is not an insurmountable problem, but it is a significant one that must be explicitly acknowledged and addressed in the design of any AI-based detection system.
The environment changes slowly and deliberately. Enterprise IT environments change constantly, new applications, new users, new devices, new configurations. Machine learning models in enterprise contexts are designed to adapt continuously to a changing environment. OT environments change slowly and deliberately, under engineering change control. This is actually an advantage for certain ML applications: a model trained on the normal operating envelope of a stable process can be highly sensitive to deviations, but it means that when the environment does change legitimately (a new field device, a process modification, a seasonal operating mode), the model must be explicitly retrained or its sensitivity will degrade or produce false positives. The retraining process must be integrated into the OT change management workflow, which most AI vendors’ operational models do not accommodate.
The protocols are specialised and the data is physically grounded. Industrial control data is not like enterprise IT log data. It is time-series telemetry from physical sensors, temperatures, pressures, flow rates, valve positions, electrical parameters, that reflects the state of a physical process governed by physical laws. Anomaly detection in this context requires models that understand the physics of the process, not just the statistical properties of the data. A temperature reading that is anomalous in a statistical sense may be entirely normal given the current operating mode, the ambient conditions, and the recent history of the process. Models that do not incorporate process context produce alert volumes that overwhelm operators and train them to ignore the detection system, which is precisely the outcome you are trying to avoid.
Latency and determinism requirements may be incompatible with ML inference. Some AI advocates propose deploying ML models in the control loop; models that influence control decisions in real time based on process telemetry. In most process control contexts, this is architecturally unacceptable. Control loops have deterministic timing requirements, a PLC executing a control programme at a 100ms scan rate cannot accommodate the variable inference latency of a neural network. Safety-related functions have additional requirements: IEC 61511 defines specific requirements for the software used in safety instrumented systems, and general-purpose ML frameworks do not meet those requirements. The control loop and the safety layer are not appropriate places for AI. The observational layer where data is collected, analysed, and presented to operators for decision-making is where AI can legitimately operate.
Part 2: Where ML genuinely earns its place: anomaly detection on process telemetry
With those constraints established, let me make the affirmative case. The most mature and well-validated application of machine learning in OT security is anomaly detection on process telemetry: using statistical and ML techniques to identify deviations in process behaviour that may indicate a cyberattack, equipment fault, or process upset.
The case for this application rests on a specific observation: sophisticated attackers targeting OT environments must, at some point, cause the physical process to behave differently from how it behaves under normal operation. This is true whether the attack is a ransomware operator shutting down a SCADA server, a nation-state actor manipulating setpoints to cause equipment stress, or an insider making unauthorised process changes. The physical process reflects the attack, even when the digital systems reporting on that process have been compromised to conceal it. A process-physics-aware anomaly detection system that monitors raw sensor telemetry: independent of the SCADA platform reporting layer, can detect the physical signature of an attack even when the SCADA system is reporting normal.
This is the architecture that Dragos, Claroty, and Nozomi have built their OT network detection platforms around: passive monitoring of industrial network traffic, including the raw telemetry values in OPC-UA, Modbus, and DNP3 transactions, with anomaly detection logic calibrated to industrial protocols and process behaviour. The ML component here is specific and bounded: it characterises the normal operating envelope of the process from historical telemetry, identifies statistically significant deviations from that envelope, and presents those deviations to human analysts for investigation and response. It does not make control decisions. It does not interact with the control plane. It observes and alerts.
Implementing process telemetry anomaly detection well requires several things that vendors rarely emphasise:
The model must be trained on data that represents the full range of legitimate operating conditions, including seasonal variations, planned maintenance modes, startup and shutdown sequences, and any other normal operating state that differs from the baseline production mode. A model trained only on steady-state production data will generate false positives during every planned startup and shutdown, which trains operators to ignore it during exactly the periods when adversaries might attempt to exploit the distraction of a transition.
The anomaly detection system must be architecturally independent of the systems it is monitoring. If the SCADA platform is compromised, the anomaly detection system must continue to function and must not rely on data from the compromised SCADA platform. This means the anomaly detection system taps raw network traffic:a SPAN port on the OT network switch, or an inline tap, rather than consuming data from historian or SCADA APIs. Independence is the architectural property that makes the detection system valuable precisely when it is most needed.
Alert triage must be integrated into operations workflows. An anomaly detection system that generates alerts into a security SIEM that nobody in operations watches is not a detection system. It is a compliance checkbox. The integration between the OT anomaly detection platform and the operations team, the control room operators who have the process knowledge to assess whether an anomaly is a security event, a process upset, or a sensor fault, must be explicitly designed, and the operations team must be trained to use it.
Part 3: Predictive maintenance: the highest-ROI ML application in OT
If anomaly detection is the most security-relevant ML application in OT, predictive maintenance is the highest-ROI application and the one with the longest track record of successful deployment in industrial environments.
Predictive maintenance uses ML models trained on historical sensor data, vibration signatures, temperature trends, current draw patterns, acoustic emissions to predict equipment failure before it occurs, allowing maintenance to be scheduled during planned downtime rather than executed reactively during an unplanned outage. For rotating equipment: compressors, pumps, turbines, motors, the vibration signature of developing bearing wear, impeller damage, or shaft misalignment is detectable weeks or months before the equipment fails. A model trained on the vibration history of similar equipment can identify the early signature of failure and schedule maintenance with sufficient lead time to avoid the failure.
The operational economics of this are compelling for energy operators. An unplanned compressor failure at a gas processing facility can cost millions in lost production and emergency maintenance, in addition to the safety risks of an uncontrolled shutdown. A bearing replacement scheduled during a planned maintenance window costs a fraction of that. The ML model does not need to be particularly sophisticated to deliver that value,in many cases, relatively simple statistical process control models applied to sensor trend data outperform more complex ML approaches because the physics of equipment degradation are well-understood and the features that predict failure are known.
The architecture for predictive maintenance is important to get right, because the data flows required to train and operate these models are among the most common routes through which OT data ends up in cloud environments with inadequate security controls.
The appropriate architecture separates the data collection layer (which remains within the OT environment) from the model training and inference layer (which can legitimately operate in a cloud or enterprise environment) and from the control interface (which must remain within the OT environment and must not receive automated commands from the model). Process data flows from the OT historian to the predictive maintenance platform through the defined IT/OT boundary architecture, the historian boundary described in the previous post. The predictive maintenance platform generates maintenance recommendations, not control commands. Those recommendations are reviewed by engineers and translated into work orders through the maintenance management system. At no point does the ML model have a path back to the control system.
This architecture is violated with depressing frequency by vendors whose integration story involves an API connection from their cloud platform back into the OT historian or, in the most egregious cases, into the SCADA system directly. The integration story is presented as a feature: seamless bidirectional data flow, closed-loop optimisation, real-time model updates. The security architecture implication: a persistent connection from a vendor-managed cloud environment to the operational control systems of a critical infrastructure operator, is presented as an implementation detail. It is not an implementation detail. It is a fundamental architectural decision that should be subject to the same scrutiny as any other conduit through the IT/OT boundary.
Part 4: Network traffic analysis: ML for OT network security monitoring
A third legitimate ML application in OT environments is network traffic analysis for security monitoring: using ML techniques to characterise the normal communication patterns of an OT network and identify deviations that may indicate a security event.
OT networks have communication patterns that are highly regular and predictable by design. A PLC polling a sensor at a 500ms interval produces a deterministic traffic pattern. An HMI querying a SCADA server produces a predictable set of transactions at predictable intervals. Engineering workstations typically communicate with a small, defined set of systems using a small, defined set of protocols. This regularity is a security asset: it means that anomalous traffic: a new connection, an unexpected protocol, a polling interval that changes without a corresponding engineering change, is detectable against a well-characterised baseline.
ML-based network traffic analysis for OT combines two techniques. The first is protocol-aware deep packet inspection: parsing industrial protocol transactions:Modbus function codes, DNP3 application layer messages, OPC-UA service calls to extract the semantic content of communications, not just their network properties. This allows the detection system to distinguish between a PLC responding to a normal read request and a PLC receiving an unexpected write command that modifies a control setpoint. The second is behavioural baseline modelling: characterising the normal communication graph of the OT network, which devices talk to which other devices, using which protocols, at what frequency and alerting on deviations from that baseline.
The combination provides detection coverage for several important attack technique categories from MITRE ATT&CK for ICS: new connections from previously unseen source addresses (relevant to lateral movement), unexpected engineering protocol transactions (relevant to manipulation of control logic), changes in polling frequency or payload size (relevant to data collection by an adversary mapping the process), and new device appearances on the network (relevant to adversary persistence through rogue hardware).
The architectural requirement here is passive monitoring,a read-only tap on the OT network, with no ability for the monitoring system to inject traffic or modify network state. The monitoring system should be on a separate, isolated network segment that receives mirrored traffic but has no routed path back to the monitored network. Detection output goes to a security monitoring platform, not back into the OT environment.
Part 5: Where AI does not belong in OT: the hard limits
Having established where ML has legitimate application, I want to be equally explicit about where it does not belong. These are not nuanced positions where reasonable practitioners might disagree. They are hard architectural limits that reflect the safety and reliability requirements of operational technology environments.
AI must not be in the control loop. Any ML model whose output influences the setpoints, mode selections, or command sequences of a process control system is in the control loop. This includes “AI-driven optimisation” systems that adjust setpoints in real time to optimise yield, energy consumption, or throughput. The safety case for a control system function must demonstrate that the function behaves correctly under all anticipated conditions, including failure conditions. A general-purpose ML model cannot satisfy this requirement, its behaviour under adversarial inputs, distribution-shifted inputs, or edge cases that were not represented in training data is, by definition, not fully characterised. IEC 61511’s requirements for safety instrumented functions explicitly require deterministic, validated logic. Machine learning does not satisfy those requirements.
This does not mean that AI-generated insights cannot inform setpoint decisions. It means that a human engineer or operator must make the decision to adjust a setpoint, based on the AI system’s recommendation, through the normal process for initiating control changes. The AI is an advisory system. The human is the control loop.
AI must not make autonomous security response decisions in OT. The automated response capabilities that are standard in enterprise IT security, automated isolation of a compromised host, automated blocking of malicious traffic, automated revocation of suspicious credentials,are not appropriate for OT environments without extensive operational validation. Isolating a host in the enterprise IT environment may disrupt a user’s productivity. Isolating a SCADA server may disrupt a control function. Blocking traffic on an OT network may interrupt a polling cycle. These are not equivalent consequences, and the decision to take automated defensive action in an OT environment must be made by a human who understands the operational implications.
The appropriate model for AI in OT security operations is detect and alert, with human-initiated response. The detection system identifies an anomaly and presents it to an analyst. The analyst assesses the anomaly, consults with operations if needed, and initiates a defined response procedure. The response procedure is executed by humans, not by automated playbooks.
AI must not be the single source of truth for process state. Some vendors are positioning AI-based “digital twin” systems as the primary representation of process state, with the physical instrumentation treated as one input among many. The process state, for operational and safety purposes, must be determined from calibrated, validated physical instrumentation not from an AI model’s prediction of what the instrumentation should be reading. An AI model that predicts process state may be valuable for anomaly detection (if the model’s prediction diverges significantly from actual measurement, that divergence is worth investigating). It must not be used to override or substitute for physical measurement in any safety-relevant context.
LLMs have no place near a PLC without robust, validated sandboxing. The enthusiasm for applying large language models to OT contexts for natural language interfaces to SCADA systems, for LLM-generated control logic, for AI-assisted engineering,deserves specific comment, because it is being pursued in the vendor community right now and the risks are not being adequately discussed.
LLMs are probabilistic text generators. They produce outputs that are statistically plausible given their training, but they do not reason about physical consequences and they do not have guaranteed behaviour. An LLM generating control logic for a PLC may produce code that looks syntactically correct and operationally plausible but contains subtle errors that only manifest under specific process conditions. An LLM providing a natural language interface to a SCADA system may interpret an ambiguous operator instruction in a way that the operator did not intend. These failure modes are not hypothetical,they are well-documented in the LLM research literature. In an enterprise IT context, they are inconvenient. In a control system context, they are dangerous.
The appropriate use of LLMs in OT contexts is in environments that are completely isolated from the control plane: documentation generation, knowledge base query, training and simulation. Any architecture that provides an LLM with a path to influence process state:however mediated, requires the same rigorous safety validation that any other control system software modification requires, and current LLM technology cannot satisfy that validation requirement at general-purpose capability level.
Part 6: The governance architecture for AI in OT
Assuming you have identified a legitimate ML application,anomaly detection, predictive maintenance, network traffic analysis , and you have validated that it satisfies the hard limits described above, the governance architecture for deploying and operating it in an OT environment requires several elements that AI projects in enterprise IT contexts do not typically address.
Model validation before deployment. The ML model must be validated against a representative test dataset before deployment in the production environment. For anomaly detection models, this means validating both sensitivity (the model detects known attack patterns or process deviations) and specificity (the model does not generate false positives for known legitimate operating conditions). The validation must include the full range of legitimate operating modes, startup, shutdown, maintenance, seasonal variation, not just steady-state production. Validation results must be documented and reviewed by both the security team and the operations team.
Ongoing model performance monitoring. Model performance degrades over time as the operational environment drifts from the conditions represented in training data. The governance programme must include regular assessment of model performance: false positive rates, detection rates against known test cases and a defined process for retraining or recalibrating models when performance degrades below defined thresholds.
Change management integration. Every change to the OT environment that affects the data the ML model processes must trigger a model review. New field devices, process modifications, changes to operating modes , all of these change the distribution of data the model sees and may require model retraining or recalibration. The ML system’s operational documentation must be updated to reflect changes in the monitored environment, and the model must be validated in the new configuration before the change is accepted as complete.
Explainability requirements. In an OT environment, an ML model that generates an alert must be able to provide a human-understandable explanation of why it generated that alert. “The model flagged this as anomalous” is not a sufficient explanation for an operations team that needs to decide whether to initiate a process shutdown or a security response. The model must be able to identify which sensors or network flows contributed to the anomaly score and what their deviation from baseline was. Black-box models whose outputs cannot be explained to the operations team that must act on them are not appropriate for OT deployment.
Vendor dependency management. Many ML platforms for OT are vendor-managed cloud services. The vendor hosts the model, the vendor processes the data, and the vendor provides the alerts. This creates dependencies that must be explicitly managed: what happens to the detection capability if the vendor is acquired, goes out of business, or terminates the service? What data is being processed by the vendor and where? What are the vendor’s obligations if the processed data reveals a security incident? These are not abstract questions they are operational risk management requirements that should be resolved before deployment, not after.
Conclusion: Precision over enthusiasm
The energy sector needs a more sophisticated conversation about AI than it is currently having. The binary choice between enthusiastic adoption of every AI capability that vendors offer and blanket rejection of AI as incompatible with operational safety is a false choice that serves neither operators nor the sector.
The conversation that is needed is precise. It distinguishes between AI applications that are observational and advisory which have legitimate, validated use cases in OT environments and AI applications that are autonomous or that operate in the control plane which do not. It distinguishes between ML techniques whose behaviour can be characterised and validated against the requirements of the deployment environment and those whose behaviour under edge cases and adversarial inputs cannot be. It distinguishes between AI deployments that strengthen the existing security architecture and those that expand the attack surface in ways that are not adequately compensated by the security value of the AI capability itself.
Making those distinctions requires technical depth, operational experience, and a willingness to tell vendors that their integration story is architecturally unacceptable. It also requires the intellectual honesty to acknowledge, when a vendor’s AI capability genuinely delivers value within appropriate constraints, that the technology has earned its place.
The narrow case for AI in OT is a real case. It deserves to be made precisely, and then defended precisely against the much broader case that vendors and enthusiasts will continue to press.
That defence is part of the security architect’s job. In critical infrastructure, it may be one of the most important parts.
Key references and further reading
- MITRE ATT&CK for ICS — Collection and Discovery Tactics — attack.mitre.org/matrices/ics/ — The adversary technique catalogue relevant to the detection use cases described in Parts 2 and 4.
- IEC 61511-1:2016 — Functional Safety: Safety Instrumented Systems for the Process Industry Sector. The functional safety standard that governs what software may perform safety-related functions — directly relevant to the hard limits in Part 5.
- ENISA — Artificial Intelligence and Cybersecurity — European Union Agency for Cybersecurity guidance on AI security considerations, including adversarial ML risks relevant to Part 5.
- Dragos — OT Anomaly Detection — Technical documentation on the passive monitoring and protocol-aware detection architecture described in Parts 2 and 4.
- Claroty — Continuous Threat Detection — Technical documentation on ML-based OT network behavioural analysis.
- NIST AI RMF (AI 100-1) — The NIST AI Risk Management Framework. A governance reference for AI deployment that, with adaptation for OT constraints, provides the structure for the governance programme described in Part 6.
- IEC TR 63069 — Industrial-Process Measurement, Control and Automation — Framework for Functional Safety and Security. The technical report addressing the intersection of functional safety and cybersecurity, directly relevant to the ML governance requirements in Part 6.
- Gartner — Operational Technology Security — Market analysis relevant to the vendor ecosystem described in Part 3 and the vendor dependency management considerations in Part 6.
This post is part of an ongoing series on security architecture for critical infrastructure and energy systems. The next post addresses sovereign cloud architecture for regulated energy operators — how to build a cloud control plane that delivers the operational benefits of cloud computing while satisfying the regulatory and security requirements of a critical infrastructure operator.
About the author: Infrastructure Architect with 14 years of experience spanning enterprise architecture, operational technology environments, and regulated digital infrastructure. Currently leading infrastructure architecture for a major energy operator. Holds CISSP certification. Previously Technical Director at a digital health startup. Views expressed are personal.