“Sovranità digitale” è una di quelle espressioni che compaiono ovunque e significano cose diverse a seconda di chi le pronuncia. Per un ente pubblico è un requisito di gara; per un’azienda è una voce in un questionario di conformità; per chi costruisce software è, molto più concretamente, la domanda su dove girino i propri server, chi possa leggere i dati che ci passano e cosa succeda se quel fornitore un giorno cambia condizioni. Nel 2026 la conversazione è uscita dagli uffici legali ed è arrivata sulle decisioni di architettura.
Le tre domande che contano
La parola copre almeno tre requisiti diversi, che spesso vengono confusi tra loro:
- Dove risiedono i dati. È il livello più semplice: scegliere una regione europea sul proprio provider cloud. Risolve la questione geografica, non quella giuridica — il fornitore resta lo stesso.
- Chi ha giurisdizione sul fornitore. Un’azienda soggetta a leggi extraeuropee può ricevere richieste di accesso ai dati che gestisce, indipendentemente dal paese in cui si trovano fisicamente i dischi. È qui che la residenza dei dati da sola non basta.
- Chi può leggere i dati tecnicamente. Cifratura a riposo e in transito sono ormai lo standard, ma la domanda successiva è chi custodisce le chiavi. Se le custodisce il fornitore, la protezione è contrattuale prima che tecnica.
Sono tre livelli indipendenti: si può soddisfare il primo e nessuno degli altri due, ed è esattamente quello che succede nella maggior parte delle migrazioni presentate come “sovrane”.
Cosa sta cambiando sul piano tecnico
L’interesse per i modelli AI aperti, eseguibili sulla propria infrastruttura, nasce in buona parte da qui. Mandare documenti interni a un servizio esterno per farli riassumere è comodo, ma sposta un flusso di dati sensibili fuori dal perimetro dell’organizzazione ogni giorno, per sempre. Un modello più piccolo, eseguito su hardware proprio, spesso è meno capace — e per molti compiti è comunque abbastanza, con il vantaggio che il dato non esce mai.
Sul lato infrastruttura, la strada più praticata non è la sostituzione integrale ma la separazione per criticità: i carichi ordinari restano dove sono, quelli che toccano dati personali o proprietà intellettuale vengono isolati su infrastruttura controllata. Meno spettacolare di una migrazione totale, molto più realistica.
I compromessi da mettere in conto
- Servizi gestiti che spariscono. Gran parte del valore di un grande cloud sta nei servizi ad alto livello: code, database gestiti, autenticazione, osservabilità. Ricostruirli altrove significa reintrodurre lavoro operativo che si era smesso di fare.
- Costi che si spostano, non scompaiono. Il risparmio sulla licenza viene spesso mangiato dal tempo delle persone che ora devono aggiornare, monitorare e mettere in sicurezza ciò che prima arrivava già pronto.
- Sicurezza da dimostrare, non da presupporre. Un’infrastruttura autogestita è più sovrana ma non automaticamente più sicura: patch, backup verificati e gestione degli accessi diventano responsabilità interna, ed è lì che si concentrano gli incidenti reali.
- Il lock-in non è solo del fornitore. Costruirsi una piattaforma interna crea una dipendenza dalle poche persone che la conoscono, un rischio meno visibile ma altrettanto concreto.
Suggerimento: prima di parlare di migrazione, fai l’esercizio più noioso e più utile: elenca quali dati escono oggi dalla tua infrastruttura, verso quale servizio e con quale finalità. Nella maggior parte dei progetti la lista è più corta di quanto si tema e contiene una o due voci che non ci si aspettava — ed è da quelle che conviene partire.
Cosa aspettarsi da qui in avanti
La direzione è chiara e non dipende dalle mode: più requisiti contrattuali sulla residenza dei dati, più attenzione a chi detiene le chiavi, più modelli eseguibili in locale con qualità sufficiente. Ma la sovranità digitale utile non è un’etichetta da esibire: è la capacità di rispondere con precisione a dove sono i dati, chi può leggerli e cosa serve per spostarli altrove. Chi sa rispondere a quelle tre domande è già più sovrano di chi ha solo cambiato regione al proprio cloud.