AI fisica: cosa eseguire all'edge, cosa nel cloud e con quali limiti

Il 12 novembre 2026 IIoT World ha pubblicato la sintesi di un panel dell'Industrial AI Summit 2026 dedicato a come distribuire, governare e proteggere la cosiddetta "physical AI". Una premessa: l'articolo è sponsorizzato da InfluxData e, secondo quanto dichiarato, è stato riassunto con l'aiuto di strumenti di AI. Intervenivano Gaspard Duthilleul (Galyos), Sanjay Mahato (AWS), Ian Clark (InfluxData) e Tauseef Ahmed (Grayhawk Consulting Group). Va letto come opinione di panel, non come ricerca indipendente.

Dove far girare l'AI: la regola di collocazione

Il panel sintetizza l'idea in una formula: una AI fisica che "agisce localmente e impara globalmente". La ripartizione proposta è questa.

• Edge: decisioni legate alla sicurezza, rilevamento di difetti di qualità e tutto ciò che richiede una risposta sotto il secondo.
• Cloud: riconoscimento di pattern tra più stabilimenti, addestramento dei modelli su dati di guasto aggregati e analisi energetica multi-sito.
• Livello ibrido: workflow agentici che rilevano un'anomalia all'edge, usano nel cloud registri di manutenzione, manuali e giacenze di ricambi per generare ordini di lavoro e richieste di parti, e rimandano l'azione all'edge per l'esecuzione.

L'esempio di Siemens Energy

Il caso citato è Siemens Energy: condition monitoring e ottimizzazione energetica girano in locale in ogni fabbrica con AWS IoT SiteWise Edge, che collega 10 tipi di protocollo, tra cui Modbus, OPC UA e il datato Siemens S7. I dati di guasto di più stabilimenti vengono poi aggregati nel cloud per addestrare modelli di manutenzione predittiva. L'articolo sostiene che un ritardo di 200 ms può fare la differenza tra uno spegnimento sicuro e un incidente, citando una firma di guasto a un cuscinetto gestita in millisecondi.

Costi e resilienza

Conservare in locale la telemetria grezza da 5 giorni a un mese e inviare al cloud solo i sottoinsiemi rilevanti può ridurre il costo di storage a circa un decimo rispetto all'ingestione completa. I dispositivi edge, inoltre, devono continuare a funzionare quando la rete cade.

Fiducia nei dati e limiti all'autonomia

Prima di qualsiasi azione autonoma il panel indica quattro verifiche:

• i dati sono aggiornati e affidabili;
• le condizioni operative rientrano nell'intervallo di addestramento del modello;
• l'ambito delle azioni autorizzate è definito con chiarezza;
• esiste un percorso definito per le eccezioni.

Un namespace unificato con un'ontologia dei tag dovrebbe intercettare deriva dei nomi, sfasamenti di clock e cambi di schema prima che raggiungano i modelli; un esempio è un intero che diventa float. Il back-testing su pattern storici è un secondo controllo, perché una deriva silenziosa dello schema degrada i modelli senza che nessuno se ne accorga. I dati vanno protetti a riposo, in transito e al punto di consumo. Ogni livello di autonomia richiede spiegabilità e percorsi di escalation verso una persona, e un modello non va riutilizzato tra impianti con apparecchiature o processi diversi.

Rischi di sicurezza

Un robot che interagisce sia con un WMS sia con un MES attraversa confini che il modello ISA-95 voleva tenere separati. Avvelenamento del modello o attacchi via prompt all'edge potrebbero propagarsi verso l'alto nei workflow agentici, fino a ordini di lavoro e pianificazione della manutenzione su più siti. Per il panel serve unire la sicurezza IT e OT. Ci sono poi i limiti fisici: l'hardware edge ha vincoli di memoria e termici, e il tempo di inferenza salirebbe di circa 30 ms in estate per il throttling termico.

Cosa portarsi a casa

Il consiglio è partire da progetti circoscritti, con ambito, criteri di successo e azioni autorizzate chiari, e solo dopo replicare architettura, governance e controlli di sicurezza tra i siti. Per chi lavora su integrazione di PLC, SCADA e historian, tre spunti sono immediatamente utili: una regola di collocazione basata sulla latenza e sulla criticità, una checklist di affidabilità del dato fondata su un namespace unificato, e la considerazione che la deriva dello schema e i limiti termici sono problemi di ingegneria, non solo di data science. Trattandosi di un contenuto sponsorizzato, conviene verificare le cifre con i propri dati di impianto.