Data readiness per agenti AI: preparare i dati aziendali

Quando un progetto di agenti AI si ferma, la sala riunioni cerca quasi sempre il colpevole nel posto sbagliato: il modello. Si discute se serva un LLM più potente, un provider diverso, un fine-tuning. Nel frattempo il problema vero sta due livelli più in basso, dentro il gestionale che nessuno ha mai riconciliato con il CRM. La data readiness per agenti AI è la fase che precede qualsiasi discorso su architetture e prompt, ed è anche quella che le aziende saltano più spesso. Gartner ha messo un numero su questo scarto: senza dati pronti per l’AI, il 60% dei progetti verrà abbandonato entro la fine del 2026, come indicato nella nota di Gartner sui rischi legati ai dati non AI-ready e ripreso da MES Computing. Una precisazione di perimetro: qui non si parla di maturità organizzativa, team, processi, sponsorship, ma esclusivamente dello stato dei dati aziendali.

In questo articolo scoprirai:

• Perché il 60% dei progetti si blocca sui dati, non sul modello
• Che cosa significa davvero data readiness per agenti AI
• I tre killer silenziosi: silos, metadati mancanti, PII non mascherate
• La checklist di data readiness per agenti AI in azienda
• Governance: GDPR, AI Act e NIST prima del pilot, non dopo

Perché il 60% dei progetti si blocca sui dati, non sul modello

Il paradosso dell’attuale ciclo dell’AI è che la componente più commodizzata, il modello, riceve il 90% dell’attenzione, mentre la componente più differenziante, i dati proprietari, riceve le briciole. Un agente che deve rispondere a un cliente sullo stato di un ordine non fallisce perché “ragiona male”: fallisce perché l’ordine esiste in tre sistemi con tre codici diversi e nessuno dei tre è autorevole.

I dati italiani sono impietosi. Secondo la ricerca Cloudera ripresa da TechFromTheNet, solo il 16% delle aziende italiane dichiara di avere una completa integrazione delle informazioni aziendali e appena il 26% sostiene di poter accedere immediatamente ai dati indipendentemente dal formato. Sul fronte governance, solo il 30% delle aziende europee ritiene di avere presidi adeguati. Il dettaglio più rivelatore: oltre il 90% riconosce l’importanza di data lineage e data catalog, ma solo il 47% ha implementato anche soluzioni basilari di catalogazione e tracciabilità. C’è consapevolezza, manca esecuzione.

Il pilot che funziona e la produzione che no

Questo scarto spiega un fenomeno che chiunque abbia portato un agente oltre la demo conosce: il pilot gira benissimo su cinquanta documenti selezionati a mano, poi crolla su cinquantamila. I problemi mascherati nella fase dimostrativa, definizioni incoerenti tra business unit, tre-cinque sistemi core mai riconciliati, assenza di tracciabilità sulle trasformazioni, emergono tutti insieme quando il sistema opera a scala. Non è un bug dell’AI: è debito tecnico sui dati che presenta il conto. Sono due valutazioni distinte e complementari: nell’AI agent readiness della propria azienda si misura la maturità organizzativa, competenze, processi, sponsorship interna, mentre in questo articolo si guarda soltanto allo stato dei dati.

Che cosa significa davvero data readiness per agenti AI

La definizione più utile in circolazione è anche la meno tecnologica: i dati sono pronti quando sono identificabili, accessibili, puliti e verificabili al punto che un agente può leggerli e produrre output affidabili senza supervisione costante. Non è un problema di quantità di dati, ma di qualità, struttura e permessi sul sottoinsieme che serve a quello specifico agente.

FullContact articola la valutazione su sei assi che vale la pena tenere come griglia mentale: i dati devono essere diverse (da più fonti), timely (attuali), accurate (deduplicati e verificati), secure (con controlli d’accesso), discoverable (localizzabili) e consumable (processabili da una macchina), come descritto nella loro analisi sulla data readiness per AI agents. L’ultimo punto è quello che le aziende sottovalutano di più: un PDF scansionato storto è un dato che esiste per un umano ma non esiste per un agente.

La differenza tra dati puliti e dati contestualizzati

C’è un livello ulteriore, ed è quello semantico. NTT DATA lo sintetizza bene: i dati devono essere “ricchi di contesto, semanticamente interoperabili, cioè non solo condivisi, ma anche compresi da piattaforme diverse, e disponibili in tempo reale”. Sono ontologie, tassonomie e metadati a permettere di interpretare dati complessi, non la pulizia in sé. Nello stesso Global GenAI Report di NTT DATA emerge che solo il 53% delle organizzazioni aveva affrontato il tema della data readiness durante la valutazione delle opportunità GenAI, pur dichiarando al 95% di volerlo fare entro l’anno successivo. La distanza tra intenzione e pratica è, ancora una volta, il vero collo di bottiglia.

