Molte organizzazioni hanno risolto la questione della residenza dei dati nel modo più ovvio: hanno scelto un provider cloud con data center europei. I dati sono fisicamente in Germania, in Irlanda, nei Paesi Bassi. La spunta sulla compliance è messa. Il problema è risolto.
Non lo è.
Non perché tu ne perda la proprietà, ma perché potresti non averne il controllo esclusivo dal punto di vista giuridico e operativo.
C’è una differenza fondamentale, e spesso ignorata, tra dove i dati risiedono fisicamente e chi li controlla davvero. Un dato archiviato su un server in Europa da un provider con sede negli Stati Uniti non è necessariamente sotto giurisdizione europea. Il provider resta soggetto alla giurisdizione statunitense. E questo cambia molto.
Il paradosso che nessuno aveva letto nel contratto
Il CLOUD Act americano (Clarifying Lawful Overseas Use of Data Act) può consentire alle autorità statunitensi di richiedere l’accesso ai dati gestiti da aziende americane, indipendentemente da dove quei dati siano fisicamente archiviati. Se il tuo provider ha sede negli Stati Uniti, i tuoi dati possono essere soggetti a richieste da parte delle autorità americane anche se i server sono a Francoforte.
Questo crea quello che alcune analisi recenti chiamano un “sovereignty gap”: una lacuna di sovranità che non emerge nei report di compliance standard, non appare nelle audit checklist ordinarie, e resta invisibile finché non diventa un problema concreto: un’indagine, una richiesta di accesso, una violazione normativa scoperta tardi.
La residenza dice dove il dato vive. La sovranità riguarda chi esercita un controllo effettivo su di esso: quale giurisdizione si applica, chi può accedervi, chi gestisce le chiavi crittografiche e con quali garanzie. Soddisfare la prima non significa soddisfare la seconda.
Perché il quadro normativo europeo ha reso il problema urgente
Con l’entrata in vigore di NIS2 e delle nuove normative europee, la sovranità digitale è diventata una priorità di board per molte organizzazioni che fino a poco tempo fa la consideravano una preoccupazione di nicchia, rilevante per i governi e le infrastrutture critiche, non per il business ordinario.
Dalla NIS2 al Data Act, passando per il Data Governance Act, l’AI Act e il GDPR, il messaggio è sempre più chiaro: le organizzazioni devono poter dimostrare non solo dove risiedono i dati, ma anche chi li controlla, come vengono gestiti e come se ne garantisce la tracciabilità. Pur con obiettivi diversi, queste normative convergono su un punto comune e chi non riesce a rispondere con chiarezza a queste domande non ha un problema legale. Ha un problema architetturale.
La sovranità dei dati non è solo un requisito normativo. È un elemento di fiducia verso clienti, partner e stakeholder e in settori dove la riservatezza delle informazioni è parte del valore che si offre, non averla progettata è una fragilità che prima o poi diventa visibile.
La distinzione che cambia le decisioni architetturali
Residenza, sovranità e localizzazione sono tre concetti correlati ma distinti, e confonderli è uno degli errori più costosi che le organizzazioni fanno quando progettano la propria infrastruttura dati.
La residenza dice dove il dato è fisicamente archiviato. La sovranità riguarda chi esercita controllo effettivo su quel dato: giurisdizione, accesso, chiavi crittografiche. La localizzazione impone che certi dati non lascino mai un determinato territorio.
Un’organizzazione può soddisfare la residenza, dati in Europa, e avere un provider soggetto a leggi extra-europee. Può soddisfare entrambe e non considerare che durante backup o manutenzione i dati transitano temporaneamente fuori dal perimetro autorizzato.
Nessuna di queste distinzioni è puramente legale. Ognuna ha implicazioni architetturali precise: dove si ospita, con quale provider, come si gestiscono i backup, come si progettano i flussi di accesso, chi detiene le chiavi di cifratura.
Cosa significa progettare per la sovranità
Le organizzazioni che stanno affrontando questo passaggio in modo strutturato non stanno solo cambiando provider. Stanno ripensando l’architettura con cui i dati vengono gestiti: chi li controlla, come vengono cifrati, dove risiedono le chiavi, come vengono tracciate le operazioni di accesso.
Questo richiede scelte che si fanno in fase di progettazione, non a posteriori. Un sistema costruito senza pensare alla sovranità dei dati non diventa sovrano aggiungendo una certificazione o migrando su un data center europeo. Richiede un intervento architetturale che tocca provider, flussi, accessi, cifratura e governance.
Prima di scegliere o confermare un’infrastruttura cloud, vale la pena porsi alcune domande concrete:
- Chi controlla realmente il provider — e a quale giurisdizione è soggetto?
- Dove risiedono le chiavi di cifratura, e chi può accedervi?
- Chi può accedere ai dati in fase di supporto tecnico o manutenzione?
- Dove transitano i dati durante backup e disaster recovery?
- Come viene dimostrata la tracciabilità degli accessi in caso di audit?
Se anche una sola di queste domande non ha una risposta chiara, il problema non è normativo. È architetturale. E le decisioni architetturali si prendono quando si progettano i sistemi, non quando arriva un audit.
La sovranità dei dati non si aggiunge a un’infrastruttura esistente. Si progetta.