AI e PLC: validare le raccomandazioni prima della scrittura sul campo

Il 13 ottobre 2026 IIoT World ha pubblicato un Q&A in cui Denis Leite, Director of Digital Transformation di Mekatronik, risponde alle domande del pubblico emerse nella sessione "From Months to Days: Accelerate Industrial AI with a Modern Data Architecture", tenuta all'Industrial AI Summit 2026. Nella sessione era presente anche Aron Semle, CTO di HighByte, azienda che ha sponsorizzato l'evento. Il contenuto è quindi di matrice commerciale e va letto tenendo conto di questo inquadramento; resta però un buon spunto su un problema reale degli stabilimenti.

Due livelli di sicurezza all'edge

Leite distingue due aspetti. Il primo è l'hardening OT tradizionale: protezione dei dispositivi, sistemi operativi, segmentazione di rete, controllo degli accessi e firmware. Secondo lui, un'architettura basata su UNS (Unified Namespace) o DataOps non sostituisce questi controlli.

Il secondo aspetto riguarda il controllo del flusso di informazioni tra OT e IT, in particolare dei dati che tornano verso le macchine. È qui che si colloca la proposta.

Validazione prima del write-back

In un'architettura punto-punto convenzionale, un'applicazione esterna di AI o ottimizzazione potrebbe scrivere un nuovo setpoint direttamente su un PLC, per esempio via OPC UA. Nel modello descritto, invece, l'applicazione pubblica nella UNS una raccomandazione o un valore richiesto. Un livello DataOps intermedio lo valida prima che si avvicini al livello di controllo. Le istanze HighByte, spiega Leite, possono operare a più livelli: vicino all'edge, nei livelli OT intermedi e all'interfaccia con l'IT.

Esempi di controlli citati:

• il valore è entro un intervallo accettabile?
• il processo si trova nello stato operativo corretto?
• il comando è ragionevole nel contesto?
• sono soddisfatte le altre condizioni richieste dall'applicazione?

L'applicazione esterna propone un risultato; è l'architettura OT a decidere se e come raggiunge il processo.

Si tratta di una parafrasi della sintesi di Leite, che inverte l'idea di fiducia: l'AI non ha un percorso di scrittura, ha un canale di proposta.

Permessi sul broker MQTT

Un secondo strumento è il controllo degli accessi del broker MQTT, che può stabilire quali client possono pubblicare o sottoscrivere specifiche porzioni del namespace. Il flusso verso l'alto (da OT a IT) e i comandi verso il basso (da IT a OT) possono essere autorizzati in modo indipendente. Un modello di analisi può quindi leggere molti dati senza avere alcun permesso di scrittura sui topic che alimentano i comandi.

L'argomento della scala

Leite non vuole centinaia di modelli di AI ciascuno con connessioni dirette a PLC e altri asset: sarebbe difficile da mantenere e moltiplicherebbe le interfacce da proteggere e governare. Una UNS con DataOps riduce le dipendenze dirette e crea confini controllati.

Un punto secondario: progetti università-industria

Leite osserva che la ricerca ha bisogno di spazio per fallire, ma ciò che deve diventare una soluzione industriale deve essere affidabile, manutenibile e scalabile. I ricercatori dovrebbero usare piattaforme mature per edge, DataOps e connettività, concentrandosi sul problema vero. Cita un progetto UNS di Stellantis nato dall'esperienza UNS di Vivix; l'articolo non riporta risultati né numeri.

Perché conta e cosa farne

L'articolo è concettuale e non fornisce metriche, quindi non dimostra l'efficacia del pattern. Offre però uno schema chiaro: un gateway di validazione più ACL sul broker, sovrapposti al normale hardening OT. Per chi valuta di far influenzare i sistemi di controllo dall'AI, alcuni passi pratici:

• censire quali applicazioni oggi hanno percorsi di scrittura diretti verso PLC e asset;
• definire per ogni setpoint limiti, stati di processo ammessi e condizioni di contesto, da codificare nel livello di validazione;
• separare i permessi di pubblicazione e sottoscrizione per direzione di flusso e per ramo del namespace;
• mantenere la validazione vicina al controllo e non affidarla solo all'applicazione che propone il valore;
• non considerare questo livello un sostituto di segmentazione, accessi e gestione del firmware.

Il principio, indipendentemente dal fornitore, è che l'ultima parola su ciò che raggiunge il processo resti all'architettura OT e a chi ne risponde.