AI pronta non significa AI decisionale: metriche e scala dell'autonomia

Il 30 ottobre 2026 IIoT World ha pubblicato il resoconto di un panel dell'Industrial AI Summit 2026, firmato da Paul Viorel. Una precisazione di metodo: la pagina è etichettata come "Sponsored by Arch Systems" e l'articolo dichiara che strumenti di AI hanno aiutato a riassumere la discussione. Va quindi letto come contenuto sponsorizzato. Le idee, però, sono utili a chi lavora ogni giorno con automazione e sistemi di supervisione.

Al panel hanno partecipato Tim Burke (Arch Systems), Abby Eon (Velotic), Bryce Barnes (LG CNS) e Sahil Yadav (AOI), con la moderazione di Jeff Winter di IIoT World.

Il divario tra adozione e scala

L'articolo cita due indagini, i cui dati riportiamo come citati e non verificati in modo indipendente. Secondo il report 2026 di Parsec sull'industria manifatturiera, il 72% dei produttori ha adottato l'AI in qualche forma, ma solo il 10% l'ha messa in produzione su larga scala. Secondo la AI Impact Survey 2026 di Grant Thornton, il 62% concentra l'AI sulle operazioni, ma solo il 7% ha testato un piano di risposta agli incidenti legati all'AI e solo il 12% ritiene di poter superare un audit indipendente di governance.

"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 una pianificazione, invia una squadra o modifica un processo di qualità. Spesso output tecnicamente corretti restano inutilizzati perché nessuno si fida abbastanza da agire.

Prima che l'AI influenzi le operazioni, devono valere cinque condizioni:

• basata su dati reali;
• contestualizzata;
• spiegabile a chi non l'ha sviluppata;
• governata, con responsabilità chiare;
• limitata nel perimetro d'azione.

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 darà con sicurezza istruzioni sbagliate all'operatore.

"Operators do not trust systems that are always sure. They trust systems that can say 'I don't know right now.'"

Tre metriche al posto dell'accuratezza

Yadav propone di misurare l'AI con indicatori operativi, non con la sola accuratezza del modello:

• Mean time to explanation: il tempo che serve a una persona per capire perché l'AI ha dato un consiglio. Se supera la finestra decisionale, il consiglio è operativamente irrilevante.
• Trust-adjusted risk: il costo in denaro di un errore dell'AI, includendo reputazione, supply chain ed esposizione normativa e legale.
• Adoption rate: la quota di raccomandazioni su cui gli operatori agiscono davvero. Un modello molto accurato ma poco adottato indica un deficit di fiducia.

Tutte e tre vanno misurate prima di introdurre l'AI, e i casi di test dovrebbe sceglierli il responsabile delle operazioni.

La scala dell'autonomia in quattro livelli

Per ogni livello va dimostrato qualcosa di preciso:

• Observe: il quadro dei dati è accurato.
• Recommend: precisione rispetto a incidenti storici reali già etichettati da persone.
• Act with supervision (conferma umana): interruttori di sicurezza (circuit breaker), audit trail completi, spiegabilità e un raggio d'impatto limitato.
• Self-heal: un track record prolungato, azioni tutte reversibili e trust-adjusted risk entro i limiti accettati.

Prospettive e consigli per la scala

I relatori prevedono che entro circa tre anni l'AI generativa cambierà il modo in cui le decisioni operative vengono selezionate e presentate, ma le decisioni resteranno umane. Gli LLM predicono il token successivo, mentre la logica di controllo richiede esiti deterministici: l'AI sceglierà quindi quale workflow deterministico eseguire e lo proporrà a un operatore.

Per crescere, il consiglio è agganciare l'AI a un'architettura aziendale condivisa, unificare uno o due sistemi esistenti e consegnare un caso d'uso da quella base. L'anti-pattern è un progetto di integrazione dati di tre anni, solo IT, che non produce nulla lungo il percorso. In AOI gli ingegneri più esperti erano i più scettici; iniziare da un compito noioso e non critico li ha convinti.

Sulle risposte individuali: barriera principale alla scala sono organizzazione (Burke), contesto (Eon), dati (Barnes) e fiducia (Yadav). Tra i primi casi d'uso da scalare sono citati root cause di qualità, attribuzione dei fermi, assistenza ai workflow e manutenzione predittiva. Considerati sopravvalutati: robot umanoidi, copilot su dati disordinati, gli LLM stessi e gli agenti autonomi in reparto.

Perché conta per chi fa automazione

Il valore sta nei criteri di accettazione concreti e in un'introduzione graduale, utile anche per giustificare i progetti davanti al management. Il collegamento con SCADA e PLC è diretto: il livello 1 dipende dalla qualità dei dati e dalla gestione del caso "sensore guasto contro valore zero"; il livello 3 da audit trail e circuit breaker. Il suggerimento pratico: prima di un pilota, definire le tre metriche di partenza, partire da Observe e promuovere un caso d'uso al livello successivo solo con le prove richieste.