Dati e architetture: l’AI non può funzionare senza fondamenta solide

Negli ultimi anni molte aziende hanno investito in progetti di intelligenza artificiale attratte dalle promesse di efficienza e innovazione. Un dato allarmante ha fatto riflettere i decision maker: la maggior parte di questi progetti non ha raggiunto i risultati sperati. Stime varie indicano che tra l’80% e il 95% dei progetti AI aziendali non produceva valore o veniva abbandonato. Un’analisi Gartner rivela che l’85% dei modelli AI sviluppati dalle aziende finisce per fallire, principalmente a causa di dati inadeguati o non pertinenti.

Queste cifre hanno fatto scattare un campanello d’allarme. Perché tanti flop? La risposta è emersa chiaramente: mentre ci si concentrava sui modelli e sugli algoritmi, si sottovalutavano le fondamenta – la qualità dei dati, l’integrazione nei sistemi esistenti, l’infrastruttura. In assenza di queste basi solide, anche l’AI più avanzata “smette di funzionare” o comunque non mantiene le promesse.

Una situazione tipica

Pensiamo alla situazione tipica: un’azienda lancia un proof-of-concept di machine learning con dati raccolti al volo da qualche sistema, ottiene magari un modello che in laboratorio funziona bene, ma quando prova a integrarlo nell’applicazione reale scopre che i dati live sono disallineati, sporchi o incompleti. Oppure si rende conto che quel modello non è mai stato pensato per reggere il carico in produzione, o che manca un processo per tenerlo aggiornato. Di qui il cosiddetto “AI PoC graveyard” – il cimitero dei proof-of-concept: progetti che hanno mostrato un video demo interessante ma non hanno mai superato la fase prototipale.

Già nel 2024 si iniziava a capire che il punto dolente non erano tanto gli algoritmi, quanto la preparazione a monte. Un’analisi RAND notava come i progetti AI falliscono il doppio delle volte rispetto a progetti IT tradizionali perché incontrano ostacoli in dati, costi e sicurezza. E Gartner lanciava un avvertimento: “entro il 2026, il 60% dei progetti AI verrà abbandonato se non supportato da dati pronti per l’AI”.

Questa predizione, fatta nel 2025, sta purtroppo trovando conferma. Vediamo più in dettaglio in cosa consistono queste fondamenta e come le imprese stanno correggendo il tiro.

L’importanza dei dati: Garbage In, Garbage Out

Il mantra “garbage in, garbage out” è vecchio quanto l’informatica, ma nell’AI assume un peso ancora maggiore. Dati di bassa qualità o non rappresentativi portano modelli a risultati scadenti o distorti. Per molto tempo, però, le aziende hanno sottovalutato l’impegno necessario per rendere i dati “AI-ready”. Significa avere dataset puliti, etichettati (quando serve), completi delle variabili pertinenti e aggiornati con sufficiente frequenza. Non è un lavoro glamour come addestrare una rete neurale, ma è ciò che determina il successo finale.

Secondo un sondaggio Gartner del 2024, il 63% delle organizzazioni ammetteva di non avere, o di non sapere se avesse, pratiche di data management adeguate per l’AI. Questa ignoranza è costata cara: dataset aziendali pieni di duplicati, valori mancanti o errori hanno “confuso” i modelli, generando output inaffidabili.

In altri casi il problema era la pertinenza: modelli allenati su dati storici che non rispecchiavano le nuove condizioni di mercato, oppure dati provenienti da un silos che non erano applicabili in un altro reparto.

Un esempio classico

Un classico esempio: una banca vuole usare l’AI per valutare il rischio di credito dei clienti. Ha anni di dati di transazioni, bilanci, storico creditizio. Ma se questi dati non sono ben integrati (magari cliente “Mario Rossi” appare in 5 database diversi con ID differenti, o mancano pezzi importanti come dati di reddito), qualunque modello soffrirà. O ancora, se i dati contengono bias (ad esempio storicamente il modello trova meno default in certe aree geografiche semplicemente perché la banca aveva politiche più restrittive in quelle aree, non perché quei clienti fossero realmente più affidabili), il modello imparerà correlazioni fuorvianti. Senza una pulizia e analisi critica dei dati, l’AI può addirittura amplificare pregiudizi e errori.

Perché le aziende trascurano i dati? In parte per la pressione di mostrare risultati rapidi: è più seducente sviluppare un prototipo di AI in poche settimane usando i dati “così come sono”, sperando che basti, piuttosto che investire mesi a sistemare archivi e flussi. Ma nel 2026 questa mentalità del quick win sta lasciando spazio a un approccio più paziente: “data first”.

