Quando le imprese decidono di spostare i propri dati al di fuori di un cloud pubblico sono costrette a pagare quella che, a tutti gli effetti, è una tassa d’uscita. Da gennaio 2027, l’EU Data Act renderà illegale questa pratica, privando i provider del diritto di applicare egress fee tra cloud e garantendo alle organizzazioni una finestra di 30 giorni per spostare i propri dati. Si tratta di un cambio di passo molto importante: per un decennio, le imprese hanno messo a budget questa voce, accettandola come “il prezzo da pagare per fare business nel cloud”. Ma se questa tassa è durata così a lungo è soprattutto perché nessuno aveva proposto una vera alternativa.
L’EU Data Act fissa la scadenza ufficiale più stringente, ma la logica economica sottostante esiste ovunque, anche oltre i confini dell’Unione. Qualsiasi impresa che stia considerando egress fee e costi di duplicazione rispetto a una strategia single-cloud sta di fatto affrontando lo stesso nodo, con o senza una legge che la riguardi direttamente.
La ritirata dal cloud pubblico è già ampiamente in corso. I workload di AI hanno portato con sé un aumento dei costi infrastrutturali per l’84% delle organizzazioni, secondo la recente survey Great AI Re-Architecture di Cloudera, che ha coinvolto 1.500 enterprise architect, cloud infrastructure lead e data architect in 9 mercati. In EMEA, il 55% delle imprese ha già tolto almeno una parte dei workload AI dal cloud pubblico nell’ultimo anno.
A sostenere questo cambiamento è stata la consapevolezza che capacità computazionale e storage non devono necessariamente risiedere nello stesso posto. Anzi, separarli consente alle imprese di portare i motori di elaborazione lì dove i dati si trovano già, con un approccio che consente di abbattere contemporaneamente due categorie di costo:
1. il tempo dedicato dai team di engineering al refactoring di workload e applicazioni per spostare un carico di lavoro al fine di eseguire una query diversa sugli stessi dati. Grazie a fondamenta Kubernetes-native e API-first, i team possono scrivere il codice una volta sola e eseguirlo ovunque: su dati on-premise, in una regione sovrana o nel cloud pubblico.
2. le egress fee applicate allo spostamento stesso.
Tutto ciò a vantaggio di una più facile scalabilità delle iniziative di AI.
Cloudera ha portato questa visione sul mercato nell’agosto 2026 con Cloudera Anywhere Cloud, una piattaforma dotata di un unico control plane che si estende su cloud pubblico, infrastruttura privata e ambienti sovrani. La piattaforma si basa su una customer base che comprende collettivamente circa 30 exabyte di dati, la scala che mette davvero alla prova la solidità di un’architettura run-anywhere in condizioni di produzione, non in un pilot o in una semplice proof of concept.
Per gli amministratori di piattaforme che gestiscono il provisioning operativo, la differenza più immediata riguarda i tempi di deployment. L’esperienza diretta di Cloudera indica una riduzione da mesi a minuti per ottenere risultati misurabili, un’accelerazione che fa la differenza quando più team richiedono sempre più spesso nuovi ambienti.
Tuttavia, questo non basta per contenere l’aumento delle spese. La portabilità su scala enterprise deve essere supportata da una governance unificata. Quando policy, identità e tracciabilità del lineage di dati risiedono in un unico punto di controllo, l’audit trail rimane coerente indipendentemente dalla regione in cui si trova il workload. Frammentare quella governance su sistemi separati significa creare zone d’ombra che nessuno nota finché qualcosa non va storto. Con il GDPR, le autorità di controllo danno ormai per scontata la tracciabilità e, dunque, la capacità di un’organizzazione di rispondere a una semplice domanda: dove sono finiti questi dati e chi li ha trattati? Con un ambiente frammentato, raramente è possibile dare una risposta chiara. Con il policy-as-code, le regole seguono automaticamente i dati in ogni ambiente, eliminando il rischio di buchi normativi. E lo stesso sistema offre ai team finance qualcosa che chiedono da tempo: sapere in tempo reale quanto costa far girare un workload AI, e dove.
Passare da un pilot AI a un deployment su scala enterprise cambia radicalmente i conti. In fase di test, pochi utenti con query semplici generano costi prevedibili. Ma quando l’AI entra nella routine quotidiana di un’intera organizzazione, i costi di utilizzo crescono ben oltre le previsioni iniziali. Con l’AI agentica il problema si amplifica: ogni singola azione visibile all’utente nasconde decine di chiamate di inferenza in background, e il consumo di token sale molto più in fretta rispetto a una normale interazione in chat. Spostare questi workload su infrastrutture proprie trasforma una voce di spesa imprevedibile in un costo fisso, con un utilizzo dell’hardware più efficiente e un ROI più solido nel tempo.
Sono i CIO e i CDO a dover dettare la linea. Il cloud pubblico non è di per sé il problema: lo diventa quando si tratta dell’unica opzione disponibile. In tutta la regione EMEA, adottare un’architettura esclusivamente cloud è un approccio ormai superato. Le piattaforme ibride danno alle organizzazioni la libertà di portare dati e workload AI dove ha senso per il business tra cloud pubblico, data center privati o ambienti sovrani. Con l’EU Data Act che elimina le egress fee e i costi di refactoring, le decisioni infrastrutturali si possono finalmente prendere sulla base del valore reale, non del rischio di lock-in. È un cambiamento radicale, che mette le organizzazioni nella condizione di poter puntare sul proprio futuro senza dover scendere a compromessi.
