AI fisica: decidere sull'edge, addestrare nel cloud, guadagnare autonomia a fasi

Il 12 novembre 2026 IIoT World ha pubblicato la sintesi di un panel dell'Industrial AI Summit 2026 dedicato a come distribuire, governare e mettere in sicurezza la cosiddetta physical AI. Intervenivano Gaspard Duthilleul (Galyos), Sanjay Mahato (AWS), Ian Clark (InfluxData) e Tauseef Ahmed (Grayhawk Consulting Group). Una precisazione necessaria: l'articolo è sponsorizzato da InfluxData e dichiara l'uso di strumenti AI per il riassunto. Va quindi letto come opinione di panel con possibile influenza dei fornitori, non come ricerca indipendente.

Dove far girare l'AI

La regola proposta è semplice e utile come punto di partenza per i responsabili di ingegneria e IT:

• Edge: decisioni critiche per la sicurezza, rilevamento di difetti di qualità e tutto ciò che richiede risposte sotto il secondo.
• Cloud: riconoscimento di pattern tra più stabilimenti, addestramento dei modelli su dati di guasto aggregati, analisi energetiche multi-sito.
• Ibrido: flussi agentici in cui l'anomalia è rilevata sull'edge, poi si usano storici di manutenzione, manuali e magazzino ricambi nel cloud per preparare ordini di lavoro e richieste di parti; l'azione torna all'edge per l'esecuzione.

Physical AI che agisce localmente e impara globalmente.

L'esempio di Siemens Energy

Il caso citato usa AWS IoT SiteWise Edge per il monitoraggio delle condizioni e l'ottimizzazione energetica in ogni fabbrica. La firma di un guasto a un cuscinetto attiva un'azione in millisecondi, senza passare dal cloud. Secondo l'articolo, 200 ms di ritardo possono separare uno spegnimento sicuro da un incidente, un difetto di qualità o un fermo linea. Sul livello edge confluiscono 10 tipi di protocollo, tra cui Modbus, OPC UA e il legacy Siemens S7, mentre i modelli di manutenzione predittiva sono addestrati nel cloud con dati di guasto raccolti da più impianti.

Costi e resilienza

Conservare la telemetria grezza in locale da 5 giorni a un mese e inviare al cloud solo i sottoinsiemi rilevanti ridurrebbe il costo di storage a circa un decimo rispetto all'ingestione completa; il dato però è privo di fonte e va verificato nel proprio contesto. Più solido il principio di resilienza: i dispositivi edge devono continuare a decidere anche quando la rete cade.

Guardrail e autonomia a stadi

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 per gestire le eccezioni.

Per la qualità del dato si suggeriscono un unified namespace e un'ontologia dei tag, utili a intercettare deriva dei nomi, sfasamenti di clock e cambi di schema (per esempio un intero che diventa float). Anche il back-testing dei nuovi sensori sull'ontologia esistente aggiunge un controllo. Il rischio è la deriva silenziosa dello schema, che degrada i modelli senza che nessuno se ne accorga.

L'autonomia va concessa in quattro stadi: osservazione; raccomandazione con approvazione umana; decisioni basate su pattern con esiti dimostrati e reversibili; autonomia piena solo dopo prestazioni costanti in tutti gli stadi precedenti. Ogni stadio richiede spiegabilità, escalation verso una persona oltre una soglia di rischio e confini di dominio, così che un modello addestrato per uno stabilimento non venga applicato a un altro.

Sicurezza e limiti hardware

La physical AI, ad esempio un robot che interagisce sia con un WMS sia con un MES, attraversa confini che ISA 95 voleva tenere separati. Un modello edge avvelenato o un attacco via prompt potrebbe risalire attraverso i flussi agentici fino a ordini di lavoro e pianificazione della manutenzione nel cloud, su più siti. Per questo il panel chiede di unire le discipline di sicurezza IT e OT e di proteggere i dati a riposo, in transito e nel punto di utilizzo.

Sul fronte hardware, la memoria dell'edge limita la dimensione dei modelli, e il calore di fabbrica causa thermal throttling che in estate aggiungerebbe circa 30 ms all'inferenza. Anche in questo caso l'articolo non ne indica la base.

Cosa farne

Il consiglio è partire da progetti circoscritti, con ambito, criteri di successo e azioni autorizzate definiti, e riusare poi architettura, governance e controlli di sicurezza sugli altri siti. Per chi guida ingegneria e IT, il messaggio pratico è progettare fin dall'inizio controlli di qualità del dato e segmentazione della rete OT, trattando le cifre del panel come ipotesi da validare, non come benchmark.