Il 7 luglio 2026 la vicepresidente della Commissione europea Henna Virkkunen ha presentato il piano d’azione su intelligenza artificiale e cyber security con un messaggio netto: niente nuove norme, ma piena attuazione di quelle già in vigore. Nella stessa conferenza stampa ha aggiunto un avvertimento: dipendere da tecnologie extraeuropee per capacità cruciali è, a suo giudizio, un rischio per la sicurezza dell’Unione.
Due affermazioni apparentemente distanti dalla robotica, ma che disegnano con precisione il perimetro entro cui le aziende italiane devono valutare oggi un fenomeno concreto: l’ingresso in magazzini, reparti produttivi e spazi pubblici di robot umanoidi e di servizio, spesso di fabbricazione cinese e aggiornati da remoto.
Il fenomeno è concreto perché il rischio ha smesso di essere teorico. Il 20 settembre 2025 due ricercatori di sicurezza hanno reso pubblico UniPwn, un exploit che permette di prendere il controllo completo di alcuni tra i robot umanoidi commerciali più diffusi al mondo, quelli del costruttore cinese Unitree, sfruttando una falla nella loro interfaccia Bluetooth. Un attaccante nel raggio del segnale può iniettare comandi ed eseguire codice con i massimi privilegi sul sistema operativo della macchina.
Non un guasto, non un video virale di un robot “impazzito”, ma la prova documentata che il sistema di controllo di una macchina dotata di attuatori può essere piegato a comandi ostili. Per chi in azienda sta introducendo queste macchine, quell’exploit ha segnato un passaggio preciso: il rischio cyber ha smesso di riguardare solo dati e continuità operativa e ha iniziato a toccare l’incolumità fisica delle persone.
Indice degli argomenti
Dal bug accidentale all’attacco deliberato
La cronaca degli ultimi mesi ha offerto un repertorio abbondante di anomalie. Un robot umanoide che durante un test di laboratorio comincia a muovere gli arti in modo convulso e danneggia le attrezzature. Un altro che, durante uno show pubblico, colpisce uno spettatore prima dell’intervento della sicurezza. In quasi tutti i casi la spiegazione ufficiale ha parlato di configurazione errata del software o di cattiva gestione dei dati sensoriali, non di intrusione esterna.
Il punto è che la distinzione tra i due scenari, dal punto di vista di chi subisce l’effetto, è meno netta di quanto sembri. Un errore accidentale produce un danno isolato e non ripetibile. Un attacco deliberato può essere sincronizzato, replicato, occultato e trasformato in leva di sabotaggio o estorsione.
Se un semplice difetto di software può far perdere il controllo a una macchina che pesa oltre cento chili, un’azione mirata sul sistema di controllo può alterare intenzionalmente le policy di movimento, i comandi ai motori, la percezione sensoriale e i limiti di sicurezza. Il risultato non è più un incidente, ma uno strumento.
Questo sposta il baricentro della valutazione del rischio. Fino a ieri un robot era un problema di safety, cioè di affidabilità meccanica e conformità del prodotto. Oggi è anche un problema di cyber security, perché il software che lo governa è capace di produrre danni fisici a persone e cose. Le due dimensioni, tradizionalmente gestite da funzioni aziendali separate, convergono su uno stesso oggetto.
Il caso UniPwn e la logica del contagio
I ricercatori Andreas Makris e Kevin Finisterre, nel rendere pubblico l’exploit battezzato UniPwn, hanno svelato un meccanismo preoccupante. La vulnerabilità colpisce l’interfaccia Bluetooth Low Energy che diversi robot Unitree usano per la configurazione della rete Wi-Fi, e riguarda i quadrupedi Go2 e B2 e gli umanoidi G1 e H1. Si tratta, per quanto risulta a IEEE Spectrum, del primo grande exploit pubblico di una piattaforma robotica umanoide commerciale.
Il meccanismo è tanto banale quanto istruttivo. I pacchetti scambiati via Bluetooth sono cifrati, ma le chiavi di cifratura sono incorporate nel firmware e identiche su tutta la flotta, e per giunta erano state pubblicate online mesi prima. Per farsi riconoscere come utente autenticato bastava cifrare la stringa “unitree” con quelle chiavi note. Superato quel varco, un attaccante nel raggio del segnale poteva iniettare comandi ed eseguire codice con privilegi di root, cioè con il massimo livello di controllo sul sistema operativo della macchina.
L’aspetto più preoccupante non è la singola compromissione, ma la sua capacità di propagarsi. I ricercatori descrivono la falla come wormable: un robot infetto può cercare altri robot Unitree nel raggio del Bluetooth e comprometterli in automatico, senza alcun intervento umano, dando origine a una botnet di macchine fisiche. È la stessa logica che ha reso devastanti i worm informatici classici, con una differenza sostanziale. Qui i nodi della rete infetta non sono server o computer, ma dispositivi dotati di attuatori, telecamere, microfoni e presenza fisica in spazi condivisi con le persone.
La società di sicurezza robotica Alias Robotics, in un’analisi separata sul G1, ha aggiunto un altro elemento: il robot trasmetteva dati verso la Cina a intervalli regolari, un dettaglio che sposta il problema dalla sola integrità del controllo alla riservatezza delle informazioni raccolte in ambienti sensibili.
Alla divulgazione, Unitree ha risposto sostenendo di aver già completato la maggior parte delle correzioni. Ma la comunicazione tra ricercatori e azienda era stata difficile, al punto che Makris, riferendosi a una precedente vulnerabilità sul modello Go1, ha posto una domanda scomoda: si tratta di sviluppo sciatto o di falle introdotte di proposito? Entrambe le risposte, ha osservato, sono ugualmente inquietanti.
L’area grigia della responsabilità
Il caso Unitree porta in primo piano una questione che le aziende utilizzatrici tendono a rimuovere: chi risponde della sicurezza del software quando il robot è prodotto da un fornitore straniero e aggiornato da remoto? La responsabilità pratica si distribuisce tra produttore, integratore e utilizzatore finale, e proprio questa distribuzione genera un’area grigia di rendicontabilità.
Il produttore controlla firmware, patch, stack software e talvolta i servizi cloud. L’integratore locale si occupa dell’inserimento della macchina nel contesto operativo. L’azienda che usa il robot resta però responsabile della gestione del rischio nel proprio ambiente e delle conseguenze su persone e processi, pur non avendo alcun controllo diretto sul codice che governa gli attuatori. Quando il fornitore è extra-UE, il divario si allarga: trasparenza limitata, scarsa leva contrattuale, difficoltà di audit del codice, dipendenza dai tempi di rilascio delle patch decisi altrove.
Senza clausole contrattuali precise su gestione delle vulnerabilità, obblighi di disclosure, tracciamento dei log, distinta dei componenti software e diritto di audit, l’azienda cliente si assume il rischio operativo senza avere il controllo tecnico corrispondente. È una posizione fragile, e la fragilità non deriva da un difetto della singola macchina, ma dall’architettura contrattuale e informativa che le sta attorno.
Le norme europee coprono i pezzi, non l’insieme
A questo punto la domanda naturale riguarda il quadro regolatorio. NIS2, AI Act e Regolamento Macchine bastano a coprire la cyber security dei sistemi robotici? La risposta onesta è che le norme esistono, ma non compongono ancora un quadro integrato.
La direttiva NIS2, recepita in Italia con il d.lgs. 138/2024, disciplina la governance del rischio cyber e gli obblighi di sicurezza e notifica per i soggetti rilevanti, ma non entra nel merito della sicurezza del movimento, dei limiti fisici o della progettazione dei sistemi di arresto di emergenza.
L’AI Act tocca le componenti decisionali e percettive dei robot, soprattutto quando integrate in prodotti soggetti a requisiti di sicurezza, ma non esaurisce da solo il problema della macchina nel suo complesso.
Il nuovo Regolamento Macchine copre la sicurezza del prodotto e dei sistemi digitali che ne influenzano il comportamento, ma la traduzione operativa dipende da standard e certificazioni che non sempre reggono il passo dell’innovazione.
Il Cyber Resilience Act aggiunge un tassello rilevante proprio sul punto più esposto del caso Unitree. Il regolamento impone requisiti di sicurezza fin dalla progettazione per i prodotti con elementi digitali, e dall’11 settembre 2026 introduce l’obbligo di notificare le vulnerabilità attivamente sfruttate e gli incidenti gravi, con tempi stringenti. Una chiave di cifratura hardcoded e identica su tutta la flotta è esattamente il tipo di difetto che una logica di sicurezza by design dovrebbe impedire a monte.
Resta il problema dell’integrazione. Il risultato non è un vuoto normativo assoluto, ma un vuoto di raccordo tra safety, cybersecurity, governance dell’IA e sicurezza della catena di fornitura del software. I robot sfuggono alle tassonomie tradizionali perché non sono soltanto macchine, non sono soltanto endpoint informatici e non sono soltanto sistemi di intelligenza artificiale. Sono le tre cose insieme, e nessuna funzione aziendale, presa singolarmente, li governa per intero.
Su questa frammentazione pesa l’orientamento europeo richiamato in apertura.
Cosa cambia per chi decide
Per il CISO la conseguenza operativa è un cambio di categoria mentale. Il robot non va trattato come un endpoint connesso, ma come un sistema cyber-fisico ad alta criticità. Il che comporta una modellazione delle minacce specifica per i moduli di controllo del movimento, la collaborazione strutturata con i responsabili OT (Operational Technology) e con la funzione che presidia la sicurezza sul lavoro, la segmentazione delle reti robotiche rispetto ai sistemi core, la verifica dei canali di aggiornamento e playbook di incident response che contemplino anche il danno fisico.
L’obiettivo si allarga. Non basta più impedire l’esfiltrazione dei dati: bisogna impedire che il software compromesso diventi un attuatore di danno nel mondo reale. E questo obiettivo non lo si raggiunge dopo l’acquisto. Nei progetti di adozione dei robot, procurement, sicurezza informatica, ufficio legale, operations e sicurezza sul lavoro devono sedersi allo stesso tavolo fin dall’inizio, perché la resilienza della macchina dipende dal contratto e dall’architettura di rete quanto dalla sua meccanica.
In concreto, un’impresa che sta sperimentando robot umanoidi o di servizio dovrebbe presidiare almeno cinque aree: l’inventario completo dei componenti software installati; il controllo contrattuale sugli aggiornamenti; la segmentazione di rete che isoli i robot dai sistemi critici; i test di sicurezza e di arresto sicuro; una governance chiara delle responsabilità tra produttore, integratore e utilizzatore. Non è una checklist esaustiva, ma è il minimo che separa un’adozione consapevole da una scommessa.
La domanda che resta
La tentazione, di fronte ai video virali, è liquidarli come sensazionalismo. È una tentazione da respingere, ma non per le ragioni che sembrano ovvie.
Il problema non è che i robot si ribellano: non lo fanno, e non è quello lo scenario da temere. Il problema è che ogni singolo episodio pubblico di malfunzionamento, autentico o esagerato che sia, abbassa la soglia di tolleranza al rischio, modifica la percezione dei lavoratori e chiama in causa la reputazione di chi quella macchina l’ha portata in azienda.
La narrazione del bug innocuo diventa insostenibile nel momento esatto in cui la macchina interagisce con corpi, clienti e operatori in carne e ossa.
La vera posta in gioco è un’altra, e la sintetizza bene la logica del caso UniPwn. Un attaccante non ha più bisogno di violare un data center per produrre danni fisici: gli basta la prossimità.
Il perimetro della sicurezza informatica, storicamente confinato dietro uno schermo, coincide ora con macchine che si muovono, manipolano oggetti e interagiscono con le persone.
Per i responsabili della sicurezza la domanda non è se lo scenario sia realistico, perché la dimostrazione tecnica ha già risposto. È un’altra: chi governa davvero il rischio, quando il robot è prodotto altrove, aggiornato da remoto e utilizzato accanto a persone reali?
Partecipa alla community