Gli LLM stanno entrando anche nel lavoro quotidiano dell’automazione industriale. Possono riordinare requisiti, spiegare codice esistente, preparare una prima struttura software o proporre casi di test. Il vantaggio non consiste nel sostituire l’automation engineer, ma nel ridurre il tempo impiegato per trasformare informazioni già note in una prima versione da verificare.
Questa distinzione è essenziale. Un modello linguistico genera una risposta plausibile sulla base del contesto ricevuto; non osserva direttamente la macchina, non conosce tutti i vincoli fisici dell’impianto e non assume responsabilità sul risultato. In automazione, invece, ogni istruzione caricata in un PLC o in un controller robot produce effetti determinati sul processo reale.
Dove gli LLM possono essere utili
Un assistente linguistico può contribuire soprattutto nelle attività in cui il risultato è controllabile da un tecnico:
- trasformare una specifica funzionale in una bozza di sequenza o macchina a stati;
- generare strutture ripetitive in Structured Text, Ladder Diagram o Function Block Diagram;
- preparare commenti, descrizioni di allarmi e documentazione operativa;
- ricavare una matrice di test da requisiti e interblocchi già definiti;
- confrontare versioni di codice e rendere più leggibile una modifica;
- sintetizzare manuali o documentazione tecnica forniti come contesto;
- predisporre checklist per simulazione, FAT, SAT e rilascio.
La norma IEC 61131-3:2025 definisce sintassi e semantica dei principali linguaggi per controllori programmabili. Un LLM può aiutare a produrre codice conforme a quella struttura, ma la correttezza sintattica non dimostra la correttezza dell’applicazione.
Il codice plausibile non è ancora codice valido
Il profilo NIST per l’intelligenza artificiale generativa descrive la confabulazione come la produzione di contenuti errati presentati con apparente sicurezza. Nel software industriale il problema non riguarda soltanto errori evidenti: una sequenza può compilare, funzionare in condizioni nominali e fallire su un riavvio, un timeout, un sensore incoerente o una transizione non prevista.
Il modello non conosce automaticamente:
- la reale mappatura degli ingressi e delle uscite;
- i tempi di risposta di azionamenti, sensori e reti;
- inerzie, ingombri, collisioni e limiti meccanici;
- la versione effettiva di firmware e librerie;
- le condizioni degradate o di ripartenza;
- le assunzioni utilizzate nella valutazione del rischio.
Per questo l’output generato deve essere trattato come una proposta tecnica, non come una fonte di verità.
La sicurezza funzionale resta un confine netto
Le funzioni che proteggono persone e impianto richiedono specifica, progettazione, verifica e validazione secondo le norme applicabili. ISO 13849-2 prevede la validazione mediante analisi e prove delle funzioni di sicurezza e del livello prestazionale raggiunto. IEC 61508-3 disciplina il ciclo di vita del software di sicurezza, compresi strumenti di sviluppo, configurazione, test e gestione delle modifiche.
Un LLM può aiutare a preparare una descrizione, un elenco di casi limite o una bozza di test. Non deve approvare una funzione di sicurezza, modificare autonomamente parametri protetti o sostituire la validazione svolta da personale competente.
Anche il nuovo Regolamento macchine (UE) 2023/1230, applicabile in via generale dal 20 gennaio 2027, rafforza l’attenzione verso documentazione tecnica, logica di programmazione, prove e validazione del software rilevante per la sicurezza.
Un flusso di lavoro pratico
1. Classificare l’attività
Prima del prompt va stabilito se il compito riguarda documentazione, codice non critico, logica di processo o funzioni di sicurezza. Più aumenta l’impatto dell’errore, più devono crescere separazione dei ruoli, profondità dei test e indipendenza della revisione.
2. Fornire un contesto controllato
Manuali, requisiti, versioni software e convenzioni devono essere identificati chiaramente. Codice cliente, credenziali, indirizzi di rete e informazioni riservate non vanno inviati a strumenti non approvati dall’organizzazione.
3. Chiedere artefatti piccoli
È più semplice verificare un singolo blocco funzione, una tabella di transizione o dieci casi di test che un intero progetto generato in una sola richiesta. Ogni output dovrebbe avere un perimetro e un criterio di accettazione espliciti.
4. Collegare il codice ai requisiti
Ogni transizione, allarme e interblocco deve poter essere ricondotto a un requisito. Se il modello introduce una condizione non richiesta, questa va rimossa o formalmente approvata come modifica progettuale.
5. Verificare per livelli
Il controllo comprende compilazione, analisi statica dove disponibile, simulazione delle sequenze, test degli stati anomali e prova sull’hardware previsto. Per la robotica si aggiungono verifica delle coordinate, dei riferimenti, delle singolarità, degli ingombri e delle condizioni di ripristino.
6. Richiedere un’approvazione umana identificabile
La persona che revisiona deve avere competenza sul dominio e accesso alle informazioni reali della macchina. Per le parti rilevanti per la sicurezza serve il processo di validazione previsto dalle norme e dall’organizzazione.
7. Rilasciare in modo controllato
Versione del codice, configurazione, risultati dei test, approvazioni e piano di ritorno devono accompagnare la modifica. L’uso dell’LLM non cambia le normali regole di change management.
Governance: poche regole, ma applicate davvero
Il NIST AI Risk Management Framework organizza la gestione del rischio nelle funzioni Govern, Map, Measure e Manage. Applicato all’ingegneria industriale significa definire almeno:
- strumenti e modelli autorizzati;
- classi di dati che possono essere utilizzate;
- attività consentite e attività escluse;
- responsabilità di autore, revisore e approvatore;
- modalità di registrazione di fonti, versione del modello e modifiche;
- criteri di test proporzionati al rischio;
- gestione di vulnerabilità, dipendenze e rilascio sicuro.
Il NIST Secure Software Development Framework offre inoltre un riferimento volontario per integrare la sicurezza nel ciclo di sviluppo.
Dal 2 agosto 2026 l’AI Act è generalmente applicabile nell’Unione, pur con calendari differiti per alcune categorie. Gli obblighi concreti dipendono dal ruolo dell’organizzazione e dal caso d’uso; le disposizioni sull’alfabetizzazione in materia di AI sono applicabili dal febbraio 2025. La pagina ufficiale della Commissione europea mantiene il calendario aggiornato.
Il criterio finale resta ingegneristico
La misura utile non è quante righe produce il modello, ma quante attività ripetitive elimina senza aumentare errori, rilavorazioni o rischio. Nell’automazione industriale l’LLM può essere un buon acceleratore. Requisiti, comportamento deterministico, sicurezza e accettazione della macchina restano responsabilità di persone competenti, sostenute da prove documentate.