An AI agent can write PLC logic that compiles and still fail the machine it was meant to control. The problem is not that industrial automation is mysteriously immune to software tooling. It is that a PLC program sits between a written intent and a physical process. The evidence needed at each step is different.

There is already useful AI work at the engineering desk. The risky claim begins when a generated program, a green simulator run or a clean syntax check is treated as permission to operate a plant. I would build the workflow as an evidence ladder: requirement → generated logic → modeled fault behavior → isolated controller test → authorized commissioning → observed physical acceptance. The qualified engineering and safety owners decide when a change moves up that ladder.

This article uses a fictional conveyor with a jam sensor that may remain high or report stale state. It is a design exercise, not a client incident, physical test or recipe for changing a live machine.

The useful work AI can do now

Siemens describes its Eigen Engineering Agent as generating or adapting SCL and LAD logic, generating test logic, fixing compile or syntax errors, changing properties, documenting a project and helping interpret legacy code inside the TIA environment. That is a credible scope of engineering assistance. Siemens also publishes productivity and quality figures on the product page; those are vendor claims, not independent evidence of physical acceptance at any given site.

The benefit is not limited to writing rungs. An agent can trace a requirement to tags and I/O, propose a state-machine table, draft test cases for abnormal conditions, compare a new block with the old one, write review notes and preserve a change packet. These are valuable because they make the engineering decision more inspectable. Whether they save time depends on the acceptance workflow, including specialist review, correction, downtime planning and commissioning. Counting generated lines or a model's response time misses the cost that actually governs a plant change.

The PLCopen description of IEC 61131-3 is a clean boundary. That part standardizes syntax and semantics of programming languages for programmable controllers. It is not a plant commissioning protocol, a physical fault oracle or safety signoff. A correct SCL program can implement the wrong requirement, map to the wrong signal, or behave differently under actual scan, network and actuator timing.

Write a physical contract before generating logic

Consider the fictional conveyor. The brief says, “If material jams, stop the line and alert the operator.” Before asking a model for ladder or structured text, a qualified engineer must turn that sentence into explicit decisions:

The right values and response windows are site- and hazard-specific. This article does not invent them. The point is that an agent cannot infer them safely from a generic “stop on jam” prompt. The owner writes the expected transition and acceptable observation first. The agent can then generate a candidate implementation and tests against that owned contract.

Even a detailed requirement can be tested from the wrong vantage point. Suppose the generated logic commands the motor output off when the sensor stays high. The unit test asserts motor_command = false and passes. A physical acceptance criterion also needs to observe the relevant motion or feedback under a defined time window, and record whether the sensor signal remained credible. A command receipt alone proves what the PLC asked for. It does not prove what the machine did.

The evidence ladder is a series of different oracles

I would record the following gates for each change, with a named owner and an artifact at every level:

1. Requirement: Signed behavior and hazard assumptions, including abnormal and recovery states. The oracle is the intended machine behavior approved by the relevant engineering owner.
2. Language and build: IEC 61131-3 syntax, vendor compiler and project consistency. The oracle is a valid build for the exact target and version. It says little about physical behavior.
3. Offline simulation: Normal and fault sequences against an explicit sensor/actuator model. The oracle is the simulation's predicted state and trace, conditional on model fidelity.
4. Isolated controller or hardware-in-the-loop bench: The target controller family, firmware and representative I/O interfaces with the physical machine disconnected. The oracle is measured controller response and communication behavior on the authorized bench.
5. Controlled commissioning: A site-approved procedure, change window, responsible personnel and stop/rollback criteria. The oracle is the observed installed system under conditions the site has authorized.
6. Post-change readback: Actual machine and controller state, alarms, operator experience and rollback readiness. The oracle is independent observation after the deployment artifact was applied.

These are not a ladder of “more tests of the same thing.” They answer different questions. The Siemens Automation Framework documentation lists PLC simulation, TIA Portal Test Suite, SIMIT models of sensors/drives/I/O and NX Mechatronics Concept Designer physics work as distinct tools. That division is useful: a syntax check, virtual controller, process model and motion model each contribute evidence at a different seam. Siemens' virtual-commissioning guide describes the engineering setup, not an exemption from actual commissioning.

The change packet should connect those gates with a common ID: signed requirement, generated diff, I/O map, controller and firmware target, model assumptions, fault traces, bench record, commissioning result, independent physical readback and rollback package. When a fault is discovered later, a team can identify which assumption failed instead of re-prompting the agent and hoping.

A green digital twin can be an honest result of an incomplete model

Digital twins and virtual commissioning can surface faults before a plant is touched. They are especially valuable when physical test windows are expensive. But a twin can only evaluate behaviors represented in its inputs and model. In the conveyor case, if the jam sensor is always fresh in the simulation and the drive always follows the commanded state instantly, then a perfect simulated stop tells us nothing about stale input or delayed motion.

