Negli ultimi due anni gli assistenti basati su modelli linguistici sono entrati stabilmente negli strumenti di sviluppo, e chi scrive software per l'industria se ne è accorto. La domanda utile non è se l'IA "cambierà l'automazione": è più concreta e riguarda il lavoro di tutti i giorni. Cosa accelera davvero, cosa non tocca affatto, e quali competenze restano indispensabili perché un impianto parta e continui a funzionare.
La risposta breve: l'IA è uno strumento efficace sulla parte software, meno utile man mano che ci si avvicina al campo, e sostanzialmente inutile nel momento in cui bisogna mettere le mani su una macchina. Vale la pena entrare nel dettaglio, perché il confine non è netto e passa in un punto preciso.
Dove aiuta davvero: la parte software
Il guadagno più concreto si ottiene sul codice che vive fuori dal PLC: supervisione, servizi, database, integrazioni, script di manutenzione, strumenti interni. Tipicamente:
- Capire codice scritto da altri — progetti ereditati, librerie senza documentazione, applicativi di cui non c'è più chi li ha fatti. Farsi spiegare un modulo prima di toccarlo fa risparmiare ore vere.
- Scrivere parti ripetitive — parser di protocollo, conversioni di formato, interfacce di test, query, routine di logging.
- Analizzare log e tracciati — filtrare migliaia di righe, correlare eventi, isolare la finestra temporale in cui è successo qualcosa.
- Produrre documentazione — descrizioni funzionali a partire dal codice, commenti, traduzioni, manuali operatore.
- Cercare dentro documentazione vasta — capire in quale parte di un manuale da 900 pagine sta la risposta, sapendo poi che la verifica va fatta sul manuale stesso.
Sulla logica PLC il vantaggio si riduce parecchio. I linguaggi IEC 61131-3 sono meno rappresentati nei dati su cui questi modelli sono addestrati, e soprattutto il senso di un blocco funzione dipende da come è cablata la macchina, non dal testo del programma. Un modello può aiutare a scrivere una funzione di scaling o a rileggere una sequenza in ST; non può sapere che quel sensore è montato al contrario.
Diagnosi: genera ipotesi, non conferme
Nel troubleshooting il contributo è reale ma va inquadrato. Descrivendo bene un sintomo si ottiene rapidamente un elenco ordinato di cause possibili, incluse quelle a cui non si era pensato. È utile soprattutto quando si lavora su tecnologie che non si tocca da tempo, o fuori dal proprio ambito abituale.
Quello che nessun modello può fare è chiudere il ciclo. L'ipotesi si conferma con una misura: un trend, un forzamento controllato, un punto di prova, un cavo seguito fino in fondo. E la scelta di quale prova fare per prima — quella che costa meno e discrimina di più — è esattamente la competenza che si costruisce sul campo.
Il collaudo non è un test di software
Qui il confine diventa netto. La messa in servizio non è la verifica che un programma compili o che una logica sia formalmente corretta: è la verifica che una macchina fisica si comporti come previsto. Significa controllare gli I/O punto per punto, verificare il senso di rotazione dei motori, tarare sensori e soglie, provare le sequenze a vuoto prima che a carico, sollecitare gli allarmi per vedere se intervengono davvero, provare l'arresto di emergenza e il ripristino dopo una mancanza di rete.
È anche la parte che non produce testo. Un finecorsa che lavora al limite della corsa, una vibrazione che non c'era, un connettore che fa contatto solo a caldo, una valvola più lenta di quanto dichiarato: sono informazioni che si raccolgono guardando, ascoltando e misurando. Non esistono in nessun file, quindi non esistono per nessun modello.
La conoscenza che non sta nel codice
Su impianti esistenti buona parte del lavoro consiste nel ricostruire la realtà. Lo schema elettrico non corrisponde più, la morsettiera è stata rinumerata anni fa, ci sono blocchi che nessuno ha documentato, e ci sono prassi di reparto che non sono scritte da nessuna parte ma che determinano come la linea viene condotta davvero.
A questo si aggiunge un tipo di giudizio che non si formalizza facilmente: capire se un allarme segnala un difetto o è la conseguenza normale di un ciclo particolare; sapere quanto si può fermare una linea prima che il fermo diventi un problema di reparto; sapere quali prove si possono fare in produzione e quali vanno rimandate al fine settimana; sapere quando è il caso di fermarsi e chiedere. Sono valutazioni che si costruiscono su impianti veri, con le conseguenze vere degli errori.
Sicurezza funzionale: un discorso a parte
Va distinto con chiarezza l'uso dell'IA come strumento di lavoro dall'inserimento di un modello dentro la macchina. Il primo caso riguarda chi progetta, il secondo cambia la natura del prodotto e le regole che gli si applicano.
Il Regolamento (UE) 2023/1230 sulle macchine, che si applica dal 20 gennaio 2027 in sostituzione della Direttiva 2006/42/CE, include nell'Allegato I Parte A i componenti di sicurezza con comportamento totalmente o parzialmente auto-evolutivo basato su approcci di machine learning che garantiscono funzioni di sicurezza. Le categorie elencate in quella parte dell'allegato sono soggette a procedure di valutazione della conformità che coinvolgono un organismo notificato. In parallelo, il Regolamento (UE) 2024/1689 (AI Act) classifica come ad alto rischio i sistemi di IA che costituiscono componenti di sicurezza di prodotti coperti dalla normativa di armonizzazione elencata nel suo Allegato I, con obblighi che entrano in applicazione in modo scaglionato.
In pratica: mettere machine learning dentro una funzione di sicurezza non è una scelta tecnica libera, e va valutata con la documentazione normativa alla mano. Usare un assistente per scrivere il codice di supervisione è tutt'altra cosa, e non cambia la classificazione della macchina. Quello che non cambia in nessuno dei due casi è chi risponde di ciò che viene messo in servizio.
Come usarla senza farsi male
- Usala dove l'errore si vede subito e costa poco. Codice testabile fuori dall'impianto, script, documentazione, analisi di log. Non su logiche che vanno direttamente in macchina senza una prova.
- Non incollare quello che non sapresti riscrivere. Chi mette il codice in macchina deve averlo letto e capito riga per riga: in impianto non esiste il rollback indolore.
- Verifica sempre sul manuale del costruttore. Funzioni di libreria, parametri, comportamenti dipendenti dalla versione firmware: su questi punti l'output di un modello va trattato come un'indicazione da controllare, mai come fonte.
- Attenzione a cosa condividi. Codice del cliente, schemi, indirizzi IP, credenziali e dati di processo finiscono su un servizio esterno. Valgono le stesse regole che si applicano a qualunque servizio cloud, e spesso c'è un contratto che le rende vincolanti.
- Prova prima in simulazione. Un banco o un simulatore intercettano una parte degli errori a costo quasi nullo. Non sostituiscono il collaudo, lo rendono più corto.
Errori da evitare
- Considerare finito un lavoro quando il codice compila. La parte lunga di un progetto raramente è scrivere il programma.
- Chiedere a un modello di "sistemare" una logica di sicurezza. Le funzioni di sicurezza si progettano e si verificano secondo le norme applicabili, non per tentativi.
- Affidare la diagnosi a chi non sarebbe in grado di verificarla. Senza verifica, una risposta plausibile e una corretta sono indistinguibili.
- Confondere la velocità di stesura con la velocità di avviamento. Il collaudo dura quanto durava prima.
- Ridimensionare la squadra tecnica sulla base di un guadagno di produttività che nessuno ha misurato sul proprio lavoro reale.
In sintesi
L'IA alza la produttività di chi già sa cosa sta facendo, e non abbassa la competenza necessaria per fare questo mestiere. Un tecnico esperto con questi strumenti chiude prima la parte software e arriva in campo più preparato. Chi invece non ha le basi ottiene codice plausibile: in un impianto è una condizione peggiore di un programma che non compila, perché l'errore non si manifesta in ufficio ma in produzione, quando la macchina si muove.
Il lavoro resta quello di prima: capire il processo, leggere l'impianto, provare, misurare, firmare. Cambia lo strumento, non il mestiere.
Come possiamo aiutare
Sviluppiamo e mettiamo in servizio software per l'automazione — PLC, HMI, SCADA, applicativi custom e integrazioni — seguendo il lavoro dall'analisi fino al collaudo in campo. Gli strumenti che usiamo in fase di sviluppo servono ad arrivare prima e meglio alla messa in servizio, che resta la parte dove si decide se un impianto funziona.
Hai un progetto di automazione, un retrofit o un software da rimettere in ordine?
Contattaci per una valutazione tecnica, con tempi e modalità di collaudo definiti prima di iniziare.