Data governance per l'AI: ruoli, policy e qualità misurabile

La data governance ha vissuto per anni la vita ingrata delle assicurazioni: tutti concordano che serva, pochi la comprano finché il danno non arriva. L'AI le ha cambiato lo statuto in un paio d'anni, per una ragione strutturale: un errore nei dati, dentro un processo tradizionale, produce un errore, mentre dentro un sistema che apprende produce un comportamento, che si replica su ogni decisione successiva e si scopre tardi. Il regolatore europeo ha tratto la conseguenza, e l'articolo 10 dell'AI Act dedica ai dati dei sistemi ad alto rischio requisiti espliciti su governance, pertinenza, rappresentatività e gestione dei bias, trasformando in obbligo ciò che era buona pratica.

La domanda operativa, per chi deve costruirla o adeguarla, è cosa contenga una data governance all'altezza dell'AI. La risposta sta in tre componenti, e in un errore di impostazione da evitare.

Nomi e cognomi prima dei comitati

La prima componente sono le responsabilità, e la regola pratica è che la governance esiste quando ogni asset di dati rilevante ha due nomi accanto. Il data owner risponde del dato sul piano del business: ne autorizza gli usi, ne definisce le regole, risponde della sua correttezza verso l'organizzazione. Il data steward lo presidia sul piano operativo: monitora la qualità, gestisce le anomalie, mantiene la documentazione. Senza questi due ruoli assegnati per iscritto, ogni progetto AI ricomincia il negoziato daccapo, e la scena che vediamo più spesso negli assessment, il team che per settimane cerca "chi può dirci se questi dati si possono usare", è il sintomo esatto della loro assenza.

Il comitato data governance, tanto amato dai framework, viene dopo e serve ad arbitrare i conflitti tra owner, non a sostituirli. Un comitato senza owner sottostanti è una riunione periodica su dati di nessuno.

Policy scritte per chi costruisce

La seconda componente sono le regole, e il criterio di qualità è che devono essere consultabili da chi sviluppa nel momento in cui sviluppa, non solo dall'audit a cose fatte. Le policy che contano per l'AI rispondono a domande da progetto: quali categorie di dati possono alimentare quali categorie di sistemi, con quali approvazioni; come si documenta la provenienza (il lineage) di un dataset di addestramento, così che tra un anno si possa ricostruire su cosa un modello ha imparato; quali soglie di qualità un dataset deve superare prima di entrare in una pipeline; come si gestiscono conservazione e cancellazione quando i dati vivono dentro modelli e non solo dentro tabelle.

Su quest'ultimo punto, la coppia GDPR e AI Act che abbiamo trattato altrove entra nella governance dei dati come requisito di progettazione, perché una cancellazione richiesta da un interessato è gestibile se il lineage esiste, quasi impossibile se nessuno sa quali addestramenti quel dato ha attraversato.

Qualità che si misura, con uno standard

La terza componente è la qualità resa misurabile, ed è quella che separa la governance vera dal documento di intenti. Lo standard ISO 8000 offre il vocabolario: completezza e accuratezza, coerenza e tempestività, unicità e validità, ognuna misurabile con metriche concrete sulle tabelle che contano. Il salto di maturità sta nel passare dal giudizio ("i dati del CRM sono buoni") al numero ("completezza dell'anagrafica al 94%, duplicati al 3%, aggiornamento medio 36 ore"), perché solo il numero permette soglie, trend e accountability degli owner.

Per l'AI la misurazione va tarata sul caso d'uso, con una soglia dichiarata sotto la quale il dataset non entra in pipeline, e un monitoraggio che continua in produzione, dato che i dati si degradano e i modelli con loro. È lo stesso principio dei gate critici che applichiamo nell'AI Rating: sotto certe condizioni non si compensa, ci si ferma.

L'errore dell'impianto totale

L'errore di impostazione più diffuso è progettare la governance come un impianto totale da costruire prima di qualunque AI, con anni di cataloghi, comitati e policy universali. Il progetto totale fallisce quasi sempre per la stessa ragione dei grandi programmi di data quality, nessun ritorno visibile lo tiene in vita, e nel frattempo blocca tutto il resto.

L'impostazione che vediamo funzionare procede per perimetri: si parte dai domini di dati che i primi casi d'uso AI toccano, lì si assegnano owner e steward, si scrivono le policy che servono davvero, si misurano le sei dimensioni di qualità, e si lascia che la roadmap AI estenda il perimetro governato un dominio alla volta. La governance cresce così alla velocità del valore che abilita, che è anche il modo migliore per difenderne il budget.

Nel nostro AI Rating la data governance attraversa Readiness e Risk, con evidenze puntuali: ruoli assegnati o vacanti, policy esistenti o presunte, qualità misurata o percepita, e ogni gap entra nella roadmap con priorità e owner. Se voleste applicare il test minimo già oggi, prendete le tre fonti di dati più critiche per il vostro prossimo progetto AI e scrivete accanto a ciascuna il nome dell'owner: se una delle tre righe resta vuota, sapete da dove iniziare. Per la versione completa: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. La governance dei dati, alla prova dell'AI, si riduce a una domanda quasi anagrafica: di chi sono, con nome e cognome, i dati su cui state per costruire?