Article. What i write

Cloud repatriation: perché sovranità dei dati e compliance stanno cambiando il cloud

Pubblicato il 30 luglio 2026 su CyberSecurity360.it
Le organizzazioni stanno rivalutando dove collocare i propri workload, riportandone una parte dai public cloud iperscalabili verso infrastrutture on-premises, private cloud o data center in colocation. Ecco cos’è il fenomeno della cloud repatriation e cosa implica
Vincenzo Calabro' | Cloud repatriation: perché sovranità dei dati e compliance stanno cambiando il cloud Dopo oltre un decennio di paradigma cloud-first, un numero crescente di organizzazioni sta rivalutando dove collocare i propri workload, riportandone una parte dai public cloud iperscalabili verso infrastrutture on-premises, private cloud o data center in colocation. Questo fenomeno, noto come cloud repatriation, che potrebbe apparire un’abdicazione al cloud, è piuttosto la sua maturazione verso una disciplina di workload placement basata sull’evidenza. Ecco i quattro fattori che spingono questo fenomeno (sicurezza, data sovereignty e compliance, economia del Total Cost of Ownership, architettura hybrid e multi-cloud) e le implicazioni operative per il CISO e per il SOC.

Il fenomeno della Cloud repatriation

La repatriation è una ridefinizione del perimetro su cui ricade la responsabilità della sicurezza. A partire dal 2010, la migrazione verso il public cloud è stata considerata una scelta obbligata: l’elasticità, il time-to-market e la delega della gestione infrastrutturale sembravano argomenti sufficienti a chiudere la questione. Quel consenso, oggi, si è incrinato. Le survey più recenti, invece, registrano un movimento contrario, parziale ma ormai strutturale: secondo il 2025 State of the Cloud Report di Flexera la repatriation verso infrastrutture private od on-premises è in corso. Circa un quinto dei workload e dei dati è già ricollocato. Invece la 2H24 CIO Survey di Barclays riporta che oltre l’80% dei CIO intende spostare almeno una parte dei workload fuori dal public cloud [9][10]. Prima di tutto, però, è necessario dimensionare il fenomeno per evitare di cadere nella retorica dell’esodo dal cloud. I dati IDC indicano che solo l’8–9% delle organizzazioni prevede una repatriation totale; nella stragrande maggioranza dei casi si tratta di workload selezionati (basi di dati, backup, capacità di calcolo a domanda costante), mentre la spesa cloud complessiva continua a salire: Gartner stima che nel 2025 la end-user spending mondiale raggiungerà i 723,4 miliardi di dollari, con un aumento del 21,5% rispetto all’anno precedente [11][12]. La repatriation, insomma, convive con l’espansione del cloud. Per chi si occupa di sicurezza, questo riassestamento non riguarda solo l’infrastruttura o i conti. Spostare un workload significa ridisegnare il perimetro su cui si esercita il controllo, ridistribuire le responsabilità previste dal shared responsibility model e modificare l’esposizione normativa. I paragrafi che seguono esaminano i quattro vettori del fenomeno dal punto di vista del CISO e del SOC.

La misura del fenomeno e una definizione operativa

Con il termine cloud repatriation si intende la ricollocazione selettiva di workload dal public cloud iperscalare verso private cloud, infrastruttura on-premises o data center in colocation gestiti, quando l’economia, le prestazioni, la giurisdizione o i vincoli di uscita rendono questa collocazione la più appropriata [18]. La letteratura di settore separa due varianti: la full repatriation, in cui rientra l’intero stack applicativo, e la partial repatriation, in cui tornano singoli componenti, di norma i più costosi o i più sensibili dal punto di vista della data gravity. È quest’ultima a dominare nettamente. Il dato che meglio sintetizza l’attuale fase di maturità è la centralità delle architetture ibride: circa il 70% delle imprese opera in ambienti hybrid, con almeno un public e un private cloud, e la repatriation è uno dei fattori che alimentano questo mix [9]. IlPrivate Cloud Outlook 2025 di Broadcom segnala che il 53% delle organizzazioni considera il private cloud prioritario per i nuovi workload nei prossimi tre anni, che circa due terzi stanno valutando una repatriation e che un terzo l’ha già messa in atto [16].

I criteri

Si colloca ogni workload dove il costo, il controllo e la qualità del servizio trovano il miglior equilibrio, conservando la possibilità di spostarlo di nuovo quando i segnali cambiano [18]. Questo è il criterio che si sta affermando.

