Perché i dati di fabbrica non arrivano all'AI: il nodo della contestualizzazione

Il 9 ottobre 2026 IIoT World ha pubblicato un resoconto di un panel dell'Industrial AI Summit 2026 dedicato a una domanda ricorrente: perché i dati di fabbrica, raccolti da anni, non arrivano davvero all'intelligenza artificiale? La risposta dei relatori è che manca uno stadio intermedio, la contestualizzazione.

Una precisazione sulla fonte: l'articolo è indicato come sponsorizzato da HiveMQ e Cybus, pur dichiarandosi editorialmente indipendente, e due dei tre relatori lavorano per gli sponsor. Va quindi letto come opinione di un panel con interessi commerciali, non come uno studio basato su dati. Inoltre, questa sintesi si basa sulla sola prima parte dell'articolo; la sezione FAQ risultava troncata.

Raccolta risolta, contesto mancante

Al panel hanno partecipato Jonathan Alexander (Albemarle), Peter Sorowka (Cybus) e Kudzai Manditereza (HiveMQ). La tesi di partenza: i produttori investono da 10-20 anni in sensori e connettività, quindi la raccolta è in larga parte risolta e la storicizzazione è diffusa. Ciò che manca è il passaggio in cui le letture grezze acquisiscono conoscenza di processo, relazioni tra apparecchiature e condizioni operative.

Quella conoscenza vive ancora nella testa degli operatori esperti, non nei sistemi.

Per il panel è questo il principale divario che impedisce all'AI di scalare.

Due architetture a confronto

I relatori criticano due modelli diffusi. Il primo è l'architettura incentrata sullo storian: conserva valori e timestamp, ma senza relazioni, contesto o governance degli accessi, e secondo il panel non è mai stato progettato per servire l'AI. Il secondo è l'integrazione incentrata sull'applicazione: ogni progetto costruisce le proprie connessioni punto a punto, per esempio prima manutenzione predittiva, poi ottimizzazione energetica, poi monitoraggio qualità. Ne nasce un'architettura a "spaghetti", fragile, indicata come una delle ragioni per cui l'AI resta confinata in pilot isolati.

L'alternativa proposta è una piattaforma dati condivisa e incentrata sull'infrastruttura: ci si collega una sola volta a tutte le fonti operative e si espongono interfacce standardizzate, così i nuovi casi d'uso si aggiungono in modo incrementale. L'articolo rimanda a contenuti sullo unified namespace (UNS), ma la parte che ho letto non lo approfondisce.

Il disaccordo sugli LLM

Sul ruolo dei modelli linguistici le posizioni divergono:

• Alexander: i modelli di frontiera non hanno mai visto dati specifici di impianto come P&ID, parametri di processo e disegni. Un'AI generalista sa risolvere un problema al climatizzatore di casa, ma ha fallito sulla strumentazione specifica di un impianto.
• Sorowka: gli LLM tollerano dati disordinati, quindi non vale lo sforzo del 90% di etichettatura e pulizia tipico del machine learning classico. Il contesto si può fornire in fase di inferenza, anche da un PDF scansionato male; attendere dati perfetti non è una buona ragione per rinviare.
• Manditereza: servono knowledge graph per il contesto semantico. Un LLM che legge documenti isolati non sa quali processi a valle si fermano se un ordine di lavoro fallisce.

Tutti e tre concordano su un punto: i dati operativi vanno esposti all'AI tramite un'infrastruttura dati adeguata e con governance.

Governance degli agenti AI

Il panel chiede di trattare l'AI come un attore dell'architettura di sicurezza:

• un'identità propria per i sistemi AI;
• regole di accesso su quali dati possono leggere, quali sistemi possono influenzare e quali decisioni possono attivare;
• tracce di audit di ciò che l'AI ha consultato, raccomandato e causato.

Senza questi elementi, un'AI può arrivare alla maturità per la produzione e poi bloccarsi su sicurezza e conformità.

Cosa farne in pratica

Al netto dei limiti della fonte (nessun dato quantitativo, sponsor che vendono MQTT/UNS e piattaforme data-ops), la checklist è utile per i responsabili IT/OT:

• verificare se i nuovi progetti AI riusano un livello dati condiviso o aggiungono l'ennesima connessione punto a punto;
• decidere dove e come catturare la conoscenza di processo oggi nelle persone, in un modello contestuale;
• definire identità, permessi e audit per gli agenti prima del passaggio in produzione, non dopo.

Il messaggio di fondo è che il collo di bottiglia non è raccogliere più dati, ma renderli interpretabili e governabili. Le scelte tecnologiche concrete vanno valutate in modo indipendente dal fornitore.