I data lakehouse diventano fondamento per l’AI aziendale: casi d’uso per le imprese

I data lakehouse sono diventati l’architettura di riferimento per l’AI enterprise, come documenta CIO. Non è una scelta estetica: è una risposta a un problema concreto che le organizzazioni hanno scoperto nel tentativo di portare in produzione applicazioni AI su scala. I data lake tradizionali avevano il dato grezzo ma non la struttura per interrogarlo in modo affidabile. I data warehouse avevano la struttura ma non la flessibilità per gestire i formati non strutturati che l’AI richiede. Il lakehouse unifica le due architetture — e aggiunge i layer di governance, sicurezza e accesso semantico che i sistemi AI moderni richiedono per funzionare in modo affidabile.

Il 65% delle organizzazioni enterprise ha già adottato architetture lakehouse, secondo Gartner. I dati di Databricks aggiungono un’informazione più sorprendente: la quota di database creati da sistemi AI invece che da sviluppatori umani è passata dallo 0,1% al 80% in due anni. Gli agenti AI stanno diventando i principali produttori di strutture dati nelle organizzazioni che li hanno adottati — e questo cambia il modo in cui il lakehouse deve essere progettato, governato e mantenuto.

Perché il lakehouse è diventato il punto di convergenza

L’architettura lakehouse nasce dalla convergenza di due tradizioni separate nel mondo dei dati enterprise. Da un lato, i data lake — repository di storage a basso costo, tipicamente su object storage S3 o equivalenti, in cui i dati vengono depositati in formato nativo senza trasformazione. Dall’altro, i data warehouse — sistemi ottimizzati per query analitiche su dati strutturati, con schema definito a priori e performance garantite sulle interrogazioni.

Il problema storico del data lake era la mancanza di struttura: i dati c’erano, ma interrogarli in modo affidabile richiedeva ingegneria significativa. Il problema del data warehouse era la rigidità: aggiungere nuovi formati, incorporare dati non strutturati o modificare lo schema richiedeva processi lenti e costosi. Il lakehouse risolve entrambi aggiungendo al data lake un layer di metadati strutturati — tipicamente tramite formati di tabella aperti come Apache Iceberg o Delta Lake — che permette query SQL affidabili senza sacrificare la flessibilità del storage grezzo.

L’AI enterprise ha amplificato questa necessità. I modelli linguistici di grandi dimensioni richiedono accesso a dati testuali non strutturati (documenti, email, trascrizioni) e a dati strutturati (transazioni, record clienti, KPI) in modo simultaneo. I sistemi RAG — Retrieval Augmented Generation — che permettono agli LLM di attingere a basi di conoscenza aziendali devono accedere a entrambi i formati in tempo reale. Il problema di fondo è che i dati degli ERP sono spesso inaccessibili agli agenti AI anche quando tecnicamente disponibili: il lakehouse risolve l’accesso, ma non le politiche di governance. Un’architettura che separa i dati strutturati dai non strutturati costringe l’applicazione AI a gestire due sistemi separati, con i costi di ingegneria e i rischi di incoerenza che questo comporta.

Docusign e Snowflake: RAG su dati contrattuali in produzione

Il caso Docusign e Snowflake illustra come il lakehouse abilita applicazioni AI che non erano praticabili con architetture separate. Docusign gestisce decine di milioni di contratti — documenti non strutturati in PDF, Word e altri formati — insieme ai metadati strutturati associati: parti contraenti, date di firma, clausole chiave, scadenze. L’integrazione con Snowflake attraverso le API MCP (Model Context Protocol) ha permesso a Docusign di costruire un sistema RAG che interroga contemporaneamente il testo dei contratti e i metadati strutturati.

Il risultato pratico: un legale che chiede “mostrami tutti i contratti con clausole di rinnovo automatico che scadono nei prossimi 90 giorni con fornitori nel settore manifatturiero” ottiene una risposta che richiede l’accesso a dati non strutturati (il testo delle clausole) e strutturati (le date di scadenza, la categorizzazione dei fornitori) in modo coerente. Prima dell’integrazione lakehouse, questa query richiedeva un’analisi manuale che impiegava giorni; dopo, secondi.

Il caso illustra anche la direzione verso cui si muove il mercato: la connettività tra strumenti AI e sistemi dati enterprise attraverso protocolli standardizzati come MCP sta diventando un requisito di fatto per le applicazioni RAG in produzione. Le architetture che non espongono i propri dati attraverso questi protocolli limitano di fatto la capacità degli agenti AI di accedere al contesto aziendale in modo efficiente.

