Why does behavioural AI struggle in OT monitoring?

Why behavioural models miss the shape of OT normality

Behavioural AI works best when normal behaviour is varied enough to learn meaningful patterns. In OT, many assets spend most of their time in stable, repetitive states, so there is less rich behavioural diversity to model. That makes it hard to separate truly unusual activity from ordinary plant rhythm, especially when the process itself is intentionally conservative.

One practical issue is that the model can learn “quiet” normality too well. If a line spends hours in a steady control loop, the model may treat almost any deviation as suspicious, even when the change reflects an expected operating step, a production changeover, or a maintenance action.

OT monitoring also has to cope with processes that are context-sensitive rather than statistically noisy. The same change can be harmless in one phase and dangerous in another, so a purely behavioural approach often needs process state, asset role and engineering context to avoid overcalling routine variation.

Why process context matters more than raw anomaly scores

In industrial environments, a useful alert is not just “different”, it is “different in a way that matters to the process”. A pump restart, a controller mode change, or a temporary override may be legitimate, but the operational meaning depends on where it occurs in the sequence. That is why OT Asset Visibility Guide and OT Network Security Monitoring Guide both emphasise protocol-aware baselines rather than generic network scoring.

Behavioural AI struggles when it cannot distinguish a planned batch cycle from an unsafe deviation, or a failover from a compromise. The model may see both as outliers, but operators need to know which one changes control risk, production quality or safety.

That is also why detections must be tied to the monitored asset’s role in the process. A change that is routine for a historian server can be abnormal for a safety-related controller, and the monitoring logic needs to reflect that difference rather than apply one universal behavioural threshold.

Where false positives and missed context come from in OT

OT environments create false positives when routine activities look irregular to a model that lacks engineering context. Maintenance windows, patching, manual override, setpoint tuning, calibration, and failover often create short bursts of unusual telemetry that are expected, but only if the monitoring stack knows the plant state and change schedule.

They also create false negatives when the attacker behaves “normally” inside the process envelope. If a malicious change stays within a plausible operating range, behavioural AI may not flag it unless there is supporting context such as privileged command use, unusual timing, or deviation from the asset’s normal control role.

For that reason, OT teams usually get more value from combining behavioural detection with protocol inspection, asset criticality and operator context. Behaviour alone is rarely enough to tell whether an anomaly is a nuisance, an engineering event or an early compromise.

Risk and Threat Considerations

OT behavioural monitoring can become noisy fast, and noise is not just an alerting problem. In plants and other industrial environments, false positives can desensitise operators, while false negatives can let small but safety-relevant process changes pass without timely review. The risk grows when the model has no visibility into planned work, process phase or safety constraints.

Failure mechanism: The model learns statistical normality without understanding process state, so legitimate maintenance, batch transitions and failover look suspicious, while controlled but malicious changes can blend into expected operating ranges.

Impact: Teams either chase too many harmless alerts or miss context that would matter for safety, availability or process integrity, which weakens trust in the monitoring stack and can delay escalation when a real control issue is developing.

Practitioner Guidance

What to verify: Check whether alerts are enriched with process phase, asset criticality and maintenance context before anyone treats a behavioural deviation as actionable. If the model cannot explain why a change is abnormal in operational terms, the alert is not mature enough for high-confidence triage.

What good looks like: Strong OT monitoring combines behavioural signals with process-aware baselines, protocol-level visibility and operator workflow context. The result is fewer “interesting but harmless” alerts and more detections that map to meaningful changes in plant behaviour.

Practitioner takeaway: Behavioural AI in OT should be a context amplifier, not the primary judge of abnormality; without process state and engineering semantics, it will usually overcall routine change or undercall slow, plausible abuse.

Related resources from NHI Mgmt Group

• What breaks when AI systems are deployed without behavioural monitoring?
• Should organisations prioritise credential lifecycle controls or behavioural monitoring for AI use?
• What are the main reasons AI agents struggle to achieve enterprise-scale deployment?
• Why is continuous monitoring important for AI agents?