
I segreti della Germania nel cloud di Google: quanto è carente la sovranità del progetto ND Cloud? – Immagine creativa sull'argomento, realizzata con intelligenza artificiale: Xpert.Digital
500 milioni di euro per ND Cloud: sicurezza, ma non completa indipendenza
Offline, ma dipendenti? Il prezzo rischioso della tecnologia Google per i servizi di informazione tedeschi
Il servizio cloud di Google per i servizi segreti tedeschi: cosa succede in caso di fallimento del fornitore?
Un servizio cloud isolato da Internet può proteggere efficacemente le informazioni classificate, ma può anche creare una dipendenza a lungo termine dal suo fornitore di tecnologia. Il progetto ND Cloud per il Servizio Federale di Intelligence (BND), l'Ufficio Federale per la Protezione della Costituzione (BfV) e il Servizio di Controspionaggio Militare (MAD) si colloca proprio in questa situazione di tensione. È concepito per consentire lo scambio sicuro di informazioni altamente sensibili operando senza una connessione diretta a Internet. Tuttavia, questo cosiddetto "air gap" non risolve tutti i problemi: chi si occuperà della manutenzione, dell'aggiornamento e dello sviluppo della piattaforma nel corso degli anni? E quali opzioni resteranno a disposizione dello Stato qualora il contesto tecnico o politico dovesse cambiare?
Per un progetto con un budget dichiarato pubblicamente di almeno 500 milioni di euro, la posta in gioco va ben oltre la semplice ubicazione dei server e le misure di sicurezza. La questione cruciale è se la Germania sarà in grado di controllare la piattaforma a lungo termine e di passare a una diversa, se necessario. Ciò richiede di considerare non solo la protezione dei dati, ma anche la fornitura di software, le competenze, i costi di migrazione e le potenziali alternative. Il cloud previsto può rappresentare un passo importante verso la modernizzazione, ma la vera sovranità digitale sarà raggiunta solo quando lo Stato non solo controllerà le operazioni in corso, ma disporrà anche di opzioni valide per il futuro.
Correlato a questo:
- Le forze armate tedesche si accordano con Google: quanta sovranità sta realmente cedendo la Germania per Google Cloud?
I segreti della Germania, la tecnologia di Google: il prezzo della sovranità digitale
Offline è ben lungi dall'essere indipendente
Un servizio cloud isolato da Internet può proteggere efficacemente le informazioni classificate, pur creando una dipendenza a lungo termine dal suo fornitore di tecnologia. La piattaforma dati congiunta pianificata dal Servizio Federale di Intelligence, dall'Ufficio Federale per la Protezione della Costituzione e dal Servizio di Controspionaggio Militare si colloca proprio in questa situazione di tensione: l'isolamento tecnico previsto risolve il problema dell'accesso alla rete esterna, ma non ancora quello della duratura libertà d'azione tecnologica.
La questione economicamente decisiva non è quindi se sulla piattaforma compaia il logo di un'azienda americana o europea. Ciò che conta è chi determina le condizioni per l'ulteriore sviluppo, la risoluzione dei problemi, il funzionamento e la potenziale migrazione durante tutto il suo ciclo di vita. Una strategia di sovranità convincente deve combinare prestazioni, requisiti di sicurezza e libertà di scelta a lungo termine, anziché considerare unicamente la localizzazione dei server.
Una piattaforma dati con implicazioni strategiche
Secondo quanto emerge dai piani di sviluppo resi pubblici al 28 ottobre 2026, il cosiddetto ND Cloud dovrebbe consentire lo scambio elettronico di informazioni classificate fino al livello SEGRETO tra i tre servizi segreti federali; in seguito, potrebbero essere inclusi anche gli uffici statali per la tutela della Costituzione. La base tecnica sarebbe, a quanto pare, Google Distributed Cloud in una configurazione sicura, con le informazioni archiviate in Germania e senza accesso diretto ai dati da parte di Google.
Non si tratta di archiviare segreti governativi su un normale servizio internet. Piuttosto, si prevede un'infrastruttura separata in grado di operare senza una connessione diretta a internet pubblico o al cloud di Google. Questa distinzione è cruciale perché modifica il panorama delle minacce: una rete tecnicamente isolata e gestita a livello nazionale deve essere valutata in modo diverso rispetto a un servizio cloud standard amministrato dall'esterno.
La cifra dichiarata pubblicamente è di almeno 500 milioni di euro; si tratta di una stima e non di una ripartizione completa dei costi pubblicata. Il lancio, originariamente previsto per il primo trimestre del 2027, subirà probabilmente un ritardo, mentre i dettagli chiave relativi all'architettura, alla portata dei servizi e ai costi di gestione non sono disponibili al pubblico. Sulla base di queste informazioni, è impossibile calcolare un ritorno sull'investimento affidabile o affermare con certezza che una particolare alternativa sarebbe una percentuale fissa più economica.
Tuttavia, la vastità del progetto dimostra che la piattaforma sarebbe ben più di un semplice sistema informatico. Influirà sui flussi di lavoro, sui modelli di dati e sulle qualifiche per gli anni a venire. Quanto più le agenzie governative allineeranno le proprie procedure specializzate con servizi tecnici condivisi, tanto maggiore sarà l'importanza strategica di quelle decisioni che inizialmente sembrano essere puramente infrastrutturali.
Perché le infrastrutture condivise possono essere economicamente vantaggiose
La necessità di modernizzazione è fondamentalmente plausibile: lo scambio di informazioni di alto livello tra sistemi governativi protetti è attualmente macchinoso, mentre i requisiti di archiviazione e le richieste di analisi automatizzata sono in aumento. Una piattaforma condivisa può semplificare i trasferimenti di dati, fornire strumenti standardizzati e accelerare la collaborazione, a condizione che autorizzazioni e responsabilità siano chiaramente definite.
Dal punto di vista economico, i potenziali vantaggi derivano dalle economie di scala. Se la potenza di calcolo, il backup dei dati, il monitoraggio e i processi di sicurezza vengono forniti congiuntamente, non tutte le autorità devono sviluppare le stesse capacità in parallelo. Ciò può migliorare l'utilizzo delle risorse e alleggerire il carico di lavoro del personale qualificato, già scarso; BWI descrive quindi un'infrastruttura cloud standardizzata e automatizzata come un mezzo per ottenere servizi IT più flessibili ed efficienti.
A ciò si aggiunge il vantaggio di una più rapida elaborazione delle informazioni. Un ambiente tecnico ad alte prestazioni può impedire che le informazioni già disponibili arrivino troppo tardi a causa di processi macchinosi. Questo vantaggio è difficile da quantificare in euro per i servizi di intelligence, ma non è quindi economicamente irrilevante. Tuttavia, un plausibile vantaggio in termini di sicurezza non deve essere utilizzato come argomento arbitrariamente flessibile per giustificare a posteriori qualsiasi dipendenza tecnologica.
Il confronto corretto, quindi, non è tra un cloud moderno e un'infrastruttura esistente priva di rischi. Anche i sistemi legacy frammentati comportano costi e rischi per la sicurezza, ad esempio a causa di una manutenzione complessa e di processi manuali. Una valutazione adeguata deve considerare sia i rischi della migrazione sia i costi dell'inazione; tuttavia, la sola necessità di modernizzazione non dimostra che ogni piattaforma offerta a tale scopo sia economicamente sostenibile nel lungo periodo.
L'intercapedine d'aria risolve solo una parte del problema
Il termine "air gap" si riferisce qui a una separazione da Internet pubblico e da altre reti esterne, non necessariamente all'isolamento completo di ogni singolo computer dagli altri. All'interno di una rete governativa protetta, i sistemi possono continuare a collaborare, mentre esistono rigidi limiti all'accesso esterno. Google descrive esplicitamente la piattaforma come permanentemente operativa anche senza una connessione al Google Cloud pubblico.
Questa caratteristica rappresenta un significativo vantaggio in termini di sicurezza e non va sottovalutata. L'assenza di connessioni esterne limita determinate vulnerabilità e crea condizioni migliori per un funzionamento controllato. Tuttavia, ciò non significa che la piattaforma possa essere mantenuta in modo sicuro o ampliata funzionalmente a tempo indeterminato senza ulteriori servizi da parte del produttore; l'indipendenza tecnica dalla rete e l'indipendenza dalla fornitura del software sono proprietà distinte.
Questo concetto può essere illustrato paragonandolo a un impianto di produzione situato interamente all'interno di un complesso industriale tedesco. La posizione geografica garantisce il controllo fisico, ma non assicura la disponibilità costante di pezzi di ricambio, software di controllo e competenze specialistiche. Il semplice fatto che qualcuno gestisca l'impianto non significa che sia in grado di svilupparlo ulteriormente in modo indipendente. La stessa logica economica si applica a un ambiente cloud altamente complesso.
La sovranità non si riduce quindi a un singolo interruttore. La sovranità dei dati, il controllo amministrativo, la certezza del diritto, la trasparenza della catena di fornitura e l'adattabilità tecnologica devono essere considerati separatamente. Una piattaforma può presentare caratteristiche di rilievo in alcune di queste dimensioni e mostrare significative dipendenze in altre; è proprio questa differenziazione che rende possibile una valutazione accurata.
Gli aggiornamenti come interfaccia del potere economico
La documentazione sulla sicurezza di Google descrive un processo di aggiornamento controllato: il produttore firma i pacchetti software, l'operatore dell'infrastruttura li esamina e li distribuisce nell'ambiente isolato. Questo processo comprende non solo il software cloud, ma anche i sistemi operativi, il firmware e altri componenti rilevanti per la sicurezza. Non è richiesta una connessione Internet automatica, ma il rapporto di fornitura tecnica continuativo rimane attivo.
Inizialmente, questo è un aspetto normale del funzionamento di un software professionale e non indice di cattiva condotta da parte del produttore. La situazione diventa problematica quando solo un fornitore è in grado di fornire aggiornamenti affidabili e tempestivi. In questi casi, la sicurezza effettiva del sistema dipende non solo dall'operatore nazionale, ma anche da un'organizzazione di sviluppo esterna e dal suo quadro giuridico ed economico.
L'entità di tali dipendenze è dimostrata dai termini e condizioni standard pubblicamente disponibili per Google Distributed Cloud air-gapped. Questi stabiliscono che le nuove versioni devono essere installate entro 30 giorni dalla notifica; contengono inoltre norme relative alla cessazione della manutenzione e alla fine dell'utilizzo del software alla scadenza del periodo di licenza. Tuttavia, questi termini e condizioni generali non devono essere equiparati a disposizioni speciali non note della piattaforma di messaggistica in fase di progettazione.
Questa distinzione è cruciale. Non è possibile verificare pubblicamente quali diritti operativi individuali, periodi di audit o ulteriori misure di sicurezza siano in vigore per ND Cloud. Allo stesso modo, sarebbe infondato dedurre dalla continua dipendenza dagli aggiornamenti l'esistenza di accessi remoti segreti o di un meccanismo di arresto tecnico. Ciò che è documentato è il ruolo costante del produttore nella fornitura del software, non un accesso esterno arbitrario.
La pericolosa differenza tra tempo di esecuzione e sicurezza
In caso di interruzione del supporto da parte del produttore, è necessario considerare diversi scenari. Un sistema già installato potrebbe inizialmente continuare a funzionare tecnicamente, mentre le vulnerabilità di sicurezza appena scoperte non verranno più corrette. Allo stesso tempo, potrebbero essere compromessi i diritti di utilizzo, la disponibilità di pezzi di ricambio e il supporto per le applicazioni dipendenti. Pertanto, la questione di quanto tempo i computer rimarranno accesi è meno rilevante rispetto alla questione di quanto tempo sarà possibile un funzionamento responsabile.
Da ciò non si può dedurre una durata di vita fissa e generale. Dipenderebbe, tra le altre cose, dalle vulnerabilità esistenti, dalle opzioni di riparazione locali, dall'utilizzo di servizi aggiuntivi e dalla disponibilità di personale qualificato. Affermare in modo generico che un cloud isolato diventi inevitabilmente inutilizzabile dopo un certo numero di mesi sarebbe altrettanto impreciso quanto rivendicare un'indipendenza illimitata.
Dal punto di vista economico, ciò crea un problema di opzioni: uno Stato ha bisogno non solo della funzionalità attuale, ma anche della capacità di agire in caso di mutamento delle circostanze. Questa opzione ha valore, anche se rimane inutilizzata per anni. Finanziarla è simile a un'assicurazione contro una perdita rara, ma potenzialmente molto costosa, del potere decisionale tecnologico.
Un piano di emergenza efficace dovrebbe quindi distinguere tra un funzionamento limitato, il ripristino completo e la migrazione verso un'altra piattaforma. Per ciascuno di questi scenari sarebbe necessario esaminare prerequisiti specifici. Ad esempio, un semplice backup dei dati è di scarsa utilità se mancano i programmi necessari per elaborare le informazioni in modo efficace e applicare le relative regole di accesso.
La dipendenza aumenta con ogni procedura specialistica
Il termine "lock-in", spesso utilizzato, descrive una situazione in cui il cambio di fornitore rimane teoricamente possibile, ma diventa sempre più complesso nella pratica. Nei sistemi cloud, questo lock-in deriva dall'interazione tra le funzioni della piattaforma, le interfacce, le strutture dati e i processi operativi consolidati. Quanto più le applicazioni specializzate richiedono servizi specifici da un determinato fornitore, tanto maggiore sarà lo sforzo necessario per replicare funzionalità equivalenti altrove.
Non ogni utilizzo di tecnologia proprietaria è antieconomico. Uno strumento specializzato può offrire un vantaggio significativo in termini di produttività. La difficoltà sta nel fatto che i benefici a breve termine sono spesso immediatamente evidenti, mentre i costi futuri di transizione rimangono incerti. Ciò rischia di creare uno squilibrio sistemico: la comodità attuale viene pienamente considerata, mentre la dipendenza futura viene menzionata solo in termini astratti.
Il collegamento a livello applicativo è particolarmente rilevante. Una macchina virtuale può essere trasferita con relativa facilità, mentre un'applicazione aziendale complessa con database, servizi di identità e di analisi specifici del fornitore non può esserlo. Pertanto, il fatto che una piattaforma supporti i container non è sufficiente a dimostrare la sua intercambiabilità. Il fattore cruciale è se l'intera funzionalità aziendale può essere implementata in un ambiente diverso con uno sforzo ragionevole.
Un'architettura coerente dovrebbe valutare i vantaggi dei servizi specifici della piattaforma rispetto agli ostacoli al passaggio ad essa. L'obiettivo non sarebbe la completa uniformità tecnica, bensì una differenziazione mirata: le funzioni di base standardizzate dovrebbero rimanere intercambiabili il più possibile, mentre le funzioni specializzate essenziali verrebbero esaminate separatamente per il loro valore aggiunto e le relative dipendenze.
Il problema del mercato europeo inizia dalle dimensioni
La sfida strutturale va ben oltre i servizi di intelligence tedeschi. Il mercato europeo dei servizi di infrastruttura cloud ha raggiunto un volume di circa 61 miliardi di euro nel 2024, circa sei volte superiore a quello del 2017; questa cifra include i servizi di infrastruttura e piattaforma, nonché i cloud privati ospitati, ma non l'intero mercato del software. I fornitori europei hanno più che triplicato i rispettivi ricavi regionali in questo periodo, ma hanno comunque perso quote di mercato relative.
La loro quota combinata è scesa dal 29% nel 2017 a circa il 15% nel 2022, per poi mantenersi all'incirca a quel livello; Amazon, Microsoft e Google insieme rappresentavano circa il 70% del mercato, secondo l'indagine pubblicata a metà del 2025. Queste cifre si riferiscono al mercato europeo e non devono essere equiparate a un mercato limitato esclusivamente all'UE, né al segmento specifico dei sistemi di intelligence chiusi.
Questo sviluppo dimostra perché la sola crescita dei ricavi non garantisce l'indipendenza tecnologica. Le aziende europee possono avere più successo pur rimanendo indietro rispetto alle piattaforme più grandi. I principali fornitori ripartiscono i costi di sviluppo e gli investimenti su basi clienti molto ampie; di conseguenza, la scalabilità e gli investimenti finanziati a lungo termine rivestono un ruolo cruciale nel mercato europeo delle infrastrutture.
Una strategia europea realistica non dovrebbe quindi necessariamente copiare ogni funzione dei più grandi hyperscaler. Sarebbe più plausibile sviluppare alternative solide per le aree applicative particolarmente critiche e promuovere congiuntamente le consolidate basi tecniche. Un mercato di nicchia orientato alla sicurezza potrebbe avere fattori di successo diversi rispetto al mercato di massa della potenza di calcolo standardizzata. La leadership di mercato generale di un'azienda non si traduce automaticamente in superiorità per ogni applicazione governativa.
Lo Stato come motore delle curve di apprendimento tecnologico
Quando numerose istituzioni pubbliche condividono requisiti simili in materia di sovranità dei dati e collaborazione sicura, l'adozione di standard comuni può creare un mercato più ampio e affidabile. Le aziende dispongono quindi di una base più solida per investire in documentazione, audit di sicurezza e gestione operativa professionale. L'ecosistema openDesk, con i suoi molteplici partner software e operativi, dimostra che un approccio collaborativo di questo tipo è già implementato nella pratica.
Ciò fornisce un argomento di politica economica a favore dell'utilizzo mirato di soluzioni europee idonee. I loro benefici non si limitano al singolo luogo di lavoro, ma possono estendersi ad applicazioni successive e ad altre strutture. Componenti riutilizzabili, personale qualificato e modelli operativi collaudati possono ridurre i costi di ingresso per gli utenti successivi. Questi effetti aggiuntivi sono facilmente sottovalutati se si considera solo l'implementazione iniziale.
Allo stesso tempo, ciò non deve creare un diritto a una protezione permanente. Anche i fornitori europei devono dimostrare prestazioni, affidabilità e redditività economica. Una politica che protegga ogni soluzione locale a prescindere dalla sua qualità potrebbe generare costi elevati e nuove dipendenze. Il punto cruciale non è l'eliminazione della concorrenza, ma la creazione di valide alternative tecniche ed economiche.
È inoltre fondamentale impedire che un monopolio internazionale venga sostituito da una dipendenza nazionale difficilmente verificabile. Interfacce aperte, conoscenze operative trasferibili e molteplici fornitori di servizi qualificati sono pertanto altrettanto importanti quanto la sede centrale dell'azienda. In definitiva, la sovranità dovrebbe rafforzare la capacità di azione dell'utente, non limitarsi a cambiare l'origine del suo fornitore più importante.
Hub per la sicurezza e la difesa - Consulenza e informazioni
Il Security and Defence Hub offre consulenza specialistica e informazioni aggiornate per supportare efficacemente aziende e organizzazioni nel rafforzamento del loro ruolo nella politica europea di sicurezza e difesa. Lavorando a stretto contatto con il gruppo di lavoro SME Connect Defence, promuove in particolare le piccole e medie imprese (PMI) che desiderano sviluppare ulteriormente la propria capacità innovativa e la propria competitività nel settore della difesa. In qualità di punto di contatto centrale, il Security Hub crea quindi un ponte cruciale tra le PMI e la strategia di difesa europea.
Correlato a questo:
ND-Cloud: strategia di sicurezza o dipendenza?
OpenDesk è rilevante, ma non rappresenta una sostituzione completa del cloud
La suite per ufficio e collaborazione openDesk è stata lanciata nell'ottobre 2024 e, secondo il Centro per la Sovranità Digitale responsabile, era installata su circa 100.000 postazioni di lavoro amministrative entro l'ottobre 2026. Questa cifra rappresenta il tasso di adozione dichiarato, non la prova di 100.000 utenti attivi giornalieri o di un numero corrispondente di postazioni di lavoro ad alta riservatezza. Ciononostante, dimostra che la collaborazione open source in Europa ha da tempo superato la fase dei piccoli progetti dimostrativi.
Dal punto di vista tecnico, il confronto deve rimanere preciso. OpenDesk raggruppa applicazioni per il lavoro d'ufficio e la collaborazione, mentre Google Distributed Cloud è una piattaforma di infrastruttura e servizi molto più ampia. Una suite di collaborazione non sostituisce automaticamente l'architettura di archiviazione, i database, le risorse di calcolo e i servizi specializzati di un intero ambiente di intelligence. Chiunque presenti entrambe le offerte come soluzioni complete e direttamente intercambiabili confonde livelli tecnici diversi.
Tuttavia, openDesk è importante per il dibattito perché non ogni collaborazione quotidiana richiede necessariamente una piattaforma proprietaria. Laddove le autorità pubbliche modificano congiuntamente documenti, coordinano progetti o comunicano, le applicazioni open source possono offrire alternative concrete. Ciò può quantomeno ridurre in parte la dipendenza, anche se alla base vengono comunque utilizzate infrastrutture diverse.
Nell'ottobre 2026, è stato dimostrato e testato il funzionamento di openDesk in ambienti completamente isolati; contemporaneamente, l'attenzione si è concentrata sulla sua certificazione per la classificazione "VS-NUR FÜR DEN DIENSTGEBRAUCH" (Riservato - Solo per uso ufficio). Ciò non deve essere interpretato come prova di idoneità operativa per tutte le attività di elaborazione fino al livello "GEHEIM" (Segreto), poiché queste classificazioni sono chiaramente distinte. Una dimostrazione di funzionamento offline è un importante passo tecnico, ma non una prova incondizionata di idoneità per tutti i casi d'uso altamente sensibili.
La matrice dimostra i vantaggi di una comunicazione aperta
Element e il protocollo aperto Matrix forniscono anche punti di partenza concreti. BwMessenger si basa su questi componenti ed è gestito da BWI nei data center della Bundeswehr; BundesMessenger trasferisce questo approccio alla pubblica amministrazione. Pertanto, esiste già un'esperienza concreta di comunicazione controllata dallo Stato su una base tecnica aperta.
Il vantaggio economico di tali infrastrutture risiede nella fondamentale separabilità tra software, gestione e servizio. Se un ente pubblico gestisce la propria infrastruttura o può scegliere tra operatori idonei, si creano condizioni più favorevoli alla concorrenza. Il controllo sul servizio in corso non deve quindi necessariamente rimanere in mano al produttore originale del software.
Tuttavia, anche un servizio di messaggistica non costituisce una piattaforma di analisi completa. La messaggistica sicura, la modifica collaborativa di documenti e l'elaborazione di grandi insiemi di dati sono attività distinte. Inoltre, ogni specifica configurazione deve soddisfare i requisiti di sicurezza necessari; l'utilizzo da parte di enti governativi non implica automaticamente l'idoneità a ogni livello di classificazione di sicurezza. La comunicazione aperta è quindi una componente importante di un'architettura sovrana, ma non una soluzione universale a tutti i problemi infrastrutturali.
L'apertura non sostituisce la propria competenza
Il software open source può ampliare le opzioni di controllo grazie alla sua struttura trasparente e alla possibilità, in linea di principio, di distribuire lo sviluppo tra più soggetti interessati. Tuttavia, questa possibilità si esprime appieno solo in presenza di specialisti realmente qualificati, strumenti di sviluppo adeguati e responsabilità finanziate in modo sostenibile. La trasparenza del codice sorgente, di per sé, non elimina automaticamente le vulnerabilità di sicurezza o le dipendenze problematiche.
Soprattutto con sistemi complessi, non è sufficiente avere la possibilità di modificare i singoli programmi solo in teoria. Ciò che serve è la conoscenza di come interagiscono, la creazione di pacchetti di installazione affidabili e il collaudo delle nuove versioni. L'attenzione rivolta ai componenti principali rinforzati e alle catene di approvvigionamento sicure nell'ecosistema open source del governo dimostra quanto sia essenziale questo livello organizzativo.
L'apertura è quindi più un prerequisito per ulteriori linee d'azione che una garanzia gratuita. Il suo vantaggio economico risiede nel fatto che gli investimenti in conoscenza e sviluppo possono essere riutilizzati più facilmente tra le istituzioni. Affinché ciò avvenga, gli adattamenti dovrebbero idealmente essere reintrodotti nelle fondazioni gestite congiuntamente. D'altro canto, molte versioni specializzate e permanentemente separate aumenterebbero i costi di manutenzione e i rischi per la sicurezza.
Anche la carenza di personale deve essere affrontata in modo realistico. Un ente non acquisisce sovranità assumendosi tutto il lavoro. Un modello più sensato prevede che lo Stato possieda sufficienti capacità interne di valutazione e controllo, potendo al contempo avvalersi di diversi fornitori di servizi professionali. Questo non elimina completamente le dipendenze, ma le rende più facilmente verificabili e gestibili.
Le forze armate tedesche presentano un quadro più sfaccettato
Per contestualizzare ND Cloud, è rilevante il cloud privato delle Forze Armate tedesche, in quanto anch'esso integra tecnologie Google e BWI svolge un ruolo centrale. Tuttavia, questa piattaforma non è sinonimo di un singolo Google Cloud: le Forze Armate tedesche adottano un approccio che utilizza diversi ambienti tecnologicamente separati, tra cui VMware, Google e software open source.
La prima fase del rollout è stata introdotta nel 2025; lo sviluppo e l'integrazione della piattaforma Google sono stati delineati a partire dal 2026, con il completamento previsto per la fine del 2027. La SAP Business Technology Platform è citata come caso d'uso specifico, mentre sono previsti due ambienti separati per le informazioni aperte e riservate (VS-NfD). Questa tempistica pubblicata non deve essere interpretata come uno stato operativo definitivo.
Questo esempio illustra come le decisioni fondamentali relative al software possano influenzare ulteriormente le decisioni infrastrutturali. Se è necessaria una piattaforma specializzata i cui ambienti operativi supportati sono definiti in modo ristretto, la selezione effettiva si restringe ancor prima di considerare i singoli fornitori di servizi cloud. Un'analisi di sovranità deve quindi esaminare l'intera catena tecnica e non può fermarsi al singolo elemento infrastrutturale visibile.
Tuttavia, piattaforme multiple creano una vera scalabilità solo se le applicazioni essenziali possono effettivamente essere spostate tra di esse. Tre ambienti separati, ognuno con le proprie procedure ben definite, inizialmente significano diversità, ma non ancora intercambiabilità reciproca. BWI cita esplicitamente la riduzione della dipendenza da fornitori specifici e la migrazione agevole delle applicazioni come obiettivi del suo approccio.
I rischi legali richiedono precisione tecnica
Nei dibattiti sulla tecnologia americana si fa spesso riferimento al Cloud Act. Il principio giuridico alla base di tale legge è che le aziende soggette alla normativa statunitense possono essere obbligate a divulgare i dati in loro possesso, custodia o controllo, indipendentemente da dove siano archiviati. Pertanto, la semplice presenza in Germania non elimina automaticamente tutti i rischi legali.
Al contrario, il diritto legale di divulgare i dati non crea un accesso tecnico che prima non esisteva. Se un fornitore non ha effettivamente accesso ai dati né controllo sulle chiavi necessarie, questa architettura deve essere considerata nella valutazione legale. Pertanto, una piattaforma isolata non può essere semplicemente equiparata a un servizio internet convenzionale gestito da un produttore.
Per quanto riguarda ND Cloud, alcuni dettagli non resi pubblici rimangono cruciali: quali ruoli sono disponibili a livello locale, come funzionano le procedure di accesso di emergenza, quali informazioni sono necessarie per l'analisi degli errori e chi controlla le chiavi crittografiche? La documentazione generale di Google delinea ruoli operativi distinti e procedure di emergenza specifiche, ma ciò non descrive automaticamente l'implementazione finale in Germania. Un via libera generalizzato sarebbe quindi altrettanto inappropriato quanto l'affermazione infondata di un accesso automatico ai dati negli Stati Uniti.
Occorre distinguere questo aspetto dal rischio di interruzione dei servizi. Anche qualora l'accesso ai dati risultasse tecnicamente impossibile, conflitti legali o geopolitici potrebbero compromettere servizi quali la manutenzione e l'assistenza dei software. Una valutazione completa della sovranità deve pertanto esaminare sia il controllo sulle informazioni sia la continuità dei servizi essenziali.
Cosa dovrebbe contenere un calcolo onesto dei costi
Un'analisi economica completa dovrebbe includere non solo i costi iniziali dell'hardware e del software, ma anche quelli relativi all'integrazione, al personale, all'energia, alla formazione, al monitoraggio della sicurezza, al backup dei dati, alle capacità di riavvio e al continuo adattamento dei processi specializzati. Per ND Cloud, mancano dati dettagliati pubblicamente disponibili per quantificare in modo affidabile queste componenti; la stima nota di almeno 500 milioni di euro non sostituisce tale ripartizione.
Inoltre, occorre considerare i costi che si presentano solo durante la migrazione. Questi includono il trasferimento dei dati, l'adattamento dei programmi, il funzionamento parallelo temporaneo e i nuovi audit di sicurezza. Di conseguenza, le normative europee sulla migrazione al cloud distinguono diverse fasi tecniche, dall'estrazione dei dati alla migrazione verso un ambiente di destinazione. Una migrazione di notevole entità dal punto di vista finanziario implica quindi molto più del semplice download di un archivio di file.
È inoltre importante distinguere tra costi a carico delle famiglie ed effetti macroeconomici. I servizi offerti dai data center e dai fornitori di servizi tedeschi possono generare valore aggiunto a livello locale, anche se il software principale proviene da una multinazionale. Al contrario, un fornitore europeo non è esente dalle dipendenze delle catene di approvvigionamento globali. Un'analisi accurata dovrebbe quindi considerare l'effettiva distribuzione delle competenze e dei ricavi, anziché attribuire semplicemente tutte le spese a un unico Paese di origine.
In definitiva, i diversi scenari di crisi dovrebbero essere valutati separatamente. Un'interruzione del supporto a breve termine, una sospensione degli aggiornamenti a lungo termine e un cambio di piattaforma a breve termine avrebbero conseguenze diverse. Invece di generare un singolo valore apparentemente preciso per tutti i rischi, sarebbe più opportuno rendere trasparenti le larghezze di banda, le ipotesi e le conseguenze particolarmente gravi. Attualmente mancano dati di progetto sufficientemente disponibili pubblicamente per determinare tali valori.
Autonomia misurabile anziché etichette rassicuranti
Con la pubblicazione, nell'aprile 2026, dei Criteri per l'autonomia del cloud computing, l'Ufficio federale tedesco per la sicurezza informatica (BSI) ha presentato un quadro di riferimento volto a rendere più sistematica la valutazione dell'utilizzo autonomo dei servizi cloud. Tali criteri integrano i requisiti C5 orientati alla sicurezza, ma non hanno di per sé valore normativo. Sicurezza e sovranità sono quindi esplicitamente trattate come questioni di valutazione correlate, ma distinte.
Il quadro di riferimento distingue tra aspetti strategici, legali, relativi ai dati, operativi, relativi alla catena di approvvigionamento e tecnologici. In questo contesto, risultano rilevanti metriche di test specifiche, come la trasferibilità delle conoscenze operative, la disponibilità di manutenzione indipendente e la capacità di proseguire le operazioni in caso di guasto di terzi. Tali caratteristiche sono più significative per una piattaforma ad alta sicurezza rispetto a una generica autodefinizione di sovranità.
Ai fini pratici, una procedura di riavvio testata regolarmente sarebbe particolarmente utile. Ciò permetterebbe di verificare se i backup, la documentazione e le competenze esistenti siano sufficienti a ripristinare le funzioni essenziali in condizioni di errore chiaramente definite. Consentirebbe inoltre di testare quali dati e applicazioni siano effettivamente utilizzabili in un ambiente secondario. Un test riuscito sarebbe più efficace di un'opzione di transizione puramente teorica.
Nemmeno i progressi normativi riescono a risolvere questa sfida tecnica. Il Data Act vieta le commissioni di passaggio per i servizi di elaborazione dati soggetti a tale divieto a partire dal 12 gennaio 2027. Tuttavia, ciò non significa automaticamente che ogni specifico ambiente di intelligence rientri in questo divieto, né elimina i costi interni di migrazione, sviluppo e sicurezza. Il passaggio gratuito per il fornitore e l'effettiva intercambiabilità tecnica non sono la stessa cosa.
Una maggiore potenza di calcolo richiede limiti di accesso chiari
Una piattaforma condivisa può facilitare la cooperazione, ma non deve livellare il campo di gioco semplificando gli aspetti tecnici e minimizzando le diverse responsabilità legali e i diritti sui dati. Un'infrastruttura condivisa non concede automaticamente a tutte le parti il permesso incondizionato di utilizzare liberamente tutte le informazioni in essa contenute. In particolare, nello scambio di informazioni tra servizi di intelligence e forze dell'ordine, sussistono requisiti costituzionali più stringenti che non devono essere confusi con i semplici scambi tra servizi di intelligence.
Dal punto di vista dell'architettura, ciò significa che ruoli, scopi, origine e condivisione consentita dei dati devono essere mappati in modo appropriato. Le piattaforme tecniche possono supportare regole di accesso granulari e registrazioni tracciabili; la documentazione di Google descrive le autorizzazioni basate su ruoli e attributi, nonché la registrazione degli accessi. Tuttavia, l'applicazione legale e pratica rimane di esclusiva responsabilità delle parti responsabili.
Inoltre, sussiste il rischio di concentrazione. L'infrastruttura condivisa può mettere in comune le competenze in materia di sicurezza, ma al contempo un'interruzione grave potrebbe colpire più enti. Pertanto, è necessario considerare congiuntamente la separazione logica, il ripristino e i meccanismi di controllo indipendenti. La valutazione economica non dovrebbe basarsi esclusivamente sull'utilizzo del data center, ma anche sull'efficacia con cui le funzioni critiche vengono mantenute durante interruzioni parziali.
L'IA sposta la dipendenza al livello del modello
La traduzione automatica, la sintesi e l'analisi di grandi insiemi di dati sono applicazioni plausibili per un cloud chiuso; Google offre le corrispondenti funzioni di intelligenza artificiale per questa famiglia di prodotti. Ciò consente all'integrazione tecnica di estendersi oltre l'infrastruttura per includere modelli, interfacce e l'organizzazione di flussi di lavoro analitici. Quanto più i processi specializzati sono allineati a specifici servizi di intelligenza artificiale, tanto più importante diventa la loro intercambiabilità.
Un modello gestito localmente, tuttavia, non è automaticamente sovrano. Anche i diritti di utilizzo, la possibilità di aggiornamento, i componenti del modello disponibili e la capacità di continuare a utilizzare lo strumento in condizioni mutate sono rilevanti; i termini generali del prodotto distinguono esplicitamente tra i vari modelli e le forme di utilizzo. Non è possibile dedurre dalla disponibilità generale del prodotto se specifiche offerte di intelligenza artificiale siano effettivamente destinate a ND Cloud.
Da un punto di vista economico, l'IA dovrebbe quindi essere misurata in base alla qualità dei risultati, non solo al numero di documenti elaborati. Una spesa aggiuntiva può essere vantaggiosa se accelera l'analisi e facilita l'individuazione di informazioni rilevanti. Tuttavia, può anche generare lavoro di verifica qualora sia necessario controllare riepiloghi errati o collegamenti non corretti; il fornitore, in genere, segnala i potenziali errori nell'output dei sistemi generativi.
Una progettazione strategicamente solida dovrebbe quindi separare, nel modo più netto possibile, l'archiviazione dei dati, i modelli e le interfacce utente. Ciò consentirebbe di aggiornare i singoli strumenti di analisi senza dover necessariamente sostituire l'intera piattaforma. Soprattutto con le tecnologie di intelligenza artificiale in rapida evoluzione, la capacità di implementare aggiornamenti controllati rappresenta un vantaggio economico, non solo un requisito politico.
Cooperazione internazionale senza dipendenza permanente dal nucleo centrale
Lo scambio di servizi con i partner può richiedere procedure tecniche compatibili. Tuttavia, ciò non significa necessariamente che tutti i processi di lavoro interni debbano svolgersi sulla stessa piattaforma. Le Forze Armate tedesche (Bundeswehr) citano l'interoperabilità internazionale come obiettivo chiave della loro strategia multipiattaforma e la collegano esplicitamente alla riduzione della dipendenza dai fornitori.
Un approccio sensato sarebbe quello di distinguere tra le operazioni nazionali principali e le funzioni di scambio chiaramente definite. Interfacce specializzate e procedure di trasferimento approvate potrebbero essere utilizzate per la cooperazione internazionale, mentre i repository centrali di dati e la collaborazione fondamentale rimarrebbero gestibili in modo indipendente. Il coinvolgimento di un fornitore di tecnologia internazionale sarebbe quindi una decisione funzionalmente limitata e non automaticamente la base per tutti i processi interni.
Tuttavia, le interfacce non risolvono tutti i problemi. Diversi livelli di riservatezza, modelli di dati e regole di rilascio creano un sovraccarico aggiuntivo. Un'architettura più disaccoppiata può quindi inizialmente risultare più costosa e complessa. Il suo vantaggio risiede nel fatto che le singole funzioni di collaborazione possono essere modificate senza influire allo stesso modo sul funzionamento del sistema centrale nazionale. Se questo vantaggio giustifichi i costi aggiuntivi andrebbe valutato in base alle esigenze specifiche.
L'abilità cruciale è la capacità di cambiare
Dal punto di vista tecnico, la prospettiva più convincente non risiede né in un rifiuto indiscriminato della tecnologia americana, né nell'assunto che la separazione delle reti tecniche risolva ogni problema di sovranità. Il progetto ND Cloud potrebbe risolvere i reali problemi di prestazioni; tuttavia, la sua architettura isolata e la continua dipendenza da software esterni devono essere valutate separatamente.
Per una collaborazione generale, le soluzioni aperte più adatte meritano una valutazione sistematica, poiché openDesk e i servizi basati su Matrix sono già elementi costitutivi di uso comune. Per elaborazioni altamente specializzate potrebbero essere richiesti requisiti tecnici diversi. È fondamentale che le eccezioni giustificate non si trasformino in una dipendenza permanente e generalizzata, e che i rischi residui vengano identificati esplicitamente.
Una strategia solida dovrebbe quindi combinare competenze di valutazione interne, processi di aggiornamento trasparenti e piani di emergenza collaudati. Non tutte le applicazioni richiedono una piattaforma secondaria pienamente funzionante e immediatamente disponibile. Tuttavia, le funzioni critiche dovrebbero essere progettate in modo tale che un guasto esterno non comporti necessariamente una perdita di capacità governativa. Ciò richiede misure di sicurezza tecniche, personale qualificato e finanziamenti a lungo termine.
La vera prova di sovranità non si manifesta durante il normale funzionamento senza interruzioni. Inizia nel momento in cui un fornitore cambia le proprie condizioni, l'assistenza viene a mancare o il quadro politico muta. Un cloud ad alte prestazioni è prezioso per lo Stato. Diventa strategicamente gestibile solo quando lo Stato non solo controlla il suo funzionamento attuale, ma dispone anche di opzioni valide per il futuro.
Consulenza - Pianificazione - Implementazione
Sarei felice di fungere da tuo consulente personale.
Responsabile dello sviluppo aziendale
Presidente del gruppo di lavoro sulla difesa SME Connect
Consulenza - Pianificazione - Implementazione
Sarei felice di fungere da tuo consulente personale.
Puoi contattarmi all'indirizzo wolfenstein∂xpert.digital o
Chiamami al numero +49 7348 4088 965 .