Il Data & Analytics Summit di Gartner enfatizza proprio l’importanza di considerare i requisiti dati sin dall’inizio: i leader devono integrare strategie di dati AI-ready nelle pratiche esistenti.

In pratica, le organizzazioni stanno adottando alcune contromisure:

• Valutazione dello stato dei dati: audit per capire quali dati possiedono, dove risiedono, con che qualità. Spesso emergono gap clamorosi.
• Data cleaning e arricchimento: progetti dedicati a ripulire dati critici, colmare lacune (magari acquisendo dati esterni dove mancano quelli interni) e standardizzare formati. Ad esempio uniformare i codici di prodotto, correggere indirizzi, rimuovere record duplicati.
• Data governance: definire responsabilità chiare (owner dei dati), politiche di aggiornamento e controllo qualità continui. Non basta pulire una volta: serve mantenere.
• Integrazione delle fonti: la classica creazione di data lake o data warehouse moderni dove le diverse fonti vengono convogliate e rese coerenti. Oggi l’integrazione dei dati è considerata la priorità dall’80% delle aziende, essendo l’aggiunta di nuove fonti senza adeguata integrazione la prima causa di fallimento nei progetti IT complessi. Senza una solida base di dati integrati, molti progetti AI rischiano di diventare costi affondati senza ritorno.

Un case study interessante

Un’azienda del retail ha investito molto nell’AI per previsioni di vendita, ma ha fallito finché non ha realizzato che i dati di inventario provenienti dai negozi erano pieni di errori (prodotti registrati in categorie sbagliate, date errate, ecc.). Hanno dovuto ristrutturare il sistema di raccolta dati nei negozi e implementare controlli automatici, dopodiché il modello ha iniziato a dare previsioni accurate. Questo mostra come prima si è dovuto risolvere un problema di architettura dati di base, poi l’AI ha potuto brillare.

Architettura AI aziendale e integrazione

Parlando di architettura, intendiamo l’insieme di infrastrutture e piattaforme su cui l’AI poggia. Un errore comune della prima ondata di progetti AI era trattarli come iniziative isolate: un team data science prende dei dati, addestra un modello, fa vedere che funziona su un laptop… e lì finisce. Ma perché quell’AI diventi un sistema aziendale, deve essere incastonata nell’architettura IT esistente o evolverla.

Un elemento critico è la data integration come già accennato, ma anche la scalabilità infrastrutturale. Molti hanno scoperto che addestrare un modello con un CSV estratto manualmente è una cosa; avere un flusso continuo di dati in produzione è un’altra. Le aziende di successo hanno dovuto investire in pipeline di dati automatizzate, in ambienti di sviluppo e produzione coerenti (ad esempio piattaforme cloud con servizi ML gestiti, feature store, ecc.), in ambienti di test e sandbox per provare i modelli senza rischi sulla produzione.

Il gap tra prototipo e produzione è stato riassunto come “pilot paralysis”: l’azienda lancia pilotini in un ambiente protetto, ma non progetta come portarli sulla catena di produzione reale. Le integrazioni con autenticazione sicura, con i flussi di lavoro e con la formazione degli utenti finali spesso restavano per dopo – e quel dopo non arrivava mai, perché quando si andava a vedere, risultava uno sforzo enorme non pianificato. Ad esempio, sviluppare un modello di raccomandazione prodotti è un conto; integrarlo nel sito di e-commerce live, con milioni di utenti, garantendo risposte in pochi millisecondi e mantenendo la sicurezza dei dati utente, è un progetto a sé stante.

AI engineering

Nel 2026, quindi, c’è maggiore consapevolezza che l’AI è un lavoro di squadra con l’IT tradizionale. Si parla ormai di AI engineering come disciplina che unisce competenze di data science, software engineering e cloud architecture. Aziende come Google e Microsoft hanno spinto concetti di MLOps simili a DevOps: pipeline CI/CD per modelli, monitoraggio continuo delle prestazioni del modello in produzione, retraining periodico, e così via. Questo implica creare o adottare strumenti adeguati – da database per dati non strutturati e vettoriali, a sistemi di logging e monitoring specifici per l’AI (ad esempio per rilevare drift dei dati o deterioramento dell’accuracy nel tempo).

