Agenti AI in ambito OT: le regole di governance emerse all'Industrial AI Summit 2026

Il 1° ottobre 2026 IIoT World ha pubblicato la sintesi di un panel tenuto all'Industrial AI Summit 2026 su come governare gli agenti AI nei sistemi OT. Intervenivano Scott Christensen (GrayMatter), Gary Tillery (CEO di Skkynet) e Ian Bramson (Black & Veatch), con la moderazione di Matt Morris (EverLine). Un'indicazione di cautela: l'articolo è contrassegnato come sponsorizzato da Skkynet, pur dichiarandosi editorialmente indipendente, e riporta di essere stato riassunto con l'aiuto di strumenti AI. Si tratta quindi di opinioni di esperti, non di uno standard, e non vengono forniti dati di indagine.

Il problema: un agente per ogni fornitore

Uno stabilimento con 20 o più fornitori rischia di ritrovarsi con un agente AI per ciascuno, ognuno con il proprio modello di accesso, le proprie integrazioni e il proprio profilo di rischio. Poiché i sistemi OT sono fortemente interconnessi, la modifica fatta da un agente può avere effetti sui sistemi a valle.

Audit trail: non basta un login generico

Secondo il panel, ogni agente deve avere credenziali uniche, come un utente umano. Senza, l'analisi forense non può stabilire quale agente ha eseguito una modifica. Il log dovrebbe registrare:

• chi ha avviato l'azione;
• i permessi posseduti dall'agente;
• i dati che hanno informato la decisione;
• come la modifica è stata eseguita;
• l'esito.

La catena dei dati dovrebbe essere tracciabile da dove sono stati generati, a dove sono stati modificati, fino a dove è stato raccomandato un setpoint, in analogia con la tracciabilità della supply chain. Il registro deve inoltre mostrare dove è avvenuta l'esecuzione e chi, o cosa, l'ha autorizzata.

Accesso e architettura

Gli agenti andrebbero gestiti come dipendenti: accesso basato su ruoli e a privilegi minimi, credenziali custodite in vault, segmentazione di rete e monitoraggio continuo. Il panel invoca lo zero trust: nessun agente è considerato affidabile su alcuna rete e ogni azione richiede una giustificazione. Un eventuale guasto va contenuto nel segmento in cui l'agente opera. Ogni flusso di dati in uscita deve essere un percorso gestito; più connettività significa più porte aperte e, per i relatori, l'air gap è un mito.

Pochi principi, chiari

Nessun framework copre da solo sicurezza OT e agenti AI. Il suggerimento è combinare IEC 62443 con principi specifici per l'AI, limitandosi a 5–10 principi fondamentali. Quelli citati sono:

• privilegio minimo per ogni agente;
• nessun agente autonomo al livello 0 del modello Purdue;
• tracciamento obbligatorio di identità e accessi per ogni azione;
• valutazione delle conseguenze prima della messa in servizio;
• analisi dei flussi di dati prima di introdurre l'AI.

Le industrie regolamentate, soprattutto in Europa, devono attendersi requisiti più prescrittivi.

Tre domande per il lunedì mattina

• Tillery: se la connettività si interrompesse, cosa continuerebbe a funzionare e chi lo ha deciso?
• Christensen: facciamo il backup dei dati, ma anche del processo, cioè configurazioni e ladder logic?
• Bramson: dov'è il registro dei rischi per l'AI in OT, chi possiede ciascun rischio e con quale priorità?

Cosa ne ricava chi lavora in campo

Per chi programma PLC, gestisce SCADA o presidia sistemi OT e si sente chiedere di aprire gli impianti agli agenti dei fornitori, il contributo è una checklist pratica. Collega l'AI a temi molto concreti: backup di configurazioni e ladder logic, e integrità dei dati negli audit trail. Un primo passo realistico è censire quali agenti già toccano l'impianto, verificare se hanno identità distinte e quali percorsi di dati aprono, e scrivere il registro dei rischi. Il tutto resta, come detto, un insieme di buone pratiche proposte da un panel: va adattato al proprio contesto e ai requisiti normativi applicabili.