Sicurezza: il perimetro di controllo e lo shared responsibility model

Il public cloud non è di per sé meno sicuro dell’on-premises. La sua sicurezza, però, dipende in modo decisivo da come si ripartiscono le responsabilità tra fornitore e cliente. Il Cloud Security Study 2024 di Thales ha rilevato che il 44% delle organizzazioni ha subito una violazione dei dati in ambiente cloud; tra le cause prevalenti figurano la misconfiguration e l’errore umano (31%), lo sfruttamento di vulnerabilità note (28%) e la mancata applicazione della multi-factor authentication (17%) [13]. Sono incidenti in larga parte evitabili, e quasi tutti ricadono nella responsabilità del cliente del shared responsibility model. Il dato di costo lo conferma: secondo l’IBM Cost of a Data Breach Report 2025, una violazione costa in media 4,44 milioni di dollari a livello globale e quelle che interessano dati sparsi su più ambienti (public cloud, private cloud e on-premises) risultano le più onerose, con un costo medio di 5,05 milioni di dollari, oltre a essere tra le più lente da contenere.

I due fronti della Cloud repatriation

Per la repatriation, questo conta su due fronti.

Da un lato, la complessità del shared responsibility model tende ad aumentare con l’eterogeneità degli ambienti: la gestione di migliaia di configurazioni distribuite su più piattaforme aumenta le possibilità di errore, ed è una delle ragioni per cui gli ambienti hybrid e multi-cloud mostrano una propensione maggiore a misconfiguration, monitoraggio frammentato e lacune di compliance [14][15]. Dall’altro lato, riportare un workload sensibile on-premises non elimina il rischio, lo trasferisce. Il perimetro torna sotto controllo diretto, ma con esso rientrano gli oneri di patching, hardening, gestione delle chiavi e detection, che il SOC deve essere pronto ad assorbire.

La concentrazione

C’è poi la questione della concentrazione. Isolare i carichi su infrastruttura dedicata elimina l’effetto noisy neighbour e riduce la superficie condivisa, ma sostituisce il rischio sistemico del fornitore con un rischio operativo interno, che richiede competenze e un presidio costante. La repatriation per motivi di sicurezza, perciò, ha senso solo se accompagnata da una valutazione realistica di quanto l’organizzazione sia in grado di gestire in proprio ciò che prima delegava.

Sovranità e compliance: il quadro normativo europeo

È sul terreno della data sovereignty che la repatriation acquista oggi il suo significato più strategico, soprattutto in Europa. Con la sentenza Schrems II (causa C-311/18, 16 luglio 2020), la Corte di Giustizia dell’Unione Europea ha invalidato il Privacy Shield UE-USA, imponendo una valutazione caso per caso dei meccanismi di trasferimento transfrontaliero e misure supplementari anche dove si applicano le Standard Contractual Clauses [2]. Per il GDPR la sovranità dipende dall’autorità giuridica cui resta soggetto e non da dove il dato risiede: un dato europeo continua a essere governato dal diritto EU ovunque si trovi. Da qui l’attrito strutturale con lo US CLOUD Act, che consente alle autorità statunitensi di esigere la divulgazione dei dati detenuti dai fornitori soggetti alla giurisdizione USA, a prescindere dalla loro localizzazione [8].

Il panorama normativo europeo

