Blog Sovranità del cloud in Europa: NIS2, DORA e AI Act

Perché la posizione fisica non garantisce più la conformità

Un tempo bastava scegliere un data center all'interno dei confini nazionali giusti per definire un workload «conforme». Questo presupposto ha silenziosamente smesso di valere. Un server collocato a Francoforte o Amsterdam non ti dice nulla su chi può essere legalmente obbligato a consegnare i dati che contiene, ed è esattamente questa la lacuna che i regolatori hanno lavorato a colmare negli ultimi tre anni.

Tre framework convergono ora sulla stessa domanda: non solo dove risiedono i dati, ma chi può accedervi e se sei in grado di dimostrarlo in un audit. NIS2 copre oltre 160.000 entità in 18 settori e le autorità europee per la protezione dei dati hanno comminato oltre 5,9 miliardi di EUR di sanzioni GDPR da maggio 2018, secondo il monitoraggio dei dati del GDPR Enforcement Tracker effettuato da Vision Compliance. DORA si applica alle entità finanziarie dell'UE e ai loro fornitori ICT critici. L'EU AI Act aggiunge a tutto ciò obblighi infrastrutturali per i sistemi di AI ad alto rischio.

Anche l'argomentazione commerciale si muove con la stessa rapidità. Il sondaggio Digital Sovereignty Trilemma di Insight, condotto da Coleman Parkes tra dicembre 2025 e gennaio 2026 su 900 decision-maker senior di organizzazioni con oltre 500 dipendenti in nove Paesi europei, ha rilevato che il 67% delle organizzazioni considera già la sovranità digitale un fattore strategico critico, quota che sale al 78% entro uno o due anni e all'82% entro tre. Il 55% ha indicato la complessità normativa come una delle principali sfide strategiche e il 43% aveva già utilizzato solide credenziali di sovranità per acquisire o mantenere clienti. Si tratta di risultati di un sondaggio commissionato da un vendor e non di statistiche ufficiali, quindi vanno interpretati come un orientamento del sentiment di settore più che come un dato assodato.

Quanto segue mappa il panorama normativo così com'è nel 2026, ciò che ciascun framework richiede concretamente alla tua architettura cloud e come le organizzazioni che costruiscono su Azure, AWS o Google Cloud possono raggiungere una postura pronta alla sovranità senza sostenere un sovrapprezzo di conformità che non riescono a giustificare internamente.

Lo stack normativo europeo e perché si comporta come un unico sistema

GDPR, NIS2, DORA e l'AI Act non sono arrivati come quattro checklist scollegate, anche se la maggior parte dei team di compliance continua a gestirli così. Entro il 2026 spingono verso gli stessi tre obiettivi: sapere con esattezza dove risiedono i dati, controllare chi può accedervi ed essere in grado di dimostrare, con prove concrete anziché con rassicurazioni, di poter continuare a operare durante un guasto o un audit.

La sovrapposizione è più marcata per le organizzazioni dei settori finanza, sanità, energia e pubblica amministrazione, dove una singola lacuna nei controlli può far scattare obblighi sotto due o tre regimi contemporaneamente.

NIS2: obblighi di cybersecurity in 18 settori, con responsabilità personale annessa

NIS2, la rinnovata Direttiva sulla sicurezza delle reti e dei sistemi informativi introdotta dall'UE nel 2023, sostituisce un predecessore più limitato con obblighi vincolanti che riguardano oltre 160.000 entità. Introduce requisiti di gestione del rischio, responsabilità a livello di consiglio di amministrazione, scadenze per la segnalazione degli incidenti e obblighi di sicurezza della catena di fornitura, con responsabilità personale per il senior management nei casi in cui venga accertata la non conformità.

La direttiva suddivide le organizzazioni soggette agli obblighi in due livelli:

