How to Spot AI-Washing in the Plant: A Virtual Commissioning Checklist

AI-washing in industrial automation occurs when analytics or code-generation tools are marketed as control intelligence without proving deterministic behavior against physical process constraints. A practical test is virtual commissioning: if logic cannot be validated against a realistic digital model before deployment, the claimed AI value is not yet engineering value.

AI in manufacturing is often sold as if prediction and control were the same thing. They are not. A dashboard that trends anomalies is useful; a system that can influence machine behavior safely under scan-cycle, interlock, and fault constraints is a different class of problem.

A recent internal Ampergon Vallis benchmark found that 68% of raw LLM-generated ladder sequences for pump staging omitted logic needed to handle mechanical hysteresis and stable transition behavior [Methodology: n=50 generated sequences for pump lead/lag staging tasks, baseline comparator = engineer-reviewed commissioning-ready logic, time window = January–March 2026]. This metric supports a narrow point: unreviewed AI-generated control logic frequently misses deployability details. It does not support a broad claim that all AI-assisted PLC work is unsafe or low value.

That distinction matters because commissioning is where vague claims meet steel, water, inertia, and consequence. Marketing usually exits the room before that point.

AI-washing in industrial automation is the practice of presenting ordinary analytics, rule-based automation, or unvalidated code generation as if it were reliable industrial intelligence. In OT, the term matters because the consequences of overstating capability are physical, not merely administrative.

A workable engineering definition is narrower than the general business one:

- AI-washing is the labeling of a tool as “AI-driven” when it lacks one or more of the following:

• awareness of deterministic control execution,
• traceable interaction with real or simulated I/O,
• validation against process behavior or equipment constraints,
• a bounded failure mode and deterministic fallback.

This distinction separates two categories that are often blurred in procurement:

- Read-only intelligence: anomaly detection, forecasting, dashboards, maintenance scoring, trend classification. - Read/write control influence: setpoint recommendation, sequence generation, control action proposals, or autonomous orchestration affecting machine state.

Read-only tools can still be valuable. The problem starts when a read-only or loosely probabilistic tool is sold as if it can safely participate in deterministic control. A trend chart cannot execute a permissive. A language model does not become scan-aware because a slide deck says “industrial.”

A practical correction engineers should make early

Not every “AI” claim is false. Many are simply unbounded. The question is not whether a vendor uses machine learning; the question is whether the claimed capability has been validated at the point where process behavior, timing, and fault handling matter.

AI-washing threatens functional safety when probabilistic outputs are allowed to influence deterministic systems without a validated supervisory structure. IEC 61508 is concerned with functional safety across the lifecycle, including specification, design, verification, validation, and management of systematic failure. That is not a friendly habitat for vague autonomy claims.

The core engineering conflict is simple:

• AI models are probabilistic.
• PLCs and safety instrumented functions are deterministic by design.

That does not make AI unusable in industrial environments. It means any interaction between probabilistic recommendation and deterministic execution must be explicitly bounded, reviewed, and architected with safe-state behavior. “It usually works” is not a safety argument.

The 3 common ways AI-washing bypasses safety discipline

1. Asynchronous setpoint injection A non-deterministic service writes or recommends values without regard to PLC execution order, task timing, or process state. Even when the write path is indirect, the result can be unstable loop behavior or sequence corruption.
2. Alarm flooding and priority dilution Predictive alerts can add noise to operator workload if they are not rationalized against actual alarm philosophy. ISA-18.2 and EEMUA-style alarm discipline exist for a reason. More alerts are not the same as better awareness. Often the opposite.
3. Loss of state awareness during transitions Power cycles, communication loss, stale tags, and network latency expose whether a system actually understands machine state. A model that loses context during a restart is not “adaptive.” It is confused at exactly the wrong moment.

Why deterministic veto matters

A deterministic veto is the hard boundary that prevents advisory or generated logic from violating process constraints, interlocks, or safe operating envelopes. In practical terms, it means:

• AI may propose.
• Deterministic logic must decide.
• Safety functions remain outside the AI’s discretion.

That is not anti-AI. It is adult supervision for systems with motors attached.

The fastest way to identify AI-washing is to test whether the claimed intelligence survives contact with control reality. If a vendor cannot answer these five questions clearly, the burden of proof has quietly shifted onto your commissioning team.

The AI-Washing Diagnostic Checklist

