IA industriale: non basta essere «AI ready», serve essere «decision ready»

Il 30 ottobre 2026 IIoT World ha pubblicato la sintesi di un panel dell'Industrial AI Summit 2026 dedicato a una domanda pratica: che cosa deve dimostrare un sistema di intelligenza artificiale prima che gli operatori agiscano sulle sue indicazioni? Intervenivano Tim Burke (Arch Systems), Abby Eon (Velotic), Bryce Barnes (LG CNS) e Sahil Yadav (AOI), con la moderazione di Jeff Winter di IIoT World.

Una precisazione sulla fonte: la pagina è etichettata «Sponsored by Arch Systems | Editorially Independent», ed è stata riassunta con strumenti di IA e poi rivista dalla redazione. I dati di survey citati sono di seconda mano e non abbiamo verificato i rapporti originali.

Il divario tra adozione e governo

Secondo il rapporto 2026 State of the Manufacturing Industry di Parsec, il 72% dei produttori ha adottato l'IA in qualche forma, ma solo il 10% l'ha messa in produzione su larga scala. Il 2026 AI Impact Survey di Grant Thornton aggiunge un dato sulla governance: il 62% dei produttori concentra l'IA sulle operazioni, ma solo il 7% ha testato un piano di risposta agli incidenti legati all'IA e solo il 12% ritiene di poter superare un audit indipendente di governance dell'IA.

«AI ready» contro «decision ready»

Per i relatori, un sistema è «AI ready» quando il modello sa produrre una risposta. È «decision ready» quando qualcuno, in base a quella risposta, cambia un piano di produzione, invia una squadra o modifica un processo di qualità. Spesso output tecnicamente corretti restano inutilizzati perché nessuno si fida abbastanza da agire.

Cinque condizioni perché l'IA influenzi le operazioni: l'output deve essere

• fondato su dati reali;
• contestualizzato;
• spiegabile a chi non ha costruito il modello;
• governato, con responsabilità chiare;
• limitato a un perimetro definito.

Eon ha indicato come più importante la capacità di segnalare l'incertezza. Una lettura di sensore pari a zero non equivale a un sensore guasto, e un modello che non distingue i due casi può indicare con sicurezza all'operatore l'azione sbagliata.

«Gli operatori non si fidano di sistemi sempre sicuri. Si fidano di sistemi che sanno dire: non lo so, adesso.» (Abby Eon, traduzione dall'inglese)

Tre metriche alternative all'accuratezza

Yadav ha proposto tre indicatori al posto della sola accuratezza del modello:

• Mean time to explanation: il tempo necessario a una persona per capire perché l'IA ha formulato una raccomandazione. Se supera la finestra decisionale, la raccomandazione è operativamente irrilevante.
• Trust-adjusted risk: il costo economico di un errore dell'IA, comprese esposizioni reputazionali, di filiera, normative e legali.
• Adoption rate: la quota di raccomandazioni su cui gli operatori agiscono davvero. Un modello molto accurato ma poco adottato segnala un deficit di fiducia.

Le tre misure vanno stabilite come riferimento prima di introdurre l'IA, e i casi di test dovrebbe sceglierli il responsabile delle operazioni.

La scala di autonomia in quattro livelli

A ogni livello va dimostrato qualcosa di diverso:

• Osservare: il quadro dei dati è accurato.
• Raccomandare: precisione rispetto a incidenti storici reali già etichettati da persone.
• Agire con supervisione (approvazione umana): interruttori di sicurezza, tracciabilità completa, spiegabilità e un raggio d'azione limitato.
• Auto-correzione (autonomia): risultati solidi e duraturi, ogni azione reversibile e trust-adjusted risk entro limiti accettati.

Prospettive e consigli di adozione

Entro circa tre anni, secondo il panel, l'IA generativa cambierà il modo in cui le decisioni vengono selezionate e presentate, ma la decisione resterà agli esseri umani. La logica di controllo richiede esiti deterministici, mentre gli LLM prevedono il token successivo. Lo schema probabile è un'IA che sceglie quale flusso deterministico eseguire e lo propone a una persona.

Burke ha sostenuto che l'investimento è difendibile se si inserisce in un piano di architettura aziendale, evitando progetti di integrazione dati di tre anni gestiti solo dall'IT e privi di risultati intermedi. In AOI, gli ingegneri senior scettici sono stati convinti partendo da un'attività noiosa e non critica. I relatori hanno indicato barriere diverse alla scalabilità (organizzazione, contesto, dati, fiducia) e primi casi d'uso diversi: analisi delle cause radice sulla qualità, attribuzione dei fermi, assistenza ai flussi di lavoro e manutenzione predittiva. Tra le cose sopravvalutate: robot umanoidi, copilot su dati disordinati, gli LLM stessi e agenti autonomi in reparto.

Perché conta

Il valore dell'articolo sta nei criteri misurabili per passare dal pilota alle operazioni: le tre metriche, le prove richieste a ogni livello e la segnalazione dell'incertezza. Parte dei temi si sovrappone a precedenti contributi di IIoT World, ma scala di autonomia e metriche sono angoli nuovi.

Spunto pratico: prima del prossimo progetto, misurate tempo di spiegazione, rischio e tasso di adozione sul processo attuale, assegnate al caso d'uso un livello della scala e definite in anticipo le prove per salire al successivo.