AI and PLCs: Validating Recommendations Before Writing to the Field
In a Q&A published by IIoT World on October 13, 2026, Denis Leite of Mekatronik describes a UNS architecture with a DataOps layer that filters AI commands bound for PLCs. A concrete pattern, but conceptual and sponsor-driven.
On October 13, 2026, IIoT World published a Q&A in which Denis Leite, Director of Digital Transformation at Mekatronik, answers audience questions from the session "From Months to Days: Accelerate Industrial AI with a Modern Data Architecture," held at the Industrial AI Summit 2026. Aron Semle, CTO of HighByte, the company that sponsored the event, also took part in the session. The content is therefore commercial in nature and should be read with that framing in mind; it remains a useful prompt on a real problem in plants.
Two layers of security at the edge
Leite distinguishes two aspects. The first is traditional OT hardening: device protection, operating systems, network segmentation, access control and firmware. In his view, an architecture based on UNS (Unified Namespace) or DataOps does not replace these controls.
The second aspect concerns controlling the flow of information between OT and IT, particularly data traveling back toward machines. This is where the proposal fits.
Validation before write-back
In a conventional point-to-point architecture, an external AI or optimization application might write a new setpoint directly to a PLC, for example via OPC UA. In the model described, the application instead publishes a recommendation or requested value to the UNS. An intermediate DataOps layer validates it before it gets anywhere near the control level. HighByte instances, Leite explains, can operate at multiple levels: close to the edge, in intermediate OT layers and at the IT interface.
Examples of the checks mentioned:
- Is the value within an acceptable range?
- Is the process in the correct operating state?
- Is the command reasonable in context?
- Are the other conditions required by the application met?
The external application proposes a result; it is the OT architecture that decides whether and how it reaches the process.
This is a paraphrase of Leite's summary, which inverts the idea of trust: the AI has no write path, only a proposal channel.
MQTT broker permissions
A second tool is access control on the MQTT broker, which can define which clients may publish or subscribe to specific parts of the namespace. Upward flow (OT to IT) and downward commands (IT to OT) can be authorized independently. An analytics model can thus read a great deal of data without any write permission on the topics that feed commands.
The scale argument
Leite does not want hundreds of AI models each with direct connections to PLCs and other assets: that would be hard to maintain and would multiply the interfaces to secure and govern. A UNS with DataOps reduces direct dependencies and creates controlled boundaries.
A side point: university-industry projects
Leite observes that research needs room to fail, but anything that must become an industrial solution has to be reliable, maintainable and scalable. Researchers should use mature platforms for edge, DataOps and connectivity, focusing on the real problem. He cites a Stellantis UNS project that grew out of Vivix's UNS experience; the article reports no results or figures.
Why it matters and what to do with it
The article is conceptual and provides no metrics, so it does not demonstrate the pattern's effectiveness. It does offer a clear scheme: a validation gateway plus broker ACLs, layered on top of normal OT hardening. For anyone considering letting AI influence control systems, a few practical steps:
- inventory which applications currently have direct write paths to PLCs and assets;
- define limits, permitted process states and context conditions for each setpoint, and encode them in the validation layer;
- separate publish and subscribe permissions by flow direction and by namespace branch;
- keep validation close to the control level and do not rely solely on the application proposing the value;
- do not treat this layer as a substitute for segmentation, access control and firmware management.
The principle, whatever the vendor, is that the final say on what reaches the process stays with the OT architecture and the people accountable for it.