| Criterion | What to Ask | What a credible answer looks like | Warning sign | |---|---|---|---| | 1. Scan-cycle awareness | Does the tool account for PLC execution order, update timing, and sequence state? | The vendor can explain how outputs are evaluated relative to scan behavior, task timing, and state transitions. | “The AI generates logic automatically” with no discussion of execution order. | | 2. Physics binding | Has the logic been tested against realistic equipment behavior such as inertia, hysteresis, friction, gravity, or fluid lag? | Validation includes a digital model or scenario where physical response can be observed and faults injected. | Validation is limited to syntax checks, unit tests, or static code review. | | 3. Deterministic fallback | If the AI service fails, disconnects, or produces nonsense, what happens? | The system has bounded fallback behavior, operator visibility, and a defined safe state. | Recovery depends on manual improvisation or cloud availability. | | 4. I/O causality | Can the team trace a software decision to tag changes, outputs, and equipment response? | There is observable cause-and-effect from logic state to simulated or physical machine state. | The tool explains decisions in prose but cannot show relay-level or tag-level consequences. | | 5. Commissioning verifiability | Can the generated logic be tested under normal, abnormal, and edge-case conditions before FAT or SAT? | The workflow includes simulation, fault injection, revision, and documented acceptance criteria. | “We validate in production with operator oversight.” That is not validation; it is optimism with a hard hat. |

What this checklist is really measuring

This checklist does not measure how impressive a demo looks. It measures whether a tool can survive a commissioning workflow. That is the useful threshold because commissioning exposes the gap between generated syntax and deployable control behavior.

“Simulation-Ready” should be defined operationally, not aspirationally. A Simulation-Ready engineer can prove, observe, diagnose, and harden control logic against realistic process behavior before it reaches a live process.

That definition is about behavior, not résumé language. In practice, a Simulation-Ready workflow includes the ability to:

• build or review ladder logic against a clear control objective,
• bind logic to observable I/O and equipment states,
• test normal sequences and abnormal conditions,
• inject faults deliberately,
• compare expected behavior with actual simulated response,
• revise logic based on evidence,
• document what “correct” means before deployment.

This is the distinction that matters: syntax versus deployability. Many people can draw a rung. Fewer can explain why a permissive failed, what state the machine should enter next, and how to prove the revision fixed the fault without creating a new one.

The engineering evidence that actually demonstrates skill

If an engineer wants to show credible capability with AI-assisted or manually written control logic, the artifact should be a compact body of engineering evidence, not a screenshot gallery.

Use this structure:

State the acceptance criteria in observable terms: start conditions, stop conditions, interlocks, alarms, timing, fail-safe behavior.

Document the abnormal condition introduced: sensor failure, stuck valve, noisy input, loss of permissive, delayed feedback.

1. System Description Define the machine or process, major I/O, operating states, and control objective.
2. Operational definition of “correct”
3. Ladder logic and simulated equipment state Show the logic alongside the resulting machine or process state in simulation.
4. The injected fault case
5. The revision made Record the logic change and why it was necessary.
6. Lessons learned Explain what the failure revealed about sequence design, state handling, timing, or process assumptions.

That format is harder to fake because it forces causality. Engineering usually improves when screenshots stop being treated as evidence.

Virtual commissioning proves ROI by reducing expensive uncertainty before FAT, SAT, or live startup. The relevant financial measure is not how quickly a tool generates code. It is whether the resulting logic reduces revision cycles, test delays, and equipment risk during commissioning.

A bounded definition helps here:

- Measurable ROI in commissioning means a quantifiable reduction in one or more of the following:

• FAT hours,
• SAT logic revisions,
• startup delays,
• hardware stress or damage caused by avoidable control errors,
• engineering rework caused by untested edge cases.

This framing is consistent with industrial digital-twin and virtual commissioning literature, which generally positions simulation as a method for earlier defect discovery, sequence validation, and reduced physical commissioning effort. The exact savings vary widely by process type, model fidelity, scope, and team discipline. That variability should be stated plainly.

Why generated code volume is the wrong metric

Lines of logic generated per minute are not a commissioning KPI. They are a drafting KPI at best. If an AI tool produces ten rungs quickly and six of them require rework after dynamic testing, the apparent speed advantage collapses into commissioning debt.

The practical ROI filter is straightforward:

• Can the logic be run against a realistic process model?
• Can faults be injected safely?
• Can the team observe cause-and-effect at tag and equipment level?
• Can revisions be made before physical deployment?

If the answer is no, the “AI savings” are still hypothetical. Field time is where hypothetical savings go to be audited.

What virtual commissioning validates that static review cannot

Static review can catch syntax errors, obvious omissions, and some logic contradictions. It cannot fully validate dynamic behavior such as:

• unstable pump staging,
• chatter caused by noisy inputs,
• race conditions in step transitions,
• missing debounce or proof timers,
• poor alarm thresholds,
• PID interaction with realistic process lag,
• restart behavior after interruption,
• interlock behavior under partial failure.

Those are not exotic edge cases. They are ordinary commissioning work.

OLLA Lab is useful here as a bounded validation environment for logic rehearsal, I/O observation, and digital twin testing before touching live equipment. It should be treated as a truth layer for unreviewed logic, not as a substitute for engineering judgment.

