AI prescrittiva in fabbrica: cosa serve davvero, secondo Siemens e Infinite Uptime

L'8 ottobre 2026 IIoT World ha pubblicato un Q&A in cui Boris Scharinger (Siemens, autore di "Industrial AI: From Pilot to Profit") e Karthikeyan Natarajan (CEO di Infinite Uptime) rispondono a otto domande emerse durante la sessione "Unlocking Plant Reliability with Verticalized Prescriptive AI" dell'Industrial AI Summit 2026. L'AI prescrittiva va oltre la previsione del guasto: indica quale componente sostituire, quale intervento di manutenzione eseguire e quando. Questa analisi si basa sulle prime sei risposte; le ultime due non erano leggibili nel testo consultato.

Una precisazione utile: il contenuto è marcato "Sponsored by Infinite Uptime | Editorially Independent". Le cifre di prestazione attribuite a Natarajan sono quindi dichiarazioni del fornitore, non verificate in modo indipendente.

Dati prima o caso d'uso prima?

Scharinger descrive il dibattito tra "use case first" e "data strategy first" come quasi ideologico: i CFO tendono a preferire il ritorno di un singolo caso d'uso, i CTO la strategia sui dati. Per lui il livello dati è una capacità fondamentale, il cui costo non può essere addebitato a un solo caso d'uso.

Natarajan sostiene invece che attendere dati puliti sia una "tassa pluriennale", perché la maggior parte degli impianti non ha uno storico completo. Afferma che un approccio consapevole della fisica porterebbe a una prima prescrizione in due settimane e alla copertura dell'intero impianto in 90 giorni (dato da vendor). Il suo consiglio, più generale, è partire dagli asset a maggiore criticità e meglio strumentati.

Retrofit negli impianti esistenti

Entrambi sostengono l'aggiunta di sensori e visione artificiale negli impianti datati. Scharinger osserva che ciò può ridurre anche la dipendenza dai costruttori delle macchine. Secondo Natarajan, la vibrazione intercetta il degrado meccanico, mentre visione e sensori termici rilevano problemi di processo e qualità che la vibrazione non vede.

Diagnosi: l'uomo resta nel ciclo

Per Scharinger il rilevamento di anomalie è solo un punto di partenza e le anomalie vanno riviste da persone. La classificazione richiede etichette, che l'AI può aiutare a produrre; le etichette si collegano poi alla documentazione tramite RAG e LLM. Il suo suggerimento è tenere separata l'AI di anomalia e classificazione da quella di consultazione.

Natarajan propone una sequenza analoga:

• firme di guasto basate sulla fisica per la prima classificazione;
• verifica di ogni prescrizione da parte di un esperto di affidabilità prima che arrivi in reparto;
• RAG+LLM usati solo come livello di spiegazione e ricerca.

Usare un LLM per individuare modi di guasto fisici è un rischio reale (Natarajan).

Sostituire o prevedere? Un modello decisionale

Non esiste una soglia empirica sul valore del componente. Scharinger raccomanda un modello quantitativo per ciascun caso d'uso, che comprenda il costo del fermo non pianificato, la vita utile residua persa con una sostituzione anticipata (ad esempio un costoso utensile CNC) e il costo della sostituzione pianificata, tra fermo programmato e manodopera. Suggerisce di usare l'AI per abbozzare il modello e di aggiungere una simulazione Monte Carlo per trattare l'incertezza.

Sul fronte dell'audit, Siemens ha impiegato circa 2-3 persone per 6 settimane per verificare algoritmi, ipotesi di business e valutazione del rischio, comprese le simulazioni Monte Carlo, senza addebitare il costo alle unità di business coinvolte.

Cosa portarsi a casa

Indicazioni pratiche per i responsabili tecnici e IT:

• trattare i dati come infrastruttura condivisa, ma iniziare da asset critici e ben strumentati;
• valutare il retrofit con sensori diversi, scegliendo la tecnologia in base al tipo di guasto;
• separare classificazione dei guasti e ricerca documentale, con revisione umana obbligatoria;
• costruire per ogni caso un modello economico con incertezza esplicita, e prevedere il lavoro di audit.

Il valore del Q&A sta soprattutto nell'impostazione: la manutenzione prescrittiva è tanto un problema di processo decisionale e governance quanto di algoritmi. Le promesse sui tempi di avvio vanno invece verificate con un pilota sui propri asset.