Che cosa può fare un agente AI nel reparto produttivo?

Un agente AI in una fabbrica è un modello linguistico di grandi dimensioni (LLM) che può leggere i dati dell’impianto, ragionarci sopra e compiere un insieme limitato di azioni attraverso degli strumenti (tool). L’architettura è la stessa di un agente per la smart home. L’ambiente no. Un impianto ha loop di controllo che girano in millisecondi, sistemi di sicurezza che non devono mai essere aggirati, protocolli vecchi di decenni e un team operativo che ha visto molte tecnologie promettere di risolvere tutto.

Il modo utile di inquadrarlo è questo: un agente è un nuovo tipo di assistente per l’operatore, non un nuovo tipo di controller. Il controllo resta nel PLC e nel DCS. La supervisione resta nello SCADA. L’agente sta sopra di loro, accanto alle persone, e svolge il lavoro lento, fatto di testo e distribuito su più sistemi, che le persone fanno intorno ai livelli in tempo reale: riassumere, cercare, correlare, scrivere bozze.

Questa guida spiega da dove un agente prende i dati, come è strutturato, i compiti che svolge bene, i guardrail che lo separano dal livello di controllo, le ragioni per eseguirlo on premise e come valutarne uno.

Da dove arrivano i dati?

Un agente di fabbrica vale quanto il suo accesso al contesto, e la maggior parte del lavoro in un’installazione è integrazione tra sistemi.

OPC UA è la fonte principale. Oltre a trasportare valori, OPC UA espone un modello informativo: nodi con tipi, unità, descrizioni e relazioni, organizzati in uno spazio degli indirizzi che un client può esplorare. Le specifiche companion standardizzano quel modello per macchine utensili, robot, presse a iniezione e altre apparecchiature. Per un agente è la differenza tra vedere “tag 4711 = 73.2” e vedere “Temperatura del cuscinetto del mandrino 1, gradi Celsius, parte del Centro di lavoro 3”. Gli strumenti dell’agente possono esplorare lo spazio degli indirizzi, leggere valori e sottoscrivere le variazioni, presentando la struttura come un albero su cui l’LLM può ragionare.

MQTT con Sparkplug è la seconda fonte, comune negli impianti con un namespace unificato (unified namespace). Sparkplug aggiunge una struttura di topic definita, certificati di nascita e di morte per i dispositivi e un payload binario con metriche e metadati, così l’agente, come qualsiasi subscriber, può scoprire che cosa esiste senza un file di configurazione.

Gli historian e i database di serie temporali conservano il passato: l’agente li interroga per rispondere a “com’era questa cosa martedì scorso”. Il MES contiene ordini, lotti e risultati di qualità; il sistema di manutenzione contiene ordini di lavoro e storici degli asset; l’archivio documentale contiene manuali e procedure. Un agente che vede solo i valori in tempo reale è un assistente peggiore di un operatore con un registro di bordo.

Come è strutturato l’agente?

Un agente di fabbrica dovrebbe essere, per progettazione, orientato quasi solo alla lettura. Il suo insieme di strumenti si divide in tre gruppi con rischi molto diversi.

Strumenti di lettura: esplorare il modello degli asset, leggere valori, interrogare lo storico, cercare nei documenti, recuperare gli ordini di lavoro aperti. Si possono concedere ampiamente senza rischi, entro le regole di accesso ai dati dell’impianto.

Strumenti di proposta: preparare la bozza di un ordine di lavoro o di un rapporto di turno, suggerire una modifica di setpoint, segnalare un’anomalia da esaminare. L’output va a una persona che lo approva o lo scarta. È qui che vive la maggior parte del valore.

Strumenti di azione: scrivere un setpoint, tacitare un allarme, avviare un lavoro. Dovrebbero essere pochi, delimitati, tracciati e, nella maggior parte degli impianti, assenti dalla prima installazione.

Il contesto è l’altra metà della struttura. Un passaggio di recupero (retrieval) fornisce al modello la porzione rilevante del modello degli asset, gli allarmi attivi, lo storico recente e il testo delle eventuali procedure pertinenti. Caricare l’intero impianto nel prompt non funziona; l’agente ha bisogno di strumenti che recuperino il sottoinsieme giusto su richiesta.

Quali compiti svolge bene un agente?

Riepiloghi per il passaggio di consegne: leggere il registro degli allarmi, gli eventi di fermo, i conteggi di produzione e gli interventi di manutenzione dell’ultimo turno, e scrivere il riepilogo che il supervisore uscente scriverebbe altrimenti a mano.

Triage delle cause: quando una linea si ferma, raccogliere gli allarmi dei minuti precedenti, le modifiche recenti ai setpoint, lo stato delle apparecchiature vicine e le pagine pertinenti del manuale, e presentare un elenco ordinato delle cause probabili con le relative evidenze. La persona decide comunque, ma parte da una pagina di fatti ordinati invece che da sei schermate.