I tre killer silenziosi: silos, metadati mancanti, PII non mascherate

Nella pratica dei progetti che si arenano, tre pattern ricorrono con una regolarità quasi noiosa.

I silos sono il primo. Non si tratta solo di sistemi separati, ma di definizioni incompatibili: “cliente attivo” significa una cosa nel CRM commerciale e un’altra nell’amministrazione. Un agente che interroga entrambi produce risposte contraddittorie e perde credibilità al terzo tentativo. Le strategie di data mesh e di federazione, suggerite da diversi vendor, sono utili quanto la premessa organizzativa che le regge: qualcuno deve possedere la definizione autorevole di ogni entità.

I metadati mancanti sono il secondo, e il più insidioso perché invisibile. Un documento senza data di validità, senza autore, senza indicazione della fonte è tecnicamente indicizzabile e praticamente pericoloso: l’agente non ha modo di sapere che quel listino è scaduto nel 2023. Mia-Platform insiste sul punto della qualificazione continua dei dati, con valutazione, validazione e monitoraggio costanti per prevenire il data drift: la readiness non è uno stato che si raggiunge una volta.

Le PII non mascherate chiudono il terzo. Indicizzare un archivio di ticket di supporto significa quasi sempre indicizzare nomi, email, numeri di telefono e talvolta dati sanitari o bancari. Se quel vector store viene poi interrogato da un agente accessibile a tutta l’azienda, si è appena costruito un canale di esfiltrazione perfettamente legale dal punto di vista IT e perfettamente illecito dal punto di vista privacy. Il masking va fatto prima dell’embedding, non dopo: un vettore già generato conserva l’informazione.

La checklist di data readiness per agenti AI in azienda

Tradotto in operazioni concrete, un audit di readiness copre tre blocchi. Queste sono le voci da verificare una per una, con una risposta sì/no documentabile prima di aprire il pilot.

• Ogni fonte dati rilevante è censita, incluse quelle non ufficiali (file Excel locali, caselle email condivise, cartelle di rete).
• Ogni fonte ha un owner nominato, con nome e cognome, responsabile della sua correttezza.
• Per ogni entità critica (“cliente attivo”, “ordine”, “contratto”) esiste una definizione autorevole unica, condivisa tra le business unit.
• Ogni formato è parsabile in modo deterministico: nessun Excel con celle unite, nessun allegato email non estratto.
• I PDF scansionati sono passati per OCR con una soglia di qualità dichiarata, e i documenti sotto soglia sono esclusi o rilavorati.
• Ogni documento porta metadati minimi: fonte, autore, data di creazione e data di validità o scadenza.
• I documenti obsoleti sono marcati o rimossi dall’indice, non solo archiviati altrove.
• Le PII sono individuate e mascherate PRIMA dell’embedding, non filtrate a valle sulla risposta.
• I permessi di accesso dei documenti originali sono replicati sul retrieval: l’agente non mostra a un utente ciò che non potrebbe aprire.
• La strategia di chunking è documentata e ogni frammento porta il contesto del documento da cui proviene.
• Esiste un ground truth di 20-50 casi reali con la risposta corretta verificata da un umano.
• È definito chi rilancia la verifica di qualità e con quale frequenza, per intercettare il data drift.

Fonti e formato: dove vivono davvero i dati

Il primo passo è mappare le fonti reali, non quelle dell’organigramma: il gestionale, ma anche il file Excel sul desktop della responsabile acquisti e la casella email condivisa. Per ciascuna va stabilito se il formato è parsabile in modo deterministico. Excel con celle unite, PDF scansionati e allegati email sono i tre formati che fanno saltare più pipeline di qualsiasi limite di contesto del modello.

Chunking ed embedding: dove si decide la qualità del recupero

Qui la letteratura è chiara e misurabile. La survey di Gao et al. su Retrieval-Augmented Generation individua nel retrieval, non nella generazione, la leva principale contro allucinazioni e conoscenza obsoleta. Anthropic ha quantificato quanto pesi il contesto aggiunto ai chunk: nei loro esperimenti sul contextual retrieval, arricchire ogni frammento con 50-100 token di contesto riduce il tasso di fallimento del recupero del 35%, che diventa 49% combinando embedding contestuali e BM25 e 67% aggiungendo un reranking. Sono guadagni ottenuti senza cambiare modello: solo preparando meglio i dati. Se il concetto di recupero aumentato non è familiare al team, conviene partire dalla nostra guida su cos’è il RAG e perché è fondamentale per l’AI.

