How should the edge be designed for security when AI applications interact with industrial control systems? Should university-industry projects follow product implementation discipline? Denis Leite, Director of Digital Transformation at Mekatronik, answers these audience questions from the “From Months to Days: Accelerate Industrial AI with a Modern Data Architecture” session at the Industrial AI Summit 2026.
How Is the Edge Designed to Be Secure?
The original audience question: “OT security is the weakness, so how is the edge designed to be secure?”
Denis Leite, Director of Digital Transformation at Mekatronik:
I think there are two different aspects of edge security that are important to separate here. The first is the security of the infrastructure itself: device hardening, operating systems, network segmentation, access control, firmware, and the other cybersecurity practices required in an OT environment. Those controls remain essential, and a UNS or a DataOps architecture does not replace them. But there is a second aspect that is particularly interesting in the architecture we discussed during the session, which is how we control the flow of information between OT and IT, especially when information is flowing back toward the machines. With a proper DataOps architecture, we can have HighByte instances operating at different levels of the architecture: close to the edge, at intermediate OT layers, and at the interface with IT. This gives us much more control over what information leaves the PLC environment and, even more importantly, what information is ultimately allowed to be written back to it. Consider an AI or optimization application as an example. The application may determine that a process setpoint should be changed. In a conventional point-to-point architecture, that external application could potentially connect directly to the industrial system through OPC UA and write the new value. With the architecture we are discussing, the value calculated by the external application does not have to be the value that is directly written to the PLC. The application can publish a recommendation or requested value through the UNS. The intermediate DataOps layer can then apply the appropriate validation before anything reaches the control system. For example, we can check whether the requested value is within an acceptable range, whether the process is in the appropriate operating state, whether the command is reasonable in the current context, or whether other conditions required by the application have been satisfied. Only after those conditions are met does the appropriate value continue toward the control layer. That separation is very important. The external application proposes an outcome, but the OT architecture remains responsible for deciding how, and under which conditions, that outcome can reach the industrial process. MQTT also gives us another useful level of control. Through the broker and its access-control mechanisms, we can define which clients are authorized to publish or subscribe to specific parts of the namespace. So the permissions for information flowing upward from OT and information or commands flowing downward toward OT can be controlled independently. This becomes particularly relevant as we scale AI. We don’t necessarily want hundreds of AI models establishing hundreds of direct connections to PLCs and other industrial assets. Besides becoming extremely difficult to maintain, that would also greatly increase the number of interfaces that have to be secured and governed. A properly designed UNS and DataOps architecture allows us to reduce those direct dependencies and create controlled boundaries between the applications producing information and the systems ultimately acting on it. So, to answer the question directly, edge security still requires the traditional OT cybersecurity controls at the device and network levels. But from a data architecture perspective, DataOps, MQTT, and intermediate processing layers give us much stronger control over what crosses the OT/IT boundary and, particularly, allow us to validate and govern information before anything coming from an external application is allowed to influence the physical process.
Should University Projects Be Product Implementations?
The original audience question: “Denis, normally there are communication problems between industry and universities. You approached this project like a product implementation. Do you agree that this must always be the approach, so these two worlds come closer?”
Denis Leite, Director of Digital Transformation at Mekatronik:
I think there are several aspects to this, but for me, it starts with people, trust, and a history of delivering results. Mekatronik has been working with manufacturing companies for about 20 years, across different industries. Over that time, our commitment to results has given us credibility and, perhaps even more importantly, strong relationships with people inside these companies. Many of the professionals we work with today are former undergraduate or graduate-school colleagues, or have worked with someone on our team in the past. When we first started bringing industrial R&D and innovation projects into UPE, that personal and professional trust was very important. In a sense, initially it was “Dênis from Mekatronik” building the bridge with the university. Mekatronik already had credibility in industry, and that helped companies feel comfortable bringing to the university projects that naturally involved technological risk and uncertainty. Mekatronik also brought into this ecosystem partnerships with technology companies such as Siemens and HighByte, and I think this has been another key element in the success of these projects. There is a very important distinction here between problems we need to research and problems the industry already knows how to solve. If our research challenge is predictive maintenance, process optimization, or a new AI application, for example, we don’t want the university team spending most of its time reinventing edge computing, DataOps, MLOps, industrial connectivity, or other capabilities for which mature technologies already exist. By working with established technology partners and using their platforms, we can rely on proven solutions for those problems and concentrate our research and engineering effort on the ultimate industrial problem we are trying to solve. Over time, UPE also built its own credibility. As projects started delivering significant results, our teams expanded, and colleagues such as Alexandre Maciel, Diego Rativa, Bruno Fernandes, and Carmelo Bastos-Filho became deeply involved in industrial challenges and invested time in understanding the factory environment. Today, we have a relevant track record of successful industrial R&D and innovation projects, and UPE itself is recognized by the industrial community for delivering results. But I still believe that, ultimately, everything comes back to people. A factory may recognize UPE or Mekatronik as an organization, but when people decide who they want to work with, they also think about the individuals they know and trust. They know their work, their commitment, and whether they will remain engaged until the problem is solved. We have also worked continuously to maintain this ecosystem. For the past few years, I have led an industry-university forum where people from different manufacturing sectors periodically meet to discuss challenges, opportunities, experiences, technologies, and results. The relationship remains strong because everyone sees value in participating. When we schedule these meetings, people genuinely don’t want to miss them. They learn from one another, and new collaborations naturally emerge. The Stellantis UNS project itself is a good example, because the initial idea emerged from Stellantis learning about the pioneering UNS experience at Vivix. Regarding the idea of treating these initiatives as product implementations, I would make one distinction. I don’t believe every university research project should be treated like a product. Research needs room for experimentation, uncertainty, and failure. But when we decide that the outcome is intended to become an industrial solution, then the mindset has to change. Proving that something works is no longer enough. It has to deliver value, run reliably in the factory, be maintainable, and be capable of scaling. So I don’t think the gap between universities and industry is closed simply by making universities behave more like companies. It is closed by bringing together the right people, building trust through repeated delivery of results, and creating an ecosystem where industry, academia, implementation companies, and technology partners each contribute what they do best. Established technologies solve the problems we already know how to solve, so researchers and engineers can focus their energy on the new problems that actually require innovation.
These questions were submitted by attendees of the “From Months to Days: Accelerate Industrial AI with a Modern Data Architecture” session at the Industrial AI Summit 2026. Answers provided by Denis Leite of Mekatronik. The session also featured Aron Semle, Chief Technology Officer at HighByte, and it was moderated by Hamish Mackenzie. The session was sponsored by HighByte.
Related from IIoT World