NIST's digital-twin credibility research calls for verification, validation and uncertainty quantification across the twin's lifecycle. I would make that operational with a mismatch register: the scenario or signal, what the model predicted, what a bench or plant observation showed, the uncertainty or omitted fault, and the decision about whether the twin may be used for this acceptance question. A mismatch is not a reason to abandon simulation. It is a reason to narrow the claim, improve the model or add an independent test.

That is the specific failure of an “AI-generated tests passed” statement. An agent can generate both control code and a simulator that shares the same mistaken assumption. The harness needs externally supplied fault cases and owner-labeled expected outcomes. For the stuck sensor, test at least fresh/high, stale/high, contradictory feedback and recovery paths in a disposable model. Change one assumption deliberately and check that the acceptance gate turns red. A simulator with no negative control can be very polished and still be self-confirming.

Keep functional safety and cybersecurity distinct

An AI integration changes both the engineering process and the OT trust boundary. ISA/IEC 62443 is a cybersecurity series for industrial automation and control systems. It addresses protection against unauthorized access and change. It is not a certificate that a machine's safety function is sufficient. For machinery, ISO 13849-1:2023 and IEC 62061 address safety-related parts or systems of machine controls. In process industries, the ISA/IEC 61511 series covers safety instrumented system lifecycle requirements. Which standard and protection function apply is determined through the actual hazard and sector analysis, not by this article.

The architectural principle is plain: an AI advisor or generated normal-control block must not be silently promoted into the required safety function. A required safety-related control path has its own specification, validation, change authority and qualified acceptance. “Independent” here means it is assessed for the hazard and not delegated to an unconstrained chat or agent loop. The exact physical architecture is an engineering decision for the site.

OT security has a different but related boundary. NIST SP 800-82 Revision 3 is the final guide to OT security. The September 21, 2026 Revision 4 posting is an initial public draft, with comments open; it must not be cited as a final standard. Both frame OT security around performance, reliability and safety constraints. Bringing an AI assistant into engineering adds new paths through project files, maintenance notes, cloud services, credentials and generated change artifacts. A prompt injection inside an untrusted note is not merely an answer-quality nuisance if it can steer a tool with authority to modify a controller project.

I would start with a read-only or staged engineering path. Constrain the AI's access to the files and tools needed for drafting. Treat external notes and model output as data, review the exact diff and target, build from an approved artifact, and preserve a rollback and independent readback. A direct conversational path from “make this better” to a live PLC would erase too many useful boundaries at once.

Ten non-destructive probes before booking the plant window

These are proposed probes for a synthetic model or authorized isolated bench. No live PLC, machine or plant network was accessed for this issue. Each expected result should be written by a qualified owner before the AI-generated logic is examined.

1. Freeze the signed jam/recovery state table and trace each generated condition to one requirement ID; identify unspecified transitions.
2. Compile the same candidate for the exact target controller and project version; diff vendor warnings and I/O assignments, not only the source text.
3. Run normal-cycle traces on an offline model and compare controller command with modeled actuator feedback.
4. Hold the jam sensor high in the simulator after the modeled material clears; verify the owner-specified fault and reset behavior.
5. Inject a stale timestamp or delayed field update into the offline model; require an explicit state rather than treating the old bit as fresh evidence.
6. Supply contradictory input and feedback states; verify the test oracle catches a self-confirming implementation and records uncertainty.
7. Change one simulator assumption deliberately, such as actuator delay, and prove the protected acceptance case changes or fails visibly.
8. On an authorized spare-controller bench with no plant actuation, compare task/scan timing, I/O mapping and restart state with the simulation expectation.
9. Exercise the staged change path with a harmless prompt-injected maintenance note; verify the assistant cannot silently change the approved target or bypass review.
10. Rehearse the commissioning packet and rollback on paper and in staging: owners, stop criteria, target hash, observations and recovery steps; defer physical execution to the site's authorized process.

Those experiments are intended to change design decisions early. If a sensor-fault probe fails, fix the requirement, model, logic or acceptance plan before buying an installation window. The loop should continue until the remaining uncertainty is explicit enough for the site's qualified owners to decide whether a controlled physical test is justified.

Buy accepted engineering time

AI may drastically reduce drafting effort. For a plant manager or integrator, the decision is whether it increases accepted engineering throughput: fewer late faults, shorter but still complete commissioning, better traceability, lower downtime exposure, and faster recovery when the installed system differs from the model. Budget the test model, bench, qualified review and commissioning window up front. A proposal that counts only generated code time is not pricing the job.

My rule: let AI write the draft and propose the faults. Let the requirement define the physical outcome, the simulation and isolated bench challenge it, and the qualified plant and safety owners release it only after controlled observation. The machine's measured behavior is the final acceptance record.

The related original written reads are on this journal. Their video and social links appear only after each exact public readback. The Week 05 engineering field notes document the synthetic oracle and its limits. No live OT experiment is claimed.

The field kit

The companion folder for this week holds runnable examples, decision records, evidence and limits. The repository release log is updated after each article's live readback.