Su questo presupposto, negli ultimi diciotto mesi si è stratificata una serie di norme che il CISO non può permettersi di ignorare:
  • NIS2 (Direttiva (UE) 2022/2555), con termine di recepimento il 17 ottobre 2024 ed entrata in vigore nel corso del 2025, estende gli obblighi di gestione del rischio, di incident reporting in tempi ristretti e di responsabilità a livello manageriale a un ampio spettro di settori, ponendo le autorità nazionali in una posizione di supervisione diretta dei sistemi che sostengono funzioni essenziali [5].
  • DORA (Regolamento (UE) 2022/2554), entrato in vigore il 17 gennaio 2025, introduce un quadro armonizzato di ICT risk management per il settore finanziario e, soprattutto, l’oversight diretto dei critical ICT third-party providers (CTPP). Il 18 novembre 2025, ai sensi dell’art. 31(9) DORA, le European Supervisory Authorities (EBA, EIOPA, ESMA) hanno pubblicato la prima lista ufficiale di 19 CTPP, che include i principali hyperscaler (AWS, Google Cloud, Microsoft, oltre a Oracle, SAP e operatori di data center e telecomunicazioni) [4]. Per le entità finanziarie ciò comporta obblighi contrattuali e di governance specifici, l’obbligo di documentare e testare almeno annualmente i piani di uscita (exit strategy) e, per i fornitori designati, sanzioni che possono raggiungere l’1% del fatturato medio giornaliero mondiale [3][4]. La concentrazione su pochi hyperscaler è esplicitamente trattata come rischio sistemico.
  • L’EU Data Act (Regolamento (UE) 2023/2854), in vigore dal 12 settembre 2025, affronta i dati non personali e industriali e, rilevante ai nostri fini, mira a contrastare le pratiche di vendor lock-in introducendo diritti di switching e portabilità [6].
  • Il Cloud Sovereignty Framework della Commissione Europea (DG DIGIT, versione 1.2.1, pubblicata il 20 ottobre 2025) traduce il concetto di sovranità in criteri di procurement misurabili: otto Sovereignty Objectives (che vanno dalla strategica agli aspetti giuridico-giurisdizionali fino alla supply chain, alla tecnologia, alla sicurezza e alla sostenibilità), valutati tramite i livelli di assurance SEAL (da SEAL-0 a SEAL-4), con un livello minimo richiesto – SEAL-2, “Data Sovereignty” – per essere ammissibili [7].

Le ragioni di sovranità della Cloud repatriation

Sommando questi tasselli, la repatriation per ragioni di sovranità smette di essere un gesto difensivo isolato e diventa la risposta a obblighi normativi di controllo, reversibilità e minore dipendenza da fornitori extra-UE. Per la componente geopolitica del fenomeno Gartner ha coniato il termine geopatriation: lo spostamento di workload dagli hyperscaler globali verso alternative regionali o nazionali [12]. Per il SOC, la conseguenza concreta è che la collocazione dei dati diventa un controllo di compliance verificabile e soggetta ad audit, e non più una scelta di pura ingegneria.

Il Total Cost of Ownership e il “paradosso del cloud”

L’argomento economico ha trovato il suo manifesto nel 2021, quando Sarah Wang e Martin Casado di Andreessen Horowitz hanno pubblicato The Cost of Cloud, a Trillion Dollar Paradox [1]. La loro tesi è che il cloud dà il meglio nelle fasi iniziali, quando ottimizza l’innovazione, l’agilità e la crescita, mentre a regime la pressione sui margini può superare i benefici, configurando una sorta di “tassa di flessibilità”. Gli autori stimavano, in modo prudenziale, che il costo del cloud potesse essere da due a tre volte superiore a quello dell’infrastruttura privata e quantificavano in oltre 500 miliardi di dollari il valore di mercato eroso alle società quotate che utilizzano il cloud su larga scala. Secondo la loro analisi, una repatriation ben eseguita riporterebbe i costi a un terzo o alla metà di quelli equivalenti in cloud [1]. È però necessario chiarire un aspetto che gli stessi autori avevano messo in evidenza: il loro obiettivo non era promuovere la repatriation in sé, ma considerare la spesa infrastrutturale come un parametro fondamentale e progettare la portabilità fin dall’inizio. Questa precisazione è importante, perché l’analisi è stata anche criticata dal punto di vista tecnico: molte aziende, infatti, recupererebbero gran parte di quei risparmi semplicemente ottimizzando l’uso del cloud, prima ancora di pensare a uscirne. I numeri sulla spesa, comunque, confermano le preoccupazioni. Secondo Flexera, l’84% delle organizzazioni indica la gestione della spesa cloud come la principale sfida, e una quota stimata intorno a un quarto della spesa risulta sprecata in risorse sottoutilizzate [9].

I candidati naturali alla repatriation

Le voci più difficili da prevedere, come i egress fees, il traffico cross-region, le API call charges e le classi di storage, colpiscono in modo sproporzionato proprio sui carichi data-intensive e always-on, che sono i candidati naturali alla repatriation [18]. Il caso meglio documentato resta quello di 37signals (Basecamp): l’azienda ha investito circa 600.000 dollari in hardware proprietario uscendo dal public cloud e stima di risparmiare 7 milioni di dollari nell’arco di cinque anni, sul presupposto di workload a domanda stabile che non sfruttavano l’elasticità, la principale proposta di valore del cloud [17]. Il calcolo del TCO della repatriation deve includere voci spesso trascurate: l’egress iniziale dei dati, i capex hardware, le licenze, l’energia e il cooling, il personale e l’overhead operativo, oltre al costo, talvolta dominante, di assumere internamente funzioni di sicurezza precedentemente esternalizzate.

