AI and PLCs: A UNS and DataOps Validation Layer Before Any Write
In a Q&A published by IIoT World on October 13, 2026, Denis Leite of Mekatronik argues that AI applications should never write directly to the control system, but instead publish recommendations that an intermediate DataOps layer validates.
On October 13, 2026, IIoT World published a Q&A in which Denis Leite, Director of Digital Transformation at Mekatronik, answers questions left open after the Industrial AI Summit 2026 session "From Months to Days: Accelerate Industrial AI with a Modern Data Architecture". The article is tagged HighByte. It is neither a standard nor a product launch: it is a practitioner's point of view, but it addresses a concrete question for anyone working with PLCs and SCADA, namely how to get an AI model's suggestions to the plant.
Two layers of security at the edge
Leite distinguishes two levels. The first is conventional OT security: device hardening, operating systems, network segmentation, access control and firmware. In his view, a UNS (Unified Namespace) or DataOps architecture does not replace these controls.
The second level is control over the flow of information between OT and IT, in particular the data that travels back toward the machines. This is where the data architecture can add a safeguard.
Recommend, don't write
In a point-to-point topology, an optimization or AI application could write a new setpoint directly into the PLC, for example via OPC UA. In the architecture Leite describes, the application instead publishes a recommendation or requested value to the UNS. An intermediate DataOps layer validates it before it reaches the control system. HighByte's DataOps instances can be deployed at several levels: close to the edge, in intermediate OT layers and at the IT interface, so as to control what leaves the PLC environment and what can re-enter it.
The checks mentioned are:
- Is the value within an acceptable range?
- Is the process in the correct operating state?
- Does the command make sense in context?
- Are the other required conditions met?
The external application proposes; the OT architecture decides how and when the change reaches the process.
Access control on the MQTT broker
A second tool is access control on the MQTT broker, which defines which clients can publish or subscribe to which parts of the namespace. Upstream permissions (OT to IT) and downstream ones (commands toward OT) can be managed separately, so an application can read a lot of data without having any write path to the field.
The problem of scale
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 these direct dependencies and creates controlled boundaries.
The university-industry angle
A secondary part of the interview covers collaboration with universities. Mekatronik has about 20 years of work with manufacturers and partnerships with Siemens and HighByte. For Leite, trust and a track record of delivery bring companies' risky R&D projects to the university (UPE). He separates research problems, such as predictive maintenance, process optimization and new AI applications, from those industry already knows how to solve, such as edge computing and DataOps. The rest of the discussion is not covered here.
Takeaways for control system designers
The practical message is a pattern for AI write-back: no direct OPC UA write access for AI applications, but validation gates, state and range checks, and ACLs on the broker. The final decision stays inside the OT perimeter, where process state and safety constraints are known. The topic ties into the broader discussion on governing AI agents in OT; here the focus is on the architecture of the write path.
As with any single expert's advice, it should be adapted to context: validation rules, ranges and permitted states depend on the process and must be defined with people who know the plant.