• Entità essenziali: grandi operatori nei settori energia, trasporti, banche, sanità e infrastrutture digitali, soggetti a vigilanza proattiva e all'applicazione più rigorosa.
• Entità importanti: organizzazioni di medie dimensioni negli stessi settori, soggette allo stesso standard tecnico ma a una vigilanza reattiva anziché proattiva.

Quattro elementi che NIS2 si aspetta che un consiglio di amministrazione sia in grado di dimostrare:

1. Titolarità del rischio. Il consiglio di amministrazione approva le misure di cybersecurity e ne supervisiona l'attuazione; non farlo può comportare responsabilità personale.
2. Requisiti di sicurezza. L'articolo 21 della direttiva NIS2 definisce misure di base, tra cui la gestione degli incidenti, la continuità operativa e la gestione delle crisi.
3. Sicurezza della catena di fornitura. Anche i vendor e i fornitori di servizi devono vedere valutate le proprie pratiche di cybersecurity, non soltanto le tue.
4. Segnalazione degli incidenti. Le entità essenziali devono notificare il proprio CSIRT nazionale entro 24 ore da un incidente significativo, con una relazione più completa da presentare entro 72 ore.

In pratica, NIS2 porta il rigore nella gestione delle identità, il logging a prova di manomissione, la governance dei fornitori e la segnalazione degli incidenti entro tempi definiti direttamente nel livello della piattaforma. La parola chiave è dimostrabile: un auditor deve poter tracciare i tuoi controlli attraverso la telemetria e i registri delle modifiche, senza doversi fidare sulla parola.

Le sanzioni sono concrete e graduate: le entità essenziali rischiano multe fino a 10 milioni di EUR o al 2% del fatturato annuo mondiale, a seconda di quale importo sia più elevato, mentre le entità importanti rischiano fino a 7 milioni di EUR o all'1,4% del fatturato. Questi importi si applicano per singolo Stato membro, quindi un'organizzazione con controllate in diversi Paesi dell'UE è esposta separatamente in ciascuno di essi.

DORA: la resilienza operativa come qualcosa che devi dimostrare, non solo pianificare

Il Digital Operational Resilience Act (DORA) impone standard di resilienza operativa alle entità finanziarie dell'UE e ai loro fornitori ICT ed è diventato applicabile a gennaio 2025. Richiede strategie di uscita documentate e testate per i fornitori critici, diritti di audit contrattuali, controlli sul rischio di concentrazione ICT e un monitoraggio continuo dei terzi.

L'ambito di applicazione è determinato dall'attività, non dal numero di dipendenti. Una FinTech di 50 persone che elabora pagamenti è soggetta agli stessi obblighi di una grande banca.

DORA standardizza la gestione del rischio ICT nell'intero settore: failover testati, obiettivi misurati di tempo e punto di ripristino, test guidati dalle minacce dove applicabili e un registro degli accordi ICT con terze parti che corrisponda davvero a ciò che è in esecuzione in produzione. La resilienza è di fatto diventata un requisito di prodotto anziché una voce in un piano di disaster recovery.

L'implicazione architetturale è l'aspetto più netto. La strategia di uscita obbligatoria prevista dall'articolo 28 impone alle entità finanziarie di mantenere un piano documentato, testato e verificabile per abbandonare qualsiasi fornitore ICT critico senza interrompere il servizio. Se la tua piattaforma è strettamente vincolata alle API proprietarie di un singolo vendor, quel «piano di uscita» può tradursi in pratica in una migrazione pluriennale: non un piano di emergenza, ma un lock-in travestito da conformità.

Cosa dovrebbero fare ora le organizzazioni finanziarie europee:

1. Verificare ogni contratto cloud esistente rispetto ai requisiti di strategia di uscita dell'articolo 28.
2. Classificare i workload per criticità e segnalare quali dipendono da servizi gestiti di un unico provider.
3. Iniziare a documentare l'architettura della strategia di uscita a livello aziendale, prima che una crisi imponga la decisione.
4. Assicurarti che il registro dei rischi ICT relativi a terze parti copra ogni provider cloud, con un monitoraggio continuo anziché una verifica una tantum.

