Le architetture lakehouse stanno ridefinendo il panorama dell’intelligenza artificiale aziendale. Questo modello ibrido, che combina le caratteristiche dei data lake e dei data warehouse sta diventando la soluzione preferita per le organizzazioni che cercano di implementare applicazioni AI su larga scala. Con il 65% delle aziende enterprise che ha già adottato questa tecnologia, è chiaro che il lakehouse non è solo una tendenza passeggera, ma una necessità operativa.
La necessità di un’architettura ibrida è emersa dalla difficoltà di gestire dati non strutturati e strutturati contemporaneamente. I data lake tradizionali offrivano storage a basso costo ma mancavano di struttura, mentre i data warehouse erano rigidi e poco flessibili. Il lakehouse risolve questi problemi aggiungendo un layer di metadati strutturati, permettendo query SQL affidabili senza sacrificare la flessibilità del storage grezzo.
L’adozione del lakehouse nell’AI enterprise
L’adozione del lakehouse è stata accelerata dall’avvento dell’AI enterprise. I modelli linguistici di grandi dimensioni richiedono accesso simultaneo a dati testuali non strutturati e dati strutturati. Le architetture RAG (Retrieval Augmented Generation), che permettono agli LLM di attingere a basi di conoscenza aziendali, necessitano di un accesso coerente e tempestivo a entrambi i formati di dati.
Un esempio concreto è l’integrazione tra Docusign e Snowflake. Docusign gestisce decine di milioni di contratti in formati non strutturati come PDF e Word, insieme a metadati strutturati. Grazie all’integrazione con Snowflake, è possibile interrogare contemporaneamente il testo dei contratti e i metadati strutturati, riducendo il tempo di analisi da giorni a secondi.
I rischi del vendor lock-in e le soluzioni
Non tutte le migrazioni verso architetture lakehouse sono state senza intoppi. Lemongrass un’azienda specializzata in migrazioni cloud SAP, ha riscontrato problemi di vendor lock-in durante il passaggio da un lakehouse custom su AWS a un lakehouse standard basato su Apache Iceberg. La migrazione ha rivelato dipendenze da feature proprietarie AWS che non esistevano nella versione standard, rendendo il processo più costoso e lungo del previsto.
Un altro problema emerso è il consumo di token degli agenti AI. I workflow agentici che interrogavano il lakehouse senza ottimizzazione del contesto consumavano quantità di token che rendevano alcune applicazioni economicamente non sostenibili. La soluzione ha richiesto una fase di ingegneria dedicata alla riduzione del contesto passato agli LLM.
Il futuro del lakehouse: semantic layer e agenti autonomi
Il semantic layer è identificato come componente critica per le architetture dati enterprise entro il 2030. Questo strato di astrazione traduce il linguaggio di business in query sul sistema dati sottostante, senza che l’utente o l’agente AI debbano conoscere lo schema tecnico del database. Per gli agenti AI, il semantic layer è particolarmente rilevante, poiché permette di rispondere a domande di business senza dover addestrare ogni agente sullo schema specifico.
Databricks ha presentato Genie Ontology come proposta di semantic layer integrato nella propria piattaforma, mentre Snowflake ha annunciato Horizon Context con funzionalità simili. Il mercato sta convergendo sull’idea che il semantic layer diventerà un componente standard dell’architettura dati enterprise.
L’accordo da 6 miliardi tra Snowflake e AWS, annunciato nel 2026, è un segnale chiaro della direzione in cui si muove il mercato. Questo accordo consolida l’ecosistema intorno a un numero ridotto di player, con implicazioni concrete per le aziende che stanno valutando la propria architettura dati. La maggior parte dei casi d’uso che richiedevano soluzioni specializzate sta venendo assorbita nelle piattaforme lakehouse principali.