Ordini di lavoro di manutenzione: prendere un avviso da un sistema di manutenzione predittiva, cercare l’asset, il suo storico e i ricambi, e preparare la bozza dell’ordine di lavoro con la procedura giusta allegata.

Domande degli operatori: “qual è la tolleranza su questo pezzo”, “quando è stata revisionata l’ultima volta questa valvola”, “quali macchine sono ferme in questo momento”. Sono domande di recupero di informazioni attraverso sistemi che non hanno mai condiviso una casella di ricerca.

Gestione degli eventi: un sistema di visione che segnala “pallet nel corridoio” produce un evento; l’agente può aggiungere contesto e inoltrarlo alla persona giusta.

Quali guardrail servono a un agente di fabbrica?

I guardrail per un agente di fabbrica sono più severi che per una casa, e la maggior parte si applica nell’architettura piuttosto che nei prompt.

Separa l’agente dal controllo. L’agente gira nella zona IT o nella DMZ, non nella rete di controllo. Le zone e i condotti della IEC 62443 danno il vocabolario: l’agente legge attraverso un condotto, spesso un server di aggregazione OPC UA in sola lettura o un broker MQTT alimentato dalla zona di controllo, e non ha alcun percorso per scrivere in un PLC. La segmentazione della rete rende questa separazione fisica, e non solo una policy.

Mantieni la sicurezza deterministica. I sistemi strumentati di sicurezza, gli interblocchi e gli arresti di emergenza non sono strumenti. Un agente non deve poterli raggiungere, e niente di ciò che produce deve essere una precondizione per il loro funzionamento.

Delimita ogni scrittura. Se esiste uno strumento per scrivere un setpoint, deve accettare solo tag presenti in una lista di autorizzazione (allowlist), solo entro un intervallo configurato, solo con limiti di frequenza e solo dopo un passaggio di approvazione umana registrato con l’identità della persona. I limiti vivono nel codice dello strumento, e il PLC mantiene sotto i propri.

Registra tutto. Ogni chiamata a uno strumento, i suoi argomenti, il ragionamento dichiarato dal modello e la persona che ha approvato un’azione vengono registrati in un archivio che l’agente non può modificare. È questo che rende possibile l’analisi degli incidenti.

Tratta gli input come non affidabili. Manuali, ticket e campi di testo libero possono contenere istruzioni. L’agente non deve mai agire perché un documento gliel’ha detto; gli output degli strumenti sono dati, non comandi.

Progetta per le risposte sbagliate. Il modello sbaglierà, con piena sicurezza, su una parte delle domande. Ogni output dovrebbe mostrare le proprie evidenze, così che una persona possa verificarle in pochi secondi, e “scarta” dovrebbe essere facile quanto “approva”.

Perché eseguirlo on premise?

I dati di produzione sono commercialmente sensibili, alcuni siti sono isolati dalla rete (air-gapped) e la dipendenza da un’API esterna è un nuovo rischio di disponibilità per un impianto che lavora senza sosta. Un modello ospitato in locale su un server GPU on premise risponde a queste preoccupazioni, al prezzo di un ragionamento più debole rispetto ai più grandi modelli cloud e dell’onere di gestire l’hardware. Una via di mezzo usa un modello locale per il recupero di informazioni e i riepiloghi di routine, e instrada una minoranza di domande difficili verso un modello cloud dopo aver rimosso i campi sensibili. Le regole sulla sovranità dei dati possono decidere la questione prima ancora che qualcuno soppesi il compromesso.

Come si valuta e come si fa il rollout?

Valuta l’agente come faresti con un nuovo assunto. Costruisci un insieme di domande reali con risposte note, tratte dallo storico dell’impianto, e assegna un punteggio all’agente prima del deployment e dopo ogni modifica al modello o ai prompt. Misura la qualità del recupero delle informazioni separatamente dalla qualità del ragionamento, perché la maggior parte dei fallimenti è dovuta a contesto mancante e non a logica sbagliata.

Procedi per fasi: prima risposte a domande in sola lettura per un piccolo gruppo, poi proposte con approvazione, poi, solo se l’impianto le vuole, azioni delimitate. Riporta le correzioni dei revisori nella configurazione del recupero e nei prompt. La guida all’Industrial IoT descrive l’architettura dei dati di impianto da cui tutto questo dipende.

Per continuare

• Agenti AI per la smart home tratta la stessa architettura di agente in un contesto in cui la posta in gioco è più bassa.
• Manutenzione predittiva con IoT e AI produce gli avvisi che un agente trasforma in ordini di lavoro.
• Industrial IoT: una guida pratica tratta il livello dei dati, dai PLC al cloud.
• Fondamenti di sicurezza IoT è lo sfondo per i requisiti di segmentazione e di audit.

Argomenti: agenti AI, OPC UA, Industrial IoT, LLM, guardrail