L'EU AI Act: un obbligo infrastrutturale nascosto dentro una normativa sull'AI

L'EU AI Act (Regolamento 2024/1689) è la prima normativa organica specifica per l'AI nel suo genere e classifica i sistemi di AI in base al rischio, imponendo ai sistemi ad alto rischio requisiti di data governance, verificabilità e infrastruttura. Raggiunge la piena applicazione il 2 agosto 2026 e le sanzioni possono arrivare al 7% del fatturato annuo globale.

Molti prodotti SaaS non si rendono conto di rientrare nell'ambito di applicazione: gli strumenti di valutazione del merito creditizio nel FinTech, lo screening dei CV nell'HR tech e le funzionalità affini ai dispositivi medici nell'HealthTech possono rientrare tutti nelle categorie ad alto rischio dell'Allegato III. Il problema infrastrutturale è diretto: le piattaforme SaaS che girano su servizi di AI condivisi e gestiti dagli hyperscaler spesso non riescono a produrre la tracciabilità a livello infrastrutturale richiesta dal regolamento. Gli ambienti self-hosted o sovrani rendono possibile una documentazione completa della data lineage in un modo che i servizi condivisi multi-tenant di norma non consentono.

Per i team infrastrutturali, questo si traduce in ambienti di addestramento e inferenza separati, documentazione dei dataset, artefatti di valutazione e percorsi di rollback, tutti elementi decisamente più semplici da realizzare quando il perimetro dei dati e la gestione delle chiavi risiedono all'interno di un'unica giurisdizione, semplice e definita.

Residenza dei dati e sovranità dei dati: la distinzione che determina la tua postura di conformità

L'equivoco più costoso oggi nella conformità cloud europea è trattare residenza e sovranità come se fossero la stessa cosa. Non lo sono, ed è proprio nel divario tra le due che si concentra la maggior parte dell'esposizione normativa.

Un hyperscaler statunitense che gestisce server su suolo UE ti garantisce la residenza. Non ti garantisce la sovranità: la legge statunitense può imporre la divulgazione dei dati indipendentemente da dove si trovi fisicamente l'hardware. Secondo l'analisi di SoftwareSeni relativa al Cloud Sovereignty Framework della Commissione europea di ottobre 2025, gli hyperscaler statunitensi controllano oltre il 70% del mercato cloud dell'UE e restano soggetti a leggi statunitensi extraterritoriali, in particolare il CLOUD Act e la FISA, che possono imporre l'accesso ai dati a prescindere dalla posizione dei server. La maggior parte dei workload regolamentati necessita ora della sovranità, e non della sola residenza, per soddisfare i propri obblighi.

Lo scenario del «kill switch»: perché la posizione da sola non ti protegge

La ricerca Digital Sovereignty Trilemma di Insight lo esprime con precisione: il 67% afferma che mantenere la sovranità digitale è un fattore critico nelle decisioni strategiche di business odierne, quota che sale al 78% entro uno o due anni e all'82% entro tre o più anni. Il settore pubblico guida questo cambiamento, con il 73% che considera la sovranità digitale cruciale per le proprie decisioni strategiche, a riflesso di una maggiore attenzione alla sicurezza nazionale e alla protezione giurisdizionale.

La resilienza operativa, in pratica, poggia oggi sulla sovranità digitale: la capacità di mantenere il controllo tecnico sui tuoi sistemi e sulle tue chiavi di crittografia a prescindere da interferenze esterne. Insight lo descrive in modo diretto: immagina una giurisdizione straniera che eserciti la propria autorità sul tuo provider cloud e di fatto azioni un kill switch sui tuoi sistemi aziendali. Non è uno scenario IT, ma una minaccia alla continuità operativa senza soluzioni semplici una volta che si verifica. La stessa ricerca ha rilevato che il 32% delle organizzazioni dà ora priorità alla resilienza e alla continuità della catena di fornitura nella valutazione della strategia cloud, davanti al controllo dei costi (20%) e alla velocità di time-to-market (16%).

