Avete l’agente. Sa rispondere, sa ragionare, sa persino usare strumenti esterni. Poi lo collegate ai sistemi veri dell’azienda e la qualità delle risposte crolla. Non è un problema del modello. È un problema di data readiness, cioè della preparazione dei dati che quell’agente deve consultare per lavorare davvero.
Gartner ha stimato che, entro fine 2026, sei progetti AI su dieci verranno abbandonati proprio per la mancanza di dati pronti a sostenerli. Non è un dettaglio tecnico da lasciare al reparto IT. È la differenza tra un progetto pilota che resta tale e un sistema che entra davvero in produzione.
Cosa significa data readiness in pratica
Un dato pronto per l’AI non è solo un dato corretto. Deve essere accessibile, aggiornato, tracciabile e soprattutto interrogabile da un sistema automatico, non solo leggibile da una persona. Un foglio Excel condiviso via email può contenere informazioni perfette e resterà comunque inutile per un agente, perché nessun sistema sa dove trovarlo, come interpretarlo o quando è stato aggiornato l’ultima volta.
La differenza tra dati pronti e dati solo corretti si vede in un caso molto comune, e molto più insidioso di un semplice errore di battitura. Un agente deve rispondere a una domanda apparentemente semplice, quanto ha speso questo cliente negli ultimi tre mesi. Per rispondere deve incrociare il CRM, dove il cliente è identificato da un codice interno, il sistema di fatturazione, dove la stessa entità compare con la partita IVA, e la piattaforma di assistenza, dove l’unico riferimento disponibile è l’indirizzo email. Nessuno di questi tre sistemi sa che sta parlando della stessa persona. Un operatore umano risolve l’ambiguità in automatico, riconoscendo il cliente dal contesto. Un agente senza un livello che colleghi queste identità produce risposte sbagliate con la stessa sicurezza con cui produrrebbe quelle giuste.
È qui che entra la data platform vera e propria, non come slogan ma come insieme di componenti precisi. Un master data management che stabilisce un’identità unica del cliente attraverso i sistemi, un catalogo dati che documenta dove vive ogni informazione e chi ne è responsabile, e un livello semantico che traduce i concetti di business, cosa significa esattamente cliente attivo, cosa significa fatturato, in una definizione unica condivisa da tutti i sistemi che la useranno.
Senza questi tre elementi, ogni nuovo agente che si collega ai dati aziendali riparte da zero nel tentativo di capire cosa significano davvero le informazioni che sta leggendo.
Per chi vuole un riferimento su come strutturare i dati in modo che restino realmente utilizzabili da sistemi diversi, un buon punto di partenza sono i principi FAIR, nati in ambito scientifico ma sempre più applicati anche nelle data platform aziendali.
L’agente ha bisogno di dati, non solo di un prompt migliore
Nelle conversazioni con i clienti il pattern si ripete quasi sempre uguale. L’azienda ha costruito un agente capace, magari basato su un modello eccellente, e si aspetta che risolva un problema di business.
Poi arriva la domanda che conta davvero: quell’agente, cosa mangia? Quali dati vede, come li riceve, chi glieli ha preparati?
Se la risposta è che l’agente legge direttamente da un database transazionale pensato per altro, o peggio ancora da esportazioni manuali fatte una volta al mese, il problema non si risolve scrivendo un prompt più elegante. Serve una data platform pensata per essere consultata da sistemi automatici, con un layer di API o microservizi che espone le informazioni in modo strutturato, un catalogo che le rende individuabili, e regole di governance che stabiliscono chi può leggere cosa.
Costruire l’agente senza aver costruito prima questo strato è come assumere un ottimo analista e lasciarlo senza accesso ai fascicoli, per quanto sia bravo, non potrà rispondere a nulla che non gli venga già raccontato a voce.
I segnali che i vostri dati non sono ancora pronti
Ci sono alcuni sintomi che tornano spesso quando facciamo una prima valutazione. Se per rispondere a una domanda semplice servono più persone che incrociano fogli diversi, i dati non sono pronti. Se ogni nuovo progetto AI richiede settimane solo per capire dove vivono le informazioni necessarie, i dati non sono pronti. Se un dato cambia significato a seconda di chi lo guarda, marketing lo legge in un modo, finance in un altro, i dati non sono pronti.
Nessuno di questi problemi si risolve con un modello più potente. Sono tutti problemi di architettura, di governance e di come i dati vengono esposti verso l’esterno, temi che riguardano chi progetta i sistemi ben prima che chi sceglie il modello di AI da adottare.
Costruire la data platform prima, non dopo
La sequenza corretta è quasi sempre inversa a quella che le aziende seguono per istinto. Si parte dal caso d’uso AI, si sceglie il modello, si costruisce l’agente, e solo alla fine ci si accorge che manca la base. Conviene invertire l’ordine: mappare i dati disponibili, capire quali servono davvero per il caso d’uso specifico, costruire una piattaforma dati che li esponga tramite API stabili e documentate, e solo allora collegare l’agente.
Questo lavoro non è un progetto a parte da fare una volta per tutte. È un’infrastruttura che deve reggere più casi d’uso nel tempo, perché il prossimo agente che costruirete avrà bisogno degli stessi dati, magari combinati in modo diverso. Un’architettura pensata bene la prima volta accorcia enormemente i tempi di tutti i progetti successivi.
Come può aiutarti Key Partner
Quando affianchiamo un’organizzazione su un progetto di intelligenza artificiale, la prima domanda che facciamo non riguarda il modello da scegliere. Riguarda i dati: dove sono, chi li possiede, in che stato sono, e cosa serve fare prima di poterli collegare a un sistema automatico in modo affidabile.
Costruiamo la data platform e gli strati di API necessari a rendere i dati davvero interrogabili, con un occhio a governance e sicurezza degli accessi fin dalla progettazione. L’obiettivo non è avere un pilota che funziona in demo, è avere un’infrastruttura che regge quando il primo agente smette di essere un esperimento e diventa un sistema che l’azienda usa ogni giorno.
Se vuoi capire quanto sono pronti i tuoi dati, contattaci per una prima valutazione, oppure approfondisci nei nostri Insights il tema della AI Governance e della roadmap operativa per la maturità AI.
Come può aiutarti Key Partner
Cosa si intende per data readiness in un progetto AI?
La data readiness è il grado di preparazione dei dati di un’organizzazione a essere usati da sistemi di intelligenza artificiale. Comprende qualità, accessibilità, aggiornamento e soprattutto la disponibilità di API o interfacce strutturate che permettano a un sistema automatico di interrogarli senza intervento manuale
Perché un progetto AI fallisce se i dati non sono pronti?
Perché l’agente o il modello finisce per lavorare su informazioni incomplete, incoerenti o difficili da interpretare correttamente. Il problema non si vede nei test iniziali, spesso costruiti su dati puliti selezionati apposta, ma emerge appena il sistema incontra i dati reali dell’azienda.
Da dove si comincia per valutare la data readiness della propria azienda?
Da una mappatura dei dati disponibili per il caso d’uso specifico che si vuole affrontare, seguita da una verifica di dove vivono quei dati, chi li aggiorna, e se esistono già interfacce che li rendono accessibili a un sistema esterno. Senza questa mappatura qualsiasi stima sui tempi di un progetto AI resta ottimistica.
La data readiness riguarda solo grandi aziende con molti sistemi?
No. Anche un’azienda con pochi sistemi può avere dati non pronti, per esempio se le informazioni chiave vivono in fogli condivisi manualmente o in applicativi senza API. La dimensione dell’azienda incide sulla complessità del lavoro, non sulla necessità di farlo.
