UNS and DataOps: Validating AI Recommendations Before They Reach the PLCs

On 13 October 2026, IIoT World published a Q&A by Paul Viorel with Denis Leite, Director of Digital Transformation at Mekatronik. The answers stem from audience questions at the Industrial AI Summit 2026, during the session "From Months to Days: Accelerate Industrial AI with a Modern Data Architecture". Leite cites HighByte and Siemens as Mekatronik's technology partners.

The most useful takeaway for those running plants and information systems is a design pattern: the outputs of artificial intelligence should not reach machines through a direct PLC connection, but through a validated data layer with controlled access.

Two layers of security at the edge

Leite distinguishes two levels. The first is classic OT security and remains indispensable: device hardening, operating systems, network segmentation, access control and firmware management. An architecture based on a UNS (Unified Namespace) or a DataOps layer replaces none of this.

The second level concerns the information flowing between OT and IT, in particular the information that returns to the machines. This is where, according to Leite, edge security must extend from the device to the data flow.

Validation before writing

In a point-to-point architecture, an AI or optimization application could write a new setpoint directly to the PLC, for example via OPC UA. In the model Leite describes, the application only publishes a recommendation or a requested value to the UNS. An intermediate DataOps layer checks the request before forwarding it. The examples cited are:

Possible checks before the command proceeds:

• Is the value within an acceptable range?
• Is the process in the correct operating state?
• Does the command make sense in context?

HighByte instances, he explains, can operate at several levels: close to the edge, in intermediate OT layers and at the interface with IT. Leite's summary is blunt:

The application proposes; it is the OT architecture that decides whether and how the change reaches the process.

Access control with MQTT

On access, MQTT broker permissions can define which clients may publish or subscribe to which parts of the namespace. Upstream flows (OT to IT) and downstream flows (commands to OT) can be governed separately, which matters because the latter have the greatest impact on the process.

The problem of scale

Leite also makes a maintainability argument: hundreds of AI models should not each have a direct connection to PLCs. That would be hard to maintain and would multiply the interfaces to protect and govern. A UNS with DataOps reduces direct dependencies and creates controlled boundaries.

Key takeaways

For plant managers and IT and OT teams, the practical guidance is:

• treat the return path (IT to OT) as a perimeter to be designed, not just the data-collection path;
• have AI publish requests and recommendations, not direct writes to controllers;
• define validation rules based on limits, process state and context;
• configure separate permissions for publishing and subscribing on the broker, separating upstream and downstream flows;
• keep the traditional OT controls: the data architecture complements them, it does not replace them.

An opinion, not a study

The context is worth remembering: this is the opinion of a vendor's technology partner, not research, and the interview reports no quantitative data or named customer installations. It nonetheless offers a clear design criterion that can be checked against your own architectures.

The Q&A also covers university-industry projects: for Leite they rest on trust and track record, and research groups should build on mature platforms for edge, DataOps and connectivity, focusing on the industrial problem. Mekatronik cites about twenty years of work with manufacturers and with the University of Pernambuco (UPE).