Lemongrass e il rischio del vendor lock-in

Non tutte le migrazioni verso architetture lakehouse producono i risultati attesi. Lemongrass, azienda specializzata in migrazione cloud SAP, ha completato nel 2026 il passaggio da un lakehouse custom costruito su AWS quattro anni prima a un lakehouse standard basato su Apache Iceberg. La migrazione ha rivelato un problema che si ripropone frequentemente: il lakehouse custom aveva accumulato dipendenze su feature proprietarie AWS che non esistevano nella versione standard, rendendo la migrazione più costosa e lunga del previsto.

I responsabili tecnici di Lemongrass hanno documentato anche un’esperienza con il consumo di token degli agenti AI: “Può fallire se non si fa attenzione all’utilizzo dei token.” 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 — un problema che le architetture lakehouse non risolvono automaticamente ma che devono essere progettate per facilitare.

Il caso Lemongrass illustra un rischio che il mercato ha sottostimato nella fase di adozione rapida del lakehouse: la scelta del formato di tabella — Snowflake, Databricks Delta Lake, Apache Iceberg, Microsoft Fabric — crea vincoli di lock-in diversi con implicazioni significative sulla portabilità futura. Apache Iceberg è il formato aperto con la maggiore portabilità; Delta Lake di Databricks è più maturo ma meno portabile; i formati proprietari Snowflake offrono performance ottimizzate sulla propria piattaforma ma sono difficilmente migrabili. La decisione architetturale presa oggi ha un orizzonte di conseguenze di 5-10 anni.

Semantic layer e agenti autonomi: il prossimo layer

Gartner ha identificato il semantic layer come componente critica per le architetture dati enterprise entro il 2030. Il semantic layer è uno strato di astrazione che traduce il linguaggio di business — “fatturato per regione nell’ultimo trimestre”, “tasso di churn per segmento clienti” — 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: un agente che deve rispondere a domande di business deve capire cosa significa “cliente premium” nel contesto specifico dell’azienda, quale combinazione di tabelle rappresenta “ordine completato”, come vengono calcolati i KPI aziendali. Senza un semantic layer, ogni agente deve essere addestrato o istruito sullo schema specifico — un processo costoso e fragile che non scala quando il numero di agenti aumenta.

Databricks ha presentato “Genie Ontology” come proposta di semantic layer integrato nella propria piattaforma — definita da Bain & Company il passaggio del lakehouse a “control plane dell’enterprise agentica”. 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 — con l’avvertenza che ogni vendor lo implementa in modo proprietario, aggiungendo un ulteriore layer di rischio lock-in alla decisione architetturale complessiva.

Il deal Snowflake-AWS e la direzione del mercato

L’accordo da 6 miliardi tra Snowflake e AWS, annunciato nel 2026, è il segnale più chiaro della direzione in cui si muove il mercato. Snowflake — nata come alternativa al cloud database AWS Redshift — è diventata il principale partner commerciale di AWS per le architetture lakehouse enterprise. L’accordo consolida l’ecosistema intorno a un numero ridotto di player — Snowflake, Databricks, Microsoft Fabric, e AWS nativamente — che stanno assorbendo la maggior parte degli investimenti enterprise nel settore.

Questa concentrazione ha implicazioni concrete per le aziende che stanno valutando la propria architettura dati. La maggior parte dei casi d’uso che due anni fa richiedevano soluzioni specializzate — vector database per RAG, feature store per ML, data catalog per la governance — sta venendo assorbita nelle piattaforme lakehouse principali. IDC documenta che la maggior parte delle organizzazioni si aspetta di fare il lavoro vettoriale all’interno del proprio database esistente entro il 2027, non su sistemi separati.

Per chi deve decidere oggi: la maturità dell’ecosistema lakehouse è sufficiente per la maggior parte dei casi d’uso enterprise. Il rischio non è più la tecnologia — è la scelta del vendor e il livello di lock-in accettabile. Le architetture basate su standard aperti (Apache Iceberg, formati Parquet) mantengono più flessibilità a lungo termine, a fronte di un maggiore investimento iniziale in ingegneria. Le architetture native del singolo vendor offrono più integrazione e meno frizione nell’immediato, a fronte di vincoli più severi sulla portabilità futura. Non esiste la risposta giusta in assoluto: esiste quella giusta per la propria situazione specifica — e ignorare la domanda non è un’opzione praticabile per chi sta costruendo infrastruttura dati che dovrà servire applicazioni AI per i prossimi cinque anni.