Anche laddove esistano sulla carta meccanismi legali di trasferimento, la maggior parte dei consigli di amministrazione preferisce ora ridurre direttamente la propria esposizione: mantenere i workload e la telemetria sensibili all'interno del SEE e detenere le chiavi sotto la giurisdizione dell'UE. È una postura che riduce il rischio, semplifica gli audit e rende molto più facile spiegare le responsabilità a posteriori.

Quanto costa realmente la non conformità

Le conseguenze finanziarie non sono più teoriche. Secondo il monitoraggio dei dati sulle sanzioni di Vision Compliance, le autorità europee per la protezione dei dati hanno comminato circa 5,9 miliardi di EUR di sanzioni GDPR da quando il regolamento è entrato in vigore, a maggio 2018 (con le prime 10 sanzioni che da sole rappresentano oltre 4,5 miliardi di EUR), e il Cost of a Data Breach Report 2025 di IBM stima il costo medio di una violazione nell'UE in 4,57 milioni di EUR. Vale la pena segnalarlo: nello stesso report i dati globali di IBM sono espressi altrove in USD (una media globale di 4,44 milioni di dollari e 4,18 milioni di dollari nello specifico per le violazioni su cloud pubblico), quindi assicurati di confrontare il dato in euro specifico per l'UE e di non mescolarlo con quello globale in dollari. A otto anni dall'avvio dell'applicazione, solo circa un terzo delle organizzazioni (il 34%, secondo il Cisco Data Privacy Benchmark Study 2025) dichiara una piena conformità al GDPR.

Il lato degli sprechi è meglio documentato. La ricerca Digital Sovereignty Trilemma di Insight stima lo spreco di capacità cloud in Europa al 24% annuo, dovuto principalmente a risorse inattive o orfane, a una scarsa visibilità tra gli ambienti e a una governance debole. L'AI ha determinato un aumento del 12% dei costi di hosting in un solo anno e il 56% delle organizzazioni non effettua una valutazione del Total Cost of Ownership prima di decisioni significative sul posizionamento dei workload, sempre secondo lo stesso sondaggio.

Costruire un'unica architettura sovrana anziché quattro flussi di conformità paralleli

L'errore più comune non è un controllo mancante: è gestire GDPR, NIS2, DORA e l'AI Act come checklist separate che non convergono mai davvero, pur sovrapponendosi nei controlli, nelle catene di reporting e nei modelli di rischio che i regolatori si aspettano di vedere. Se mappi l'intento comune, ossia limitare il rischio sistemico, applicare controlli verificabili e proteggere i dati dei cittadini europei, gran parte delle decisioni architetturali diventa piuttosto evidente.

Cinque principi definiscono il modello che tende a superare un audit normativo europeo:

1. Multi-region esclusivamente UE con failover verificabile. Utilizza almeno due località UE indipendenti. Mantieni produzione, snapshot e copie di DR all'interno del SEE. Esegui failover controllati con cadenza programmata e conserva le prove con lo stesso rigore riservato ai documenti finanziari.
2. Gestione deterministica delle chiavi. Adotta un KMS residente nell'UE con titolarità esplicita. Per i workload rilevanti, utilizza il bring-your-own-key o l'hold-your-own-key supportati da root of trust hardware e da una custodia ripartita.
3. Governance dell'egress di rete. Chiudi l'egress predefinito. Elenca le destinazioni consentite tramite policy e documenta il motivo per cui ciascuna esiste.
4. Operatività incentrata sulle prove. Centralizza log, cronologia delle configurazioni e tracce degli accessi privilegiati in archivi immutabili e gestiti lungo il loro ciclo di vita. La piattaforma dovrebbe essere in grado di rispondere alle domande su chi, cosa, quando e dove senza ricorrere a script improvvisati durante un incidente.
5. Uscita e portabilità by design. Progetta la strategia di uscita fin dall'inizio, non dopo aver firmato un contratto. Utilizza immagini VM standard e formati di dati aperti. Mantieni i playbook di ripristino e migrazione sotto controllo di versione e provali davvero: la tua portabilità vale solo quanto l'ultima volta in cui l'hai dimostrata.