Ground truth: come si misura se ha funzionato

L’ultimo blocco è quello che quasi nessuno prepara e che decide se il pilot sarà valutabile: un set di 20-50 casi reali con la risposta corretta verificata da un umano. Senza ground truth, la valutazione dell’agente diventa un’opinione, e le opinioni non sopravvivono al primo confronto con il CFO. È anche la condizione per ragionare seriamente di time-to-value dal pilot al ROI.

Governance: GDPR, AI Act e NIST prima del pilot, non dopo

La governance dei dati non è un adempimento successivo: nel 2026 è un vincolo di progettazione. L’articolo 5 del GDPR impone principi che collidono frontalmente con l’istinto di “indicizziamo tutto”: limitazione della finalità, minimizzazione dei dati, esattezza, limitazione della conservazione. Un vector store che conserva embedding di dati personali oltre la finalità originaria è un trattamento nuovo, non una copia tecnica.

Sul fronte AI Act, l’articolo 10 sulla data governance richiede per i sistemi ad alto rischio dataset “pertinenti, sufficientemente rappresentativi e, nella misura del possibile, privi di errori e completi”, con esame documentato dei possibili bias e delle scelte di raccolta e annotazione, obblighi la cui applicazione è fissata al 2 agosto 2026. Anche fuori dal perimetro alto rischio, quel set di pratiche è un ottimo standard di riferimento. Il NIST AI Risk Management Framework, con le sue quattro funzioni Govern, Map, Measure e Manage, offre l’impalcatura organizzativa per tenere insieme il tutto. Il tema è approfondito nel nostro articolo su sicurezza, GDPR e AI.

L’onboarding Mimír: l’audit dei dati prima del pilot

La ragione per cui insistiamo su questa fase è che l’abbiamo resa parte del servizio, non un prerequisito da scaricare sul cliente. In Mimír l’onboarding non comincia dalla configurazione dell’agente: comincia da un audit dei dati aziendali che mappa fonti, formati, duplicazioni, permessi e presenza di dati personali, e che restituisce una fotografia onesta di che cosa è pronto e che cosa non lo è. Capita regolarmente di consigliare di ridurre il perimetro del primo agente, un processo solo, una fonte sola, tipicamente tra gli agenti AI per automatizzare processi ripetitivi di back-office, perché è il modo più rapido per arrivare a un risultato misurabile invece che a una demo impressionante e inutilizzabile.

Piattaforma vs. servizio: dove si vede la differenza

È qui che si vede la differenza tra vendere un prodotto e offrire un servizio: la piattaforma la si attiva in un pomeriggio, mentre la data readiness richiede persone che entrino nel merito dei processi del cliente. Ne parliamo più diffusamente in perché il servizio conta più del modello, e chi è una PMI trova in cosa aspettarsi da un partner AI il quadro di come lavoriamo. Per capire come funziona la soluzione nel concreto, il punto di partenza è la pagina su Mimír AI Agent.

Come iniziare: la domanda giusta sui dati

Se in azienda avete un caso d’uso in mente ma il dubbio è se i vostri dati siano nelle condizioni di reggerlo, è esattamente la domanda con cui vale la pena iniziare una conversazione. Il team di Mimír affianca le aziende in questa fase di audit e onboarding, prima ancora che si parli di configurare un agente. Una valutazione onesta del punto di partenza costa molto meno di un pilot abbandonato.

Fonti:

• Gartner — Lack of AI-Ready Data Puts AI Projects at Risk
• MES Computing — I problemi sui dati che frenano i progetti AI nel mid-market
• FullContact — Data readiness for AI agents
• NTT DATA — Data readiness, il primo passo verso l’agentic AI
• Mia-Platform — AI data readiness: come preparare i dati
• Soraia — Preparare i dati aziendali per gli agenti IA
• IBM — Che cosa sono i dati AI-ready
• Salesforce — Come misurare la data readiness
• B-EYE — Gli step di data readiness per l’agentic AI
• Neo4j / Gartner — Come valutare la AI data readiness
• McKinsey — The data dividend: fueling generative AI
• Gao et al. — Retrieval-Augmented Generation for LLMs: a survey (arXiv)
• Anthropic — Introducing contextual retrieval
• GDPR — Articolo 5, principi del trattamento
• AI Act — Articolo 10, data e data governance
• NIST — AI Risk Management Framework