Il lato umano dell'AI industriale: responsabilità, operatori e cambiamento

Il 15 ottobre 2026 IIoT World ha pubblicato le risposte a sei domande del pubblico, raccolte durante la sessione "From AI Pilots to Profit: Unlocking Manufacturing's Hidden Data Advantage" all'Industrial AI Summit 2026. A rispondere sono stati Neil Smith, Segment President Consumer Packaged Goods di Schneider Electric, e Andrew Waycott, President e co-fondatore di TwinThread. Il tema è quello che spesso decide la sorte dei progetti: le persone.

Una premessa necessaria: entrambi i relatori sono fornitori di tecnologia, quindi le loro posizioni non sono indipendenti, e il pezzo è un Q&A di un panel, non una ricerca. Resta però utile come sintesi di pratiche che molti responsabili tecnici stanno affrontando.

La resistenza della forza lavoro è un rischio misurabile

Secondo lo studio 2026 di Schneider sull'AI nel settore CPG, il 25,7% dei produttori a livello globale indica la resistenza della forza lavoro come rischio per la scalabilità dell'AI. Non è quindi un aspetto marginale, ma una voce da inserire nell'analisi dei rischi di progetto.

Raccomandazioni all'operatore, non azioni autonome

Waycott descrive l'approccio di TwinThread: il sistema rileva la deriva di processo e invia all'operatore una raccomandazione, invece di agire da solo sul processo. L'operatore può approvarla, modificarla o rifiutarla, e il modello apprende da questa scelta. Le azioni storiche degli operatori definiscono i setpoint iniziali e i limiti operativi, mentre gli ingegneri usano i feedback per migliorare i modelli.

Il vantaggio è duplice: il controllo resta a chi conosce l'impianto e la competenza degli operatori diventa parte del ciclo di miglioramento, anziché essere aggirata.

Di chi è la colpa quando l'AI sbaglia?

Alla domanda su chi sia responsabile di un guasto quando l'AI agisce senza supervisione umana (data engineer, fornitore del modello o operatore), Waycott risponde che si tratta di un fallimento del flusso di lavoro, non di un singolo attore. Propone salvaguardie condivise:

• i data engineer garantiscono un flusso di dati pulito e affidabile;
• i fornitori del modello definiscono soglie che avvisano il team quando un guasto è imminente;
• ingegneri e operatori dispongono di procedure chiare per individuare e diagnosticare le anomalie e intervenire.

Il change management come parte del progetto

Per Smith l'AI industriale non è solo un progetto IT. Il consiglio pratico è coinvolgere presto i team di operations e manutenzione, già nella scelta dei casi d'uso, e mantenerli coinvolti fino al rilascio. I programmi di successo, sostiene, investono in change management e competenze quanto nelle piattaforme, e le aziende con il miglior ritorno sull'AI tendono ad avere maggiore coinvolgimento e fidelizzazione del personale.

Entrambi vedono nell'AI anche uno strumento per catturare l'esperienza dei veterani e metterla a disposizione di colleghi più giovani e digitali, attenuando l'effetto di turnover e cambi turno.

L'esempio di Wuhan, con cautela

Schneider cita la fabbrica "Lighthouse" di Wuhan, dove un'AI agentica ha tracciato le lacune di competenze e assegnato formazione personalizzata. I dati sono dichiarati dall'azienda e non verificati in modo indipendente:

• preparazione della forza lavoro dal 20% al 76%;
• 56% dei dipendenti riqualificato;
• tempo di introduzione di nuovi prodotti ridotto da 36 a 12 mesi, un taglio del 66,7%.

Cosa farne in pratica

Per responsabili di ingegneria e IT, le indicazioni sono tre:

• progettare l'AI come supporto alle decisioni, con approvazione dell'operatore;
• definire responsabilità condivise tra dati, modello e operations, con soglie e procedure scritte;
• prevedere nel budget il change management accanto alla tecnologia.

Sono principi di buon senso, ma la distanza tra enunciarli e applicarli è dove molti pilota si arenano. Trattare gli operatori come co-progettisti, e non come destinatari finali, è il modo più concreto per ridurre quel rischio.