Da Hybrid-by-Accident a Hybrid-by-Design: padroneggiare la sovranità dei dati e il controllo dei costi dell'AI
Nessuna azienda costruisce intenzionalmente un panorama tecnologico caotico. Di solito questo succede attraverso acquisizioni, team che acquistano i propri strumenti e migrazioni al cloud disconnesse e spesso parziali. Il risultato è un'architettura "Hybrid-by-Accident", un ambiente IT costruito su anni di scelte reattive piuttosto che su azioni intenzionali e, cosa peggiore, nessuno ha un piano concreto per risolverlo.
Man mano che l'AI aziendale passa dalla sperimentazione alla produzione, l'Hybrid-by-Accident è più di un inconveniente tecnico: è una responsabilità strategica. Per mantenere la sovranità dei dati ed evitare i costi astronomici dell'AI, le organizzazioni devono adottare un'architettura Hybrid-by-Design. Coloro che compiono questo passaggio in modo deliberato sbloccheranno il pieno valore dei propri asset di dati. Coloro che non lo faranno vedranno il proprio debito architettonico aumentare con il passare degli anni e con ogni nuova iniziativa di AI.
Questo è stato l'argomento della mia recente conversazione con Noel Yuhanna, VP Principal Analyst presso Forrester, e relatore ospite del webinar di Cloudera "Benvenuti nell'era dell'Hybrid-by-Design."
In questo blog, approfondirò tale conversazione e spiegherò come le organizzazioni possano creare un'architettura Hybrid-by-Design sfruttando una governance unificata, standard aperti e una chiara mappatura dei requisiti del ciclo di vita dell'AI.
Come le aziende arrivano a questo punto
Oltre alle attività di M&A, all'adozione di strumenti isolati e alle linee di business che si vincolano a fornitori preferiti, la rapida spinta verso il cloud degli ultimi decenni è una delle cause principali. Molte organizzazioni hanno effettuato la migrazione in modo rapido e su vasta scala, e ora il pendolo sta tornando indietro. Il rimpatrio dal cloud è un tema reale e sempre più discusso.
I numeri parlano chiaro: i piani riportati dai CIO di rimpatriare i carichi di lavoro nuovamente on premise sono aumentati dal 43% nel 2020 all'83% nel 2024. Non si tratta di un rifiuto del cloud: è la consapevolezza sempre più matura che non tutti i carichi di lavoro appartengono a quell'ambiente. Infatti, come sottolinea Yuhanna, oggi circa l'80% dell'elaborazione transazionale nei settori bancario e sanitario viene ancora eseguita on premise. L'iniziale equivoco secondo il quale "il cloud costa meno" ha lasciato il posto a interrogativi complessi sull'ottimizzazione dell'architettura, sull'overprovisioning e sui costi di egress che erodono la proposta di valore.
La pressione normativa alla base di tutto
La conformità sta imponendo un'azione immediata su quello che un tempo era un problema di IT a lento sviluppo. Normative come il GDPR, l'EU Data Act e l'HIPAA richiedono una rigorosa sovranità dei dati. Nel frattempo, lo US CLOUD Act, che consente alle autorità statunitensi di accedere ai dati a livello globale, si scontra con le norme sulla privacy dell'UE e dell'APAC, spingendo attivamente le imprese verso provider di cloud sovrani non statunitensi. Nel settore finanziario, il DORA impone strategie di uscita dai fornitori poiché fare troppo affidamento su un singolo cloud rappresenta ora un rischio sistemico.
Con le nuove normative sull'AI che richiedono una rigorosa tracciabilità, questa pressione non farà che aumentare nel 2026 e oltre. La governance dei dati e dell'AI si stanno fondendo in un unico enorme ostacolo alla conformità, e le aziende prive dell'architettura adeguata dovranno affrontare un retrofit doloroso e costoso.
Perché l'AI rende tutto ciò urgente ora
L'AI aziendale trasforma un problema infrastrutturale cronico in uno acuto. Il ciclo di vita dell'AI ha esigenze molto diverse in ogni fase: l'addestramento e la contestualizzazione richiedono un calcolo su larga scala e a intermittenza, il che potrebbe renderli più adatti al cloud, mentre l'inferenza a regime è spesso più economica on premise. Il termine "Ibrido consapevole" significa mappare ogni fase sull'infrastruttura che effettivamente si adatta ad essa, piuttosto che ripiegare su un unico ambiente e ammortizzarne le penalità.
La gravità dei dati complica ulteriormente la situazione. L'AI richiede enormi volumi di dati distribuiti e il loro spostamento tra ambienti comporta costi reali di latenza e di uscita (egress). Ci si trova davanti a un bivio: limitare i modelli a un set di dati ridotto (sacrificando la qualità) o sostenere costi ingenti per centralizzare i dati (compromettendo il business case).
L'agentic AI accentua notevolmente questa sfida. Poiché questi sistemi richiedono dati affidabili in tempo reale per agire, le pipeline con ritardi dovuti all'elaborazione in batch semplicemente non sopravviveranno. Come osserva Yuhanna, l'adozione dell'agentic AI si attesta attualmente intorno al 24% e si prevede che raddoppierà entro la fine del 2026. Le organizzazioni che oggi costruiscono un'architettura proattiva per questa realtà ne coglieranno il valore domani.
Il caso degli standard aperti
Il blocco da fornitore non è solo un rischio teorico: è un costo attivo sia a livello di infrastruttura sia a livello di software. Quando i propri strumenti di dati proprietari funzionano solo su uno specifico cloud, si affronta un "doppio blocco" composto. Questo dà tutto il potere contrattuale al fornitore, creando un grave collo di bottiglia nel momento in cui un carico di lavoro deve essere spostato, che si tratti di trasferire un progetto pilota cloud completato per eseguirlo sulla capacità inutilizzata del data center, o di migrare verso un nuovo cloud sovrano per soddisfare i requisiti di conformità. Le organizzazioni recuperano tale potere contrattuale attraverso la portabilità dei carichi di lavoro e gli standard aperti.
Due standard di riferimento rendono possibile tutto ciò:
Kubernetes funge da livello di astrazione universale per l'infrastruttura sottostante. Fornendo un modello operativo coerente e cloud-native, indipendentemente dall'hardware o dal provider cloud sottostante, elimina la "tassa di cambio di piattaforma", cioè il sovraccarico di re-ingegnerizzazione che si accumula ogni volta che un carico di lavoro attraversa un confine infrastrutturale.
Apache Iceberg svolge un lavoro equivalente a livello di dati. Non si tratta solo di astrarre il luogo in cui risiedono i dati, ma di aumentare chi può accedervi. Il formato open table e il catalogo Iceberg REST consentono alle organizzazioni di condividere i dati in-place con qualsiasi sistema di terze parti. Ciò significa che è possibile lasciare i propri dati governati esattamente dove si trovano, consentendo al contempo alle piattaforme di analytics esterne di interrogarli direttamente. Disaccoppiando completamente i dati dai motori di calcolo specifici del fornitore, le organizzazioni ottengono una flessibilità autentica e a prova di futuro su come e dove eseguire l'AI.
Consideriamo cosa significhi realmente la scalabilità nella pratica. Di recente, Yuhanna ha incontrato un cliente che ha connesso 50.000 database attraverso 1.000 sistemi sorgente disparati. A tale ordine di grandezza, la complessità non cresce in modo lineare, ma si moltiplica. Gli standard aperti non sono un optional: sono il modo in cui le aziende mantengono il controllo dei propri ambienti.
Il divario di governance e i relativi costi
Un'infrastruttura frammentata produce in modo affidabile una governance frammentata. Come sottolinea Yuhanna, circa il 70% dei dati aziendali è privo di metadati e catalogazione adeguati. Ciò significa che solo il 25% viene effettivamente utilizzato per l’analisi e la maggior parte dei dati aziendali rimane completamente inutilizzata! Nel 2006, il matematico britannico e pioniere della scienza dei dati Clive Humby ha coniato la celebre frase "i dati sono il nuovo petrolio", osservando che i dati grezzi devono essere raffinati dall'AI e dall’analisi per generare un valore reale. Se ogni dato contiene un potenziale insight, perché tollerare un'architettura che impedisce attivamente di utilizzarli tutti?
Anche le implicazioni per la sicurezza sono altrettanto concrete. Secondo il report di IBM sulle violazioni dei dati del 2025, le violazioni in ambienti multipli hanno un costo medio superiore a 5 milioni di dollari (ben al di sopra della media globale di 4,44 milioni di dollari) e rappresentano ora circa il 30% di tutti gli incidenti. Il motivo è semplice: le violazioni si verificano nei punti di integrazione e ogni confine di ambiente è un punto di integrazione.
La risposta è un livello di politica unificato: un piano di controllo singolo e federato che abbraccia classificazione, controllo di accesso, lineage, auditing e conformità. In questo modello, le politiche seguono i dati, applicandosi in modo coerente e in tempo reale in tutto l'ecosistema.
Da dove iniziare
Spinte dalle esigenze reali dell'AI in produzione, dai requisiti sempre più stringenti sulla sovranità dei dati e da una maggiore attenzione ai costi effettivi dell'infrastruttura, le organizzazioni devono passare da architetture Hybrid-by-Accident ad architetture Hybrid-by-Design. Ecco come iniziare:
Stabilisci intenti chiari. Prima di toccare qualsiasi tecnologia, costruisci una roadmap di 18 mesi ancorata a risultati di business concreti, che si tratti di crescita dei ricavi, ottimizzazione dei costi o obiettivi di resilienza.
Esegui un audit della data gravity. Mappa dove risiedono effettivamente i dati, chi vi accede e la tua esposizione a latenza ed egress. Ciò fa emergere in modo affidabile carichi di lavoro dimenticati, dati duplicati e punti ciechi di conformità.
Esegui una razionalizzazione deliberata. Razionalizza gli strumenti sovrapposti, consolida le relazioni con i fornitori, standardizza la governance e pianifica la portabilità dei carichi di lavoro.
Per saperne di più, riascolta la mia conversazione con Noel Yuhanna e approfondisci con il report sui trend del settore "From Chaos to Control: Why ‘Hybrid by Design’ Is the Future of Enterprise Data Strategy".