AI in OT: lo stack di standard e i controlli al confine IT/OT

Il 23 ottobre 2026 IIoT World ha pubblicato un Q&A tratto dalla sessione "It Can't Happen to Me – Until It Does" dell'Industrial AI Summit 2026. Gli interlocutori sono Gary Tillery, CEO di Skkynet, e Matt Morris, VP Security and Resilience di EverLine. Non è una notizia su un evento o una ricerca, ma una raccolta di indicazioni di practitioner. Va letta tenendo presente che l'articolo è marcato come sponsorizzato da Skkynet ("editorially independent") e che i relatori operano in questo mercato.

Nessuno standard copre da solo l'AI in fabbrica

Il punto centrale di Tillery è che serve uno stack di standard. Il divario maggiore riguarda i sistemi agentici e generativi: gli standard attuali presuppongono un modello circoscritto, non un pianificatore che sceglie autonomamente gli strumenti da usare. Tillery precisa di aver cercato i riferimenti dopo il panel e che l'elenco non è completo, quindi va considerato un punto di partenza.

Gli ambiti citati:

• Interoperabilità e dati degli asset: IEC 62541 (OPC UA) come livello di base, perché l'AI legga lo stato macchina e non tag grezzi; IEC 63278 (Asset Administration Shell) e RAMI 4.0 per la rappresentazione digitale degli asset; MQTT con Sparkplug B per la telemetria leggera, senza sostituire la semantica OPC UA per i dati rilevanti per il controllo.
• Sicurezza e architettura: IEC 62443 per zone e conduit, privilegio minimo e livelli di sicurezza, anche per il percorso dell'AI; IEC PAS 62443-1-6 per l'IIoT; NIST SP 800-82 Rev. 3 come guida OT; IEC 62264/ISA-95 per il confine tra impresa e controllo; ISO/IEC 27001 per l'IT aziendale, ma non in sostituzione della 62443 sulla rete di impianto.
• Sicurezza funzionale: le funzioni di safety restano su IEC 61508, 61511, 62061 o ISO 13849, e nessun modello o strumento remoto deve scrivere attraverso quel percorso.
• Governance dell'AI: ISO/IEC 42001:2023 (sistema di gestione certificabile), ISO/IEC 23894, 5338, 5259 e 22989 per rischio, ciclo di vita, qualità dei dati e vocabolario; NIST AI RMF (AI 100-1) con il profilo generativo AI 600-1; l'EU AI Act, dove applicabile, che classifica come ad alto rischio i componenti di sicurezza e alcuni usi industriali.
• Digital twin: ISO 23247 come framework per la manifattura.

Secondo Tillery, l'AI Act si allinea con la 42001 e con la separazione della safety, ma non sostituisce IEC 61508 o 62443. Anche altre associazioni, come il crosswalk tra NIST AI RMF e 42001, sono sue valutazioni e non verifiche indipendenti.

Regole di progetto per l'AI

Tillery propone tre principi:

• trattare l'AI come consulente (advisor);
• nessuna credenziale permanente del modello verso PLC o historian;
• chiamate agli strumenti tramite un broker esterno al prompt, con credenziali di breve durata legate al compito e un audit trail che indichi chi ha delegato l'azione.

Il confine IT/OT secondo Morris

Morris parte da una premessa: se un singolo clic di phishing può raggiungere l'OT, c'è un problema di architettura. Si progetta quindi assumendo che l'IT sia già compromesso. I ponti reali, osserva, sono di solito Active Directory condiviso, credenziali riutilizzate, workstation di engineering dual-homed e accesso remoto dei fornitori sempre attivo.

I controlli indicati:

• identità OT separata, nessun trust di dominio, nessun account condiviso;
• connettività mediata da una DMZ IT/OT: i dati vengono spinti fuori e nulla avvia connessioni verso l'OT;
• accesso remoto tramite jump host, MFA resistente al phishing, approvazione e registrazione delle sessioni, accessi a tempo;
• application allowlisting su HMI e workstation di engineering;
• monitoraggio OT-aware nella DMZ;
• verifica delle dipendenze operative.

Come esempio di dipendenza, Morris cita Colonial Pipeline: la parte OT non era stata compromessa, ma fu fermata perché fatturazione e tracciamento dei prodotti dipendevano dall'IT.

Come dimostrare che i controlli funzionano

Le prove suggerite sono:

• test assume-breach a partire da una workstation IT compromessa, in un laboratorio replica o in finestre di manutenzione, non alla cieca sui sistemi in produzione;
• analisi dei percorsi d'attacco sulla configurazione as-built, non sullo schema di rete;
• esercitazioni in island mode che separano IT e OT per un periodo definito.

Le metriche proposte sono il tempo di isolamento, la percentuale di conduit validati nell'anno e il numero di dipendenze non documentate trovate.

Cosa farne

Per responsabili IT e di stabilimento il valore sta nella checklist e nelle metriche misurabili, più che nell'elenco di norme, che resta la memoria di un singolo relatore. Un primo passo pratico è mappare i ponti reali tra IT e OT, verificare che nessun agente AI abbia credenziali permanenti e fissare un obiettivo per il tempo di isolamento da misurare in un'esercitazione. Va infine notato che questa sintesi si basa sulla prima parte dell'articolo; la sezione sull'utilità di una rete sicura dedicata non è stata considerata.