Physical AI: decidere all'edge, imparare nel cloud, con autonomia graduale

Il 12 novembre 2026 IIoT World ha pubblicato la sintesi di un panel dell'Industrial AI Summit 2026 su come implementare, governare e mettere in sicurezza la cosiddetta physical AI. Intervenivano rappresentanti di Galyos, AWS, InfluxData e Grayhawk Consulting Group. Una premessa: il pezzo è marcato come sponsorizzato da InfluxData e dichiara l'uso di strumenti di AI per la sintesi. Va quindi letto come opinione influenzata dai fornitori, non come ricerca indipendente.

Dove far girare l'AI

La regola proposta si riassume nella formula del panel: l'AI "agisce localmente e impara globalmente". Il criterio di ripartizione è questo.

• Edge: decisioni critiche per la sicurezza, rilevamento dei difetti di qualità e tutto ciò che richiede risposte sotto il secondo (indicativamente meno di 200 ms).
• Cloud: riconoscimento di pattern tra più stabilimenti, addestramento dei modelli su dati di guasto aggregati, analisi energetica multi-sito.
• Livello ibrido: un workflow agentico rileva un'anomalia all'edge, consulta nel cloud registri di manutenzione, manuali e magazzino ricambi, crea l'ordine di lavoro e riporta l'azione all'edge.

Come esempio viene citata Siemens Energy: monitoraggio delle condizioni e ottimizzazione energetica girano in locale in ogni fabbrica con AWS IoT SiteWise Edge, che porta nel livello edge 10 tipi di protocollo, tra cui Modbus, OPC UA e il vecchio Siemens S7. I dati di guasto di più impianti sono poi aggregati per addestrare modelli di manutenzione predittiva. Secondo l'articolo, 200 ms di ritardo possono separare uno spegnimento sicuro da un incidente, un difetto o un fermo linea.

Costi e resilienza

Il panel sostiene che conservare la telemetria grezza in locale da 5 giorni a un mese, inviando al cloud solo i sottoinsiemi rilevanti, possa ridurre il costo di storage a circa un decimo rispetto all'ingestione completa. È un'affermazione del panel, non verificata in modo indipendente. Più solido è il principio di resilienza: i dispositivi edge devono continuare a funzionare quando la rete cade.

Dati affidabili prima dell'autonomia

Prima di un'azione autonoma l'articolo indica quattro controlli: dati aggiornati e affidabili; condizioni operative entro il campo di addestramento del modello; perimetro delle azioni autorizzate definito; percorso previsto per le eccezioni.

Per la fiducia nei dati si cita un unified namespace con ontologia dei tag, utile a intercettare derive di nomenclatura, sfasamenti di clock e cambi di schema (per esempio un intero che diventa decimale). Il back-testing delle nuove fonti su pattern storici è un secondo controllo. Una deriva silenziosa dello schema, avverte il pezzo, degrada i modelli senza che nessuno se ne accorga.

Quattro stadi di autonomia

• Osservazione.
• Raccomandazione con approvazione umana.
• Azione basata su pattern, con esiti provati e reversibili.
• Piena autonomia, conquistata solo dopo prestazioni costanti in ogni stadio precedente.

Ogni decisione deve essere spiegabile e tracciabile, con escalation a una persona oltre una soglia di rischio. Un modello addestrato su un sito non andrebbe applicato a un altro con impianti o processi diversi.

Il nodo della sicurezza

Un robot che dialoga sia con un WMS sia con un MES attraversa confini che il modello ISA-95 voleva tenere separati. Un modello edge compromesso potrebbe inoltre influenzare ordini di lavoro e manutenzione su più siti: per questo, secondo l'articolo, le discipline di sicurezza IT e OT devono convergere. Ci sono anche limiti fisici: l'hardware edge ha memoria e dissipazione limitate, e in estate il tempo di inferenza cresce di circa 30 ms per il thermal throttling.

Cosa farne in pratica

L'articolo non tratta il contesto italiano né settori specifici, ma il metodo è trasferibile. Si parte da progetti circoscritti, con ambito, criteri di successo e azioni autorizzate chiari, per poi riusare architettura, governance e controlli di sicurezza su altri stabilimenti.

Connettività di macchina e dati puliti e contestualizzati (MES, OPC UA, unified namespace) vengono prima di qualsiasi autonomia.

Per plant manager e responsabili IT/OT la lezione è una checklist per il primo pilota: decidere cosa richiede latenza locale, garantire la qualità dei dati, fissare lo stadio di autonomia di partenza e definire in anticipo soglie di escalation e controlli di sicurezza.