Un chiaro segnale del cambio di mentalità è il fatto che i colli di bottiglia discendono verso l’infrastruttura. Come abbiamo discusso in altri articoli, non è più l’algoritmo ma l’infrastruttura (chip, energia, rete) a dettare i limiti. Ciò si riflette anche nelle architetture software: un rapporto di fine 2025 recita “l’innovazione AI è ora limitata dall’infrastruttura, non dai modelli”.

In pratica, molte aziende sanno cosa vorrebbero fare con l’AI, ma devono fare i conti con i propri sistemi interni non pronti a supportarla. Questo ha portato investimenti mirati, come la modernizzazione dei data center, l’adozione di architetture cloud ibride, l’utilizzo di data lakehouse per combinare analitiche classiche e dati per l’AI, e la revisione delle pipeline di dati in tempo reale.

L’AI non deve essere un’isola

Un aspetto spesso trascurato è la documentazione e conoscenza interna. In varie organizzazioni, team diversi lavoravano su AI e sui sistemi di origine senza parlare molto tra loro. Ciò creava silos e conflitti: i team AI magari duplicavano dati perché non conoscevano le API esistenti, oppure i team IT vedevano i data scientist come “cowboy” che usavano dati in modi non previsti, col rischio di violare la governance. Ora vediamo nascere strutture di coordinamento: Center of Excellence per l’AI, comitati tra IT e Data Science, ruoli come il CDAO (Chief Data and AI Officer) che unificano la visione. Questo aiuta a far sì che l’AI non sia un’isola ma parte di una strategia unitaria di architettura.

Data readiness: pratiche emergenti nel 2026

Come stanno reagendo le aziende per assicurare basi solide ai progetti AI? Ci sono alcune best practice emergenti:

• AI-ready data practice: Gartner consiglia di evolvere le pratiche di data management tradizionali in pratiche orientate all’AI. Ciò include introdurre nuove tecnologie come vector database (per gestire embedding e similitudini), chunking dei documenti, embedding store e integrazione di Retrieval-Augmented Generation (RAG) per portare contesto ai modelli generativi. In pratica, si allarga la “cassetta degli attrezzi” della gestione dati per includere questi elementi propri dell’AI moderna.
• Metadata e data observability: Non basta avere i dati, bisogna sapere come sono fatti e tenerli sotto controllo. Si passa da metadati passivi a metadati attivi: collezione e analisi costante di informazioni sui dati (provenienza, qualità, frequenza di aggiornamento, utilizzi) con strumenti che segnalino anomalie. Ad esempio, se un flusso di dati in ingresso improvvisamente dimezza il volume o cambia formato, un sistema di data observability allerta il team prima che quel problema infici il modello.
• Data governance in era AI: La governance non è più solo proteggere e documentare dati, ma anche considerare rischi specifici dell’AI (bias, privacy, uso etico). I CDO e i responsabili devono rispondere a domande nuove: se i dati usati per addestrare il modello saranno interoperabili tra dipartimenti, come rilevare dati sensibili e proteggerli nei pipeline AI, come documentare l’uso dei dati per spiegare decisioni automatiche. Molte organizzazioni stanno aggiornando le policy di governance aggiungendo sezioni su AI, ad esempio imponendo tracciabilità dei dati usati nei modelli e validazione di assenza di bias noti.
• Infrastruttura modulare e scalabile: Invece di applicazioni monolitiche, architetture a microservizi e API facilitano inserire componenti AI. Ad esempio, un’azienda di e-commerce può avere un microservizio “raccomandazione prodotti” che espone via API le raccomandazioni generate dall’AI; ciò permette di inserirlo facilmente in diversi punti (sito web, app, email marketing) senza riscrivere logica, e di scalare quella componente indipendentemente. Inoltre con i container e orchestratori (Kubernetes etc.) si gestiscono meglio i modelli in produzione, anche varianti diverse in parallelo (A/B testing di modelli).
• Three Lines of Defense adattato all’AI: In settori regolamentati, alcune aziende stanno applicando il modello delle tre linee di difesa anche all’AI: la prima linea (i team di business che usano l’AI) deve fare controlli operativi sui dati e output, la seconda linea (risk management/compliance) definisce linee guida, valuta i modelli più critici prima del deployment, la terza linea (audit) verifica periodicamente se i controlli funzionano. Nel settore bancario, per esempio, BaFin e altre autorità si aspettano che l’uso di AI venga incorporato nei sistemi di controllo interno equivalenti a quelli per altri rischi operativi.
• Auto-valutazione e categorizzazione dei rischi AI: anticipando normative come l’EU AI Act, diverse aziende stanno mappando i propri casi d’uso AI classificandoli per rischio (basso, alto, ecc.) già prima che la legge lo imponga. Questo aiuta a capire dove concentrare gli sforzi di solidità: ad esempio, un semplice chatbot interno informativo avrà meno requisiti di un algoritmo che decide l’esito di un reclamo assicurativo.
• Questa categorizzazione spesso porta alla scoperta di applicazioni AI “ombra” sviluppate senza supervisione (shadow AI): facendo l’inventario, ci si accorge che dipartimenti diversi hanno implementato modelli fai-da-te, magari usando dati al di fuori di controlli. Far emergere e regolarizzare queste situazioni è parte della costruzione di fondamenta affidabili.

