Failure or cyberattack? Detecting reactor anomalies with an AI you can understand

Picture the control room of a power plant. An indicator is drifting: the water level in a steam generator is no longer quite what it should be. The operator has a few seconds to settle a question that is anything but trivial: is a sensor giving out, or is an attacker lying to the instruments?

The two symptoms look alike. The two responses are opposite. If it's a failure, you repair the component and life goes on. If it's a cyberattack, you may need to shut down the reactor, a heavy, costly maneuver, but sometimes a vital one. Get it wrong one way and you lose millions for nothing. Get it wrong the other way and you miss an accident.

I recently came across a research paper that tackles exactly this problem. And it put words to an intuition I'd been carrying around since my I&C classes: in an environment like this, an AI that detects isn't enough. You need an AI that explains.

That's what I want to talk about.

I. A power plant has become code#

We still picture nuclear power as a world of pipes, steam and big mechanical buttons. The reality is more mundane: a modern plant is first and foremost an instrumentation and control system (I&C), in other words a vast network of sensors, controllers and digital computers that measure, decide and command continuously.

This digitalization has a downside: anything connected can be attacked. And an anomaly in the I&C can have two radically different origins.

A random failure. A component gives out. Typically, the system stops responding, or a feedback signal drops out. It's a reliability problem.

A deliberate cyberattack. This one is sneakier: the system may keep behaving normally on the surface, while someone quietly falsifies the measurements or the commands. It's a security problem.

The trap is that both can produce the same symptom on the surface. Yet the response is not the same at all: you don't repair malicious intent, and you don't shut down a reactor because a sensor burned out. Identifying the nature of the anomaly quickly and correctly isn't a nicety: it's what separates the right decision from disaster.

II. AI can detect, but it can't justify itself#

This is exactly the kind of task where AI excels. Learning what normal operation looks like from mountains of data, then spotting the deviation that doesn't fit: that's tailor-made for anomaly detection models. On paper, the operator has the ideal ally to get out of the dilemma.

Except there's a catch, and it's the heart of the problem. Most of these models (large neural networks in particular) are black boxes. They output a verdict: "anomaly" or "nothing to report". But they can't say why. And in a control room, an answer without a justification isn't worth much.

Because the operator's real question isn't just "is there an anomaly?". It's "can I trust you before I shut down a reactor?". A human who has to make a call worth several million euros, or one that puts the safety of a facility on the line, needs to check the reasoning, not be handed an oracle. Explainability isn't a cosmetic luxury here. It's the condition for anyone to agree to trust the system.

And here I come back to an obsession that runs through everything I write about AI: an answer you don't understand isn't really an answer. It's a bet disguised as certainty.

III. The trick: splitting the problem into layers#

The paper's idea is elegant, and very "engineer" in spirit: rather than a single giant AI that swallows everything and spits out an opaque verdict, you split the problem along the actual structure of the I&C.

An I&C system is organized in layers. At the very bottom, the sensors and actuators, which touch the physical process. Above them, the controllers: the programmable logic controllers, or PLCs. Higher still, the supervision and management workstations. And, crucially, an attacker has neither the same skills nor the same entry points depending on the layer they're targeting.

So the framework sets up three specialized detectors, one per layer, each fed with its own type of data:

• an IT module, which monitors network traffic: the top layer, where most attacks come in;
• an ICS module, which monitors controller data: cycle time, PLC state;
• a Process module, which monitors the reactor's physical variables: level, flow, pressure.

And that's where the mechanism gets clever. Each module simply answers 0 or 1: normal or abnormal. But it's the combination of the three answers that becomes the explanation.

In other words, the system doesn't just say "attack" or "failure". It says where it's happening and how far it reaches. The explanation isn't bolted on afterward to reassure the operator: it's built into the architecture itself.

One last point I found satisfying as a future engineer: each layer gets its own algorithm. The network and PLC data, which are tabular, are handled by methods suited to them: random forests, gradient boosting. The process variables, which are time series, are handed to a network specialized in time (an LSTM), trained to predict normal behavior and to raise the alarm as soon as reality departs from it. You don't reach for the biggest hammer; you pick the right tool for the data. The result on their test bench: around 99% correct identification.

Conclusion: explainability as a design constraint#

This paper struck me less for its numbers than for what it says between the lines. We tend to judge an AI on its performance: its detection rate, its accuracy. But in a critical system, that criterion is incomplete. An AI that is right but can't justify it remains unusable, because no sensible person will shut down a reactor on the word of a silent oracle.

Explainability shouldn't be a layer you add at the end to make things look nice. It should be a design constraint, on the same footing as accuracy or latency, built in from the architecture stage, as it is here. It's exactly the same reflex as for energy, or for our own dependence on these tools: whatever we treat as a detail always ends up catching up with us.

And let's be honest: it isn't magic. In their own tests, a handful of very stealthy attacks slipped under the radar, misclassified because they affected the process too slightly and too briefly to cross the alarm threshold. That's precisely why we keep a human in the loop, and why we want that human to understand what the machine is showing them, so they can catch what it lets through.

Thinking about AI like an engineer doesn't mean asking it to be right. It means asking it to be able to prove it.

An answer without an explanation doesn't remove doubt. It moves it.