Architettura dominante: hybrid e multi-cloud

La repatriation quasi mai, si traduce in un rientro totale all’on-premises. L’esito di gran lunga più frequente è l’architettura ibrida, che combina l’agilità del public cloud per i carichi bursty con la prevedibilità dell’on-premises per le operazioni core e i dati sensibili [9]. La tendenza è strutturale: Gartner stima che entro il 2027 il 90% delle organizzazioni adotterà un approccio hybrid cloud [12]. Questa convergenza non è priva di costi in termini di sicurezza: la distribuzione delle responsabilità tra più ambienti e più fornitori aumenta le lacune di compliance e i punti ciechi di visibilità, e accresce la domanda di competenze specifiche per la gestione della sicurezza multi-cloud [14][15]. L’indicazione architetturale più solida è progettare la portabilità ex ante: la diffusione di Kubernetes e della containerizzazione è in parte una reazione alla volontà di non restare vincolati a un singolo cloud, e riduce sensibilmente lo sforzo necessario a ricollocare un workload in futuro [1]. Dal punto di vista della sicurezza, la portabilità è anche un controllo di resilienza: un exit plan credibile, oggi obbligatorio per le entità soggette a DORA, presuppone che i workload siano progettati per poter essere spostati [3].

Versanti economico, ambientale e sicurezza

Sul versante economico, una parte della comunità tecnica obietta che quei risparmi sono spesso raggiungibili con il FinOps e con una migliore ottimizzazione dell’uso, senza i rischi e i capex di un’uscita [19]. Invece, sul versante ambientale, alcune analisi attribuiscono ai grandi data center iperscalari un’efficienza energetica superiore a quella di infrastrutture on-premises di scala ridotta [19]. E sul versante della sicurezza vale ricordare che gli hyperscaler schierano team, telemetria e capacità di risposta difficilmente replicabili in casa: in certi contesti, rientrare può abbassare anziché alzare la postura di sicurezza. La collocazione ottimale è specifica per ciascun workload e va rivista periodicamente, su un orizzonte di norma compreso tra dodici e trentasei mesi, soppesando unit economics, sensibilità all’egress, latenza, data gravity e posizione regolatoria del servizio [18].

Implicazioni operative per CISO e SOC

Dall’analisi emergono alcune indicazioni concrete per chi si occupa della sicurezza:
  • Trattare la collocazione come un controllo di sicurezza e compliance. La scelta tra cloud e on-premises deve essere inserita nel framework di gestione del rischio e mappata sugli obblighi applicabili (GDPR/Schrems II, NIS2, DORA, EU Data Act), con evidenze auditabili sulla localizzazione e sull’autorità giuridica applicabile ai dati.
  • Ridefinire esplicitamente lo shared responsibility model a ogni spostamento. Ogni repatriation trasferisce responsabilità verso l’interno: patching, gestione delle chiavi, detection e risposta devono essere formalmente riassegnati e dotati di risorse, evitando le zone grigie che generano misconfiguration.
  • Trasformare l’exit strategy da documento a requisito di progettazione. Per le entità soggette a DORA si tratta di un obbligo da testare annualmente; mentre per tutte le altre è una buona pratica. Il presupposto tecnico è la portabilità: containerizzazione e rinuncia ai servizi proprietari non sostituibili.
  • Quantificare il TCO di sicurezza, non solo quello infrastrutturale. Internalizzare SOC, threat intelligence e incident response ha un costo che può erodere o azzerare i risparmi attesi, e come tale va messo nel business case.
  • Governare la complessità degli ambienti hybrid. La visibilità unificata, la mappatura dei controlli sui framework normativi e la gestione coerente dell’identità (IAM) tra gli ambienti sono priorità, soprattutto perché gli ambienti misti sono quelli che mostrano la maggiore propensione agli errori di configurazione.

Dal cloud-first alla Cloud repatriation

La cloud repatriation non segna la fine del public cloud né rinnega il paradigma che lo ha imposto. Invece, segna il passaggio da una logica cloud-first a una logica di workload placement: ogni workload viene collocato nel luogo in cui costo, controllo, prestazioni e conformità si bilanciano meglio. Per il responsabile della sicurezza, la collocazione dei dati è diventata una variabile di sicurezza e di compliance, retta tanto dall’economia quanto da un quadro normativo europeo (Schrems II, NIS2, DORA, EU Data Act, Cloud Sovereignty Framework) che in diciotto mesi ha reso la sovranità del dato un requisito verificabile. Un’ultima notazione, in prospettiva. Il fronte oggi più mobile è quello dei carichi di intelligenza artificiale: l’AI repatriation.

