La sicurezza dei dati governativi non è più una questione di collocazione fisica. Il caso KA-SAT, la migrazione ucraina in cloud, l’interruzione di servizi decisa da un fornitore nel settembre 2025, gli appalti cloud della NATO e la frontiera dei data center orbitali mostrano che la sovranità digitale si scompone in tre problemi distinti: riservatezza, disponibilità, integrità procedurale; con avversari diversi e rimedi che non si sostituiscono a vicenda.
Un bilancio degli strumenti europei suggerisce che uno solo dei tre sia stato trattato come questione di potere.
Indice degli argomenti
Cloud militare e sovranità digitale: la lezione di KA-SAT
Il 24 febbraio 2022, poche ore prima che le colonne corazzate russe attraversassero il confine ucraino, decine di migliaia di modem satellitari smisero di funzionare in mezza Europa. L’obiettivo era la rete KA-SAT, controllata da Viasat e con infrastruttura di terra operata da Skylogic, utilizzata anche dalle comunicazioni militari ucraine.
La ricostruzione tecnica, pubblicata poche settimane dopo, ha una qualità quasi didascalica: l’attaccante ha sfruttato un’appliance VPN mal configurata per entrare nel segmento di gestione fidato della rete, si è mosso lateralmente fino al segmento operativo e da lì ha impartito comandi legittimi che hanno distribuito sui terminali degli utenti un wiper (battezzato AcidRain) progettato per sovrascrivere la memoria flash dei modem SurfBeam2. Unione Europea, Regno Unito e Stati Uniti hanno formalmente attribuito l’operazione alla Russia nel maggio successivo.
Vale la pena fissare due dettagli, perché entrambi verranno traditi da quasi tutte le narrazioni successive. Il primo: non fu un attacco spaziale. Il satellite non fu toccato, tantomeno l’infrastruttura orbitale. Fu un’operazione contro il segmento di terra, cioè contro la parte più noiosa e meno fotogenica di qualunque architettura satellitare, la rete di gestione. Il secondo: l’effetto più citato, la perdita di controllo remoto su circa 5.800 turbine eoliche di un costruttore tedesco, non fu un blackout. Le turbine continuarono a produrre energia; ciò che si interruppe fu la capacità di sorvegliarle e comandarle a distanza. Non un danno fisico, ma la recisione di un legame informativo.
Da questi due dettagli discende tutto il resto. Un errore di configurazione in un apparato di rete ha attraversato i domini commerciale, militare ed energetico, producendo simultaneamente un effetto tattico in Ucraina, un effetto industriale in Germania e un effetto contrattuale su migliaia di clienti in Polonia, Italia e Francia. Nessuna delle categorie con cui siamo abituati a pensare la sicurezza dei dati (il confine, la classifica di segretezza, il perimetro fisico) ha svolto in quel frangente alcuna funzione utile.
Dal bunker al Joint Warfighting Cloud Capability
È a questo punto, e non prima, che si può liquidare l’immagine del bunker. Per decenni la sicurezza dei dati governativi è stata pensata come questione di collocazione: server blindati e isolati dalla rete pubblica sepolti in basi sotterranee rigorosamente entro i confini nazionali. Quell’architettura oggi è obsoleta perché è cambiata la funzione che i dati devono svolgere. Le operazioni multidominio, l’analisi automatizzata dei flussi sensoristici e la condivisione in tempo reale con gli alleati richiedono che il dato circoli, e un dato che circola non può essere difeso da un perimetro fisico.
Il Joint Warfighting Cloud Capability del Pentagono, aggiudicato nel dicembre 2022 ad Amazon, Microsoft, Google e Oracle con un tetto di nove miliardi di dollari, segnala che il punto di non ritorno è stato superato, e i numeri dicono che non si tratta di retorica dell’annuncio. Gli ordini emessi sul veicolo superavano i tre miliardi di dollari nell’estate del 2025, con l’Aeronautica ancora in fase di onboarding. In poco più di tre anni è stato consumato oltre un terzo della capienza contrattuale: la dipendenza è oggi una posizione da amministrare.
Che la traiettoria sia consolidata lo conferma la successione già in cantiere. Quello che veniva chiamato JWCC Next è stato ridefinito come JWCC Unified Cloud Marketplace, articolato su più livelli: un UCM Core riservato al rapporto diretto con gli hyperscaler e livelli ulteriori aperti a fornitori terzi e a servizi software; la bozza di capitolato relativa al Core è stata diffusa da DISA all’inizio di giugno 2026, la richiesta d’offerta finale è attesa entro la fine dell’anno e le aggiudicazioni dal 2027. È un’architettura di acquisto pensata per aumentare la trasparenza sulla spesa e la pluralità dei fornitori: entrambe ammissioni implicite di ciò che il primo ciclo ha prodotto.
La sovranità dei dati nel cloud: il paradosso ucraino
Il modello giuridico che stiamo abbandonando ha un nome preciso. La giurisdizione westfaliana lega il potere al territorio: lo Stato dispone entro i propri confini e non oltre. Trasferito al digitale, quel principio si è cristallizzato nel dogma della data residency, l’idea che tenere i server sul suolo nazionale sia condizione necessaria e quasi sufficiente della sovranità sulle informazioni.
L’Ucraina lo ha smentito nel modo più brutale possibile, applicandolo fino alla vigilia dell’invasione e poi abbandonandolo in quarantotto ore. Fino al febbraio 2022 la legge ucraina imponeva che determinati dati pubblici e alcuni dati privati risiedessero su server fisicamente collocati nel Paese. Circa una settimana prima dell’attacco la Rada approvò la normativa che consentiva lo spostamento in cloud; nelle settimane successive alcune delibere governative ne resero operativa la migrazione.
I primi dispositivi AWS Snowball (valigie corazzate per il trasferimento fisico di grandi volumi) furono portati in Ucraina attraverso la Polonia, e da lì partì l’evacuazione digitale dello Stato, proseguita poi in larga misura per via telematica: oltre dieci petabyte, quarantadue autorità governative, ventiquattro università, il registro della popolazione, il catasto, l’anagrafe tributaria.
L’inferenza che se ne trae di solito è che l’Ucraina abbia salvato la propria sovranità rinunciando alla territorialità. È vera solo a metà. L’Ucraina ha salvato la continuità dello Stato, che è cosa diversa dalla sovranità, e l’ha fatto pagando un prezzo che vale la pena nominare: ha trasferito la disponibilità dei propri registri fondamentali a fornitori soggetti a giurisdizione straniera, in un momento in cui non aveva alcun potere negoziale. Che la scelta fosse giusta è fuori discussione, in quanto l’alternativa era la decapitazione digitale nei primi giorni di guerra. Ma è una scelta che ha sostituito un rischio fisico con un rischio politico, non lo ha eliminato.
Un dettaglio documentato chiude il cerchio. Secondo quanto riferito dalla stampa specializzata e confermato dalla comunicazione aziendale, AWS ha successivamente proposto ad altri governi interessati un’offerta modellata su quell’esperienza, denominata Continuity of Government IT. Il fatto è accertato; l’interpretazione che ne propongo è che la trasformazione di una risposta emergenziale in un servizio standardizzato dica qualcosa di preciso sul nostro oggetto: nel cloud la resilienza si acquista, e ciò che si acquista non si possiede.
Le tre sovranità del cloud militare
Il dibattito europeo sulla sovranità digitale soffre di un vizio logico che i casi appena richiamati rendono evidente: tratta come un problema unico ciò che sono tre problemi distinti, con avversari differenti e rimedi che non si sostituiscono a vicenda.
Riservatezza: chi detiene le chiavi
La prima è la sovranità sulla riservatezza, e il suo avversario è il magistrato straniero. È il problema che il CLOUD Act statunitense e la sezione 702 del FISA pongono all’Europa: anche quando il server si trova a Francoforte o a Milano, l’autorità americana può ordinare al fornitore americano di consegnare i dati che gestisce. Il rimedio esiste ed è tecnicamente solido: cifrare il dato prima di affidarlo al fornitore, mantenendo le chiavi in infrastrutture governative (modelli Bring Your Own Key e Hold Your Own Key).
Di fronte a un’ingiunzione il provider può consegnare soltanto cifrato incomprensibile. È un rimedio reale, con due limiti che raramente vengono dichiarati: non protegge i metadati — chi comunica con chi, quando, con quale volume, che in ambito militare costituiscono già intelligence — e non copre i dati in elaborazione, se non ricorrendo a tecnologie di confidential computing la cui radice di fiducia risiede comunque nel silicio del fornitore.
Disponibilità: chi può interrompere il servizio
La seconda è la sovranità sulla disponibilità, e il suo avversario è l’amministratore delegato. Qui la crittografia non serve. Nessuna chiave custodita a Roma accende un fascio satellitare che l’operatore ha deciso di non attivare. Il caso Starlink va raccontato con precisione, perché la versione circolata è quella sbagliata e la versione corretta è analiticamente più interessante.
La biografia di Elon Musk pubblicata nel 2023 sosteneva che egli aveva ordinato di spegnere la copertura entro cento chilometri dalla costa crimeana per impedire un attacco ucraino con droni navali contro la flotta russa a Sebastopoli. L’autore ha successivamente corretto il passaggio e il Washington Post ha pubblicato una rettifica: la copertura in quell’area non era mai stata attivata, e Musk rifiutò la richiesta ucraina di estenderla, invocando anche vincoli derivanti dal regime sanzionatorio. Reportage successivi hanno documentato ulteriori limitazioni di celle durante la controffensiva del settembre 2022, contestate da SpaceX; su questo secondo episodio la ricostruzione resta controversa e va trattata come tale.
La differenza tra spegnere e non accendere è politicamente enorme e tecnicamente nulla. In un’infrastruttura software-defined la copertura è una configurazione: una frontiera tracciata su una mappa diventa una frontiera nel cielo in pochi minuti. Ma il non-atto ha proprietà giuridiche che l’atto non ha. Non lascia traccia, non attiva clausole contrattuali, non richiede motivazione, non è agevolmente impugnabile. La sovranità non cede quando il fornitore stacca la spina: cede quando lo stato di default del servizio è deciso altrove. Che il Dipartimento della Difesa abbia poi spostato parte dell’utilizzo ucraino su un contratto governativo dedicato (Starshield) è coerente con questa lettura: ha comprato la disponibilità invece di chiederla.
I casi di cronaca
Che il rischio non sia teorico lo mostra il caso più netto, ed è recente. Il 25 settembre 2025 Microsoft ha comunicato di aver cessato e disattivato una serie di servizi cloud e di intelligenza artificiale erogati a un’unità del ministero della difesa israeliano, all’esito di una verifica interna avviata dopo un’inchiesta giornalistica sull’impiego della piattaforma per l’archiviazione di intercettazioni di massa.
Le circostanze sono politicamente controverse e la valutazione di merito esula da questo articolo; ciò che rileva qui è la struttura dell’evento, che è la più pura possibile. Non un magistrato, non un attaccante, non un guasto: l’applicazione dei propri termini di servizio da parte di un fornitore commerciale ha interrotto unilateralmente la disponibilità di una capacità a un cliente statale della difesa.
È esattamente il rischio che un altro committente aveva anticipato quattro anni prima, ed è il controesempio più istruttivo perché è anteriore alla crisi anziché successivo.
Il programma israeliano Nimbus, appalto da 1,2 miliardi di dollari aggiudicato nel 2021 a Google e Amazon per i servizi cloud del governo e della Difesa, ha affrontato in via prioritaria proprio questa seconda sovranità: accanto ai requisiti di residenza dei dati, secondo quanto riferito dalla stampa israeliana all’epoca dell’aggiudicazione e successivamente da un’inchiesta internazionale sui documenti contrattuali, l’accordo contiene clausole che impediscono ai fornitori di sospendere il servizio a determinate entità governative o di limitarne l’uso in risposta a pressioni politiche o campagne di boicottaggio, oltre a un meccanismo relativo alle richieste di dati provenienti da autorità giudiziarie straniere.
Le stesse clausole sono state lette, dentro e fuori le aziende coinvolte, come garanzia contro qualunque obiezione all’impiego dei servizi, e su questo il giudizio resta legittimamente diviso: è una ragione in più per registrarne la logica invece di celebrarla.
La logica è questa. Un committente statale ha riconosciuto che il rischio principale non era la lettura dei dati da parte di un terzo, ma la loro indisponibilità decisa dal fornitore stesso, e lo ha trattato per quello che è: materia contrattuale, negoziata quando il potere negoziale c’era ancora. Vale la pena aggiungere un’osservazione che riguarda la prima sovranità e non la seconda: il meccanismo previsto per le ingiunzioni straniere mostra uno Stato cliente che tratta come oggetto di negoziato la portata extraterritoriale della legge americana, cioè precisamente ciò che l’Europa tratta come vincolo normativo esterno.
Non è un modello esportabile né, per molti versi, desiderabile. È però la prova che la questione ammette una risposta contrattuale, e che chi non la pone in sede di gara non la porrà mai.
La reversibilità come disciplina progettuale
Il rimedio è architetturale: standard aperti, containerizzazione, portabilità dei carichi, molteplicità dei fornitori. Occorre però graduare il giudizio, perché la reversibilità non è un attributo binario ma una proprietà che varia per strato. Il calcolo stateless containerizzato è oggi genuinamente portabile, e per quello i tempi brevi che la letteratura promette sono realistici. Lo stato — volumi di dati, indici, modelli addestrati — si sposta in tempi proporzionali alla sua massa.
I servizi gestiti proprietari sono lo strato critico: identità, code, database, orchestrazione dei modelli, telemetria. È lì che si annida il vincolo, ed è lì che si decide se una migrazione richieda settimane o trimestri. La formula corretta non è che la reversibilità sia una finzione, ma che sia il risultato di una disciplina progettuale esplicita, mantenuta a costo di rinunciare a parte dell’efficienza offerta dai servizi nativi del fornitore. Un’architettura che quella disciplina non l’ha esercitata non diventa portabile perché il contratto lo afferma.
Integrità procedurale: chi configura gli accessi
La terza è la sovranità sull’integrità, e il suo avversario è il proprio amministratore di sistema. All’inizio del 2023 un ricercatore di sicurezza individuò su Internet un server del Dipartimento della Difesa statunitense, ospitato su Azure Government e riconducibile allo US Special Operations Command, che esponeva senza alcuna password circa tre terabyte di posta elettronica militare interna — sensibile ma non classificata, coerentemente con la natura di quella rete — inclusa documentazione personale relativa alle procedure di security clearance. Non un attacco sofisticato, non una violazione contrattuale del fornitore: una configurazione errata rimasta attiva per circa due settimane.
Si noti la simmetria con l’incidente KA-SAT. In entrambi i casi la causa prima è la stessa: un apparato lasciato in una configurazione insicura; cambia soltanto la scala della conseguenza — nell’un caso l’apertura cinetica di una guerra, nell’altro l’esposizione di corrispondenza militare interna e di dossier personali di vetting. Nel cloud la sovranità coincide con la competenza tecnica di chi scrive le policy, ed è la forma di sovranità meno delegabile di tutte: si può appaltare l’infrastruttura, non la responsabilità sulla sua configurazione.
I leak degli insider
A questo terzo problema appartengono anche i grandi leak da insider, abitualmente citati in questo dibattito senza che se ne chiarisca la pertinenza. Snowden nel 2013, Teixeira dieci anni dopo; il militare della Guardia Nazionale Aerea che condivise materiale classificato in un server di videogiocatori, condannato a quindici anni nel novembre 2024. Non sono episodi di fallimento tecnologico. Sono l’effetto collaterale strutturale della dottrina del need to share affermatasi dopo l’11 settembre, che allargò deliberatamente l’accesso per correggere la compartimentazione ritenuta responsabile del fallimento predittivo.
Il cloud porta quella logica alla sua conclusione: la convergenza che rende possibile l’analisi multidominio è la stessa che rende possibile un Teixeira. Non è un difetto correggibile del sistema; è il prezzo della sua funzione. L’architettura Zero Trust — autenticazione continua, microsegmentazione, verifica automatizzata delle configurazioni — è la risposta corretta, purché si comprenda che è un programma organizzativo pluriennale e non un prodotto, e che le organizzazioni coinvolte negli incidenti citati l’avevano già adottata, sulla carta.
Il cloud militare della NATO tra contratti e giurisdizione
L’Alleanza non sta discutendo il cloud: lo sta contrattualizzando, e in fretta. Nel settembre 2025 la NCIA, l’agenzia NATO per le comunicazioni e l’informazione, ha scelto Oracle Cloud Infrastructure per migrare carichi mission-critical e consolidare tre data center legacy, con Thales come prime contractor e Red Reply e Shield Reply del gruppo Reply tra i partner di integrazione; tra i requisiti dichiarati figurano le capacità di cloud sovrano e i controlli di residenza del dato.
Nel luglio 2026, a margine del vertice di Ankara, la stessa NCIA ha firmato con Accenture — che eseguirà il programma insieme a Leonardo — un contratto stimato in duecento milioni di euro e durata settennale per il Protected Business Network, il programma che stabilisce il fondamento delle operazioni digitali classificate dell’Alleanza: circa ventinovemila utenti, un modello operativo cloud comune in sostituzione degli approcci legacy. A febbraio 2026 la NATO Software Factory, l’ambiente cloud di sviluppo dell’Agenzia, ha ottenuto il rinnovo dell’accreditamento di sicurezza, conseguito per la prima volta nel 2022.
L’industria italiana nella catena del cloud NATO
Il dato industriale va registrato prima di quello giuridico, perché riguarda direttamente il lettore italiano: in entrambi i contratti principali la componente nazionale è strutturale — Leonardo nell’esecuzione del Protected Business Network, il gruppo Reply nell’integrazione della migrazione OCI. Non è cronaca d’appalto. È la misura di quanto la terza sovranità, quella sull’integrità procedurale, sia ormai una funzione distribuita lungo catene industriali europee di cui l’industria italiana è parte qualificata, in un perimetro dove gli standard di configurazione cessano di essere materia aziendale e diventano materia d’Alleanza.
Il nodo delle leggi applicabili
Ciò che nessuno di questi contratti scioglie è il nodo giurisdizionale, e ora che l’infrastruttura esiste il nodo smette di essere teorico. I dati che uno Stato membro riversa in un ambiente condiviso restano soggetti alla legge del Paese che li ha generati, o alla legge applicabile al fornitore che li ospita, o al regime dell’Alleanza che ne definisce la classificazione?
Chi risponde di una violazione che attraversa i tre livelli? Va detto con precisione, per non attribuire all’Alleanza una lacuna che non ha: la NATO dispone di policy di classificazione e di proprietà dell’informazione mature, di un modello di accreditamento serio e di accordi di sicurezza con gli Alleati che disciplinano la circolazione ordinaria. L’obiezione non riguarda quel corpo di regole, ma la fattispecie che esso non contempla — il conflitto tra il regime dell’Alleanza e un’ordinanza extraterritoriale rivolta al soggetto societario che opera materialmente l’ambiente, anche quando la regione è dedicata e collocata sul suolo dell’Alleanza. È un’ambiguità che oggi si può discutere e in una crisi si può soltanto subire.
Le sigle europee da distinguere
Un chiarimento terminologico è opportuno, perché la letteratura in lingua italiana accumula sigle con qualche disinvoltura. Le iniziative europee pertinenti al cloud di difesa sono l’EDOCC, il progetto di cloud collaborativo operativo finanziato dallo European Defence Fund, e IRIS² per la connettività governativa sicura. Gli strumenti di procurement congiunto — EDIRPA, oggi confluito nella traiettoria EDIP — riguardano l’acquisto comune di equipaggiamenti, non le infrastrutture digitali. ESSOR è il programma PESCO sulle radio software-defined: attiene alla forma d’onda tattica, non al cloud.
Cloud militare in orbita: giurisdizione e registri
Sulla frontiera orbitale la disciplina intellettuale richiesta è duplice: distinguere ciò che esiste da ciò che è annunciato, e distinguere ciò che il diritto già dispone da ciò che accadrà quando qualcuno deciderà di servirsene.
Dall’edge computing ai data center spaziali
Ciò che è operativo oggi è l’elaborazione a bordo sui satelliti di osservazione: sensori che preprocessano, classificano e scartano localmente, trasmettendo a terra soltanto l’informazione utile. È vero orbital edge computing, ed è maturo. Ciò che è ancora dimostrativo è il data center in orbita.
La cronologia recente è densa ma sperimentale: nel novembre 2025 la statunitense Starcloud ha portato in orbita un acceleratore GPU di classe datacenter; nel gennaio 2026 Axiom Space ha dispiegato i primi nodi dedicati su piattaforma libera, con collegamenti ottici; Google ha annunciato il progetto Suncatcher, i cui primi risultati sui test di radiazione dei propri acceleratori sono stati pubblicati nel novembre 2025 insieme al preprint di progetto e i cui satelliti prototipo sono attesi per l’inizio del 2027; sul versante europeo procede lo studio ASCEND.
Sono investimenti seri e in rapida crescita, ma allo stato nessun carico governativo o di difesa risiede stabilmente in orbita: la formula ricorrente secondo cui le costellazioni in orbita bassa ospiterebbero già data center in miniatura descrive uno scenario, non un inventario.
La giurisdizione segue lo Stato di registrazione
Proprio perché siamo a monte del fatto compiuto, però, vale la pena esaminare l’architettura giuridica che quei sistemi erediteranno — ed è qui che va corretto l’errore concettuale più diffuso. Si sostiene abitualmente che il cloud orbitale apra un vuoto normativo. Non è così.
Il Trattato sullo spazio extra-atmosferico del 1967 stabilisce all’articolo II che lo spazio non è suscettibile di appropriazione nazionale, ma all’articolo VIII che lo Stato di immatricolazione conserva giurisdizione e controllo sull’oggetto lanciato e sul suo personale — regime completato dalla Convenzione sull’immatricolazione degli oggetti lanciati nello spazio, aperta alla firma nel 1975 ed entrata in vigore nel 1976. Un data center in orbita non sfuggirebbe dunque ad alcuna giurisdizione: la trasporterebbe con sé, quella dello Stato di registrazione.
Il rischio delle bandiere di comodo
La domanda che ne discende è di progettazione istituzionale, non di descrizione dell’esistente: se la giurisdizione segue il registro, e il registro dipende dallo Stato di lancio o di immatricolazione scelto dall’operatore, quale disciplina impedirà che la scelta della bandiera diventi una variabile di ottimizzazione societaria, come è accaduto nella marina mercantile? La domanda non è oziosa.
Uno degli operatori citati presenta già i propri nodi orbitali come archiviazione e calcolo sovrani indipendenti dalle giurisdizioni terrestri, e le domande depositate presso la FCC statunitense per costellazioni di satelliti-datacenter di scala industriale indicano che l’ambizione non è marginale. Se un’analogia con le bandiere di comodo si realizzerà, sarà una scelta politica compiuta nei prossimi anni, non un dato di fatto odierno — e questa è precisamente la ragione per cui conviene occuparsene adesso, quando i regimi di autorizzazione sono ancora scrivibili.
Per un decisore europeo l’implicazione è immediata: se lo scenario si avvera, ciò che si affaccia non è la fine della territorialità, ma la sua smaterializzazione in una scelta di bandiera — il confine non scompare, diventa negoziabile. E il potere che conterebbe, in un simile regime, non sarebbe quello di chi ospita i server ma di chi tiene il registro: chi autorizza il lancio, chi assegna lo spettro, chi controlla l’accesso allo spazio.
La risposta europea alla sovranità nel cloud militare
Il giudizio conclusivo esige un bilancio degli strumenti, altrimenti resta un’impressione. Sulla prima sovranità l’Unione ha investito il massimo capitale politico disponibile: la disciplina dei trasferimenti internazionali di dati, il contenzioso che ne ha scandito le successive impalcature di adeguatezza con gli Stati Uniti e, soprattutto, lo schema europeo di certificazione dei servizi cloud, il cui punto controverso — se includere requisiti di immunità rispetto alle legislazioni extraterritoriali — è rimasto per anni l’oggetto reale della trattativa, al prezzo di un’adozione ripetutamente rinviata.
Non lo considero un fallimento: è il segno che quella sovranità è stata trattata come questione di potere, perché si litiga a lungo soltanto su ciò che si ritiene decisivo.
Disponibilità e portabilità nel mercato europeo
Sulla seconda l’Unione ha legiferato in chiave di mercato. Il Data Act disciplina il passaggio tra fornitori di servizi di trattamento dei dati imponendo obblighi di portabilità, tempi massimi di transizione e la progressiva eliminazione dei corrispettivi di uscita; il Cloud and AI Development Act muove nella direzione della capacità industriale. Sono strumenti costruiti sul presupposto di un cliente che vuole andarsene, non di un fornitore che decide di non servirlo più, e la differenza non è accademica: nessuna disciplina del cambio fornitore restituisce una capacità nelle quarantotto ore in cui servirebbe. La reversibilità pianificata è la condizione preliminare della risposta; non è la risposta.
Integrità, conformità e competenza tecnica
Sulla terza l’Unione ha prodotto obblighi di gestione del rischio, di governance e di notifica — la direttiva sulla cibersicurezza delle reti e dei sistemi informativi, il regolamento sulla resilienza operativa digitale per il settore finanziario, il regolamento sulla ciberresilienza per i prodotti con elementi digitali. È un’architettura di conformità, utile e distinta dalla competenza di configurazione, che non si certifica una volta per tutte perché si esercita ogni giorno o non esiste.
In Italia la distinzione ha nomi concreti: il Polo Strategico Nazionale ha risolto il problema della collocazione e della qualificazione delle infrastrutture per la pubblica amministrazione, e l’Agenzia per la cybersicurezza nazionale ha costruito il quadro di classificazione dei dati e dei servizi cloud. Sono passi necessari, e nessuno dei due, per come è disegnato, risponde alla domanda su che cosa accada quando la capacità viene meno per decisione di chi la fornisce.
Chi controlla davvero i dati nel cloud militare
Resta la domanda iniziale — di chi sono i dati nell’era del cloud militare — e conviene rispondervi senza il conforto della domanda retorica finale.
I dati appartengono, nell’ordine:
a chi ne detiene le chiavi (riservatezza);
a chi può interromperne il flusso (disponibilità);
a chi ne configura gli accessi (integrità procedurale).
Sono tre soggetti diversi, e quasi mai coincidono con lo Stato che quei dati ha generato. L’Unione europea ha costruito strumenti per tutte e tre le sovranità; ma solo la prima è stata trattata come una questione di potere, mentre le altre due sono state affidate al diritto del mercato e alla disciplina della conformità. È un ordine di priorità coerente con la natura giuridica dell’Unione, e a mio avviso poco coerente con l’esperienza degli ultimi quattro anni e mezzo di guerra — la quale suggerisce che la sovranità si perde raramente per una sentenza straniera, e quasi sempre per una decisione commerciale o per una configurazione dimenticata.
La sovranità digitale, nell’era del cloud militare, non è dunque un attributo che si possiede una volta per tutte. È una prestazione che va riconquistata ogni giorno: con le chiavi che si custodiscono, con i contratti che si negoziano, con le configurazioni che si controllano. L’Europa ha fatto molto. Ha politicizzato la sovranità sbagliata.
Le opinioni espresse in questo articolo sono esclusivamente personali dell’autore e non impegnano in alcun modo le organizzazioni con cui collabora.
Partecipa alla community