AI Safety in Industrial Control Systems

Industrial control systems are built around predictable behavior. If pressure crosses a limit, a valve opens. If temperature keeps climbing, power is cut. The point is not elegance. The point is that the system keeps people alive when everything else gets messy.

AI does not behave that way. It can find patterns, recommend tuning changes, and spot operating conditions that a human might miss. It can also be confidently wrong in ways that are hard to reconstruct after the fact.

That gap matters in environments where a rare mistake can become a physical incident.

The Basic Conflict

Connectivity Creates Exposure

AI systems want data: sensor streams, historian data, maintenance notes, operating history, and feedback loops. OT security has spent decades limiting exactly that kind of connectivity. The more data paths you open, the more places an attacker can interfere.

Probabilistic Advice Is Not A Safety Function

Standards like IEC 61508 assume software behavior can be specified, tested, and bounded. A model optimizing for yield or efficiency may recommend a change that looks valid statistically but violates the reason a safety margin exists.

That does not make AI useless. It means AI cannot be the final authority.

Forensics Get Harder

After an incident, logs usually answer a practical question: what happened? With an AI-assisted decision, you also need to know what the model saw, what version was running, what prompt or policy wrapped it, and why the output passed downstream checks.

That is a lot more than a timestamp and a command.

Standards Are Necessary, But Not Sufficient

The difficult case is not an unauthenticated attacker. It is an authenticated AI agent or operator workflow issuing a command that is technically allowed but physically unsafe.

How I Would Bound It

Keep Proposal And Execution Separate

Let the model propose. Do not let it execute directly.

For example, an AI can recommend a temperature adjustment. A deterministic control layer should still check hard limits for pressure, temperature, reaction rate, maintenance state, and operating mode. If the recommendation fails those checks, it dies there.

Log The Decision Trail

For every recommendation, keep enough context to replay the decision:

• sensor inputs
• model and prompt version
• recommendation
• deterministic checks applied
• operator action
• final execution result

This is useful for investigations, but it is also useful for catching drift before there is an incident.

Keep Hardware Interlocks Independent

Mechanical pressure relief, analog cutoffs, emergency stop circuits, and firmware limits should not depend on the AI stack. They are not backups to the model. They are the safety system. The model is just another input operating inside those boundaries.

Validate Sensors Continuously

If the model trusts bad sensor data, it will produce bad advice. Cross-check sensors against physics, not only against historical averages. Temperature and pressure relationships, impossible rate changes, and inconsistent redundant sensors should all be treated as safety signals.

The Hard Line

AI can be useful in industrial environments when it is treated as an optimizer inside fixed physical limits. It should not replace deterministic safety controls, and it should not be allowed to explain its way past them.

The question is not whether a model can outperform a tired operator on a normal day. The question is whether the system remains safe when the model is wrong.