Perché l'IA che funziona in uno stabilimento si rompe al ventesimo

Il 29 ottobre 2026 IIoT World ha pubblicato la sintesi di un panel dell'Industrial AI Summit 2026 dedicato a un problema noto: un progetto di IA che funziona in uno stabilimento si rompe quando lo si replica in venti. Al panel hanno partecipato Gaspard Duthilleul (Galyos), Sanjay Mahato (AWS), Ian Clark (InfluxData) e Tauseef Ahmed (Grayhawk Consulting Group).

Una precisazione: l'articolo è etichettato come "Sponsored by InfluxData | Editorially Independent" e Ian Clark di InfluxData era tra i relatori. È quindi lecito aspettarsi una prospettiva da fornitore di tecnologia, pur con contenuti che riflettono problemi reali di campo.

Dove si rompe la scalabilità

Un progetto pilota funziona perché ha un perimetro stretto: una linea, un team, dati conosciuti. Estenderlo a venti siti mette in crisi più cose insieme:

• Nomi dei tag che divergono: "compressore uno" può indicare cose diverse in siti diversi.
• Sfasamento degli orologi tra le sorgenti, che introduce errori di timestamp nei dati di addestramento.
• Proprietà dei dati e definizione di "dato di qualità" differenti da sito a sito.
• Correzioni manuali e connettori su misura costruiti per un solo sito, che diventano un debito tecnico.

C'è anche un tema economico. Con le licenze degli historian tradizionali basate sul numero di tag, il costo cresce a ogni sensore aggiunto, mentre i modelli di IA tendono a funzionare meglio con più sensori collegati. L'economia, insomma, lavora contro la scala.

I cinque requisiti di una base dati "AI-ready"

Secondo il panel, la base dati deve offrire:

• durabilità con store-and-forward per le interruzioni di rete;
• precisione dei timestamp al nanosecondo;
• standard aperti, per evitare il vendor lock-in;
• supporto sia all'addestramento sia all'inferenza;
• un livello semantico che imponga un significato coerente tra i siti.

Il contesto conta più del volume

Secondo il panel i produttori hanno già molti dati; manca il contesto: identità dell'asset, prodotto in lavorazione, condizioni operative, storico di manutenzione ed esiti di qualità. Anche la risoluzione pesa. Le dashboard campionano tipicamente ogni 1-5 secondi, mentre i modelli di anomaly detection richiedono spesso segnali a livello di kilohertz: addestrarli su dati a risoluzione da dashboard appiana proprio i fenomeni che dovrebbero rilevare.

L'esempio Volkswagen

Come riportato, la Digital Production Platform di Volkswagen copre 43 stabilimenti. I dati sono raccolti all'edge con i metadati associati già in acquisizione, restano nel singolo stabilimento e un livello semantico ne garantisce il significato coerente. Quando uno stabilimento risolve un problema di qualità con l'IA, gli altri 42 ne beneficiano. Si riferisce che l'architettura sarà estesa ad altri 70 stabilimenti.

Business case e numeri

Il panel consiglia di legare la spesa infrastrutturale a problemi concreti (fermi macchina, first-pass yield, costi di manutenzione e garanzia, produttività del lavoro) e di trattare i dati come un prodotto, con un responsabile e un budget. In un sondaggio dal vivo, il 33% dei partecipanti aveva in corso la scalabilità dell'infrastruttura dati e il 41% non la considerava una priorità. Una ricerca MIT citata nella sessione stima che circa il 95% dei 35-40 miliardi di dollari investiti ogni anno nell'IA nel mondo non riesca a scalare. Il dato è del panel e non ho verificato la fonte primaria.

Perché riguarda chi lavora in automazione

Standardizzare i tag, sincronizzare il tempo e contestualizzare i dati sono attività di ingegneria PLC, SCADA e historian, e vanno completate prima di estendere l'IA a più stabilimenti.

Un punto di partenza pratico: prima del prossimo pilota, verificare una convenzione di naming condivisa, la sincronizzazione degli orologi (per esempio tramite una sorgente di tempo comune) e quali metadati vengono associati a ogni segnale. Poi chiedersi se la risoluzione di acquisizione è adeguata al modello previsto, non alla dashboard.