AI in OT systems: it may recommend, never command

Sooner or later, when you deploy AI at a factory, a pumping station or a building, someone from operations will ask you: can this system write anything to the PLC? How you answer decides whether you are invited back or whether the project is moved into the cybersecurity team’s approval queue.

In enterprise software, an agent that gets things wrong produces wrong data or wrong tickets. OT is the systems that control valves, motors and furnaces, so a mistake can go straight out into the physical world.

The FDE skill that matters here, then, is not prompting. You have to design the system so that even if the AI fails or is compromised, it still cannot cause harm.

The good news is that you do not have to work this out from scratch. In late 2025, CISA, ASD ACSC and international partners published joint guidance on integrating AI into OT, built on four principles: understand AI, consider AI use in the OT domain carefully, establish governance and assurance frameworks, and embed safety and security practices into the system itself.

Combine those four principles with the vocabulary of IEC 62443 and you get three design rules that work at any customer.

Three rules: data goes out, people decide, there is always a way back

The first rule: data may flow out, but commands may not flow in. The guidance recommends push-based or one-way transfer architectures to preserve OT network segmentation and reduce the attack surface, rather than giving AI persistent access to the control network.

The model the guidance favours is pushing sanitised OT data out to a separate, protected AI system.

The second rule: humans keep the decision. According to the guidance, important decisions that could affect the physical environment must have a human in the loop.

Legal analyses also stress that human oversight remains a key requirement for safety functions. When you draw this as an architecture, the clearest approach is for the AI only to recommend, while the operator approves and carries out the action by hand.

The third rule: always have a way back. An OT system that uses AI must have documented failure states, and it must be possible to bypass or switch off the AI quickly so operators can return to manual or fixed-rule control.

The stated goal is fail-safe: a faulty or compromised model cannot on its own make a dangerous control decision.

IEC 62443 for newcomers: zones, conduits and security levels

To discuss these three rules with a customer’s OT security team, you need to speak their language, and that language is usually ISA/IEC 62443.

ISA describes the series as a set of requirements and processes for implementing and maintaining security for industrial automation and control systems (IACS) across their lifecycle.

ISA treats shared responsibility as a foundational principle of automation security. For an FDE, the practical reading is that the security of the AI system you bring in is your job too, not just the OT team’s.

The two concepts you will use every day are zones and conduits. Assets with similar protection needs are grouped into a zone.

Communication between zones must pass through controlled conduits, and each zone and conduit has its own level of protection according to risk. Phoenix Contact’s documentation defines a conduit as a logical grouping of network assets used solely for communication between two or more zones.

The third concept, and the one most often misunderstood, is the security level (SL). An SL is not a single number but a vector across seven foundational requirements.

At the two ends of the scale, SL1 targets accidental misuse, while SL4 targets nation-state attackers. The standard also splits SL into three types, and each one prompts a different question for an FDE:

Type	Meaning	The question to ask
SL-T (target)	Derived from risk and threat assessment	What is the SL-T of the zone the AI system connects to, and who assessed it?
SL-C (capability)	What the device or component itself can achieve	What level can the gateway and servers we bring in reach?
SL-A (achieved)	The result of the measures actually deployed	After installation, does the real configuration meet the SL-T?

Example: an energy-optimisation agent for a pumping station

Imagine the customer is a water utility that wants an agent to suggest pump schedules that cut electricity use. The naive design puts the agent on a server inside the control network and lets it read from and write to the PLC directly over an industrial protocol. That design works well in a demo but breaks all three rules at once.

The right design splits the system into three parts. The control zone, with the PLC and HMI, stays as it is. A one-way conduit pushes filtered historian data such as flow, pressure and power to a separate AI zone, and there is no path from that zone back to the PLC.

The agent writes recommendations to a queue. The operator reviews them on a separate screen and, if they agree, enters the change themselves through the HMI.

On the software side, a recommendation might look like this:

from dataclasses import dataclass

@dataclass
class Recommendation:
    asset: str                 # e.g. "pump P-2"
    action: str                # e.g. "lower the VFD frequency"
    rationale: str             # which data led to the recommendation
    data_window: str           # time range of the data used
    status: str = "proposed"   # proposed -> approved / rejected
    decided_by: str | None = None

def decide(rec: Recommendation, operator: str, approve: bool, audit_log: list) -> None:
    if rec.status != "proposed":
        raise ValueError("this recommendation has already been handled")
    rec.status = "approved" if approve else "rejected"
    rec.decided_by = operator
    audit_log.append(rec)      # no command is ever sent down to the control equipment

What matters is what the decide function does not do: it calls nothing in OT. The approver also sees the rationale and the data window behind the recommendation, not just an OK button.

Alongside the code sits a one-page description of failure states: if data is lost, recommendations stop being shown; if the AI needs switching off, who does it, where, and which fixed schedule the station falls back to.

How to start at a customer

The first job is to sit with the OT team, draw the existing zones and conduits, and ask for the SL-T of the zone you plan to take data from. Then propose a one-way conduit and list exactly which data fields are allowed out. “Sanitised” has to be a list you can sign, not an adjective.

The joint guidance treats AI risk as fundamentally data risk, so that list matters as much as the model itself. The guidance also covers defining the vendor’s role in the AI supply chain.

SecurityScorecard’s analysis emphasises requiring OT vendors that embed AI to be transparent about their software components, for example through an SBOM. If you are the vendor, prepare the SBOM before the customer asks.

If the customer works in buildings or access control, also read NIST SP 800-82 Rev. 3 (September 2023). It widens the scope from ICS to OT in general, including building automation and physical access control.

Mistakes that get a design sent back

The most common mistake is understanding “read-only” only at the permission level. A read-only account running over a persistent two-way connection is still a way into the control network, which is exactly what a one-way push architecture exists to eliminate.

The second mistake is turning the approver into a reflexive button press: if operators cannot see the reasoning behind a recommendation, they are signing, not approving.

The third is having a kill switch with no documentation that nobody has ever rehearsed. The fourth is saying “the system meets SL2” as if an SL were a single number, when the OT team will ask about each foundational requirement and whether you mean SL-T, SL-C or SL-A.

For your career: when you see IEC 62443, NIST SP 800-82 or OT/ICS in a job description, have a design like the pumping-station example ready to present in the interview, with a zone and conduit diagram.

On your CV, describe concretely what you did rather than just listing standard names, for example: “Designed a one-way data flow from the historian to an isolated AI zone following the zone/conduit model, with an operator approval process and documented failure states.”

To an operations team, a trustworthy FDE is one who says up front what their AI cannot do, then shows them where that lives in the diagram.