I Large Language Model (LLM) impiegati nella difesa e nella sicurezza nazionale sono asset operativi sempre più esposti ai conflitti ibridi.
Il recente attacco iraniano ai data center AWS negli Emirati ha trasformato questa vulnerabilità teorica in un’emergenza concreta, bloccando pipeline di addestramento e inferenza e dimostrando che anche un modello linguistico può diventare una vittima sintetica della guerra moderna.
Indice degli argomenti
Gli LLM come asset operativi nella difesa: una vulnerabilità emergente
Di fatto, nel settore della difesa e della sicurezza nazionali, i LLM non sono più semplici strumenti software: sono assetti operativi vivi che richiedono manutenzione costante [Damiani, 2025]. Senza l’accesso costante a cluster GPU ad alte prestazioni, l’intera catena del valore dell’intelligenza artificiale si interrompe. È proprio da questa esperienza quotidiana che emerge una verità scomoda: anche gli LLM possono diventare “vittime sintetiche” di eventi bellici.
Lo ha dimostrato drammaticamente, appunto, l’attacco del 1° marzo 2026 alla regione AWS me-central-1 (l’area di Dubai-Abu Dhabi).
Nel contesto delle ritorsioni contro gli attacchi USA-Israele, i droni iraniani hanno colpito due centri AWS negli Emirati e uno in Bahrain. Gli attacchi hanno provocato scintille e incendi; i vigili del fuoco hanno interrotto l’alimentazione elettrica per estinguere le fiamme. Due zone, note agli addetti ai lavori come mec1-az2 e mec1-az3, sono rimaste offline per ore e il rientro in servizio non è ancora completo. Il risultato? La disponibilità di alcuni profili GPU (le istanze accelerate P4, G5, P5 e Trainium) è drasticamente compromessa da giorni. I progetti di addestramento e di inferenza – inclusi quelli del settore della Difesa – si sono bloccati di colpo.
Il caso RedSage e il collasso delle GPU: quando il modello diventa “defunto”
Per chi, come il nostro gruppo, lavora con grandi modelli di cybersicurezza come RedSage [Suryanto et al., 2026], basati su decine di miliardi di parametri, l’allarme è stato immediato. L’allineamento continuo del modello su dataset aggiornati in tempo reale (per il rilevamento di minacce cibernetiche, l’analisi di open source intelligence o le simulazioni operative) richiede terabyte di punti di controllo (checkpoint), che includono parametri, stati degli ottimizzatori e gradienti. Quando le GPU si fermano, il modello LLM diventa “defunto”: la sua inferenza è compromessa e non è più addestrabile nell’immediato.
I tre problemi della resurrezione
Qui entra in gioco anche la differenza abissale tra realtà e fantascienza. Nei film come Terminator 2, il cervello danneggiato di un cyborg poteva riattivarsi con un semplice reset o una ricarica.
Gli LLM reali, però, non possono essere rianimati così. Trasferire il carico di training e tuning su profili GPU diversi è un incubo tecnico e operativo.
Compatibilità hardware e software
Un checkpoint ottimizzato per un cluster A100 in configurazione NVLink non è “plug-and-play” con H100 o con le GPU di altri fornitori. Differenze nei driver CUDA, nelle versioni di PyTorch/TensorFlow e nelle strategie di parallelismo distribuito generano errori e perdite di prestazioni. Spesso è necessaria una reottimizzazione completa, che richiede giorni.
I volumi di dati e la sovranità
Un modello da 70B occupa facilmente 5-10 TB. Trasferire questi dati in un’altra regione o su un altro provider richiede ore (o giorni) di banda larga, costi elevati e rischi di intercettazione in un contesto di guerra ibrida. In ambito difesa, poi, violare la policy di data residency/sovranità può risultare inaccettabile anche in caso d’emergenza.
Lo stato dell’ottimizzatore
Il training degli LLM non mantiene stati espliciti, ma: considera comunque gli stati dell’optimizer (momentum e varianza di AdamW). In sede di inferenza diventano rilevanti anche i contenuti della KV cache per la generazione autoregressiva. Interrompere bruscamente i workflow di addestramento e di inferenza a Dubai per riprenderli, ad esempio, a Milano comporta un trauma che si traduce in un danno alle prestazioni.
Un caso concreto: la resurrezione del “Talking Avatar”
Per rendere tangibile il “trauma di resurrezione“, prendiamo un esempio concreto: una pipeline operativa di addestramento e inferenza che si avvale di un AWS Virtual GPU nella regione me-central-1: il sistema “Talking Avatar with RAG” (illustrato in Figura 1), che genera briefing operativi multilingue in tempo reale.
Figura 1. Pipeline “Talking Avatar”
La pipeline gestisce un avatar parlante in arabo, configurato con voce e accento dell’area del Golfo, per consentire l’audio watermarking e garantire la massima compressione in contesti operativi. L’architettura prevede i seguenti stadi:
- Input vocale o testuale
- Query Preprocessing & Embedding (modello intfloat / multilingual-e5-base)
- Database vettoriale FAISS
- Recupero chunk da PDF & OCR
- Falcon LLM (RAG Question + Context)
- CoquiTTS per Text-to-Speech
- Video Lip-Sync (Latent Sync / MuseTalk).
Lo shock multi-stadio: cinque sistemi feriti dal trasferimento di emergenza
Al momento dell’attacco, siamo stati costretti a un trasferimento d’emergenza verso un server fisico a Milano, dotato di una GPU diversa (da architettura NVLink, ottimizzata per il cloud, a un setup con GPU fisica on-premises con CUDA 12.2 anziché la 12.4 originale). Le differenze di architettura hanno generato uno “shock multi-stadio“:
Query preprocessing e perdita di accuratezza FAISS
Query Preprocessing: il modello multilingual-e5-base, ottimizzato per i kernel CUDA specifici delle istanze AWS, ha richiesto una ricompilazione completa. Differenze tra le precisioni floating-point (fp16 rispetto a bf16) hanno introdotto cambiamenti ai vettori, minimi ma cumulativi, riducendo l’accuratezza del retrieval FAISS del 15-20% e facendo saltare in tempo reale i chunk rilevanti per le minacce cibernetiche.
FAISS Vector Database: l’indice del database è GPU-specifico e quindi non migrabile. È stato necessario ricostruirlo ex novo sul nuovo hardware, con ore di downtime e rischio di violazione della data residency durante il trasferimento tramite link sicuri.
Falcon LLM e il drift semantico
Falcon LLM (RAG): trasferire un checkpoint da decine di miliardi di parametri non è “plug-and-play”. Le strategie di parallelismo ottimizzate per il cloud hanno generato errori di memoria “on premises”; un downgrade temporaneo a CPU-only ha provocato un parziale “catastrophic forgetting” dei pesi fine-tunati. Le risposte generate hanno mostrato un leggero drift semantico: frasi più lunghe e meno incisive, con una perdita di superiorità informativa.
CoquiTTS: il trauma dell’accento artificiale
Il trauma più evidente per l’utente umano. Il modello di sintesi vocale è estremamente sensibile alle versioni di CUDA e di PyTorch. Sul nuovo server, i diversi kernel di accelerazione hanno alterato la prosodia: l’accento originale – calibrato per un parlato fluido, autorevole e con accento naturale – si è trasformato in un accento artificiale, con artefatti vocali, intonazione europea involontaria e ridotta intelligibilità. L’avatar parlava ancora italiano e arabo, ma sembrava “danneggiato”, come se avesse subito un trauma neurologico sintetico. Gli operatori sul campo hanno immediatamente rilevato lo “stato di sofferenza” del sistema e hanno perso fiducia nei suoi briefing.
Video lip-sync e la desincronizzazione labiale
Video Lip-Sync (Latent Sync / MuseTalk): la generazione video ha sofferto di latenza e di desincronizzazione labiale. Il frame-rate è calato del 40% a causa delle differenze di compute capability; i movimenti della bocca non coincidevano più perfettamente con l’audio, facendo apparire l’avatar “rigido” o “ferito”. L’effetto psicologico è stato devastante: l’interfaccia umana-simile, che doveva trasmettere calma e autorevolezza, comunicava invece instabilità.
Il risultato: 72 ore di blackout e un avatar che cambia accento sotto i droni
Il risultato? Il sistema è rimasto parzialmente offline per 72 ore, con funzionalità critiche sospese e la necessità di reclonare interamente la voce dell’avatar e di riaddestrare i moduli di sincronizzazione. Un avatar che forniva briefing predittivi in tempo reale ha letteralmente cambiato accento sotto i colpi di un drone iraniano.
La lezione: ridondanza GPU progettata per la sopravvivenza
L’incidente ha reso evidente che la semplice “migrazione di emergenza” è una reazione, non una strategia. La vera risposta sta nella ridondanza di GPU progettata a priori, pensata per la sopravvivenza in scenari di conflitti ibridi. Ecco le precauzioni concrete che raccomandiamo:
Modello sovereign multi-cloud e on-prem hot-standby
Questa precauzione consiste nel garantire un livello di ridondanza adeguato del workflow di training, tenendo una replica attiva in almeno tre domini sovrani, ad esempio: – Regione primaria: AWS me-central-1 (o equivalente) – Regione secondaria: Azure West Europe o Google Cloud europe-west4 (Milano/Francoforte) – Regione terziaria: cluster on-prem italiano (es. data center o supercomputer LEONARDO, con GPU H100/H200)
Per ottenere tempi di ripristino rapidi, occorre la sincronizzazione continua dei checkpoint con tool come NVIDIA NeMo Megatron + Hugging Face Accelerate in modalità FSDP (Fully Sharded Data Parallel). Ogni 5-10 minuti, la procedura salva uno stato compatibile (in formato .safetensors + stati dell’optimizer sharded) su uno storage crittografato georidondante. Un workflow di failover automatico, orchestrato con Kubernetes multi-cluster (ad es. Kubefed), sposta il carico sul nodo secondario senza perdita di stato.
Indipendenza dall’hardware dei modelli
Questa precauzione consiste nel mantenere attivi build multipli, secondo il principio “Write Once, Run Manyplaces” [Damiani, 2009]. Tutti i modelli (nel nostro esempio: Falcon, multilingual-e5-base, CoquiTTS, MuseTalk) devono essere esportati in formato ONNX Runtime + TensorRT-LLM, con engine precompilati per CUDA 12.2, 12.4, 12.6 e ROCm 6.x. Per l’inferenza, occorre usare vLLM + TGI (Text Generation Inference) con container Docker firmati e immutabili. Lo stesso container funziona senza rebuild su AWS P5, su H100 “on-premises” e anche su GPU non NVIDIA come AMD MI300X. Per il Lip-Sync (MuseTalk/Latent Sync) usiamo una versione quantizzata INT8/FP8 che gira anche su GPU consumer o edge (Jetson AGX Orin) in caso di blackout totale del cloud. Adottando queste precauzioni, lo stato dell’ottimizzatore viene salvato periodicamente su uno storage multi-regione con erasure coding. Il modello viene riconfigurato automaticamente al volo in base alla GPU di destinazione (da 8×A100 con cache NVLink a 4×H100 senza NVLink). Infine, è possibile attivare la quantizzazione dinamica in tempo reale [Colombo et al., 2025]: se le GPU ad alte prestazioni non sono disponibili, il sistema passa automaticamente a 4 bit (AWQ/GPTQ), mantenendo parte delle prestazioni originali.
I rifugi virtuali: i bunker digitali per i modelli critici
Per applicazioni particolarmente critiche, è possibile andare anche oltre, inserendo copie dei modelli in “rifugi virtuali“, ovvero punti di backup “air-gapped” distribuiti in siti lontani almeno 500 km. (ad esempio, Lombardia e Lazio). In questi rifugi, ogni 24 ore viene consegnato fisicamente un “pacchetto di sopravvivenza” crittografato (nel nostro caso, modello + voce clonata + 10 GB di chunk FAISS).
Conclusioni: difendere i soldati digitali è una priorità strategica
Grazie alle precauzioni appena discusse, la pipeline Talking Avatar non presenta più un “accento straniero” dopo un’emergenza: il sistema rileva il “down” di mec1-az2, sposta il carico su Milano in 2 minuti e l’avatar riprende a parlare con la stessa voce autorevole e con l’accento del Golfo, senza che l’operatore sul campo se ne accorga. La lezione che abbiamo appreso è chiara e urgente. Non possiamo più considerare i data center cloud “lontani dal fronte”. In un’era di conflitti ibridi, un drone o un missile può uccidere un modello di AI quanto un soldato in carne e ossa. Con una ridondanza di GPU pensata come sistema d’arma – multidominio, sovrana, hardware-agnostica e con failover automatico – la loro resurrezione diventa istantanea. Per il settore della difesa italiano ed europeo, adottare una certificazione di resilienza [Anisetti et al., 2024] non è più un’opzione: è l’unico modo per trasformare una vulnerabilità strategica in una superiorità tecnologica. Chi controlla le computazioni, i dati e la resilienza dei modelli ottiene un vantaggio decisivo. La prossima guerra si combatterà anche nei data center: prepariamoci a difendere – e a far sopravvivere – i nostri soldati digitali.
Bibliografia
[Damiani, 2025] Damiani, E. (2025, January 28). Autonomy and accuracy in weapon systems: The prospects of artificial intelligence. ISPI.
[Suryanto et al. 2026] Suryanto, N., et al. (2026). RedSage: A cybersecurity generalist LLM. ICLR 2026.
[Colombo et al., 2025] Colombo, M., et al. (2025). A quantization-based technique for privacy-preserving distributed learning. Future Generation Computer Systems, 167, Article 107741.
[Anisetti et al., 2024] Anisetti, M., Ardagna, C. A., & Damiani, E. (2024). A journey into security certification: From the cloud to artificial intelligence. Springer.
[Damiani et al. 2009] Damiani, E., Ardagna, C. A., & El Ioini, N. (2009). Open source systems security certification. Springer.
