Per molto tempo, le decisioni tecnologiche sono state valutate attraverso una serie di domande familiari: è più veloce? È più economico? Può scalare? Renderà il team più produttivo?
Queste domande contano ancora. Non bastano più.
Quando un'organizzazione si affida a infrastrutture, piattaforme e, sempre più spesso, modelli di AI esterni, una domanda più difficile viene prima: che cosa succede quando cambiano le condizioni? Che cosa succede quando l'accesso diventa più costoso, limitato, politicamente esposto o difficile da spiegare a un regolatore, al consiglio di amministrazione o a un cliente?
Questa è la questione della sovranità nell'IT e nell'AI.
Non riguarda solo il luogo in cui risiedono i dati. Riguarda il controllo in senso più ampio: chi può ispezionare il sistema, interromperlo, imporre l'accesso, cambiare le regole o rendere difficile uscirne. Riguarda anche la responsabilità. Quando qualcosa va storto, chi resta responsabile?
Non esiste un'unica definizione globale di sovranità digitale. Giurisdizioni diverse mettono l'accento su aspetti diversi: portata giuridica, dipendenza dall'infrastruttura, controllo dei dati, resilienza operativa, concentrazione dei fornitori e, sempre più, controllo sul livello dei modelli di AI. Il filo conduttore è pratico, non ideologico.
La sovranità è la capacità di mantenere un controllo significativo sulle capacità digitali da cui un'organizzazione dipende maggiormente.
Questo non significa che ogni Paese o azienda debba costruire tutto da sé. Significa sapere dove la dipendenza è accettabile, dove è pericolosa e quale controllo deve restare interno o essere contrattualmente esigibile.
La sovranità non è autosufficienza
La sovranità viene spesso confusa con l'autosufficienza o con la residenza dei dati. Nessuna delle due coglie l'intero problema.
Un'azienda può conservare i propri dati nella giusta giurisdizione ed essere comunque esposta se la piattaforma circostante è difficile da abbandonare, il fornitore resta soggetto a richieste legali straniere oppure i sistemi di AI integrati nei flussi di lavoro critici non possono essere sottoposti ad audit né influenzati dal cliente.
L'AI rende questa distinzione più urgente. Un modello non è solo un altro componente software. Può plasmare il modo in cui un'organizzazione scrive, cerca, classifica, supporta i clienti, analizza le informazioni e prende decisioni. Quando questo accade, la dipendenza sale di livello nello stack. La domanda non è più soltanto dove gira una macchina. È chi plasma l'intelligenza all'interno del lavoro.
La maggior parte delle organizzazioni se ne accorge nelle normali attività operative. Un fornitore cambia i prezzi e un caso d’uso prima sostenibile diventa improvvisamente costoso. Un aggiornamento del modello modifica gli output e i flussi di lavoro interni devono essere ricalibrati. I team legali o di compliance pongono domande semplici sulla gestione dei dati e ricevono risposte vaghe. Il procurement scopre che un’architettura apparentemente flessibile sarebbe costosa e lenta da sostituire.
Non serve una crisi geopolitica. Basta la dipendenza ordinaria.
Un dibattito globale con un linguaggio giuridico diverso
La questione è globale, anche dove la terminologia è diversa.
Negli Stati Uniti, la preoccupazione viene spesso espressa in termini di autorizzazione federale e controlli di sicurezza nazionale, più che con l’espressione sovranità digitale. FedRAMP fornisce un approccio standardizzato per valutare, autorizzare e monitorare in modo continuo i servizi cloud utilizzati dalle agenzie federali. Le agenzie restano responsabili dei propri workload anche dopo averli spostati nel cloud, e gli ambienti della difesa aggiungono ulteriori requisiti.
Nel Regno Unito, la questione tende a essere inquadrata in termini di resilienza operativa e dipendenza sistemica. La Bank of England, la PRA e la FCA hanno istituito un regime per i Critical Third Parties perché una grave interruzione presso un fornitore esterno può creare un rischio non solo per una singola impresa, ma per l’intero sistema finanziario.
Il profilo canadese di controllo del cloud per le informazioni Protected B rende esplicito il principio di accountability: le responsabilità possono essere delegate ai fornitori cloud, ma l’accountability non scompare con il passaggio di consegne.
L’India abbina requisiti di localizzazione dei dati per i dati dei sistemi di pagamento all’aspettativa che le entità regolamentate restino responsabili degli accordi di outsourcing IT e cloud. Singapore accoglie l’adozione del cloud, trattandola però come un’attività di outsourcing che deve essere governata. Anche Australia, Brasile e Sudafrica affrontano la questione attraverso la resilienza operativa, il rischio dei fornitori di servizi, l’accesso da parte delle autorità di vigilanza, la governance dei dati e le infrastrutture strategiche.
Lo schema è chiaro. La sovranità non è una preoccupazione di nicchia europea. È una risposta ampia al fatto che la dipendenza digitale è diventata strategica.
Perché l’approccio europeo è importante
L’Europa ha portato il concetto più avanti della maggior parte delle giurisdizioni, trasformandolo in un quadro di procurement e valutazione.
Il Cloud Sovereignty Framework della Commissione europea valuta i fornitori di sovereign cloud rispetto a otto obiettivi: considerazioni strategiche, legali e giurisdizionali, relative a dati e AI, operative, di supply chain, tecnologiche, di sicurezza e compliance, e ambientali. Utilizza due meccanismi complementari:
- Sovereignty Effectiveness Assurance Level (SEAL): un livello minimo di assurance per ciascun obiettivo.
- Overall sovereignty score: un confronto ponderato tra le offerte che soddisfano la soglia SEAL richiesta.
La distinzione è importante. Il SEAL complessivo è determinato dal livello rilevante più basso raggiunto tra gli obiettivi. Una debolezza seria in un’area critica può quindi limitare il livello complessivo del fornitore, indipendentemente dai punti di forza altrove. Il punteggio ha uno scopo diverso: distinguere tra offerte che hanno già superato la soglia minima.
Il livello segue una logica di soglia; il punteggio una logica comparativa.
Le linee guida della Commissione lasciano all’autorità contraente margine per fissare il SEAL minimo richiesto per una procedura di procurement, e poi confrontare le offerte qualificate attraverso il punteggio. La sua procedura di procurement per il sovereign cloud del 2026 richiedeva ai fornitori di raggiungere almeno SEAL-2. Il framework riconosce anche diversi gradi di sovranità: SEAL-2 è associato alla sovranità dei dati, SEAL-3 alla resilienza digitale e SEAL-4 alla piena sovranità digitale.
Il livello più alto è deliberatamente molto esigente. La Commissione osserva che la piena sovranità resta difficile nell’attuale contesto europeo a causa delle dipendenze ancora presenti nelle supply chain, in particolare per hardware e chip. Questo è un utile correttivo al pensiero binario. Un servizio può migliorare la postura di sovranità di un’organizzazione senza soddisfare la definizione più forte immaginabile di sovranità.
Per questo il framework è più di una checklist. Costringe il concetto a reggere il confronto con il procurement, l’ingegneria, la revisione legale e l’accountability istituzionale.
Perché questo conta anche oltre i settori regolamentati
Banche, operatori telecom, organizzazioni della difesa, sistemi sanitari e autorità pubbliche tendono ad avvertire per primi queste pressioni perché la regolamentazione rende visibile ciò che è in gioco. La vulnerabilità di fondo è molto più ampia.
Un produttore che dipende da una singola regione di un hyperscaler per l’analisi della produzione, un’azienda software che ha costruito funzionalità fondamentali attorno a un unico fornitore di modelli, un retailer che si affida a un’infrastruttura di identità esterna o un’università che integra strumenti di AI di terze parti nella ricerca e nell’amministrazione si trovano tutti ad affrontare varianti dello stesso problema.
Una parte del rischio è geopolitica. Controlli sulle esportazioni, sanzioni, interventi di sicurezza nazionale e richieste legali transfrontaliere possono penetrare nello stack tecnologico più a fondo di quanto molte organizzazioni avessero previsto. Un’altra parte è strutturale: un numero ristretto di imprese sostiene una quota ampia della capacità globale di cloud, piattaforme, identità e AI. Le loro capacità sono spesso eccellenti. Ed è proprio per questo che la dipendenza può diventare profonda.
L’AI rende il problema più acuto perché i servizi esterni diventano capacità interne. Quando un modello viene integrato nei flussi di lavoro del supporto, nella redazione, nella ricerca, nella revisione della conformità o nell’esperienza di prodotto, diventa parte del modo in cui l’organizzazione pensa e opera. Se quel livello è difficile da verificare, governare o sostituire, la dipendenza non è più soltanto tecnica. Diventa manageriale e strategica.
Cosa aiuta a vedere la lente della sovranità
La sovranità si comprende meglio come una disciplina del giudizio, non come una richiesta di indipendenza totale.
La domanda utile non è se un’organizzazione controlli tutto. Quasi nessuna può farlo. La domanda migliore è: quale obiettivo di sovranità è più debole, e perché?
Il fattore limitante è la proprietà e la governance? L’esposizione legale? Il controllo dei dati? La dipendenza operativa? La fragilità della supply chain? Il lock-in tecnologico? O il livello stesso dell’AI?
Una volta che questo è visibile, la risposta diventa concreta. Alcune organizzazioni hanno bisogno di diritti di audit e di uscita più solidi. Altre hanno bisogno di limiti giurisdizionali più stringenti per dati o carichi di lavoro specifici. Alcune possono mantenere determinate funzioni portabili tra diversi fornitori di cloud o di modelli, anche se questo comporta costi aggiuntivi. Altre possono accettare una dipendenza gestita in aree meno critiche, mantenendo però un controllo più forte sui sistemi che determinano resilienza, accountability o vantaggio competitivo.
Questo è il valore della lente della sovranità. Non prescrive un’unica conclusione politica né richiede una drastica autosufficienza tecnologica. Offre alle organizzazioni un modo disciplinato per individuare il loro obiettivo rilevante più debole, capire perché lo sia e decidere se l’esposizione sia accettabile.
Questa domanda ora si applica all’infrastruttura, ai dati e, sempre più, anche all’AI.
Fonti
- Commissione europea: spiegazione del Sovereign Cloud Framework (2026)
- Commissione europea: Cloud Sovereignty Framework — linee guida per l’implementazione (2026)
- Commissione europea: la Commissione promuove la sovranità del cloud attraverso appalti strategici (2026)
- APRA: CPG 230 Gestione del rischio operativo
- U.S. General Services Administration: Sicurezza del cloud
- Bank of England, PRA e FCA: Terze parti critiche per il settore finanziario del Regno Unito
- Governo del Canada: Profilo dei controlli di sicurezza per i servizi GC basati su cloud
- Reserve Bank of India: FAQ sulla conservazione dei dati dei sistemi di pagamento
- Reserve Bank of India (Commercial Banks – Managing Risks in Outsourcing) Directions, 2025
- Monetary Authority of Singapore: Cloud
- Banco Central do Brasil: Resolução CMN nº 4.893
- Governo del Sudafrica: Politica nazionale su dati e cloud (2024)
