The Transparency Curve: Understanding Statistics, Machine Learning, LLMs, and AI in OT Cybersecurity

Dr. Rishabh Das

Critical Infrastructure Cybersecurity researcher at Assistant Professor, Ohio University || Web

Dr. Rishabh Das is an Assistant Professor at the Scripps College of Communication, Ohio University. Dr. Das has over a decade of hands-on experience in operating, troubleshooting, and supervising control systems in the oil and gas industry. Dr Das's research portfolio includes virtualization of Industrial Control Systems (ICS), threat modeling, penetration testing in ICS, active network monitoring, and the application of Machine Learning (ML) in cybersecurity.

The term Artificial Intelligence (AI) often covers everything from a mathematical decision tree written in 2011 to a large language model deployed last quarter. Discussions about AI in OT cybersecurity rarely distinguish between the two, because it forces a harder conversation that gets into the nuts and bolts of the solutions.

But that harder conversation is the one worth having. Understanding what is running under the hood lets a defender answer two questions: 

• When will this solution generate an alert? 
• Why did it fire?

In Information Technology (IT), that trade-off is often acceptable; a false positive costs an analyst ten minutes. In Operational Technology (OT), defenders cannot add a protection layer that acts on probability. For example, a relay that trips a turbine has to be deterministic and certifiable, because the failure mode is a physical event. So it is important to understand the four terms that get flattened into “AI”: statistics, machine learning, artificial intelligence, and large language models (LLMs). Doing so is what lets us see how transparent a given decision really is, and how close to the physical process it can be trusted to sit.

Without giving out spoilers, I can tell you this: Most of the time, as models move up the complexity curve, decision transparency often takes a hit.

Four Terms, One Transparency Curve

Each technology sits at a different point on the same curve: as capability and pattern-finding power go up, the ability to point to a single, auditable reason for an output goes down. Where a model sits on that curve determines whether it belongs near a protection function, or only ever near a screen a human is watching.

Statistics: fully transparent, fully deterministic

Statistics describe data and quantify uncertainty. Using statistical parameters such as means, variances, and control limits, engineers can specify logic in advance. Every alert traces back to an exact, reproducible rule.

Example use case: A Statistical Process Control (SPC) chart on a boiler feedwater pump can monitor flow rate. When a bearing degrades, the reading drifts outside the control limit and triggers an alert. The workflow is always answerable in one sentence: “flow exceeded the upper control limit by X.” This is precisely why statistics is the only category of the four that regularly sits inside the actual protection layer.

Machine Learning: probabilistic, explainable in aggregate – not in the instant

Machine learning generalizes statistics by letting an algorithm learn parameters from a dataset rather than having them specified by an engineer. Algorithms like isolation forests, LSTMs, and autoencoders fall here. ML finds structure in a large dataset. The structure defines model weights that are often abstract and do not always translate to operational thresholds.

Example use case: Imagine an ML model that learns how a water treatment plant normally operates by observing things like water pressure, flow rate, chlorine levels, and valve positions. Over time, it recognizes the normal patterns between these measurements. If a cyberattack secretly changes how a valve behaves while also faking the sensor readings to look normal, the ML model can still notice that something doesn’t “fit” and raise an alert even though every individual sensor appears normal.

The model can later explain which measurements contributed to the alert, but because machine learning models learn from data, their behavior can change when they are retrained. That’s why models are a powerful tool for monitoring and detecting suspicious activity, but critical safety decisions are still best handled by deterministic engineering controls rather than machine learning alone.

Artificial Intelligence: the umbrella

AI is the broadest category, and usually includes any tasks associated with intelligence, including planning, reasoning, and perception. Machine learning is a subset of AI, and so are statistical systems. Calling a product “AI-powered” says nothing about its mechanism, which is why the term gets mixed up.

Example use case: A security system that watches an industrial network follows simple rules, such as “If someone changes a controller setting outside of scheduled maintenance, raise an alert.” It also uses AI to spot unusual behavior and considers how important each device is before deciding how serious the alert should be. Intelligence comes from combining these different approaches, not from a single AI model. A well-designed system tells security teams why an alert was triggered, whether it came from a rule, the AI, or another source. A poorly designed system simply displays a mysterious “high-risk” score without any explanation, making it difficult for defenders to know what happened or whether the alert can be trusted.

Large Language Models: fluent, but not deterministic by design

LLMs use transformer-based architectures that excels at natural language by predicting the statistically likely next token (Output). They do not natively understand Modbus registers or physics, and they do not execute verifiable logic. They generate the most plausible-sounding continuation of a prompt.

Example use case: An AI detection system first identifies an unusual event, such as “Flow sensor FT-204 has been reporting values much higher than expected for the last 90 seconds.” An LLM then reads this alert along with maintenance records and past incidents to generate a human-friendly explanation, such as: “The flow sensor is reading about 12% higher than expected, which could indicate a partially closed valve. A similar pattern was observed during a false alarm in March.”

The important point is that the LLM did not detect the problem, it explains information produced by other monitoring systems. Because LLMs can occasionally generate convincing but incorrect responses, they should never make critical safety decisions on their own. Instead, they should be used to help operators understand alerts that have already been generated by more reliable and transparent detection methods.

Why OT Cannot Let a Protection Layer Act on Probability

The Purdue Model’s layered architecture segments IT and OT because the two environments carry different risk profiles. Physical safety concerns are concentrated at Levels 0-2, while confidentiality and data volume become more prominent higher up the stack. Protection functions at the lower levels – safety-instrumented systems, interlocks, emergency shutdown logic – are typically certified against standards such as IEC 61508 and IEC 61511, which require a documented, reproducible chain of reasoning from input to trip decision. A model that cannot state with certainty why it produced a given output cannot be certified into that chain, no matter how accurate it is on average.

This is a structural property of probabilistic and generative models, not a maturity gap. More training data will not close this gap. LLMs tend to optimize for the best answer across a distribution, not a guaranteed-correct answer for the one input in front of them right now. For teams evaluating AI in OT cybersecurity, the key issue isn’t whether a tool uses AI, but whether its decisions are transparent enough for the operational context where it is used.

The Takeaway

None of these four technologies is new. Statistics have guarded control loops since before “cyber” meant anything in OT, precisely because its logic is fully transparent. Machine learning found the anomalies in large datasets that statistics could not, at the cost of instant, deterministic explainability. AI is the umbrella term for how those pieces get orchestrated into a decision. That decision is only as transparent as the orchestration design. LLMs sit furthest from the physical process for a reason; they are the least deterministic of the four and most useful precisely where determinism is not required.

The question worth asking about any AI technology in OT is not “How accurate is it.” It is “What happens when I ask it why it alerted, and is that answer something a safety engineer could sign off on?” If the answer gets vaguer as the technology gets more impressive, that technology belongs further from the protection layer. Defensive security across the Purdue stack is not being reinvented by LLMs in OT security. But it is being made legible, faster to act on, and more accessible to the people standing closest to the process. That’s a meaningful acceleration that will help defenders across all layers.