Trasformare la conformità in un vantaggio competitivo

La sovranità non deve necessariamente comportare un sovrapprezzo permanente. Le organizzazioni che ottengono i risultati migliori in tema di conformità in Europa sono in genere quelle che la trattano come un principio di progettazione fin dal primo giorno, anziché come qualcosa da aggiungere dopo che un regolatore ha posto domande.

L'approccio di Insight progetta framework di conformità sovrana che mantengono le operazioni attive 24 ore su 24 senza restare in ostaggio dei cambiamenti nelle licenze dei vendor o delle modifiche alle normative regionali sui dati. Attraverso i FinOps e Hybrid Cloud Assessment, Insight ricolloca i workload ad alta intensità nell'ambiente realmente più conveniente in termini di costi. Insight riferisce che i clienti recuperano tipicamente circa il 12% del proprio budget di hosting da reinvestire in AI e R&S, un dato che deriva dalle attività di Insight con i propri clienti e non da una media di settore verificata in modo indipendente.

Evitare la tassa sulla sovranità con il FinOps

La pagina della campagna Digital Sovereignty di Insight attribuisce a Gartner l'affermazione alla base di tutto ciò: poiché il 56% delle organizzazioni non effettua una valutazione del TCO prima di spostare i workload, la maggior parte paga inconsapevolmente un sovrapprezzo del 15-30% per un'infrastruttura «conforme». I FinOps e Hybrid Cloud Assessment di Insight individuano risparmi nella stessa fascia del 15-30%, come benchmark interno derivante dalle attività con i clienti, da validare rispetto al profilo dei tuoi workload anziché considerare un risultato garantito.

I servizi FinOps di Insight incontrano le organizzazioni in qualsiasi punto del percorso si trovino: individuando sprechi e risorse inutilizzate, allineando i team, ottimizzando i costi e rafforzando la governance, con l'obiettivo di una governance migliore, costi più bassi e una collaborazione più stretta tra finanza e ingegneria.

Esplora i servizi FinOps di Insight per scoprire dove la tua organizzazione potrebbe silenziosamente finanziare inefficienze legate alla conformità.

Preparazione a NIS2: dalla gap assessment alla fiducia a livello di consiglio di amministrazione

L'approccio di Insight alla conformità NIS2 si basa sui processi esistenti e tiene conto delle direttive UE che si sovrappongono, anziché trattare NIS2 come un esercizio isolato, dando priorità fin dall'inizio alla gestione del rischio e alla segnalazione degli incidenti. Insight offre un NIS2 Awareness Workshop per preparare i team di senior management, oltre a un NIS2 Assessment Service per individuare le lacune e produrre una roadmap di conformità su misura.

Cosa significa tutto ciò per la strategia cloud europea

NIS2, DORA, l'EU AI Act e la più ampia agenda europea sulla sovranità dei dati non sono questioni future da pianificare. Sono rischi di business già attivi, con attività di enforcement, sanzioni finanziarie e ricadute reputazionali che si stanno già manifestando in tutto il continente.

Le organizzazioni meglio posizionate per i prossimi anni sono quelle che trattano resilienza operativa, agilità ed efficienza dei costi come un unico framework strategico anziché come tre priorità in competizione: progettando per la sovranità fin dall'inizio, pur mantenendo una flessibilità sufficiente ad adattarsi mentre il panorama normativo continua a cambiare, perché continuerà a cambiare.

Le organizzazioni che progettano fin dall'inizio in ottica di sovranità non si limitano ad affrontare meglio il prossimo shock normativo. Tendono a conquistare più clienti proprio grazie a questo. La resilienza ha smesso di essere una voce di spesa difensiva: è un'argomentazione commerciale.