Il problema della data readiness nell’AI enterprise

I programmi di AI enterprise raramente si bloccano perché un team non sa interrogare un modello. Si bloccano perché l’organizzazione non sa stabilire che cosa significhino i dati, se siano aggiornati, quale record sia autorevole, chi possa agire su un output e come misurare l’esito. Affrontiamo queste domande prima di scegliere il modello, attraverso sei verifiche: provenienza, freschezza, duplicati, baseline, diritti d’azione e misurazione dei risultati.

Il modello di solito non è il primo vincolo

Il modello è la parte visibile; quella operativa comprende fonti, identità, definizioni, permessi, code di revisione, percorsi di scrittura e feedback. Un modello potente su dati inaffidabili produce incertezza ben formulata; un modello più semplice in un sistema decisionale definito può creare valore affidabile.

La readiness attraversa funzioni diverse: Operations conosce il processo, Technology i sistemi, Finance le definizioni, Legal e Security i limiti, i team di business le azioni. Nessuno può dichiararla da solo.

RAND indica dati inadeguati, infrastruttura debole e disallineamento con il problema aziendale tra le cause ricorrenti di fallimento. Dati raccolti per reporting o compliance possono non contenere il contesto necessario a un nuovo uso. Il capitolo Economy dello Stanford AI Index 2026 descrive crescita di adozione e investimenti, ma l’adozione non equivale a ritorno operativo misurabile. La readiness va quindi verificata su una decisione e un workflow.

Partire da un contratto decisionale

Prima delle tabelle scriviamo decisione ricorrente, responsabile, azioni consentite, tempo disponibile, evidenze e risultato da osservare. «Usare l’AI per i dati prodotto» non è un contratto; «suggerire attributi mancanti prima della pubblicazione settimanale senza sovrascrivere record approvati» lo è.

Il contratto evita di ottimizzare metriche offline senza sbocco operativo e mostra se l’AI serve davvero. Lookup, soglie e riconciliazioni restano regole; l’AI interviene su input ambigui o non strutturati. Ogni gate ha evidenza, owner e condizione di superamento.

Gate 1: Provenienza

La provenienza chiarisce origine, definizione, trasformazioni e autorità di ogni campo. Conserviamo sistema sorgente, orario di estrazione, chiave, versione della trasformazione e correzioni umane. Valori discordanti si risolvono confrontando definizioni e lineage.

Il lineage deve essere interrogabile e ogni raccomandazione deve riferirsi ai record sorgente. Un workflow operativo di estrazione dati ripetibile registra richieste, risposte ed errori, evitando di scambiare un’assenza per zero. Il gate passa se un reviewer ricostruisce un output senza lo sviluppatore originario.

Gate 2: Freschezza

La freschezza è l’età massima accettabile per quella decisione. Distinguiamo momento dell’evento, registrazione nella fonte e consumo nel workflow. «Pipeline riuscita» non significa «dato aggiornato».

Un freshness budget stabilisce avviso, astensione, fallback deterministico o blocco della scrittura. Una piattaforma di warehouse e ingestion affidabile è parte del prodotto decisionale.

Gate 3: Duplicati e identità

I duplicati sono spesso problemi di identità. Definiamo quando due record rappresentano la stessa entità e con quale ambito; conserviamo ID grezzi e canonici, metodo e confidenza. Le chiavi deterministiche hanno precedenza, i match incerti vanno in revisione.

Servono tassi per fonte e segmento, merge reversibili, regole di prevalenza e monitoraggio delle collisioni. La piena proprietà dei dati operativi preserva storico grezzo e ID stabili per riconciliare e riprodurre il processo quando le interfacce cambiano.

Gate 4: Baseline

Senza baseline l’AI resta una demo. Misuriamo errori, tempi, effort di review, copertura, eccezioni e outcome prima dell’intervento. Le evidenze interne riservate usano un indice Baseline = 100; valori assoluti, denominatore e popolazione rimangono nell’ambiente autorizzato. Segmentazione e modifiche concomitanti evitano attribuzioni facili. La baseline deve essere riproducibile da dati e definizioni versionati.

Gate 5: Diritti d’azione

Accesso ai dati non significa diritto di agire. Per ogni azione mappiamo system of record, attore, approvazione, limiti, separazione dei compiti e rollback. Si parte in lettura o raccomandazione, poi dry run e infine scrittura approvata. Credenziali minime, separazione read/write, approval token, idempotenza e correlation ID rendono concreto il controllo umano.

Gate 6: Misurazione dei risultati

La qualità del modello non basta. Colleghiamo input → raccomandazione → revisione → azione → risultato con ID stabili, includendo astensioni e rifiuti. Il piano definisce outcome primario, guardrail e cadenza: gravità degli errori, override, reclami, violazioni, latenza e lavoro spostato. Ridurre una coda creandone una nascosta non è miglioramento.

Una scorecard pratica

Stato	Significato	Conseguenza per il rilascio
Unknown	Evidenza non raccolta	Nessun pilot con claim operativi
Defined	Owner, definizione e test esistono	Solo valutazione offline
Verified	Test superato su dati rappresentativi	Pilot controllato
Monitored	Soglia e risposta operative	Scaling limitato possibile

Le medie ingannano: cinque gate monitorati non compensano diritti sconosciuti. Il gate più debole capace di causare danno limita il rilascio. Per i builder la scorecard diventa backlog di test; per gli executive, filtro di portafoglio.

Ordinare gli investimenti prima del modello

Risolviamo identità prima della capacità, contesto prima delle previsioni, diritti prima di un agente senza autorità e baseline prima di cambiare processo. Solo dopo confrontiamo modelli su successo, calibrazione, latenza, privacy e costo. Fonti, ID, permessi e definizioni cambiano: ogni gate richiede owner, test e risposta alle soglie.

La domanda per gli executive

La domanda utile non è «Quale modello usiamo?», ma «Mostrate la catena dall’evidenza sorgente all’azione autorizzata e al risultato misurato». Se è riproducibile, il programma può imparare. Altrimenti, più capacità accelera un processo non verificato. La data readiness è il sistema operativo che rende affidabile l’AI.