Executive Summary
- BLUF: l’esercitazione “Alabarda d’Argento 2026” al Monte Bivera è confermata dall’Esercito Italiano; il presunto sparo anomalo del 10 giugno 2026, la sospensione di sei mezzi e lo stato dell’indagine non risultano invece documentati, alla data del 23 luglio 2026, da comunicati pubblici verificabili del Ministero della Difesa, dell’Esercito o di Leonardo. Devono quindi essere trattati come informazioni operative non ancora confermate, non come fatti definitivamente accertati.
- Se la dinamica descritta fosse confermata, non dimostrerebbe automaticamente un “attacco AI”: sarebbe compatibile con almeno cinque famiglie causali concorrenti—guasto elettromeccanico, errore del controllo embedded, comando spurio sul data bus, problema di integrazione o manutenzione, compromissione cyber.
- Il segnale tecnicamente più grave non sarebbe la rotazione inattesa, ma l’eventuale concatenazione movimento–abbassamento–abilitazione–fuoco, perché implicherebbe il superamento simultaneo o sequenziale di più barriere di sicurezza.
- Una Remote Weapon Station deve essere trattata come un sistema cyber-fisico safety-critical, non come un’arma tradizionale alla quale sia stata semplicemente aggiunta una console digitale.
- L’introduzione di AI diagnostica, visione artificiale, manutenzione predittiva o supporto al targeting amplia la superficie d’attacco attraverso modelli, dati, aggiornamenti, acceleratori, sensori e supply chain.
- La priorità nazionale non è rendere “intelligente” il fuoco, ma rendere dimostrabilmente impossibile che software non autorizzato, dati corrotti o una singola anomalia provochino un’azione cinetica.
- Nel quinquennio 2026–2031, il rischio principale sarà la convergenza tra automazione militare, software-defined platforms, attacchi alla catena di fornitura e strumenti AI capaci di trovare vulnerabilità più rapidamente.
- La risposta richiesta è un regime italiano di weapon-system cybersecurity assurance, con registrazione forense indipendente, separazione hardware del circuito di fuoco, red teaming adversarial-ML e certificazione continua delle configurazioni operative.
Tre colpi senza ordine: la nuova frontiera cyber-fisica
Il pericolo non è la macchina che improvvisamente “diventa cosciente”. È qualcosa di più concreto e, proprio per questo, più difficile da governare: un errore elettrico, una riga di codice, un sensore ingannato o un aggiornamento compromesso che attraversano in pochi millisecondi la distanza tra un dato e un colpo d’arma da fuoco.
Il caso segnalato durante l’esercitazione alpina del giugno 2026 al Monte Bivera, dove una torretta remotizzata installata su un veicolo Lince avrebbe ruotato e sparato tre colpi senza un comando intenzionale, non risulta ancora descritto in comunicati pubblici della Difesa o del costruttore. L’Esercito ha confermato, invece, lo scenario generale: l’“Alabarda d’Argento 2026”, conclusa il 16 giugno, ha coinvolto oltre 300 militari a quasi duemila metri di quota, con sistemi a pilotaggio remoto e nuove tecnologie applicate al combattimento terrestre.
Questa distinzione è essenziale. Un episodio non ancora corroborato pubblicamente non può essere trasformato né nella prova di un attacco informatico né nella rassicurante formula del “semplice guasto”. Può però essere assunto come il segnale di una vulnerabilità più ampia: mentre il software entra nel cuore delle capacità militari, la sicurezza nazionale dipende sempre più dalla possibilità di dimostrare perché una macchina si è mossa, quale componente ha autorizzato un’azione e quali barriere avrebbero dovuto impedirla.
Il colpo nasce prima del grilletto
Una torretta remotizzata non riceve soltanto un ordine e lo esegue. Prima dell’effetto fisico interviene una catena di sistemi: la console dell’operatore, il computer di controllo, il software real-time, i sensori di posizione, il data bus del veicolo, gli attuatori, gli interlock di sicurezza e il circuito che abilita materialmente il fuoco.
Se uno solo di questi livelli produce un dato errato, gli altri dovrebbero riconoscerlo e bloccarne la propagazione. Il problema diventa grave quando più funzioni dipendono dalla stessa elettronica, dalla stessa fonte di alimentazione o dal medesimo software. In quel caso, una sola anomalia può ingannare contemporaneamente il controllo del movimento, la verifica della posizione e la barriera di sicurezza.
La descrizione di una rotazione, dell’abbassamento della linea di tiro e di una raffica di tre colpi, se confermata, indicherebbe una concatenazione più complessa di una semplice vibrazione meccanica. Non dimostrerebbe, tuttavia, l’esistenza di un comando digitale ostile: una breve alimentazione del circuito di scatto può produrre più colpi secondo la cadenza dell’arma. La domanda investigativa corretta non è quindi “chi ha premuto il grilletto?”, ma “in quale punto è comparso il primo stato non autorizzato?”.
Le spiegazioni concorrenti sono almeno cinque: guasto elettromeccanico; difetto del software embedded; errore di manutenzione o configurazione; compromissione cyber; interazione anomala tra operatore e interfaccia. Escluderne una senza log, misure elettriche, immagini delle memorie e ricostruzione temporale significherebbe sostituire la prova con l’intuizione.
L’AI moltiplica i percorsi
L’intelligenza artificiale non deve controllare direttamente un’arma per aumentarne il rischio. Può entrare nella visione artificiale, nella classificazione degli oggetti, nella fusione dei sensori, nella navigazione, nella manutenzione predittiva o nei programmi utilizzati per progettare e verificare il firmware.
Può anche operare dall’altra parte. Strumenti AI sono ormai capaci di analizzare codice, cercare vulnerabilità, generare sequenze di input e individuare condizioni rare molto più rapidamente di un gruppo umano. Per sabotare una piattaforma non è necessario prenderne il controllo durante la missione: è possibile colpire mesi prima una workstation di manutenzione, un repository software, un subfornitore o una libreria inserita nel pacchetto ufficiale.
La NATO ha aggiornato nel luglio 2024 la propria strategia sull’AI, riconoscendo la necessità di accelerarne l’adozione ma anche di proteggerla dalla manipolazione avversaria. I principi alleati comprendono legalità, responsabilità, tracciabilità, affidabilità e governabilità. Quest’ultima parola è la più importante: una capacità militare è governabile soltanto se può essere arrestata anche quando il software principale non risponde o è stato compromesso.
Un pulsante di emergenza che dipende dallo stesso processore responsabile dell’anomalia non rappresenta una vera barriera. Nei sistemi con effetti cinetici, l’interruzione deve essere anche fisica: una logica separata, semplice e verificabile deve poter togliere energia al circuito di fuoco.
La porta nascosta della manutenzione
Le piattaforme militari operano spesso su reti isolate. Ma isolamento non significa invulnerabilità. Ogni intervento tecnico crea un ponte temporaneo verso l’esterno: laptop diagnostici, supporti rimovibili, account del fornitore, apparecchiature di calibrazione, ricambi e pacchetti di aggiornamento.
È qui che la catena militare incontra quella industriale. Un software può essere autentico, correttamente firmato e tuttavia contenere un difetto. Una firma digitale prova l’origine del pacchetto, non la sua sicurezza. Una centralina autorizzata può inviare un comando pericoloso se è stata compromessa o configurata male. Un ricambio nominalmente identico può contenere una revisione diversa del firmware.
Il sabotaggio più efficace potrebbe quindi non lasciare l’immagine cinematografica dell’hacker collegato al veicolo. Potrebbe presentarsi come un aggiornamento legittimo, installato attraverso procedure regolari e attivato soltanto da una combinazione rara: una temperatura, una sequenza di comandi, un determinato orientamento o uno specifico segnale.
La conseguenza strategica è il rischio di flotta. Se decine di mezzi condividono software, tool diagnostici e componenti, una sola vulnerabilità può imporre la sospensione di un’intera configurazione. L’uniformità riduce i costi logistici, ma trasforma il difetto locale in una possibile crisi di disponibilità nazionale.
L’Italia entra nella fase decisiva
Il 26 febbraio 2026 il Ministero della Difesa ha pubblicato la prima Strategia italiana in materia di intelligenza artificiale militare, definendone l’adozione un imperativo politico e strategico. Il documento prevede un’integrazione rapida e sistemica di capacità avanzate, sicure e resilienti. Al centro è stato posto il Laboratorio di Intelligenza Artificiale per la Difesa, destinato a ridurre dipendenze critiche e collegare Forze armate, industria, università e ricerca.
La direzione è corretta, ma la sovranità tecnologica non si misura dal numero di algoritmi sviluppati in Italia. Si misura dal potere effettivo dello Stato di conoscere la configurazione di una piattaforma, verificare il comportamento del software, interrompere una funzione pericolosa e correggere una vulnerabilità senza dipendere integralmente dal produttore.
Nel Piano nazionale della ricerca militare 2026, la Difesa ha incluso comando e controllo, ISTAR, sistemi autonomi, swarming, manned-unmanned teaming, manutenzione predittiva, miglioramento dei sistemi d’arma, droni armati e loitering munitions. Una procedura pubblicata nel gennaio 2026 riguarda inoltre prototipi per una campagna di sperimentazione su Robotics & Autonomous Systems e AI, affidata a Iveco Defence Vehicles; i dati sull’esecuzione non sono divulgati per ragioni di sicurezza nazionale.
L’Italia è dunque già oltre la discussione teorica. La questione è come impedire che la sperimentazione proceda più velocemente della verifica.
Ogni sistema critico dovrebbe essere accompagnato da una distinta completa del software e dell’hardware, dalla provenienza dei dati utilizzati per addestrare i modelli, da registratori indipendenti, da prove di sabotaggio simulato e dalla capacità di riprodurre esattamente ogni versione. Il produttore non può restare l’unico soggetto in grado di investigare il proprio prodotto. Serve un’autorità tecnica indipendente della Difesa che possa ordinare il fermo di una configurazione, accedere ai log e verificare codice, aggiornamenti e catena dei fornitori.
Il Sahel come laboratorio reale
Il tema non riguarda soltanto le piattaforme avanzate dispiegate nei teatri europei. Nel Sahel, l’incontro tra droni commerciali, gruppi jihadisti, reti criminali, criptovalute e frontiere scarsamente controllate sta già cambiando la natura della minaccia.
Il 14 luglio 2026, il rappresentante speciale delle Nazioni Unite Leonardo Santos Simão ha riferito al Consiglio di Sicurezza che i gruppi terroristici e gli altri attori armati non statali, soprattutto nel Sahel centrale e nel nord della Nigeria, stanno adattando le proprie tattiche e utilizzano sempre più droni, sistemi avanzati di comunicazione e criptovalute. Le operazioni vengono coordinate attraverso più Paesi e si sovrappongono alle reti della criminalità transnazionale.
Il Sahel dimostra che la rivoluzione robotica non richiede industrie aerospaziali sofisticate. Piattaforme commerciali, componenti reperibili, software accessibile e capacità di adattamento possono produrre ricognizione, propaganda, sorveglianza delle forze, correzione del tiro e, progressivamente, attacco.
Per l’Italia non è una periferia remota. La Farnesina definisce il Sahel la frontiera meridionale dell’Europa, strategica per sicurezza, migrazioni e contrasto ai traffici illeciti. Nel febbraio 2026 il Capo di Stato Maggiore della Difesa, generale Luciano Portolano, ha visitato il contingente della missione MISIN a Niamey; nel giugno successivo la missione ha completato un Centro di medicina aeronautica destinato alle autorità nigerine. La presenza italiana combina addestramento, cooperazione istituzionale e rafforzamento delle capacità locali.
Proprio questa presenza impone una nuova priorità: accanto alla formazione tradizionale servono difesa dai droni, disciplina delle comunicazioni, protezione dei dispositivi manutentivi, raccolta forense e capacità di riconoscere la manipolazione di sensori e software. Un mezzo ceduto o un sistema addestrativo introdotto in un ambiente privo di gestione sicura degli aggiornamenti può trasformarsi, nel tempo, in una vulnerabilità condivisa.
Acquistare controllo, non soltanto prestazioni
La trasformazione dovrà cominciare dai contratti. La Difesa non può più acquistare soltanto velocità, precisione, autonomia e disponibilità. Deve acquistare il diritto di capire, verificare, modificare e sostituire.
Ogni programma robotico dovrebbe stabilire chi possiede le chiavi digitali, chi autorizza gli aggiornamenti, chi conserva la versione originaria del codice, quali subfornitori hanno accesso e quanto tempo occorre per isolare una release vulnerabile. Dovrebbe inoltre prevedere una via d’uscita: nessun asset essenziale può diventare inutilizzabile perché un fornitore interrompe il supporto o un servizio cloud non è più disponibile.
Il ciclo 2026-2031 sarà decisivo. Nei primi anni dominerà il problema dell’integrazione tra sistemi legacy e nuovi moduli AI; seguiranno l’esposizione delle pipeline di aggiornamento e il rischio dei modelli addestrati su dati non controllati. Verso la fine del decennio, la minaccia principale sarà il difetto comune: lo stesso software, modello o componente compromesso su molte piattaforme contemporaneamente.
La macchina militare del futuro non sarà necessariamente fuori controllo. Ma sarà controllabile soltanto se il comando umano verrà tradotto in architettura, prove, responsabilità e potere contrattuale. Altrimenti, la sovranità resterà scritta nei documenti, mentre il vero potere risiederà nel codice, nelle chiavi digitali e nelle mani di chi può modificarli.
Navigational Index
- Evento, catena causale e standard probatorio — distinzione tra ciò che è ufficialmente confermato, ciò che deve essere preservato forensicamente e le cinque ipotesi tecniche concorrenti.
- Architettura cyber-fisica e nuovi vettori AI — controllo embedded, interlock, data bus, manutenzione, aggiornamenti, sensori, modelli, supply chain e possibili percorsi di sabotaggio.
- Outlook 2026–2031 e sovranità operativa italiana — governance militare dell’AI, assurance industriale, deterrenza cyber, responsabilità tecnica e trasformazione degli acquisti della Difesa.
Master Abstract
Dall’“incidente d’arma” all’evento cyber-fisico
Il punto di partenza metodologico deve essere una separazione netta tra corroborazione ambientale e conferma dell’incidente. L’Esercito Italiano documenta che il ciclo addestrativo “Alabarda d’Argento 2026”, iniziato il 25 maggio, si è concluso nell’area del Monte Bivera coinvolgendo oltre 300 militari, reparti della Brigata Alpina “Julia”, personale albanese, osservatori internazionali, sistemi a pilotaggio remoto e tecnologie applicate al combattimento terrestre. Questo conferma luogo, periodo, natura interforze e presenza di piattaforme tecnologiche, ma il comunicato del 16 giugno 2026 non menziona spari accidentali, veicoli danneggiati, sospensioni cautelative o indagini industriali — Conclusa l’esercitazione pluriarma “Alabarda d’Argento 2026” – Esercito Italiano – giugno 2026 — fonte ufficiale verificata. Anche l’identificazione generale della piattaforma è coerente con fonti ufficiali: l’Esercito descrive il VTLM Lince equipaggiato con torretta remotizzata HITROLE come un sistema che permette l’impiego dell’arma dall’interno del veicolo e riduce l’esposizione dell’operatore — Gli Ufficiali del 199° corso e le piattaforme da combattimento della fanteria – Esercito Italiano – ottobre 2021 — fonte ufficiale verificata. Tuttavia, la specifica ricostruzione del 10 giugno 2026 deve restare classificata, in questa fase, come allegazione da verificare. Questo non la rende tecnicamente irrilevante: la rende un caso da analizzare mediante ipotesi concorrenti anziché tramite attribuzione prematura. L’errore più comune sarebbe tradurre “movimento senza comando” in “hackeraggio” o “AI impazzita”. In una torretta remotizzata, l’azione osservata può emergere da un guasto del joystick, da un bit errato sul bus, da un reset parziale, da una tensione transitoria, da un sensore di posizione incoerente, da un errore di calibrazione, da una procedura manutentiva incompleta, da software corrotto oppure da un’azione ostile. La domanda corretta non è quindi chi abbia impartito l’ordine, ma quale combinazione di stati abbia fatto credere ai sottosistemi di movimento e fuoco che esistessero le condizioni autorizzative necessarie.
Le cinque ipotesi concorrenti e il significato dei tre colpi
Un’Analysis of Competing Hypotheses preliminare deve mantenere aperte almeno cinque spiegazioni. H₁, guasto elettromeccanico: deriva dell’encoder, cortocircuito, relè incollato, disturbo elettromagnetico, attuatore fuori controllo o anomalia dell’alimentazione. Questa classe può spiegare una rotazione spontanea, ma spiega meno facilmente l’abilitazione dell’arma, salvo che il circuito di sparo condivida vulnerabilità elettriche o ritorni di massa con il controllo del movimento. H₂, errore software deterministico: race condition, overflow, deadlock recuperato in modo scorretto, variabile non inizializzata, perdita di sincronizzazione o gestione anomala del riavvio. È plausibile quando l’evento emerge soltanto in una combinazione rara di temperatura, quota, vibrazioni, sequenza di comandi e stato del veicolo. H₃, problema di integrazione, manutenzione o configurazione: firmware non allineato, cablaggio sostituito, parametri errati, modalità test lasciata attiva, procedura di caricamento o messa in sicurezza incompleta. H₄, comando spurio o compromissione cyber: frame contraffatto sul bus, accesso attraverso una porta manutentiva, dispositivo diagnostico compromesso, aggiornamento manipolato, credenziale condivisa o modulo di terze parti infetto. H₅, interazione sistemica uomo–macchina: un input reale ma non intenzionale viene trasformato dal software in una sequenza cinetica a causa di logiche di debounce, priorità, latenza o interfaccia. L’elemento decisivo è la descritta raffica di tre colpi. Un movimento incontrollato e una scarica singola possono derivare da fenomeni diversi; una raffica con cardinalità coerente può invece suggerire l’esecuzione di una funzione discreta, di un parametro “burst length” o di un comando registrato, pur senza provarlo. L’indagine deve perciò ricostruire separatamente la catena intent recognition → fire enable → actuator command → solenoid energization → shot count, verificando se ogni passaggio abbia lasciato una traccia indipendente. Senza questa segmentazione, il rischio è che il costruttore trovi “nessun comando dell’operatore” ma non identifichi quale sottosistema abbia generato un equivalente funzionale del comando.
La nuova superficie d’attacco: AI, diagnostica e supply chain
L’AI non deve trovarsi direttamente nel circuito di fuoco per aumentare il rischio del sistema. Può essere introdotta nella manutenzione predittiva, nel riconoscimento delle minacce, nella stabilizzazione dell’immagine, nella classificazione degli oggetti, nella fusione sensoriale, nell’assistenza all’operatore, nella simulazione, nella generazione automatica di test o negli strumenti di sviluppo usati dal fornitore. Ogni livello crea una superficie distinta: model layer, dataset, pipeline di addestramento, librerie, acceleratori, firmware, interfacce di telemetria, repository degli aggiornamenti e postazioni diagnostiche. Il NIST distingue attacchi di evasion, poisoning, violazione della privacy e misuse, precisando che i rischi adversarial possono colpire diverse fasi del ciclo di vita e diversi metodi di apprendimento — Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations – NIST – marzo 2025 — fonte ufficiale verificata. Per un sistema armato, tuttavia, la tassonomia deve essere estesa al passaggio dagli output informativi agli effetti fisici: una classificazione errata non deve mai diventare automaticamente un consenso di fuoco; un modello compromesso non deve poter modificare gli interlock; un aggiornamento del modulo video non deve possedere privilegi sul fire-control computer. La regola ingegneristica centrale è non-interference by construction: il dominio AI può proporre, segnalare o prioritizzare, ma deve restare tecnicamente incapace di energizzare l’attuatore di sparo. Questa separazione deve essere hardware, verificabile e sottoposta a fault injection, non affidata soltanto a permessi software. La convergenza tra strumenti AI offensivi e software embedded aumenta inoltre la probabilità di vulnerabilità scoperte prima dell’impiego: agenti automatici possono analizzare firmware, generare sequenze di input, individuare condizioni di race e costruire exploit contro simulatori o digital twin. Il rischio dominante del prossimo quinquennio non sarà quindi un’intelligenza artificiale che “decide di sparare”, ma un avversario che utilizza AI per trovare il percorso minimo attraverso una catena di componenti tradizionali insufficientemente separati.
Safety, security e governabilità non sono sinonimi
La tradizionale distinzione tra safety e cybersecurity è ormai insufficiente. La safety presume spesso guasti casuali caratterizzati da distribuzioni probabilistiche; la security considera un avversario che sceglie tempi, condizioni e sequenze per massimizzare l’effetto. Un’interfaccia diagnostica raramente usata può avere una probabilità accidentale trascurabile di provocare fuoco, ma diventare il vettore preferito di un aggressore perché consente di bypassare gli stati normali. Le linee guida internazionali sull’Operational Technology sottolineano che le decisioni di sicurezza devono preservare un ambiente OT sicuro e affidabile, integrando governo, identificazione, protezione, rilevamento, risposta e ripristino — Principles of Operational Technology Cybersecurity – CISA e partner governativi – ottobre 2024 — fonte ufficiale verificata. Per una Remote Weapon Station, però, “ripristino” non può significare semplicemente riavviare il servizio: dopo uno stato incoerente il sistema deve transitare verso una condizione fisicamente sicura, con fire inhibit, rimozione dell’energia dall’attuatore, verifica indipendente della posizione e necessità di un nuovo consenso umano. La NATO ha formalizzato sei principi per l’AI militare—legalità, responsabilità, spiegabilità e tracciabilità, affidabilità, governabilità e mitigazione dei bias—e la governabilità comprende la possibilità di disattivare sistemi che mostrino comportamenti non intenzionali — NATO’s Data and Artificial Intelligence Review Board – NATO – ottobre 2022 — fonte ufficiale verificata. La governabilità, applicata rigorosamente, richiede però più di un pulsante di emergenza: serve una catena di arresto separata, con autorità superiore al software missione, comportamento fail-silent e prova periodica dell’effettiva disconnessione. Un sistema non è governabile se il medesimo processore interpreta il comando, controlla l’interlock, registra il log e certifica retrospettivamente di essersi comportato correttamente.
Il vuoto regolatorio europeo e la necessità di assurance militare nazionale
Il quadro europeo produce un paradosso strategico. Il Regolamento europeo sull’AI adotta un’impostazione basata sul rischio e sottopone a requisiti elevati i sistemi che fungono da componenti di sicurezza di prodotti regolamentati; tuttavia, esclude i sistemi sviluppati, immessi in servizio o utilizzati esclusivamente per finalità militari, di difesa o sicurezza nazionale — Regulation (EU) 2024/1689 – Unione europea – luglio 2024 — testo ufficiale verificato. L’esclusione è giuridicamente comprensibile, ma non costituisce uno standard tecnico sostitutivo. Essa trasferisce allo Stato membro l’onere di creare un regime almeno equivalente, e in materia di sistemi armati necessariamente più severo. La Cina sta parallelamente costruendo una base normativa molto più granulare sul rapporto tra robotica e sicurezza informatica: lo standard GB/T 45502-2025, pubblicato il 28 marzo 2025 ed efficace dal 1° ottobre 2025, stabilisce requisiti generali di information security per robot di servizio — General Requirements for Information Security of Service Robots – State Administration for Market Regulation, China – marzo 2025 — fonte governativa cinese verificata. Un ulteriore standard cinese, GB/T 45958-2025, definisce una cornice di sicurezza per piattaforme di calcolo AI ed è entrato in vigore il 1° febbraio 2026 — Security Framework for Artificial Intelligence Computing Platform – State Administration for Market Regulation, China – agosto 2025 — fonte governativa cinese verificata. Questi standard civili non provano le caratteristiche dei sistemi militari cinesi e non vanno interpretati come garanzia di conformità operativa; mostrano però che Pechino tratta sicurezza del controller robotico, piattaforma AI e dati come domini normativi separati. L’Italia necessita di un’architettura analoga ma militare: certificazione del circuito cinetico, sicurezza della piattaforma di calcolo, controllo della supply chain, qualificazione degli aggiornamenti, validazione dei modelli e responsabilità formale del configuration authority.
Il protocollo forense che il caso richiederebbe
Se un sistema armato ha eseguito movimenti e fuoco senza un ordine intenzionale, l’indagine non può essere affidata esclusivamente alla diagnostica standard del costruttore, perché tale diagnostica potrebbe condividere gli stessi presupposti, clock, software o vulnerabilità del sistema investigato. Occorre preservare il veicolo, la torretta, l’arma, le munizioni residue, le centraline, i cablaggi, le batterie, i dispositivi manutentivi, le versioni firmware e ogni supporto rimovibile mediante una catena di custodia militare-industriale con replica indipendente. I dati da sincronizzare comprendono log della console, frame del bus di bordo, tensioni di alimentazione, eventi del fire-control computer, encoder azimutali ed elevazione, stato degli interlock, pressione sul grilletto, posizione dei selettori, temperatura, vibrazioni, eventuali disturbi radioelettrici e telemetria di manutenzione. Il primo obiettivo non è “trovare il bug”, ma stabilire una cronologia con risoluzione sufficiente a determinare quale dominio abbia cambiato stato per primo. Se il log registra il comando di fuoco ma la console non lo genera, la ricerca si concentra sull’iniezione a valle o sulla corruzione della memoria; se nessun log registra il comando ma l’attuatore si energizza, cresce il peso delle ipotesi elettriche, del bypass hardware o di una registrazione incompleta; se il log e l’attuatore concordano ma gli interlock risultano impossibili, il problema riguarda la veridicità o indipendenza della telemetria. Devono seguire test su un gemello fisico e digitale mediante hardware-in-the-loop, fault injection, replay dei messaggi, fuzzing dei protocolli, variazioni termiche, perdita di alimentazione, riavvii parziali e disturbi elettromagnetici. Qualsiasi prova con arma reale richiede barriere fisiche, attuatori inertizzati o simulatori del solenoide. Il principio probatorio deve essere severo: la mancata riproduzione non dimostra l’assenza del difetto; indica soltanto che lo spazio delle condizioni iniziali non è stato ancora ricostruito.
Outlook 2026–2031: cinque anni di rischio crescente
Nel periodo 2026–2031, la probabilità di incidenti cyber-fisici aumenterà non necessariamente perché i singoli componenti diventeranno meno affidabili, ma perché cresceranno la complessità, il numero di dipendenze software, la frequenza degli aggiornamenti e l’interconnessione tra sensori ed effettori. La strategia digitale NATO del gennaio 2026 prevede maggiore impiego di inferenza AI al margine tattico, con fusione dei sensori, predictive analytics e flussi sensor-to-effector in ambienti contestati — Alliance Digital Strategy – NATO – gennaio 2026 — fonte ufficiale verificata. Questa trasformazione aumenta il valore operativo, ma riduce il tempo disponibile per riconoscere stati anomali e moltiplica i punti nei quali un dato errato può propagarsi. Un modello Monte Carlo concettuale deve quindi rappresentare almeno quattro variabili: Pᵥ, probabilità di vulnerabilità sfruttabile; Pₐ, probabilità di accesso dell’avversario; Pᵦ, probabilità di bypass delle barriere; Cₖ, conseguenza cinetica. Anche con valori individualmente bassi, la coda del rischio cresce quando flotte numerose condividono firmware, chiavi, strumenti diagnostici o fornitori. Lo scenario centrale, stimato qualitativamente al 50%, vede incidenti rari ma ricorrenti contenuti da interlock e miglioramento della registrazione forense; lo scenario di stress, 30%, include compromissioni della supply chain, exploit AI-assisted e sospensioni operative di intere configurazioni; lo scenario grave, 15%, contempla un incidente letale o l’impiego ostile di credenziali manutentive; lo scenario estremo, 5%, vede attacchi coordinati contro una famiglia di piattaforme durante una crisi. Queste percentuali non sono frequenze empiriche: sono priors trasparenti destinati ad aggiornamento bayesiano dopo test, incidenti, intelligence e audit. La misura strategica non è la probabilità del singolo sparo, ma il rischio di difetto comune capace di propagarsi a molti mezzi simultaneamente.
Implicazioni per l’Italia: dalla conformità alla sovranità tecnica
Per l’Italia, la questione supera Leonardo, il Lince e la singola torretta. Coinvolge la capacità dello Stato di conoscere, verificare e controllare il comportamento delle proprie piattaforme anche quando hardware, librerie, processori, toolchain e sottosistemi provengono da catene multinazionali. La sovranità operativa non richiede necessariamente la produzione nazionale di ogni componente; richiede però accesso al software rilevante, disponibilità dei simboli di debug, tracciabilità delle dipendenze, chiavi sotto controllo governativo, capacità di riprodurre le build e autorità indipendente per bloccare configurazioni non sicure. Nel modello raccomandato, ogni sistema armato riceverebbe un Cinetic Safety Case aggiornato per ciascuna configurazione: diagramma delle barriere, analisi STPA-Sec, fault tree, attack tree, matrice di privilegi, inventario software, distinta crittografica dei componenti, risultati di fuzzing e prova del circuito di inibizione. Gli aggiornamenti operativi dovrebbero essere firmati con chiavi separate tra sviluppo, collaudo e rilascio; nessuna workstation manutentiva dovrebbe poter comunicare contemporaneamente con reti aziendali e circuiti d’arma; i log critici dovrebbero essere replicati su un registratore append-only con clock indipendente; ogni comando di fuoco dovrebbe produrre una catena di evidenze verificabile ma progettata per non rallentare l’azione legittima. La responsabilità deve essere distribuita senza diventare opaca: l’operatore conserva l’autorità sull’impiego, il comandante sulla missione, il configuration authority sulla versione, il costruttore sulla conformità tecnica e un organismo pubblico indipendente sull’assurance. Il criterio conclusivo è semplice ma radicale: l’Italia non deve acquistare soltanto prestazioni, precisione e disponibilità. Deve acquistare anche dimostrabilità, cioè la capacità di provare perché un sistema ha agito, quali barriere hanno funzionato e quali condizioni rendono fisicamente impossibile una ripetizione.
RWS Failure & Sabotage Risk Codex
Bayesian Stress Inputs
Dynamic Risk Dial
Five-Hypothesis Structural Matrix
Sistemi d’arma robotizzati: evento, catena causale e standard probatorio
Il perimetro fattuale: ciò che è confermato e ciò che non può ancora esserlo
L’analisi deve iniziare separando rigorosamente il contesto verificato dalla ricostruzione dell’anomalia, perché in un sistema d’arma digitalizzato la qualità della conclusione dipende dalla disciplina con cui vengono distinti fatti, testimonianze, dati macchina e inferenze. È ufficialmente confermato che, tra il 25 maggio e il 16 giugno 2026, l’Esercito Italiano ha condotto nell’area addestrativa del Monte Bivera, nelle Alpi Carniche, l’esercitazione a fuoco “Alabarda d’Argento 2026”, coinvolgendo oltre 300 militari della Brigata Alpina “Julia”, reparti specialistici, personale dell’Esercito albanese, osservatori internazionali, sistemi a pilotaggio remoto e nuove tecnologie applicate al combattimento terrestre. L’attività si è svolta a quasi 2.000 metri di quota, un dato tecnicamente rilevante perché temperatura, pressione atmosferica, vibrazioni, umidità, escursione termica, irraggiamento solare e qualità dell’alimentazione possono influenzare elettronica embedded, encoder, cablaggi, batterie e attuatori. Il comunicato ufficiale, tuttavia, non riferisce un fuoco accidentale, il danneggiamento di un secondo veicolo, il fermo precauzionale di sei piattaforme o una successiva indagine industriale. Di conseguenza, la dinamica attribuita al 10 giugno 2026—rotazione improvvisa della torretta, abbassamento della linea di tiro e raffica di tre colpi contro un altro Lince—deve essere classificata come informazione non corroborata pubblicamente, ancorché sufficientemente circostanziata da giustificare un’analisi tecnica condizionale. La piattaforma generale è compatibile con l’ecosistema descritto: Leonardo presenta HITROLE Light come una stazione d’arma remotizzata leggera configurabile con mitragliatrici da 7,62 o 12,7 millimetri oppure con lanciagranate automatico da 40 millimetri, destinata a sorveglianza, pattugliamento e protezione della forza. Questa compatibilità non identifica però automaticamente il modello coinvolto, la configurazione software, l’arma installata o la versione di produzione. Lo standard probatorio corretto richiede pertanto quattro etichette separate: confermato, compatibile, asserito, non determinato. Confondere tali categorie produrrebbe un errore analitico irreversibile, perché trasformerebbe l’assenza di una spiegazione pubblica in prova di cyberattacco oppure, all’opposto, in prova di semplice guasto. Conclusa l’esercitazione pluriarma “Alabarda d’Argento 2026” – Esercito Italiano – giugno 2026 — fonte ufficiale. HITROLE Light – Leonardo – consultato luglio 2026 — scheda ufficiale del sistema.
| Elemento | Stato probatorio al 23 luglio 2026 | Valore analitico | Limite |
|---|---|---|---|
| Esercitazione al Monte Bivera | Confermato | Colloca luogo, periodo e ambiente operativo | Non conferma l’incidente |
| Presenza di tecnologie remotizzate | Confermato in termini generali | Dimostra un ambiente cyber-fisico complesso | Non identifica la torretta coinvolta |
| Rotazione e abbassamento inattesi | Asserito | Indizio di perdita del controllo del moto | Manca telemetria pubblica |
| Raffica di tre colpi | Asserito | Indizio potenziale di sequenza discreta | Non prova un comando software |
| Sei mezzi sospesi | Non corroborato pubblicamente | Se vero, suggerirebbe rischio di configurazione comune | Manca ordine operativo verificabile |
| Indagine Leonardo ancora aperta | Non corroborato pubblicamente | Se vero, indica mancata root cause definitiva | Manca comunicazione societaria o militare |
La catena causale: perché “ha sparato da sola” non è una diagnosi
La descrizione giornalistica di un’arma che “spara senza comando” comprime in una sola frase una catena tecnica composta da molteplici livelli indipendenti. In una stazione d’arma remotizzata, l’effetto cinetico finale richiede normalmente una progressione di stati: alimentazione disponibile, inizializzazione del controller, accettazione degli input dell’operatore, calcolo della posizione, comando agli attuatori, verifica degli interlock, abilitazione del circuito di fuoco, energizzazione del solenoide o dell’organo di scatto e prosecuzione della raffica secondo la logica del sistema o la meccanica dell’arma. Il quesito decisivo non è quindi se l’operatore abbia premuto il grilletto, ma dove sia nato il primo stato illegittimo e quali barriere non abbiano impedito la sua propagazione. Una deriva dell’encoder può provocare una rotazione non richiesta senza necessariamente consentire il fuoco; un frame spurio sul bus può generare un comando di movimento ma dovrebbe essere respinto da un controllo di autenticità o plausibilità; un relè incollato può energizzare un attuatore ma non dovrebbe simultaneamente alterare orientamento ed elevazione; una variabile software corrotta può associare una modalità di tiro a un input non correlato; un difetto di cablaggio può creare un accoppiamento elettrico tra sottosistemi; un reset parziale può lasciare un modulo in stato operativo mentre un altro torna a valori predefiniti pericolosi. Il fatto, se confermato, che la torretta avrebbe ruotato, abbassato la linea di fuoco e sparato tre colpi è più significativo della sola partenza accidentale, perché suggerisce una sequenza multi-dominio. Tuttavia, tre colpi non dimostrano l’esecuzione di un comando digitale: una breve energizzazione può produrre una raffica determinata dalla cadenza meccanica dell’arma, dal tempo di permanenza del circuito o da una logica configurata. La root cause deve essere ricostruita attraverso una cronologia comune con risoluzione almeno millisecondica, confrontando input dell’operatore, messaggi di rete, stato dei selettori, tensioni, encoder, interlock, corrente del solenoide, log della mission computer e conseguenze balistiche. Senza una base temporale comune, l’ordine apparente degli eventi può essere invertito e un sintomo a valle può essere erroneamente identificato come causa primaria. I principi internazionali di sicurezza dell’Operational Technology insistono sulla necessità di progettare ambienti sicuri, affidabili e controllabili considerando congiuntamente eventi accidentali e intenzionali; questa convergenza è ancora più vincolante quando l’output non è un processo industriale, ma un effetto cinetico. Principles of Operational Technology Cybersecurity – CISA, ASD, FBI, NSA e partner – ottobre 2024 — documentazione ufficiale.
Le cinque ipotesi concorrenti: un’ACH che impedisce attribuzioni premature
L’Analysis of Competing Hypotheses deve mantenere almeno cinque famiglie causali simultaneamente attive, evitando di scegliere la spiegazione più intuitiva prima della raccolta delle evidenze. H₁ – guasto elettromeccanico comprende encoder difettosi, contatti intermittenti, relè incollati, dispersioni, disturbi elettromagnetici, cadute di tensione, alimentazione instabile, guasto dell’attuatore o problemi di massa. H₁ spiega bene un moto incontrollato, ma spiega meno bene una sequenza coordinata di orientamento, elevazione e fuoco, a meno che esista una vulnerabilità elettrica comune. H₂ – difetto del software embedded include race condition, overflow, puntatori corrotti, variabili non inizializzate, gestione errata del watchdog, riavvio asincrono, stato persistente non azzerato o conflitto tra task real-time. H₂ acquista peso se l’evento si verifica soltanto in una combinazione rara di temperatura, vibrazioni, sequenza operativa e versione firmware. H₃ – errore di configurazione, manutenzione o integrazione comprende cablaggio sostituito, firmware incompatibili, calibrazione errata, modalità test non disabilitata, parametri importati da una configurazione diversa, ricambio non equivalente o procedura di rimessa in servizio incompleta. H₃ diventa particolarmente plausibile quando mezzi nominalmente identici hanno storie manutentive differenti. H₄ – compromissione cyber o sabotaggio digitale richiede un percorso di accesso, una capacità tecnica, una persistenza e un meccanismo di attivazione: porta diagnostica, workstation manutentiva, supporto rimovibile, aggiornamento manipolato, credenziali condivise, frame contraffatti, componente di supply chain o backdoor. L’assenza di connessione a Internet non elimina H₄, perché i sistemi isolati possono essere compromessi durante sviluppo, manutenzione o aggiornamento. H₅ – interazione uomo-macchina e comportamento emergente considera input reali ma non intenzionali, ambiguità dell’interfaccia, latenza, rimbalzo del comando, pressione accidentale, sequenze operative incompatibili o conflitto tra controllo manuale e stabilizzazione automatica. Nessuna ipotesi deve essere eliminata soltanto perché “improbabile”: in un’indagine safety-security, la probabilità iniziale conta meno della capacità dell’ipotesi di spiegare l’intera sequenza senza eccezioni ad hoc. Il NIST distingue esplicitamente il rischio intrinseco, derivante da errori di modello o implementazione, dal rischio adversarial prodotto da azioni deliberate; la distinzione è essenziale perché gli stessi sintomi esterni possono derivare da cause completamente diverse. Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations – NIST – marzo 2025 — pubblicazione ufficiale.
| Evidenza potenziale | H₁ Elettromeccanica | H₂ Software | H₃ Configurazione | H₄ Cyber | H₅ Uomo-macchina |
|---|---|---|---|---|---|
| Comando assente nei log della console | Compatibile | Compatibile | Compatibile | Compatibile | Contraddittorio |
| Frame di fuoco valido sul bus | Debole | Forte | Medio | Forte | Medio |
| Nessun frame, ma corrente al solenoide | Forte | Debole | Medio | Medio | Debole |
| Hash firmware non conforme | Debole | Forte | Forte | Molto forte | Debole |
| Difetto riprodotto con stessa sequenza | Medio | Molto forte | Forte | Medio | Forte |
| Evento su più mezzi identici | Debole | Forte | Molto forte | Forte | Debole |
| Artefatti malware o accesso non autorizzato | Contraddittorio | Contraddittorio | Debole | Decisivo | Contraddittorio |
| Anomalia sensibile a temperatura/vibrazione | Molto forte | Medio | Medio | Debole | Debole |
Lo standard probatorio: da “plausibile” a “attribuibile”
Un’indagine tecnicamente seria deve applicare una scala probatoria più rigorosa di quella normalmente utilizzata nella comunicazione pubblica. Il livello E₀ comprende dichiarazioni, ricordi degli operatori, fotografie e rapporti iniziali: sono indispensabili per orientare la ricerca ma vulnerabili a errori percettivi, sequenze ricostruite ex post e contaminazione narrativa. Il livello E₁ comprende prove fisiche e telemetriche non ancora validate—bossoli, impatti, posizione della torretta, log, memoria volatile, file di diagnostica—che dimostrano un effetto ma non ancora la causa. Il livello E₂ richiede correlazione temporale tra almeno due fonti indipendenti, per esempio la corrente del circuito di sparo e il log di un registratore separato, oppure il frame del bus e il movimento misurato dall’encoder. Il livello E₃ richiede riproducibilità controllata mediante banco prova, hardware-in-the-loop, fault injection o replay, conservando la stessa configurazione di software e hardware. Il livello E₄ consente una root cause quando esiste un meccanismo dimostrato capace di produrre tutti gli effetti osservati e quando le ipotesi alternative sono state testate, non semplicemente dichiarate improbabili. L’attribuzione a un attore ostile richiede poi un livello ulteriore, E₅, costituito da access path, capability, intent, infrastruttura, artefatti, temporalità e possibilmente intelligence indipendente; un’anomalia non costituisce di per sé evidenza di sabotaggio. Questo standard è cruciale perché il produttore, l’utilizzatore e l’autorità investigativa possono possedere incentivi differenti: il costruttore tende a cercare un difetto riproducibile del prodotto, l’unità operativa può concentrarsi sulla procedura, l’autorità cyber può privilegiare indicatori di compromissione, mentre la catena di comando deve decidere rapidamente sulla sicurezza della flotta. Per evitare che l’urgenza operativa distorca il giudizio, la conclusione dovrebbe essere prodotta da un board con autorità indipendente, analogo concettualmente ai meccanismi di revisione degli incidenti aeronautici o cyber, con accesso ai codici, ai log, alla configurazione e alla supply chain. CISA ha promosso processi standardizzati di risposta e revisione degli incidenti per assicurare coordinamento, tracciabilità e catalogazione delle evidenze; nei sistemi d’arma questo principio deve essere esteso fino al livello fisico e balistico. Executive Order on Improving the Nation’s Cybersecurity – CISA – aggiornamento consultato luglio 2026 — quadro ufficiale.
| Livello | Contenuto | Conclusione consentita |
|---|---|---|
| E₀ | Testimonianze e rapporti iniziali | “L’evento è stato segnalato” |
| E₁ | Evidenza fisica o digitale grezza | “L’effetto è avvenuto” |
| E₂ | Correlazione tra fonti indipendenti | “La sequenza è tecnicamente ricostruibile” |
| E₃ | Riproduzione controllata | “Il meccanismo è plausibile e ripetibile” |
| E₄ | Root cause con alternative escluse | “La causa tecnica è dimostrata” |
| E₅ | Accesso, capacità, intenzione e artefatti | “L’azione ostile è attribuibile” |
Preservazione forense: cosa deve essere congelato prima di qualsiasi riparazione
La priorità immediata non dovrebbe essere rimettere il mezzo in servizio, ma impedire che test, accensioni, aggiornamenti o sostituzioni distruggano lo stato che ha prodotto l’anomalia. Devono essere sequestrati logicamente e fisicamente il veicolo, la torretta, l’arma, le munizioni residue, i bossoli, i connettori, i cablaggi, le centraline, gli encoder, gli attuatori, le batterie, le memorie rimovibili, i dispositivi di caricamento software e le workstation manutentive utilizzate nei mesi precedenti. È necessario acquisire immagini bit-a-bit delle memorie non volatili, catturare la RAM prima di spegnimenti non indispensabili, registrare hash crittografici, fotografare ogni posizione dei selettori e documentare numeri di serie, revisioni hardware, versione del bootloader, firmware, librerie e parametri. La Software Bill of Materials deve essere accompagnata da una distinta hardware e da una cronologia delle manutenzioni; una lista nominale di componenti non basta se non viene collegata alla configurazione effettivamente installata. I log devono essere estratti da fonti differenti senza utilizzare, quando possibile, lo stesso software diagnostico potenzialmente coinvolto nell’anomalia. La telemetria da preservare include messaggi del bus, input della console, timestamp, stato del grilletto, modalità selezionata, comandi di azimut ed elevazione, feedback degli encoder, stato degli interlock, assorbimenti elettrici, reset, watchdog, errori di checksum, temperatura, vibrazioni e perdita di alimentazione. Devono inoltre essere acquisiti i log delle reti di manutenzione, dei repository di aggiornamento, delle credenziali usate, delle firme digitali e degli accessi dei fornitori. CISA raccomanda, negli incidenti cyber, di preservare prioritariamente memoria, immagini dei sistemi, log e artefatti volatili prima che vengano persi o alterati; nel dominio cyber-fisico questa regola deve includere anche stato meccanico, cablaggi e prove balistiche. StopRansomware Guide – CISA – aggiornamento consultato luglio 2026 — guida ufficiale sulla preservazione delle evidenze. ICS Recommended Practices – CISA – consultato luglio 2026 — raccolta ufficiale di pratiche forensi OT.
Il fattore AI: non serve un algoritmo nel circuito di fuoco per creare rischio
La presenza di intelligenza artificiale nel sistema non deve essere presunta, ma il suo impatto sul rischio va analizzato in modo più ampio del semplice “targeting autonomo”. L’AI può entrare nella catena attraverso visione artificiale, stabilizzazione, riconoscimento degli oggetti, manutenzione predittiva, generazione dei test, analisi dei log, supporto alla programmazione, simulazione o strumenti di sviluppo del fornitore. Un modello compromesso può non avere alcuna autorità diretta sul grilletto, ma può alterare la valutazione dello stato, produrre dati anomali, influenzare priorità, saturare un bus o indurre il software tradizionale in una condizione non prevista. Ancora più rilevante è l’uso offensivo dell’AI da parte di chi cerca difetti: agenti automatici possono analizzare firmware, decompilare funzioni, generare input, effettuare fuzzing, individuare sequenze rare e ottimizzare exploit molto più rapidamente di un processo manuale. Il NIST classifica attacchi di evasion, poisoning, privacy e misuse lungo differenti fasi del ciclo di vita, ma in una piattaforma armata occorre aggiungere una domanda assente dai sistemi informativi ordinari: quale output AI può propagarsi fino a un attuatore fisico e con quali barriere? La NATO riconosce sei principi per l’uso responsabile dell’AI—legalità, responsabilità, spiegabilità e tracciabilità, affidabilità, governabilità e mitigazione dei bias—e la strategia rivista del 2024 sottolinea la necessità di proteggere e monitorare le tecnologie AI, gestire i rischi e affrontare il loro impiego avversario. In termini ingegneristici, la governabilità non può dipendere dal medesimo processore che controlla la missione: il circuito di inibizione del fuoco deve essere separato, verificabile e capace di portare il sistema in stato sicuro anche quando il software principale è compromesso. Summary of NATO’s Revised Artificial Intelligence Strategy – NATO – luglio 2024 — testo ufficiale. Adversarial Machine Learning – NIST – marzo 2025 — tassonomia ufficiale.
Il confronto europeo, cinese e russo: tre modelli di governo del rischio
Il confronto multilaterale mostra che il problema non è soltanto tecnologico, ma riguarda il modo in cui gli Stati classificano e governano sistemi capaci di trasformare dati in effetti fisici. Nell’Unione europea, il Regolamento 2024/1689 stabilisce un regime basato sul rischio per i sistemi di AI, ma esclude quelli immessi sul mercato, messi in servizio o utilizzati esclusivamente per finalità militari, di difesa o sicurezza nazionale. L’esclusione non implica assenza di obblighi, ma trasferisce agli Stati membri la responsabilità di creare un sistema militare di assurance che non può essere sostituito automaticamente dall’AI Act. In Cina, l’autorità nazionale di standardizzazione ha pubblicato il GB/T 45502-2025 sui requisiti generali di sicurezza informatica dei robot di servizio, operativo dal 1° ottobre 2025, e il GB/T 39404-2026 sui requisiti generali di sicurezza delle unità di controllo dei robot industriali, pubblicato il 30 aprile 2026 ed efficace dal 1° novembre 2026. Questi standard non riguardano armi né provano la sicurezza delle piattaforme militari cinesi, ma dimostrano una segmentazione normativa tra robot, controller e sicurezza dell’informazione. In Russia, la strategia nazionale sull’AI aggiornata nel febbraio 2024 riconosce la comparsa di nuove minacce alla sicurezza informativa specifiche dell’AI e prescrive l’impiego di tecnologie “affidabili” nei settori in cui può essere danneggiata la sicurezza dello Stato; parallelamente, la legislazione sulla critical information infrastructure ha rafforzato obblighi di protezione, segnalazione e interazione continua con il sistema statale di rilevamento e risposta agli attacchi informatici. Anche in questo caso, tali documenti non descrivono sistemi d’arma russi, ma mostrano un orientamento alla centralizzazione della risposta e alla sovranità tecnologica. Per l’Italia, la lezione comparata è che un regime efficace deve unire l’impostazione europea sui diritti e sul rischio, la granularità tecnica cinese sui controller e la disciplina russa di reporting e continuità operativa, evitando però opacità e concentrazione non verificabile. Regulation (EU) 2024/1689 – Unione europea – luglio 2024 — testo ufficiale. GB/T 45502-2025 – State Administration for Market Regulation, China – marzo 2025 — standard ufficiale. GB/T 39404-2026 – State Administration for Market Regulation, China – aprile 2026 — standard ufficiale. Decree No. 124 amending the National AI Strategy – Presidenza della Federazione Russa – febbraio 2024 — testo ufficiale in russo. Order No. 547 on reporting and response to computer incidents – Federazione Russa – dicembre 2025 — pubblicazione ufficiale.
Aggiornamento bayesiano e orizzonte 2026–2031
Una valutazione bayesiana responsabile non deve inventare precisione numerica, ma rendere esplicito come ciascuna nuova evidenza modificherebbe il peso delle ipotesi. In assenza di telemetria, H₁, H₂, H₃ e H₅ devono conservare priorità significativa, mentre H₄ non può essere né esclusa né privilegiata. Se emergesse un frame di fuoco valido, correttamente formato e assente dalla console, aumenterebbero H₂ e H₄; se il segnale elettrico raggiungesse l’attuatore senza alcun comando sul bus, crescerebbe H₁; se più mezzi con lo stesso aggiornamento riproducessero il difetto, H₂ e H₃ diverrebbero dominanti; se soltanto un mezzo con una particolare storia manutentiva fosse coinvolto, aumenterebbe H₃; se venissero trovati hash non conformi, accessi non autorizzati o strumenti diagnostici compromessi, H₄ riceverebbe un aggiornamento sostanziale. Nel quinquennio 2026–2031, il rischio sistemico aumenterà per quattro ragioni: crescita delle dipendenze software, diffusione di aggiornamenti frequenti, integrazione di moduli AI e maggiore uniformità delle flotte. L’uniformità riduce costi e semplifica la logistica, ma crea un common-mode failure risk: un singolo difetto può propagarsi a decine o centinaia di piattaforme. Lo scenario centrale prevede incidenti rari contenuti da interlock migliorati e registrazione forense; lo scenario di stress considera difetti software condivisi, fermo flotta e compromissione di strumenti manutentivi; lo scenario grave include un effetto letale o la perdita temporanea di fiducia in un’intera famiglia di sistemi; lo scenario estremo contempla sabotaggio coordinato contro configurazioni comuni durante una crisi. La misura decisiva non sarà il numero assoluto di malfunzionamenti, ma il tempo necessario per identificare, isolare e correggere una causa senza distruggere l’evidenza. Entro il 2031, ogni piattaforma armata remotizzata dovrebbe disporre di registratore indipendente, firme di configurazione, interlock hardware separati, test di fault injection, audit della supply chain e un safety-security case aggiornato per ogni release. Senza questi strumenti, l’aumento di autonomia produrrà non soltanto più capacità operativa, ma anche più incertezza probatoria dopo ogni anomalia. La strategia NATO sottolinea la necessità di monitoraggio, gestione del rischio e pianificazione anticipatoria; il caso italiano dimostra perché tali principi debbano diventare requisiti contrattuali e non semplici dichiarazioni.
Figure 1: Proiezione quinquennale del rischio cyber-fisico 2026–2031
Indice analitico composito, non probabilità empirica. Base 2026 = 100.
Architettura cyber-fisica e nuovi vettori AI nei sistemi militari robotizzati
Il sistema d’arma come catena digitale di effetti fisici
Una piattaforma remotizzata o semi-autonoma non è più descrivibile come un’arma tradizionale collegata a una telecamera e a un joystick: costituisce una architettura cyber-fisica distribuita nella quale sensori, software embedded, reti interne, attuatori, interlock, apparati diagnostici e procedure manutentive concorrono alla produzione di un effetto fisico potenzialmente irreversibile. Il rischio non dipende quindi soltanto dalla possibilità che un aggressore “prenda il controllo” dell’intero sistema, scenario spettacolare ma spesso tecnicamente meno probabile di un’alterazione parziale. È sufficiente che un attore, un difetto o una combinazione di anomalie modifichi una singola variabile decisiva: l’interpretazione della posizione, la validità del consenso umano, lo stato di un settore vietato, l’autenticità di un messaggio sul bus, la versione del firmware o il risultato di un algoritmo di classificazione. La trasformazione promossa dalla NATO verso Software Defined Defence, tactical edge computing, piattaforme federate, inferenza AI e flussi sensor-to-effector aumenta velocità, modularità e interoperabilità, ma rende la funzione militare sempre più dipendente dall’integrità del software, dei dati e delle identità digitali. La strategia digitale dell’Alleanza del gennaio 2026 prevede esplicitamente l’impiego di AI inferenziale al margine tattico, la fusione dei sensori, predictive analytics, Zero Trust e integrazione dei flussi tra sensori ed effettori; ciò dimostra che il problema non è futuribile, ma incorporato nella direzione corrente della trasformazione militare. Alliance Digital Strategy – NATO – gennaio 2026 — testo ufficiale verificato. L’effetto strategico è duplice: da un lato, il controllo può essere distribuito tra nodi diversi, migliorando resilienza e continuità; dall’altro, la piattaforma eredita vulnerabilità che non appartengono più alla sola arma, ma al sistema operativo real-time, alle librerie, ai microcontrollori, ai moduli di rete, agli strumenti di sviluppo e ai servizi industriali che ne sostengono l’intero ciclo di vita. La nozione corretta di sabotaggio deve pertanto includere non solo l’invio remoto di un comando ostile, ma qualsiasi manipolazione capace di trasformare uno stato digitale illegittimo in moto, puntamento, rilascio, collisione o fuoco.
Controllo embedded: il punto in cui il software diventa movimento
Il controllo embedded rappresenta il confine operativo tra informazione e meccanica. Esso comprende microprocessori, microcontrollori, FPGA, sistemi operativi real-time, firmware, moduli input/output, driver degli attuatori, watchdog, routine di inizializzazione e logiche di gestione degli errori. In un’architettura robusta, la perdita di un sensore, un reset, una divergenza tra encoder, un messaggio fuori sequenza o una tensione irregolare devono portare il sistema verso uno stato definito e fisicamente sicuro; in un’architettura fragile, la stessa anomalia può produrre uno stato composito non previsto, nel quale alcuni moduli risultano reinizializzati, altri conservano dati precedenti e altri ancora interpretano valori predefiniti come comandi validi. Questo fenomeno è particolarmente insidioso perché non richiede un bug evidente nel codice principale: può emergere dall’interazione temporale tra task corretti individualmente ma non verificati nella loro combinazione. Un attaccante può sfruttare tale fragilità senza introdurre malware persistente, provocando reset selettivi, saturazione del bus, errori temporali o sequenze di input che spingono il controller verso una condizione logicamente valida ma operativamente pericolosa. La resilienza del firmware richiede tre proprietà distinte: protezione, affinché modifiche non autorizzate non possano essere installate; rilevamento, affinché alterazioni avvenute vengano riconosciute; recupero, affinché il sistema possa tornare a una configurazione nota e affidabile. Il NIST identifica esattamente queste tre funzioni nelle proprie linee guida sulla resilienza del firmware di piattaforma, sottolineando che un attacco al firmware può rendere un sistema inutilizzabile o richiedere il ripristino da parte del produttore. Platform Firmware Resiliency Guidelines, NIST SP 800-193 – NIST – maggio 2018 — pubblicazione ufficiale verificata. In un sistema d’arma, tuttavia, il recupero automatico non deve essere equiparato al ritorno immediato alla disponibilità: dopo qualsiasi incongruenza del firmware, la piattaforma dovrebbe rimanere in fire-inhibit, richiedere verifica indipendente della configurazione e impedire che il semplice riavvio ristabilisca capacità cinetiche. Secure boot, measured boot e firma del firmware sono necessari, ma non sufficienti, perché autenticano il software installato senza dimostrare che quel software sia privo di errori, correttamente configurato o compatibile con tutti i moduli collegati.
| Livello embedded | Errore o manipolazione | Effetto possibile | Controllo richiesto |
|---|---|---|---|
| Bootloader | Immagine non autorizzata o rollback | Avvio di firmware vulnerabile | Secure boot e anti-rollback |
| RTOS | Scheduling anomalo o race condition | Comandi fuori sequenza | Analisi temporale e watchdog indipendente |
| Driver | Valore errato all’attuatore | Moto o attivazione impropria | Limiti hardware e plausibility check |
| FPGA | Bitstream alterato | Bypass della logica software | Firma e verifica del bitstream |
| Memoria persistente | Parametri corrotti | Settori, limiti o modalità errati | Configurazione firmata e ridondante |
| Watchdog | Recupero incompleto | Stato ibrido post-reset | Reset coordinato e default sicuri |
Interlock: la barriera che non deve condividere il destino del software missione
Gli interlock costituiscono l’ultima difesa tra una decisione digitale e un effetto fisico, ma la loro efficacia dipende dalla reale indipendenza rispetto ai sottosistemi che dovrebbero sorvegliare. Un interlock implementato come semplice variabile nello stesso software che controlla puntamento e fuoco non è una barriera indipendente: è una condizione logica vulnerabile agli stessi bug, privilegi, errori di memoria e compromissioni del controller principale. La progettazione corretta richiede una struttura a più livelli: consenso umano esplicito; conferma della modalità operativa; verifica dell’arma e della piattaforma; controllo dei settori vietati; plausibilità di azimut ed elevazione; integrità della comunicazione; consenso di un modulo separato; interruzione fisica dell’energia al circuito di sparo. La criticità maggiore emerge quando diversi controlli derivano dalla medesima fonte. Se posizione, orientamento e settore di sicurezza dipendono dallo stesso encoder o dalla stessa unità inerziale, una singola falsificazione può rendere coerente un quadro interamente errato. L’indipendenza deve essere quindi non soltanto software, ma funzionale, elettrica e informativa: sensori diversi, alimentazioni separate, logiche di confronto e percorsi di arresto capaci di operare quando la mission computer è guasta o compromessa. La governabilità richiamata dalla strategia NATO sull’AI presuppone che sistemi responsabili di effetti militari possano essere disattivati quando mostrano comportamenti non intenzionali; tuttavia, la disattivazione è credibile soltanto se il meccanismo di arresto non dipende dal componente che sta manifestando l’anomalia. Summary of NATO’s Revised Artificial Intelligence Strategy – NATO – luglio 2024 — testo ufficiale verificato. La conseguenza ingegneristica è che l’AI, il software di missione e il modulo di targeting non devono possedere un percorso privilegiato verso l’attuatore. Possono generare raccomandazioni, tracce, priorità o soluzioni di tiro, ma l’abilitazione fisica deve essere subordinata a un componente minimale, verificabile e separato, con logica sufficientemente semplice da poter essere formalmente analizzata. Anche il pulsante di emergenza deve essere progettato contro guasti latenti: una linea mai testata, un relè bloccato o un arresto software privo di isolamento energetico possono produrre l’illusione della governabilità senza garantire alcuna capacità reale di interrompere l’effetto.
Data bus: il falso presupposto che una rete interna sia automaticamente fidata
Il data bus di bordo è spesso il punto nel quale l’architettura storica incontra la minaccia moderna. Molti protocolli veicolari o industriali furono concepiti privilegiando determinismo, semplicità, latenza e robustezza elettrica, non autenticazione crittografica, segregazione delle identità o resistenza a un avversario interno. In tale contesto, un messaggio formalmente corretto può essere accettato perché proviene dal canale previsto, senza che il ricevente disponga di prove sufficienti sull’identità del trasmettitore. Il rischio non consiste unicamente nell’iniezione di un comando di fuoco: un attaccante può alterare telemetria, posizione, stato dell’interlock, temperatura, disponibilità dell’arma o modalità selezionata; può effettuare replay di messaggi validi; può saturare il bus provocando latenze e fallback; può indurre un modulo a riavviarsi; può generare collisioni o errori di sincronizzazione che emergono soltanto in determinate sequenze. La migrazione verso architetture Ethernet e software-defined non elimina il problema, ma cambia la sua forma: aumenta larghezza di banda, indirizzabilità e capacità di aggiornamento, introducendo contemporaneamente stack protocollari più complessi, servizi di rete, librerie, autenticazione, certificati e nuove dipendenze. La strategia digitale NATO prescrive Zero Trust, verifica continua, least privilege e segregazione dei domini informativi; applicata al veicolo militare, questa impostazione significa che nessun modulo dovrebbe essere considerato affidabile soltanto perché fisicamente installato a bordo. Ogni nodo deve possedere un’identità verificabile, ogni funzione deve ricevere soltanto i privilegi necessari e i messaggi cineticamente rilevanti devono essere protetti contro alterazione, replay e origine non autorizzata. La crittografia, però, non risolve il rischio di un nodo legittimo compromesso: se una centralina autorizzata genera comandi errati, le firme possono attestare con precisione l’origine del messaggio senza garantirne la sicurezza. Occorrono quindi controlli semantici: velocità massime, variazioni plausibili, coerenza tra sensori, separazione tra comando e conferma, limiti fisici e registrazione indipendente. Il passaggio fondamentale è da una sicurezza basata sulla fiducia nel componente a una sicurezza basata sulla verifica continua del comportamento.
Manutenzione e aggiornamenti: la superficie d’attacco che segue il mezzo per decenni
La manutenzione costituisce una delle superfici più realistiche di compromissione perché collega periodicamente una piattaforma segregata a dispositivi, reti e persone esterne al perimetro operativo. Laptop diagnostici, dongle, supporti rimovibili, strumenti di calibrazione, repository, account dei fornitori, reti delle officine, collegamenti remoti e procedure di assistenza formano una catena transitoria che può avere privilegi superiori a quelli disponibili durante la missione. Un aggressore non deve necessariamente colpire il veicolo sul campo: può compromettere una workstation mesi prima, manipolare un pacchetto di aggiornamento, ottenere credenziali di un subfornitore o alterare un parametro durante una manutenzione programmata. Il rischio cresce quando gli strumenti sono condivisi tra molte piattaforme, perché un singolo dispositivo può diventare vettore di propagazione di un difetto o di un impianto malevolo. Il Cyber Resilience Act europeo impone ai produttori civili di prodotti con elementi digitali obblighi di sicurezza nella progettazione, nello sviluppo, nella produzione e nella gestione delle vulnerabilità lungo il periodo di supporto; riconosce inoltre che aggiornamenti e modifiche software possono alterare la natura del rischio e, in determinate condizioni, costituire modifiche sostanziali. Regulation (EU) 2024/2847, Cyber Resilience Act – Unione europea – ottobre/novembre 2024 — testo ufficiale verificato. Sebbene i sistemi sviluppati esclusivamente per finalità militari ricadano in regimi differenti, il principio tecnico è direttamente applicabile: ogni aggiornamento deve essere trattato come una modifica della configurazione operativa, non come un’operazione amministrativa. Servono firma digitale, doppia autorizzazione, verifica della provenienza, anti-rollback, staging su ambiente rappresentativo, test hardware-in-the-loop, registrazione immutabile e possibilità di ripristino controllato. Gli aggiornamenti automatici, appropriati in alcuni prodotti di largo consumo, possono essere incompatibili con ambienti critici nei quali un cambiamento non validato interferirebbe con l’operazione; lo stesso regolamento europeo riconosce questa specificità per reti professionali, industriali e critiche. Nel settore militare, nessun aggiornamento dovrebbe raggiungere direttamente una piattaforma operativa senza una catena di promozione distinta tra sviluppo, collaudo, qualificazione e rilascio, con chiavi separate e impossibilità per il singolo fornitore o manutentore di completare unilateralmente l’intero processo.
| Fase | Vettore realistico | Indicatore forense | Mitigazione prioritaria |
|---|---|---|---|
| Diagnostica | Laptop compromesso | Processi, driver o connessioni anomale | Postazione dedicata e attestazione |
| Aggiornamento | Pacchetto alterato | Firma assente, hash divergente | Firma offline e doppia custodia |
| Calibrazione | Parametri manipolati | Differenza dalla baseline | Parametri firmati e confronto automatico |
| Assistenza remota | Credenziale sottratta | Accesso fuori finestra | Accesso just-in-time e registrato |
| Ricambio | Componente non conforme | Seriali o firmware inattesi | Provenance e accettazione tecnica |
| Rollback | Versione vulnerabile reinstallata | Contatore versione ridotto | Anti-rollback hardware |
Sensori e fusione dati: sabotare la percezione invece del comando
I sensori rappresentano il livello nel quale la realtà fisica viene tradotta in dati, e tale traduzione può essere manipolata senza violare direttamente il controller. Telecamere, sensori infrarossi, laser, radar, GNSS, unità inerziali, encoder, sensori di inclinazione e rilevatori dello stato meccanico producono rappresentazioni parziali che il sistema combina per stimare posizione, orientamento, bersaglio, sicurezza e disponibilità. Un attacco alla percezione può utilizzare accecamento, saturazione, spoofing, segnali sintetici, interferenze, pattern adversarial, manipolazione della calibrazione o compromissione del firmware del sensore. L’obiettivo non è necessariamente far vedere un bersaglio inesistente: può essere sufficiente spostare di pochi gradi la stima dell’orientamento, far risultare libero un settore vietato, produrre una falsa stabilità o impedire al sistema di rilevare la divergenza tra posizione comandata e posizione reale. Nei sistemi AI-enabled, la fusione sensoriale può aumentare la resilienza quando sorgenti indipendenti si controllano reciprocamente, ma può anche nascondere l’anomalia se il modello apprende a compensare dati incoerenti senza segnalarli oppure se più sensori dipendono dalla stessa fonte temporale, navigazionale o di calibrazione. La strategia NATO del 2026 descrive una crescente integrazione di dati, sensori, predictive analytics e flussi sensor-to-effector; la sua implicazione di sicurezza è che l’integrità della percezione diviene parte della mission assurance, non un requisito secondario. Il principio tecnico necessario è la diversità controllata: differenti fenomeni fisici, differenti produttori o implementazioni, clock separati e verifiche geometriche indipendenti. Se telecamera, encoder e computer di missione condividono la stessa alimentazione, il medesimo gateway e un’unica fonte temporale, la ridondanza numerica non corrisponde a indipendenza reale. Ogni sensore critico deve inoltre esporre non soltanto un valore, ma una misura di qualità, integrità e stato interno; il controller deve poter degradare la funzione senza trasformare l’incertezza in consenso. In un’arma robotizzata, “dato mancante” deve significare capacità ridotta o inibita, non autorizzazione basata sull’ultimo valore valido.
Modelli AI: dall’errore statistico alla propagazione cinetica
Un modello AI introduce una modalità di guasto qualitativamente diversa dal software deterministico tradizionale. Un algoritmo classico può essere verificato rispetto a requisiti specifici e input formalizzati; un modello di apprendimento produce output sulla base di correlazioni statistiche apprese da dati che non coprono necessariamente tutte le condizioni operative. Il rischio comprende distribution shift, esempi fuori distribuzione, bias dei dati, labeling errato, avvelenamento del training set, manipolazione dei pesi, backdoor, input adversarial, estrazione del modello, compromissione della pipeline MLOps e degrado non rilevato dopo aggiornamenti. Il NIST classifica gli attacchi adversarial lungo le diverse fasi del ciclo di vita, includendo poisoning, evasion, privacy e misuse; la rilevanza militare deriva dal fatto che un output probabilistico può essere interpretato da software a valle come segnale operativo certo. Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, NIST AI 100-2e2025 – NIST – marzo 2025 — pubblicazione ufficiale verificata. La NATO riconosce espressamente che attori statali e non statali possono sfruttare difetti e limitazioni dei sistemi AI, interferire con essi, manipolarli o sabotarli, e richiede threat analysis, audit di sicurezza e stress testing specifici. Summary of the NATO Artificial Intelligence Strategy – NATO – ottobre 2021 — testo ufficiale verificato. Il requisito più importante non è quindi una generica “accuratezza” del modello, ma la limitazione della sua autorità causale. Un classificatore può segnalare, tracciare o ordinare priorità, ma non dovrebbe modificare direttamente interlock, settori di tiro o consenso cinetico. Ogni output deve essere accompagnato da incertezza, provenienza, versione del modello e qualità dei sensori; il sistema deve essere testato non soltanto sui dati medi, ma sui bordi dello spazio operativo, sulle condizioni meteorologiche estreme, sugli input manipolati e sui fallimenti combinati. La TEV&V prevista dalla strategia NATO riveduta deve includere modelli, dati, piattaforme di calcolo, pipeline di aggiornamento e interazione uomo-macchina, perché validare il modello isolatamente non dimostra la sicurezza del sistema che lo incorpora.
| Vettore AI | Punto d’ingresso | Effetto diretto | Rischio cinetico indiretto |
|---|---|---|---|
| Data poisoning | Dataset di training | Modello distorto | Classificazione sistematicamente errata |
| Backdoor | Training o pesi | Trigger nascosto | Comportamento attivabile |
| Evasion | Input operativo | Errore di percezione | Tracking o priorità falsati |
| Model replacement | Aggiornamento | Modello non autorizzato | Politica operativa alterata |
| MLOps compromise | Repository o pipeline | Artefatti manipolati | Propagazione a più piattaforme |
| Hallucination/overconfidence | Inferenza | Output non fondato | Decisione umana fuorviata |
| Model drift | Ambiente mutato | Prestazione degradata | Rischio crescente non rilevato |
Supply chain: il sabotaggio più efficace può precedere di anni l’impiego
La supply chain di un sistema robotizzato comprende più della distinta componenti finale: include progettazione elettronica, fonderie, microcontrollori, FPGA, bootloader, sistemi operativi, librerie open-source, toolchain di compilazione, software di test, servizi cloud, dati di addestramento, integratori, manutentori, subfornitori e logistica dei ricambi. Ogni livello può introdurre vulnerabilità accidentali o intenzionali, mentre la complessità contrattuale può impedire al committente di conoscere dipendenze decisive. Un componente formalmente conforme può contenere firmware diverso tra lotti; una libreria può ricevere un aggiornamento malevolo; una chiave di firma può essere sottratta; un fornitore minore può avere accesso privilegiato senza disporre della protezione del prime contractor; un modello AI può incorporare dati o pesi di provenienza non verificabile. Il rischio strategico nasce dalla commonality: la stessa dipendenza distribuita su un’intera flotta consente a un difetto o impianto di produrre effetti simultanei, trasformando una vulnerabilità tecnica in problema di prontezza nazionale. Il quadro europeo NIS2 per specifici soggetti digitali richiede di valutare pratiche di sicurezza dei fornitori, procedure di sviluppo sicuro, qualità e resilienza dei prodotti, capacità di soddisfare specifiche di cybersecurity e possibilità di diversificare le fonti per limitare il vendor lock-in. Commission Implementing Regulation (EU) 2024/2690 – Unione europea – ottobre 2024 — testo ufficiale verificato. Questi principi devono essere rafforzati nel procurement militare mediante diritti di audit, accesso alle dipendenze, Software e Hardware Bill of Materials, build riproducibili, controllo delle chiavi, verifica della provenienza e test indipendenti. La Cina, sul piano civile e industriale, ha progressivamente segmentato la standardizzazione tra sicurezza generale dei robot, sicurezza informatica dei robot di servizio, interfacce aperte dei controller e requisiti di sicurezza delle unità di controllo industriali: GB/T 45502-2025 è in vigore dal 1° ottobre 2025; GB/T 32197-2025 dal 1° novembre 2025; GB/T 39404-2026 è stato pubblicato il 30 aprile 2026 con entrata in vigore prevista il 1° novembre 2026. General Requirements for Information Security of Service Robots – SAMR/SAC – marzo 2025 — record ufficiale cinese. Industrial Robot Controller Open Communication Interface Specification – SAMR/SAC – aprile 2025 — record ufficiale cinese. General Security Requirements for Control Unit of Industrial Robot – SAMR/SAC – aprile 2026 — record ufficiale cinese. Questi standard non descrivono capacità militari cinesi, ma dimostrano che controller, comunicazioni e sicurezza informatica vengono trattati come superfici distinte, esattamente la scomposizione necessaria anche nell’assurance militare europea.
Percorsi di sabotaggio: dalla compromissione industriale all’attivazione sul campo
Un percorso di sabotaggio credibile deve essere valutato come una catena composta da accesso iniziale, acquisizione di privilegi, introduzione della modifica, persistenza, evasione dei controlli, attivazione e produzione dell’effetto. Il percorso S₁ può iniziare presso un subfornitore: compromissione della toolchain, inserimento di una libreria modificata, firma con credenziali valide e distribuzione attraverso il processo ufficiale. Il percorso S₂ utilizza la manutenzione: una workstation infetta altera parametri, firmware o log durante una sessione autorizzata. Il percorso S₃ sfrutta il bus interno: un modulo legittimo ma compromesso invia telemetria o comandi formalmente validi. Il percorso S₄ colpisce i sensori: spoofing o manipolazione della calibrazione produce una rappresentazione falsa che induce decisioni errate senza modificare il fire-control software. Il percorso S₅ agisce sul modello AI: backdoor o poisoning attivano un comportamento soltanto davanti a un trigger specifico, riducendo la probabilità di scoperta nei test ordinari. Il percorso S₆ sfrutta l’operatore: interfacce ambigue, alert saturati, fiducia eccessiva nell’automazione o informazioni manipolate trasformano l’essere umano nel vettore finale di un effetto preparato digitalmente. Nessuno di questi percorsi richiede necessariamente accesso remoto durante la missione. La Federazione Russa ha rafforzato nel dicembre 2025 i requisiti di notifica, risposta e interazione continua tra soggetti della critical information infrastructure e il sistema statale di rilevamento e risposta agli attacchi, confermando l’importanza attribuita alla continuità del monitoraggio e alla centralizzazione degli incidenti. FSB Order No. 547 on reporting and response to computer attacks and incidents – Federazione Russa – dicembre 2025 — pubblicazione ufficiale in russo. FSB Order No. 548 on continuous interaction with the state detection and response system – Federazione Russa – dicembre 2025 — pubblicazione ufficiale in russo. Tali atti non documentano sistemi militari robotici, ma evidenziano una tendenza geopolitica più ampia: le grandi potenze considerano la capacità di rilevare, riferire e contenere rapidamente gli incidenti come elemento della sovranità operativa. Per l’Italia, la risposta non dovrebbe essere una replica centralizzata del modello russo, ma una rete nazionale militare-industriale capace di correlare eventi di piattaforme, fornitori, laboratori e teatri operativi senza dipendere esclusivamente dai log controllati dal costruttore.
Outlook 2026–2031: dalla vulnerabilità del componente al rischio di flotta
Nel quinquennio 2026–2031, l’aumento del rischio non deriverà semplicemente da una crescita lineare del numero di sistemi robotizzati, ma dall’interazione di quattro trasformazioni: maggiore programmabilità, più frequenti aggiornamenti software, convergenza tra AI e autonomia, dipendenza crescente da supply chain transnazionali. La NATO sta accelerando l’adozione di AI, droni e sistemi autonomi e nel luglio 2026 ha ribadito che tali tecnologie stanno ridefinendo le capacità richieste per deterrenza e difesa. Innovation and Technology Adoption – NATO – luglio 2026 — pagina ufficiale verificata. Il vantaggio sarà una capacità più rapida di integrare sensori, algoritmi e funzioni; la vulnerabilità sarà una maggiore instabilità della baseline, perché la piattaforma cambierà nel tempo attraverso aggiornamenti, nuovi modelli, componenti sostituiti e software condiviso. Nel 2026–2027, il rischio dominante sarà la persistenza di sistemi legacy collegati a moduli moderni attraverso gateway non progettati per Zero Trust. Nel 2027–2028, crescerà l’esposizione delle pipeline di aggiornamento e dei dispositivi manutentivi, poiché l’agilità software richiederà cicli di rilascio più frequenti. Nel 2028–2029, l’integrazione di modelli AI al tactical edge renderà centrali model provenance, TEV&V e monitoraggio del drift. Nel 2029–2030, l’interoperabilità multinazionale moltiplicherà identità, standard, data space e dipendenze tra piattaforme di nazioni diverse. Nel 2030–2031, il rischio principale sarà il common-mode compromise: una vulnerabilità o un artefatto malevolo capace di colpire simultaneamente famiglie di sistemi che condividono firmware, librerie, modelli o strumenti diagnostici. La priorità strategica italiana deve quindi spostarsi dalla certificazione una tantum alla continuous assurance. Ogni configurazione operativa dovrebbe avere una firma univoca, un safety-security case aggiornato, registri di provenienza, risultati di test adversarial e una valutazione dell’impatto di flotta. La capacità di bloccare rapidamente una configurazione senza immobilizzare l’intera famiglia di mezzi diventerà una misura di prontezza pari alla disponibilità meccanica. In altre parole, la sovranità non consisterà soltanto nel possedere la piattaforma, ma nel poter dimostrare, aggiornamento dopo aggiornamento, che nessun dato, modello o componente possiede un percorso non controllato verso l’effetto fisico.
Figure 1: Evoluzione dei vettori cyber-fisici, 2026–2031
Indice prospettico normalizzato: 2026 = 100. Valori analitici di scenario, non frequenze empiriche.
Outlook 2026–2031 e sovranità operativa italiana nell’era dell’AI militare
La sovranità operativa non coincide più con la proprietà della piattaforma
Nel ciclo strategico 2026–2031, la sovranità militare italiana non potrà più essere misurata soltanto dal numero di piattaforme disponibili, dalla nazionalità del prime contractor o dalla capacità di produrre scafi, torrette, radar e munizionamento. Un sistema robotizzato o AI-enabled resta realmente sotto controllo nazionale soltanto quando la Difesa può determinare quale configurazione software stia operando, verificare l’origine di modelli e dati, ricostruire ogni decisione rilevante, interrompere autonomamente una funzione pericolosa e correggere una vulnerabilità senza attendere un fornitore estero o perdere la certificazione dell’intera piattaforma. La sovranità operativa deve pertanto essere definita come la combinazione di cinque poteri effettivi: conoscere l’architettura; autorizzarne le modifiche; verificarne il comportamento; negare funzioni non sicure; ripristinare una configurazione affidabile. Questa trasformazione è già riconosciuta dalla politica italiana. La Strategia della Difesa in materia di Intelligenza Artificiale, pubblicata il 26 febbraio 2026, qualifica l’adozione dell’AI come imperativo strategico e politico e richiede un’integrazione sistemica orientata verso sistemi avanzati, sicuri e resilienti; il successivo approfondimento istituzionale del 2 aprile 2026 collega esplicitamente tale strategia al rafforzamento della sovranità tecnologica e dell’autonomia strategica, individuando nel Laboratorio di Intelligenza Artificiale per la Difesa, LIAD, uno strumento per ridurre dipendenze critiche, creare sinergie con università e industria e mantenere il controllo umano. Strategia della Difesa in materia di Intelligenza Artificiale – Ministero della Difesa – febbraio 2026; Intelligenza Artificiale: ecco la strategia della Difesa – Ministero della Difesa – aprile 2026. Il passaggio decisivo, tuttavia, sarà trasformare queste finalità in obblighi tecnici contrattuali. Il controllo umano nominale perde significato quando l’operatore non può conoscere la provenienza dell’output, quando il modello è aggiornato da terzi, quando il registratore dipende dal medesimo software che deve controllare o quando l’arresto di emergenza condivide alimentazione e logica con il sistema compromesso. Entro il 2031, la distinzione strategica non sarà dunque tra piattaforme nazionali ed estere, ma tra capacità ispezionabili e governabili e capacità acquistate come scatole nere.
| Potere sovrano | Domanda operativa | Evidenza minima necessaria |
|---|---|---|
| Conoscere | Quali componenti, dati e modelli stanno operando? | SBOM, HBOM, model card, distinta delle configurazioni |
| Autorizzare | Chi può modificare software, pesi o parametri? | Autorità di configurazione e chiavi nazionali |
| Verificare | Il sistema rispetta requisiti e limiti? | TEV&V indipendente, red teaming, fault injection |
| Negare | La Difesa può disattivare una funzione rischiosa? | Kill switch e interlock indipendenti |
| Ripristinare | È possibile tornare a una baseline sicura? | Build riproducibili, recovery offline, immagini firmate |
| Attribuire | È ricostruibile la sequenza decisionale? | Logging append-only e timestamp indipendenti |
Governance militare dell’AI: dall’enunciazione etica all’autorità di configurazione
La governance italiana dell’AI militare dovrà evitare due estremi simmetrici: una regolazione tanto astratta da non incidere sulle piattaforme e una frammentazione nella quale ogni Forza armata, direzione tecnica o programma definisce autonomamente criteri diversi. La NATO ha adottato sei Principi di uso responsabile—legalità, responsabilità e accountability, spiegabilità e tracciabilità, affidabilità, governabilità e mitigazione dei bias—e la strategia riveduta del luglio 2024 richiede standard, assessment template, processi di revisione, capacità di Testing, Evaluation, Verification and Validation, interoperabilità e protezione contro l’impiego avversario dell’AI. Summary of NATO’s Revised Artificial Intelligence Strategy – NATO – luglio 2024. Il Data and Artificial Intelligence Review Board dell’Alleanza è stato concepito per trasformare tali principi in standard e pratiche comuni e costruire fiducia tra militari, innovatori e opinione pubblica. NATO’s Data and Artificial Intelligence Review Board – NATO – ottobre 2022. Per l’Italia, questo modello dovrebbe tradursi in una National Defence AI Assurance Authority distribuita ma unitaria, non necessariamente una nuova agenzia burocratica, bensì una funzione dotata di indipendenza tecnica rispetto all’ufficio che acquisisce e al contraente che sviluppa. Essa dovrebbe mantenere un registro classificato dei sistemi AI, assegnare livelli di criticità, approvare i piani di TEV&V, stabilire le soglie per l’intervento umano, controllare l’autorità di aggiornamento e ordinare il fermo tecnico quando una baseline non è più affidabile. La governance dovrebbe distinguere almeno quattro categorie: AI amministrativa; AI di supporto logistico o intelligence; AI integrata in funzioni operative; AI con influenza diretta o indiretta su effetti fisici e cinetici. L’errore da evitare consiste nel classificare un algoritmo soltanto in base alla sua etichetta commerciale. Un modello presentato come “supporto decisionale” può esercitare autorità sostanziale quando ordina bersagli, determina priorità, filtra ciò che l’operatore vede o controlla il tempo disponibile per decidere. La valutazione deve quindi riguardare l’autorità causale reale, non la denominazione formale. Ogni sistema dovrebbe possedere un responsabile operativo, uno tecnico e uno per l’assurance; nessuna delle tre funzioni dovrebbe poter certificare da sola la sicurezza dell’intera catena.
Il LIAD come infrastruttura di sovranità e non semplice laboratorio di innovazione
Il LIAD può diventare l’elemento centrale della sovranità operativa italiana soltanto se viene progettato come infrastruttura nazionale di verifica, non come incubatore di dimostrazioni tecnologiche. Il suo valore strategico dipenderà dalla capacità di ricevere sistemi reali, dati rappresentativi, versioni operative dei modelli e accesso alla catena di sviluppo; eseguire test adversariali; riprodurre build; simulare perdita di sensori e connettività; valutare il comportamento fuori distribuzione; e certificare non soltanto l’accuratezza media ma i limiti, i fallback e le modalità di arresto. La Difesa ha già incluso l’AI tra le priorità del Piano Nazionale della Ricerca Militare 2026, menzionando comando e controllo, ISTAR, sicurezza, combat support, sistemi autonomi, data management, logistica, addestramento e image/video analytics. Avviso apertura Call PNRM 2026 – Ministero della Difesa – 2025. Sono inoltre documentate attività contrattuali italiane riguardanti prototipi nell’ambito di una campagna di sperimentazione su Robotics & Autonomous Systems e AI, con una variante approvata nel maggio 2026, mentre i dati sull’esecuzione non sono pubblicati per ragioni di sicurezza nazionale. Prototipi nell’ambito della Campagna di sperimentazione su RAS e AI – Ministero della Difesa – gennaio/maggio 2026. Questo conferma che l’Italia è già entrata nella fase sperimentale; il problema del prossimo quinquennio sarà impedire che sperimentazione e acquisizione procedano più rapidamente dell’assurance. Il LIAD dovrebbe quindi operare come national range for military AI, collegato ai centri DIANA e alle strutture NATO, ma capace di mantenere dati classificati, modelli sovrani e test nazionali. Dovrebbe disporre di digital twin, hardware-in-the-loop, banchi elettromagnetici, cyber range, ambienti di guerra elettronica e capacità di testare sistemi uomo-macchina. Per evitare dipendenza dal produttore, la Difesa dovrebbe poter ricostruire autonomamente almeno le componenti critiche del processo di validazione, verificare firme, rieseguire dataset di prova e confrontare una release con la precedente. Un laboratorio privo di accesso ai pesi, alla telemetria e ai log reali rischierebbe di certificare una rappresentazione dimostrativa, non la capacità schierata.
Assurance industriale: la responsabilità non termina con la consegna
L’assurance industriale dovrà diventare una funzione permanente che attraversa progettazione, produzione, impiego, manutenzione e dismissione. Il tradizionale collaudo di accettazione è insufficiente per sistemi che cambiano mediante aggiornamenti software, nuovi dataset, modelli retrained, componenti sostitutivi e librerie di terze parti. Ogni modifica può alterare la superficie d’attacco o invalidare conclusioni precedenti senza cambiare esteriormente la piattaforma. Il principio necessario è quello della continuous certification: non una ricertificazione burocratica completa a ogni patch, ma un meccanismo basato sull’impatto che stabilisca quali test devono essere rieseguiti quando cambia un componente, un parametro o una dipendenza. La Direzione Nazionale degli Armamenti ha il compito istituzionale di tradurre gli indirizzi politico-amministrativi e tecnico-operativi in attività industriali, ricerca, sperimentazione e approvvigionamento, e si presenta come nodo della partnership tra Difesa e industria. Direzione Nazionale degli Armamenti: chi siamo – Ministero della Difesa – consultato luglio 2026. Nel nuovo paradigma, questa partnership deve mantenere collaborazione senza produrre dipendenza epistemica: il fornitore non può essere l’unico soggetto capace di spiegare, testare e certificare il proprio prodotto. I contratti dovrebbero imporre Software Bill of Materials, Hardware Bill of Materials, provenienza dei dataset, documentazione dei modelli, gestione delle vulnerabilità, accesso controllato al codice critico, conservazione delle toolchain, build riproducibili, escrow delle chiavi e diritto di audit sui subfornitori. Per i componenti più sensibili, lo Stato dovrebbe possedere una capacità di “second source” o almeno di sostituzione progressiva. Le responsabilità industriali devono inoltre coprire i rischi derivanti da modelli general-purpose e tecnologie dual use: quando una componente commerciale viene integrata in una funzione militare, il prime contractor deve dimostrare non solo che funziona, ma che il suo ciclo di aggiornamento, le dipendenze cloud, le licenze e le interfacce sono compatibili con la continuità operativa. La sovranità non richiede necessariamente autarchia tecnologica, ma richiede che nessun singolo fornitore possa rendere indisponibile, opaca o non correggibile una capacità essenziale.
| Requisito di assurance | Prima della firma | Durante lo sviluppo | Dopo il dispiegamento |
|---|---|---|---|
| Architettura | Accesso e diritti di audit | Threat modelling | Aggiornamento dell’attack surface |
| Software | SBOM e licenze | Secure development | Vulnerability management |
| AI | Provenienza di dati e modelli | Red teaming e TEV&V | Drift e incident monitoring |
| Hardware | Provenienza e second source | Test di integrità | Controllo dei ricambi |
| Configurazione | Baseline contrattuale | Build riproducibile | Firma di ogni release |
| Responsabilità | Matrice RACI | Registro delle decisioni | Obblighi post-consegna |
Deterrenza cyber: negazione, resilienza e attribuzione tecnica
La deterrenza cyber applicata ai sistemi militari robotizzati non può basarsi soltanto sulla minaccia di una risposta offensiva, perché l’attribuzione di un’anomalia embedded o di supply chain può richiedere settimane o mesi e rimanere probabilistica. La prima componente deve essere la deterrenza per negazione: rendere l’attacco costoso, incerto e incapace di produrre un effetto strategico. Ciò implica segmentazione, identità hardware, aggiornamenti firmati, interlock indipendenti, diversità delle configurazioni, monitoraggio continuo e capacità di degradare in modo sicuro. La seconda componente è la deterrenza per resilienza: un avversario deve sapere che la compromissione di un componente non immobilizzerà l’intera flotta, che l’Italia può isolare una release, ripristinare una baseline e continuare l’operazione con modalità ridotte. La terza è la deterrenza per attribuzione tecnica e politica: registratori indipendenti, telemetria forense, cooperazione con NATO e UE, intelligence sulla supply chain e procedure comuni di incident disclosure devono permettere di trasformare un sospetto in un dossier utilizzabile per sanzioni, contromisure, azioni giudiziarie o risposta collettiva. La strategia NATO riveduta riconosce l’esigenza di proteggere e monitorare le tecnologie AI, gestire i rischi e difendersi dall’uso avversario, includendo previsione strategica, standard e testing. L’Italia dovrebbe aggiungere una National Military AI Incident Cell, con partecipazione della Difesa, dell’Agenzia per la Cybersicurezza Nazionale, dell’intelligence, dell’industria e dei laboratori, capace di correlare eventi su piattaforme diverse senza divulgare dati operativi. La deterrenza richiede infatti conoscenza aggregata: anomalie isolate possono apparire casuali, mentre la correlazione tra versioni, fornitori, date e teatri può rivelare una campagna. Per ridurre il rischio di sabotaggio common-mode, alcune funzioni critiche dovrebbero mantenere diversità tecnologica e geografica, evitando che un’unica toolchain, chiave o piattaforma cloud diventi punto di collasso nazionale. La resilienza deve essere testata in esercitazioni nelle quali la Difesa simula la perdita di fiducia in un fornitore, in una famiglia di firmware o in un modello AI, misurando il tempo necessario per identificare le piattaforme interessate, limitarne le funzioni e ristabilire capacità sicure.
Responsabilità tecnica: chi risponde quando la decisione è distribuita
L’introduzione dell’AI militare rischia di creare una responsibility gap non perché manchino soggetti coinvolti, ma perché ve ne sono troppi e ciascuno controlla soltanto una porzione della catena. L’operatore può aver seguito correttamente l’interfaccia; il comandante può aver autorizzato la missione; il program office può aver accettato la piattaforma; il prime contractor può aver integrato un modello di terzi; il fornitore del modello può aver escluso l’uso militare dalle proprie garanzie; il manutentore può aver installato una configurazione ufficiale; il software può aver prodotto un output formalmente conforme ma operativamente errato. Per evitare che la complessità dissolva l’accountability, ogni capacità deve possedere una catena di responsabilità tecnica nominativa. Il principio NATO di responsibility and accountability richiede che la responsabilità umana sia mantenuta durante sviluppo e impiego; explainability e traceability impongono inoltre la possibilità di ricostruire decisioni, dataset, processi e tecnologie. In Italia, questo principio dovrebbe essere tradotto in cinque ruoli distinti: Mission Authority, responsabile dell’uso operativo; Technical Design Authority, responsabile dell’architettura; Configuration Authority, responsabile della release; AI Assurance Officer, responsabile della valutazione indipendente; Industrial Accountable Executive, responsabile delle dichiarazioni tecniche del contraente. Nessuna funzione dovrebbe poter trasferire integralmente la responsabilità a un algoritmo o a un subfornitore. Per i sistemi con influenza cinetica, l’approvazione dovrebbe includere una dichiarazione esplicita dei limiti operativi: ambiente, sensori richiesti, qualità minima dei dati, connettività, tipi di bersaglio, soglie di confidenza e condizioni di arresto. Quando il sistema opera fuori da tali limiti, il comportamento deve essere considerato non autorizzato anche se tecnicamente possibile. La registrazione deve permettere una revisione post-missione senza creare un rischio di sorveglianza indiscriminata o esposizione dei dati classificati. La responsabilità industriale, infine, deve sopravvivere alla consegna: vulnerabilità note non comunicate, dipendenze non dichiarate, aggiornamenti non verificati e perdita delle toolchain devono produrre conseguenze contrattuali concrete, perché altrimenti il costo del rischio viene trasferito interamente allo Stato.
Trasformazione degli acquisti: dal requisito prestazionale al diritto di controllo
La trasformazione più profonda dovrà avvenire nel procurement. Il modello tradizionale definisce prestazioni, quantità, tempi, supporto e costo; nel periodo 2026–2031 dovrà acquistare anche diritti tecnici, capacità di verifica e libertà di sostituzione. Il Documento Programmatico Pluriennale della Difesa 2025–2027 resta il documento pubblico di riferimento mentre, al 9 luglio 2026, la documentazione programmatica 2026 risulta ancora in elaborazione nella pagina istituzionale. Documenti di programmazione – Ministero della Difesa – aggiornamento luglio 2026. Le programmazioni triennali delle acquisizioni mostrano che il processo italiano continua a essere articolato tra molteplici direzioni e Forze armate, circostanza fisiologica ma potenzialmente problematica per tecnologie trasversali come AI, cloud, data fabric e autonomia. Programmazione triennale degli acquisti di beni e servizi – Ministero della Difesa, TELEDIFE – aggiornamento giugno 2026. L’Italia dovrebbe introdurre un AI and Cyber-Physical Procurement Annex obbligatorio per ogni programma che incorpori automazione, robotica o software ad alta criticità. L’annesso dovrebbe contenere: matrice di autorità causale; requisiti di logging; diritti sul codice e sui dati; criteri di TEV&V; politica di aggiornamento; responsabilità post-consegna; exit plan dal fornitore; diversificazione della supply chain; tempi massimi di patching; modalità di incident disclosure; e costo del ciclo di assurance. La valutazione delle offerte dovrebbe assegnare punteggi non soltanto a prezzo e prestazione, ma a verificabilità, modularità, sostituibilità e riduzione delle dipendenze. Un prodotto apparentemente più economico può risultare strategicamente più oneroso se richiede cloud proprietario estero, impedisce audit, blocca l’accesso ai log o rende ogni aggiornamento dipendente da una singola azienda. Il contratto dovrebbe inoltre separare l’accettazione della funzione dall’autorizzazione all’impiego: una capacità può essere consegnata e testata senza essere immediatamente abilitata in tutti gli scenari operativi. Questa distinzione permetterebbe innovazione più rapida senza ridurre la disciplina dell’assurance.
Il quadro europeo: opportunità finanziaria e rischio di dipendenza collettiva
La trasformazione italiana avverrà all’interno di una fase di espansione senza precedenti degli strumenti europei per la difesa. Lo strumento SAFE, entrato in vigore il 29 maggio 2025, mette a disposizione fino a 150 miliardi di euro in prestiti per investimenti e appalti comuni, con l’obiettivo di aumentare rapidamente produzione, disponibilità delle capacità e base tecnologica e industriale europea. SAFE: il Consiglio approva uno stimolo di 150 miliardi di euro – Consiglio dell’Unione europea – maggio 2025. La Strategia industriale europea della difesa stabilisce inoltre obiettivi al 2030: almeno il 40% degli equipaggiamenti acquistato in collaborazione; almeno metà dei bilanci di procurement spesa in prodotti realizzati in Europa; almeno il 35% del commercio di beni per la difesa effettuato tra Stati membri. Prima Strategia industriale europea della difesa – Commissione europea – marzo 2024. Nel maggio 2026, i ministri della Difesa dell’UE hanno inoltre approvato il primo passo di un rafforzamento triennale dell’Agenzia europea per la difesa, comprendente maggiore ricerca e innovazione, una struttura dedicata al procurement collaborativo e un ruolo più centrale nello sviluppo delle capacità. Ministers of Defence pave the way for a stronger European Defence Agency – EDA – maggio 2026. Per l’Italia, questi strumenti offrono scala, accesso a finanziamenti e possibilità di incidere sugli standard; presentano però un rischio: sostituire la dipendenza nazionale da un fornitore con una dipendenza europea condivisa ma altrettanto opaca. Un programma comune che utilizzi un’unica toolchain, un unico modello o una sola infrastruttura cloud può creare un punto di fallimento continentale. Roma dovrebbe pertanto promuovere European sovereign assurance, non soltanto European content: diritti di audit reciproci, laboratori federati, formati aperti, identità interoperabili, registri delle dipendenze e possibilità per ciascuno Stato di isolare una funzione. L’obiettivo non deve essere produrre tutto in Italia, ma impedire che l’accesso alla capacità italiana dipenda da decisioni unilaterali esterne.
Un modello operativo italiano per il 2031
Il modello consigliato per il 2031 è un sistema a quattro cerchi. Il primo è la governance, con politica nazionale, classificazione della criticità, registro dei sistemi e autorità di configurazione. Il secondo è l’assurance, con LIAD, laboratori delle Forze armate, università selezionate, industria e connessione ai test centre NATO; il loro compito è verificare comportamento, sicurezza e governabilità. Il terzo è la resilienza operativa, con registrazione forense, gestione delle vulnerabilità, capacità di rollback, diversità delle configurazioni e incident response. Il quarto è la sovranità industriale, con controllo delle dipendenze, diritti contrattuali, disponibilità di competenze e possibilità di sostituzione. Per misurare i progressi, la Difesa dovrebbe pubblicare—nei limiti della classificazione—indicatori aggregati: percentuale di sistemi AI registrati; quota sottoposta a TEV&V indipendente; tempo medio di isolamento di una release vulnerabile; percentuale di componenti critici con second source; numero di incidenti e near miss analizzati; quota di aggiornamenti con build riproducibile; percentuale di sistemi cinetici dotati di interlock indipendente. Il modello deve essere sostenuto da personale tecnico con carriere competitive, perché la sovranità documentale senza competenza interna resta nominale. La formazione non può limitarsi a pochi specialisti: comandanti, procurement officer, manutentori, operatori, legali e auditor devono comprendere limiti e implicazioni dell’automazione. La strategia italiana del 2026 afferma la necessità di integrare l’AI rapidamente e sistematicamente; il successo dipenderà dalla capacità di associare la velocità a un sistema di controllo altrettanto rapido. Entro il 2031, una piattaforma dovrebbe poter essere interrogata come un asset digitale: quale versione opera, quali dipendenze contiene, quale autorità l’ha approvata, quale test ha superato, quali vulnerabilità restano aperte, quale modalità ridotta è disponibile e chi può interrompere la funzione. La vera autonomia strategica italiana emergerà quando queste risposte non dipenderanno dalla buona volontà del fornitore, ma saranno incorporate nell’architettura istituzionale, tecnica e contrattuale della Difesa.
| Fase | Priorità nazionale | Risultato verificabile |
|---|---|---|
| 2026–2027 | Registro AI, tassonomia di criticità, autorità di configurazione | Inventario delle capacità e responsabilità nominate |
| 2027–2028 | LIAD operativo come centro TEV&V | Test indipendenti su sistemi reali |
| 2028–2029 | Nuove clausole standard di procurement | SBOM, model provenance, audit ed exit plan |
| 2029–2030 | Federazione con NATO ed EDA | Mutuo riconoscimento e test interoperabili |
| 2030–2031 | Continuous assurance di flotta | Aggiornamenti controllati e isolamento rapido |
| Dopo il 2031 | Sovranità verificabile | Nessun effetto critico affidato a una black box |
Figure 1: Traiettoria della sovranità operativa italiana, 2026–2031
Indici prospettici normalizzati, 2026 = 100. La curva del rischio residuo diminuisce soltanto nello scenario di piena attuazione delle misure proposte.