Differenza fra training e inference

La distinzione fondamentale è tra training e inference:
  • il primo, assetato di GPU di ultima generazione, è intermittente e resta tendenzialmente favorevole all’elasticità del public cloud;
  • il secondo, una volta in produzione, assume un profilo steady-state, prevedibile e sensibile alla latenza, esattamente la combinazione che l’analisi precedente ha individuato come candidata naturale alla repatriation.
Questo andamento amplifica la posta in gioco: McKinsey stima che entro il 2030 l’inference supererà il training come workload AI dominante, arrivando a oltre il 40% della domanda complessiva dei data center, mentre Deloitte colloca già nel 2026 l’inference intorno ai due terzi del compute totale [20][21]. A questo si aggiungono l’economia dell’hardware (server e memorie con prezzi in forte rialzo per la pressione sulla supply chain dei componenti AI), la data gravity dei dataset di addestramento e le esigenze di sovranità sui dati più sensibili usati per i modelli. La maturità delle piattaforme MLOps gestite e dei government cloud spinge molti carichi nella direzione opposta. Per il responsabile della sicurezza, l’AI repatriation non introduce nuovi vettori rispetto a quelli analizzati in precedenza, ma li intensifica e li concentra su una classe di workload ad altissima intensità di dati e di costi.

Riferimenti

  • Wang S., Casado M., The Cost of Cloud, a Trillion Dollar Paradox, Andreessen Horowitz, 27 maggio 2021.
  • Corte di Giustizia dell’Unione Europea, Data Protection Commissioner v. Facebook Ireland Ltd e Maximillian Schrems (“Schrems II”), causa C-311/18, sentenza del 16 luglio 2020. EUR-Lex CELEX: 62018CJ0311.
  • Regolamento (UE) 2022/2554 del Parlamento europeo e del Consiglio (Digital Operational Resilience Act, DORA), in applicazione dal 17 gennaio 2025. EUR-Lex CELEX: 32022R2554.
  • EBA, EIOPA, ESMA (European Supervisory Authorities), comunicato congiunto e prima lista dei Critical ICT Third-Party Providers (19 provider) designati ai sensi dell’art. 31(9) DORA, 18 novembre 2025.
  • Direttiva (UE) 2022/2555 del Parlamento europeo e del Consiglio (NIS2), termine di recepimento 17 ottobre 2024. EUR-Lex CELEX: 32022L2555.
  • Regolamento (UE) 2023/2854 del Parlamento europeo e del Consiglio (EU Data Act), applicabile dal 12 settembre 2025. EUR-Lex CELEX: 32023R2854.
  • Commissione Europea (DG DIGIT), Cloud Sovereignty Framework, versione 1.2.1, 20 ottobre.
  • US CLOUD Act (Clarifying Lawful Overseas Use of Data Act), Pub. L. 115-141, 2018.
  • Flexera, 2025 State of the Cloud Report (survey su 759 cloud decision-maker, dati di fine 2024).
  • Barclays, 2H24 CIO Survey (dati di fine 2024).
  • IDC, Server and Storage Workloads Survey (ottobre 2024).
  • Gartner, Gartner Forecasts Worldwide Public Cloud End-User Spending to Total $723 Billion in 2025.
  • Thales, 2024 Cloud Security Study.
  • Thales, 2025 Data Threat Report.
  • IBM Security, Cost of a Data Breach Report 2025.
  • Broadcom (VMware Cloud Foundation Division), Private Cloud Outlook 2025.
  • 37signals (Basecamp), disclosure pubbliche sui costi e sui risparmi della repatriation da AWS (2022-2023).
  • CIO.com / 451 Alliance, Why cloud repatriation is back on the CIO agenda, ottobre 2025.
  • CloudZero, A Trillion Dollar Paradox: Why Repatriation Isn’t The Answer.
  • McKinsey & Company, The future of AI workloads.
  • Deloitte, Technology, Media & Telecommunications Predictions 2026 – compute power for AI.

Vincenzo Calabro'Vincenzo Calabro' | Ingegnere informatico specializzato in sicurezza informatica e investigazione digitali. Autore di articoli e saggi. Lecturer, Speaker, Trainer.