A practical workflow looks like this:

1. Start with a control narrative, not blind code acceptance

If an AI assistant generates a sequence description or draft ladder logic, first define:

• the machine objective,
• the required permissives,
• the expected sequence states,
• the abnormal conditions that must be handled,
• the fail-safe response.

This prevents the common mistake of validating text output instead of validating machine behavior.

2. Build the ladder logic in the browser-based editor

OLLA Lab’s ladder editor supports core instruction categories used in PLC work, including:

• contacts and coils,
• timers and counters,
• comparators and math,
• logical operations,
• PID instructions.

This is where draft logic becomes inspectable. Generated logic that looked plausible in text often becomes less impressive when rendered as actual sequence structure.

3. Bind the logic to a scenario with observable equipment behavior

OLLA Lab includes scenario-based simulations and digital twin-style environments across industrial contexts. The useful point is not visual novelty. The useful point is that the engineer can observe whether ladder state and equipment state agree.

Examples of what to test include:

• motor start/stop permissives,
• lead/lag pump rotation,
• conveyor jam response,
• mixer sequencing,
• analog thresholds and trip points,
• PID response under changing process conditions,
• estop or fault-chain behavior.

4. Use simulation mode and the variables panel to inspect causality

Simulation mode allows the engineer to run logic, stop logic, toggle inputs, and observe outputs and variable states without hardware. The variables panel provides visibility into:

• inputs and outputs,
• tag states,
• analog values,
• PID-related variables,
• scenario selection and state changes.

This matters because AI-generated errors are often not syntactic. They are causal. The rung energizes, but the machine should not have moved. Or the machine does not move, and the missing permissive is buried three conditions upstream.

5. Inject fault conditions deliberately

A useful validation environment must support abnormal-state testing. In OLLA Lab, that means using scenario behavior, variable manipulation, and sequence testing to expose:

• noisy inputs,
• delayed proof feedback,
• failed permissives,
• alarm conditions,
• analog drift or threshold crossing,
• sequence stalls.

This is where the “AI wrote it” claim becomes irrelevant. The logic either survives faulted behavior or it does not.

6. Revise the logic and document the correction

The goal is not to watch AI fail for sport. The goal is to identify omissions, revise the logic, and leave behind evidence of why the revision was necessary.

A compact example:

Text example of a ladder correction:

• Add a TON debounce timer to a noisy photoeye input.
• Use the timer-done bit, rather than the raw input, to permit the transition.
• Re-test the sequence under repeated input chatter to confirm stable behavior.

That kind of correction is mundane, which is precisely why it matters. Commissioning problems are often built from ordinary omissions.

What OLLA Lab supports, and what it does not

A bounded product claim is the credible one.

OLLA Lab supports:

• ladder logic practice in a web-based editor,
• simulation-based testing,
• I/O and variable visibility,
• digital twin-style scenario validation,
• guided learning workflows,
• analog and PID experimentation,
• scenario-based rehearsal of sequencing, interlocks, alarms, and fault handling.

OLLA Lab does not by itself provide:

• site competence,
• certification,
• SIL qualification,
• automatic proof of field readiness,
• exemption from engineering review or safety lifecycle obligations.

That boundary protects the reader from overclaiming.

Procurement should ask for evidence tied to commissioning behavior, not presentation quality. If a vendor’s strongest proof is a dashboard screenshot or a generated logic demo with no fault injection, the evaluation is incomplete.

Use questions like these:

• What part of the workflow is advisory, and what part can influence control action?
• How is deterministic execution protected from probabilistic output?
• What is the fallback state if the AI service is unavailable or incorrect?
• Has the logic or recommendation been validated against a realistic process model?
• Can the vendor demonstrate fault injection and recovery behavior?
• What evidence exists that the tool reduces FAT/SAT effort rather than shifting work downstream?
• How are alarm philosophy, interlocks, and restart behavior handled?

A vendor that cannot answer these questions may still have a useful analytics product. It just should not be purchased as if it were commissioning intelligence.

AI-washing in industrial automation is best identified by testing whether a claimed capability survives deterministic control reality. The decisive question is not whether a tool uses AI. It is whether its outputs can be validated against scan-cycle behavior, physical constraints, I/O causality, and faulted process states before deployment.

Virtual commissioning is the practical filter because it converts vague capability claims into observable engineering behavior. That is where real value appears, and where fake innovation usually runs out of vocabulary.

OLLA Lab fits this workflow as a bounded environment for building, simulating, observing, faulting, and revising control logic against realistic scenarios. That is a serious use case. It does not need embellishment.

- IEC 61131-3: Programmable controllers — Part 3: Programming languages - IEC 61508 Functional safety standards family - NIST AI Risk Management Framework (AI RMF 1.0) - EU Industry 5.0 policy background - Digital twin overview (NIST)