“No data, no AI”: un nuovo slogan nei boardroom

Tutto quanto sopra si riflette anche nell’attenzione del top management. Se nel 2023/24 i consigli di amministrazione chiedevano “abbiamo un progetto AI?” (spesso inteso come iniziativa vetrina), nel 2026 chiedono “abbiamo i dati in ordine per l’AI?”. Come rilevato in un rapporto di Harvard Business School, quasi la metà delle grandi società ha ora indicato esplicitamente nei documenti di corporate governance che il board sovrintende i rischi legati all’AI. E uno dei rischi più evidenziati è proprio quello dei dati e della sicurezza/qualità. Inoltre, nelle informative di bilancio 36% delle società ha aggiunto l’AI come specifico fattore di rischio, citando sfide regolatorie, di privacy e di integrazione. Questo significa che a livello strategico si riconosce che se i progetti AI vanno fuori rotta, spesso è per problemi di base.

Le conversazioni nei comitati rischi ora includono domande come:

• “Siamo sicuri che i nostri dati siano accurati e protetti prima di darli in pasto a un modello AI?”
• “Abbiamo sufficiente capacità di calcolo e un’architettura elastica per supportare i picchi di utilizzo dell’AI?”
• “Le nostre varie piattaforme parlano tra loro o l’AI è costretta a lavorare a compartimenti stagni?”.

C’è anche un riflesso negli investimenti: budget IT e dati in crescita. Dopo anni in cui era difficile ottenere fondi per “rifare l’architettura dati” – percepito come lavoro poco visibile – ora i dirigenti capiscono che è la condizione per sfruttare davvero l’AI.

Studi indicano che la spesa in data integration e data quality tools è salita fortemente, e che i progetti di modernizzazione di data warehouse hanno acquisito priorità elevata nel 2025. In parte, è anche la pressione di non voler più buttare soldi in progetti AI falliti: i CFO hanno iniziato a chiedere conto degli insuccessi, e la risposta dei CIO/CDO è stata “dobbiamo sistemare le basi, altrimenti continueremo a fallire”.

Un articolo emblematico titolava “Lack of AI-Ready Data Puts AI Projects at Risk” come comunicato di Gartner e la sintesi era brutale: se non fai bene i compiti sui dati, stai buttando via i tuoi investimenti in AI. Questo messaggio, venuto dall’esterno, è stato amplificato all’interno dalle unità di innovazione che magari inizialmente avevano sottovalutato questi aspetti e se ne sono pentite.

Fondamenta solide per sogni ambiziosi

In sintesi, il 2026 è l’anno in cui l’industria ha veramente interiorizzato che l’AI è un castello che si regge su fondamenta fatte di dati e architettura. Senza quelle, il castello crolla. Non è un caso che si parli di “stabilizzazione sistemica” anche riferita ai modelli (vedi articolo sui modelli AI): la stabilità di un sistema AI dipende in larga misura dalla stabilità e robustezza delle sue alimentazioni (dati) e infrastrutture (architettura).

Le aziende stanno correndo ai ripari, costruendo basi più solide: data lake integrati, pipeline di dati affidabili, governance e metriche di qualità, infrastruttura scalabile, competenze nuove di AI engineering. Il risultato atteso è duplice: meno fallimenti clamorosi e, al contrario, una capacità di implementare AI con confidenza. Quando le fondamenta ci sono, i team AI possono innovare più velocemente e con maggiore sicurezza di poter mettere in produzione ciò che creano.

In definitiva, l’AI smette di “funzionare” quando mancano le fondamenta, ma fiorisce quando queste sono presenti. Il 2026 segna quindi il passaggio dall’euforia spesso ingenua dei primi progetti alla costruzione metodica dell’ambiente in cui l’AI diventa sostenibile e scalabile. È un po’ meno scintillante come narrativa, ma è esattamente ciò che fa la differenza tra un’azienda che gioca con l’AI e un’azienda che la incorpora con successo nei propri processi core.