Governance dei dati: dai pilastri alle prove

In sintesi

• La governance dei dati è il modello operativo che stabilisce chi decide, in base a quali regole, attraverso quali processi e su quale tecnologia. Su questo punto tutte le guide disponibili concordano.
• Ciò che è cambiato è il risultato atteso. Nel momento in cui entrano in gioco sistemi di IA, la governance dei dati deve produrre prove documentali e non soltanto decisioni.
• L’articolo 10 dell’AI Act pone otto requisiti espliciti sui set di dati di addestramento, convalida e prova.
• DAMA-DMBOK, DCAM, DGI e COBIT sono anteriori alla regolamentazione dei dati di addestramento. Restano ossature valide, ma nessuno di essi indica che cosa archiviare.
• Una sola verifica è dirimente: il vostro impianto è in grado di produrre, per qualunque modello in produzione, una scheda del set di dati, un tracciato di provenienza e una relazione sull’esame dei bias?

Che cosa si intende davvero per governance dei dati

La governance dei dati è il modello operativo che determina il modo in cui un’organizzazione raccoglie, conserva, protegge e utilizza i propri dati. Si articola in quattro componenti ricorrenti: politiche e standard che fissano le regole, ruoli e responsabilità che reggono la rendicontabilità, processi che trasformano le regole in prassi e tecnologia che conserva traccia di quanto è avvenuto.

Si tratta di una definizione corretta ma incompleta, poiché descrive una struttura decisionale e non dice quasi nulla su ciò che tale struttura deve produrre. Per vent’anni l’omissione ha avuto conseguenze modeste, dal momento che il destinatario del modello era l’organizzazione stessa, nella forma di un cruscotto di qualità, di un comitato di indirizzo e di un catalogo pensato per gli analisti.

Questa stagione si è chiusa. Quando i dati alimentano un sistema di IA, il destinatario della vostra governance dei dati può essere un organismo notificato, un’autorità di vigilanza del mercato oppure un grande cliente che conduce la propria due diligence sui fornitori. Questi lettori non accettano un modello operativo come risposta: chiedono documenti. Un impianto che non sia in grado di produrli configura un racconto di conformità, che è cosa ben diversa. Il tema si colloca all’interno della questione più ampia della governance dell’IA intesa come disciplina operativa.

Governance dei dati e gestione dei dati

La distinzione è più semplice di quanto lascino intendere molte trattazioni. La gestione dei dati attiene all’esecuzione: flussi, archiviazione, regole di qualità, dati anagrafici, integrazione. La governance dei dati costituisce il livello di autorità sovrastante: chi ha titolo per decidere, quale sia lo standard applicabile e in che modo l’organizzazione dimostri che lo standard è stato rispettato.

Un modo utile per tenere ferma la differenza consiste nel dire che la gestione risponde al come, mentre la governance risponde alla domanda su chi l’abbia stabilito e dove si trovi la prova. Chi produce soltanto documentazione di processo ha descritto la gestione e l’ha chiamata governance.

I quattro modelli di riferimento e la loro finalità originaria

Tutte le trattazioni citano il medesimo elenco. Non si tratta di modelli concorrenti: sono stati concepiti per scopi differenti.

Modello	Origine	Finalità	Impiego consigliato
DAMA-DMBOK	DAMA International	Definire la prassi di gestione dei dati su undici aree di conoscenza	Come riferimento di prassi e lessico
DCAM	EDM Council	Misurare la maturità delle capacità rispetto a un parametro	Come strumento di valutazione
Modello DGI	Data Governance Institute	Disegnare diritti decisionali e catene di responsabilità	Come livello organizzativo
COBIT	ISACA	Governare il sistema informativo e il rischio tecnologico	Come lessico di audit e controllo

Lo schema più diffuso nel 2026 consiste nell’abbinarli: il DAMA-DMBOK definisce la buona prassi, il DCAM misura la distanza che vi separa da essa. La versione 3.0 del DMBOK, attualmente in elaborazione, estende il proprio perimetro alla gestione dei dati per l’apprendimento automatico, il che indica con chiarezza la direzione intrapresa.

Perché nessuno di essi è stato scritto per i sistemi di IA

Tutti e quattro sono stati concepiti per governare il dato in quanto risorsa aziendale. Nessuno è stato concepito per governarlo in quanto componente di un prodotto regolamentato. Lo spostamento non ha nulla di cosmetico.

Nella logica della risorsa, la domanda rivolta a un set di dati riguarda l’accuratezza, la reperibilità, la sicurezza e la titolarità. Nella logica del prodotto la domanda cambia natura: quel preciso set di addestramento era pertinente e sufficientemente rappresentativo rispetto alla finalità per la quale il modello è stato immesso sul mercato, e siete in grado di dimostrarlo? Una governance dei dati costruita sulla logica della risorsa risponderà agevolmente alla prima domanda e per nulla alla seconda.

Che cosa cambia quando l’IA entra nel patrimonio informativo

Tre mutamenti si producono simultaneamente.

In primo luogo, i dati di addestramento, convalida e prova diventano un oggetto regolamentato dotato di criteri di qualità fissati per legge. Non sono più semplici input analitici, bensì il fondamento probatorio di un’affermazione di conformità relativa a un prodotto.

In secondo luogo, ogni set di dati acquisisce un responsabile chiamato a rispondere della rappresentatività e non soltanto dell’accuratezza. Si tratta di proprietà distinte, poiché un set può risultare perfettamente accurato rispetto alla popolazione sbagliata.

In terzo luogo, l’inventario su cui poggia la vostra governance dei dati cessa di essere affidabile. L’impianto presuppone che sia noto quali sistemi consumino quali dati, e gli strumenti non dichiarati incrinano silenziosamente tale presupposto: è la ragione per cui la shadow AI costituisce anzitutto un problema di dati e solo in seconda battuta un problema di sicurezza. Se un gruppo di lavoro incolla anagrafiche di clienti in un assistente non autorizzato, nessun registro annota quel flusso e nessuna politica ha trovato applicazione.

Articolo 10 dell’AI Act: gli obblighi da soddisfare

L’articolo 10 è la disposizione che trasforma la governance dei dati da buona prassi in obbligo giuridico per i sistemi di IA ad alto rischio. Ai sensi dell’articolo 10, paragrafo 1, i sistemi ad alto rischio sviluppati mediante tecniche di addestramento devono fondarsi su set di dati di addestramento, convalida e prova che soddisfino i criteri di qualità enunciati dalla disposizione.

Il paragrafo 2 stabilisce che tali set siano sottoposti a pratiche di governance e gestione adeguate alla finalità prevista, elencando poi otto profili da coprire. Letti come capitolato, impongono di documentare:

1. Le scelte progettuali, formalizzate anziché presupposte.
2. I processi di raccolta e l’origine dei dati, compresa, per i dati personali, la finalità originaria della raccolta.
3. Le operazioni di preparazione: annotazione, etichettatura, pulizia, aggiornamento, arricchimento e aggregazione.
4. Le ipotesi su ciò che i dati dovrebbero misurare e rappresentare.
5. La valutazione di disponibilità, quantità e idoneità dei set necessari.
6. L’esame dei bias suscettibili di incidere sulla salute, sulla sicurezza o sui diritti fondamentali, ivi compresi gli effetti discriminatori.
7. Le misure adeguate di rilevazione, prevenzione e attenuazione di tali bias.
8. L’individuazione di lacune o carenze che ostacolano la conformità, unitamente al relativo rimedio.

Il paragrafo 3 fissa la soglia qualitativa: i set devono essere pertinenti, sufficientemente rappresentativi e, nella misura del possibile, privi di errori e completi rispetto alla finalità prevista, con proprietà statistiche adeguate alle popolazioni interessate. Il paragrafo 4 impone di tenere conto delle caratteristiche proprie del contesto geografico, comportamentale o funzionale di utilizzo. Un modello di selezione del personale convalidato su un mercato del lavoro nazionale non porta con sé quella convalida quando varca un confine.

Il paragrafo 5 contiene una facoltà circoscritta e spesso fraintesa: il fornitore può eccezionalmente trattare categorie particolari di dati personali ove ciò sia strettamente necessario alla rilevazione e alla correzione dei bias, fatte salve garanzie adeguate e in assenza di alternative efficaci. Si tratta di una deroga delimitata e non di una licenza a raccogliere abitualmente attributi sensibili, come il Garante per la protezione dei dati personali ha avuto modo di ribadire richiamando il principio di minimizzazione. Il paragrafo 6 chiude il quadro per i sistemi che non apprendono dai dati, rispetto ai quali rilevano i soli set di prova. L’architettura complessiva di questi obblighi è illustrata nella nostra guida operativa al regolamento europeo.

L’allegato IV e l’obbligo di scheda descrittiva

L’articolo 10 dice come devono essere i dati. L’allegato IV dice che cosa deve risultare per iscritto. Il punto 2, lettera d), dell’allegato IV richiede che la documentazione tecnica comprenda, ove pertinente, schede descrittive delle metodologie e delle tecniche di addestramento nonché dei set utilizzati: descrizione generale, provenienza, ambito e caratteristiche principali, modalità di ottenimento e selezione dei dati, procedure di etichettatura e metodologie di pulizia. Il punto 2, lettera g), estende la medesima disciplina ai dati di convalida e prova e alle metriche di accuratezza e robustezza.

È questa la disposizione che modifica la natura del lavoro richiesto. La tracciabilità cessa di essere una comodità per gli analisti e diventa un deliverable documentale in formato prescritto. Il riferimento scientifico sottostante è il contributo di Gebru e colleghi, Datasheets for Datasets, che proponeva esattamente questa forma: motivazione, composizione, processo di raccolta, pre-elaborazione, usi, distribuzione e manutenzione. La nostra guida alla documentazione dei sistemi di IA copre il resto del fascicolo.

Che cosa deve il deployer ai sensi dell’articolo 26, paragrafo 4

La letteratura sul tema si rivolge quasi sempre al titolare dei dati. Il regolamento vincola però anche l’organizzazione che si limita ad acquistare il sistema. Ai sensi dell’articolo 26, paragrafo 4, il deployer che eserciti il controllo sui dati di input deve garantire che tali dati siano pertinenti e sufficientemente rappresentativi rispetto alla finalità prevista del sistema ad alto rischio. Il paragrafo 6 impone la conservazione dei log generati automaticamente per almeno sei mesi.

Ne consegue che, se utilizzate in licenza un modello di scoring alimentandolo con le vostre anagrafiche, la vostra governance dei dati porta un obbligo di legge su quelle anagrafiche. L’acquisto del modello non esternalizza l’obbligo relativo al dato.

Allineare i pilastri alla ISO 42001 e al NIST AI RMF

La mossa utile non consiste nel sostituire l’impianto esistente, bensì nel ridefinire ciò che ciascun pilastro deve restituire. La tabella che segue ne offre la versione sintetica.

Pilastro classico	ISO/IEC 42001 allegato A	NIST AI RMF	Documento da produrre
Politiche e standard	A.7.2 dati per lo sviluppo, A.7.4 qualità dei dati	MAP 2.3	Criteri di qualità scritti per finalità
Ruoli e responsabilità	A.7.3 acquisizione dei dati	MAP 4.1, MAP 4.2	Responsabile nominato e riesame dei dati di terzi
Processi	A.7.6 preparazione dei dati	MAP 2.3	Protocollo di etichettatura, relazione sui bias
Tecnologia	A.7.5 provenienza dei dati	MEASURE 2.2	Tracciato dalla sorgente all’input del modello

La norma ISO/IEC 42001 raccoglie i requisiti sui dati nel controllo A.7 dell’allegato A, dedicato ai dati per i sistemi di IA e articolato in A.7.2 dati per lo sviluppo e il miglioramento, A.7.3 acquisizione dei dati, A.7.4 qualità dei dati, A.7.5 provenienza dei dati e A.7.6 preparazione dei dati. Chi punta alla certificazione lavora esattamente contro questo elenco, che si innesta sull’articolo 10 senza duplicarlo. Abbiamo trattato altrove le ragioni per cui la sola ISO 42001 non produce conformità all’AI Act.

Il NIST AI RMF fornisce invece un lessico del rischio e non un traguardo certificativo. La sottocategoria MAP 2.3 riguarda l’integrità scientifica e le attività di test, valutazione, verifica e convalida, includendo espressamente il disegno sperimentale nonché la raccolta e la selezione dei dati. Le sottocategorie MAP 4.1 e 4.2 attengono al rischio derivante da dati di terzi e all’obbligo di riesaminare il materiale acquisito dall’esterno sotto il profilo dei bias, della riservatezza e della sicurezza prima di ogni autorizzazione. Quest’ultimo punto pesa ogni anno di più, dal momento che la maggior parte delle organizzazioni addestra ormai su dati che non ha raccolto. Il raffronto completo tra i riferimenti si trova nel nostro confronto fra NIST AI RMF, ISO 42001, AI Act e principi OCSE.

L’elenco dei documenti da produrre

Questa è la traduzione operativa. Una governance dei dati che copra sistemi di IA deve essere in grado di produrre, su richiesta e per ciascun sistema, i nove documenti seguenti.

1. Un registro dei set di dati collegato all’inventario dei sistemi di IA, affinché ogni modello possa essere ricondotto ai dati che ha utilizzato.
2. Una scheda descrittiva per ciascun set di addestramento, convalida e prova, nel formato dell’allegato IV.
3. Un tracciato di provenienza dal sistema sorgente all’input del modello, comprensivo delle trasformazioni.
4. Una relazione sull’esame dei bias che indichi le caratteristiche protette esaminate e il metodo adottato.
5. Un registro delle decisioni di attenuazione, comprensivo delle decisioni di accettare un bias residuo e di chi le ha assunte.
6. Un registro di lacune e carenze con responsabili e scadenze, che dà corpo alla lettera h) del paragrafo 2.
7. Un protocollo di annotazione, con misura della concordanza fra annotatori ove le etichette comportino margini di giudizio.
8. Un prospetto di conservazione e base giuridica, raccordato alla valutazione d’impatto sulla protezione dei dati ove siano coinvolti dati personali.
9. Un’approvazione nominativa per ciascuna versione del set, poiché un documento non firmato è un’affermazione e non un controllo.

I punti quattro e cinque sono quelli in cui i programmi risultano più fragili e sono i primi che un auditor richiede. La nostra guida al bias dell’IA illustra i metodi di esame.

Il registro degli elementi dati critici, esteso all’IA

Gli enti regolamentati tengono già un registro degli elementi dati critici. Non vi serve un secondo registro, bensì una chiave esterna.

Aggiungete una relazione fra ciascun elemento critico e i sistemi di IA che lo utilizzano e il registro smetterà di essere un artefatto di qualità per rispondere a domande di conformità: quali modelli risultano compromessi se quell’elemento si degrada, quali set ne hanno ereditato i difetti noti e quali responsabili di modello vanno avvisati quando la sua definizione muta. Questa sola giunzione converte un lavoro già svolto in prova regolamentare a costo marginale, ed è l’intervento a maggior resa su un impianto esistente.

Un percorso in novanta giorni

Una sequenza realistica per un’organizzazione che disponga già di una governance dei dati e debba estenderla all’IA.

1. Settimane 1 e 2, perimetro e presupposto giuridico. Stabilite quali sistemi rientrino nell’alto rischio, quali siano modelli per finalità generali che vi limitate a utilizzare e quali restino fuori ambito. Gli obblighi divergono sensibilmente e gli errori di qualificazione si pagano dopo.
2. Settimane 3 e 4, inventario. Censite i sistemi di IA e i set che ciascuno utilizza. Attendetevi un elenco incompleto al primo passaggio e programmate una ricognizione degli strumenti non dichiarati.
3. Settimana 5, classificazione. Qualificate ogni set per sensibilità, base giuridica, origine (interna, di terzi, sintetica, estratta dal web) e natura di addestramento, convalida o prova.
4. Settimana 6, responsabilità. Assegnate un responsabile nominato per ciascun set. Una persona, non una struttura: una responsabilità condivisa è una responsabilità assente.
5. Settimane da 7 a 9, documentazione. Redigete le schede nel formato dell’allegato IV, partendo dal sistema più esposto, poiché è lì che il formato viene messo realmente alla prova.
6. Settimane 10 e 11, verifica di rappresentatività. Confrontate le proprietà statistiche dei set con la popolazione destinataria e con il contesto di impiego. Verbalizzate gli scostamenti rilevati anziché correggerli in silenzio.
7. Settimana 12, approvazione e cadenza. Ottenete l’approvazione nominativa e fissate l’evento che innesca il riesame, ancorandolo ai riaddestramenti e non al calendario.

È proprio sulla cadenza che i programmi sbagliano più spesso. Se il vostro framework di governance dell’IA riesamina i dati una volta l’anno mentre i modelli vengono riaddestrati ogni settimana, la documentazione descrive un sistema che non esiste più.

I cinque fallimenti ricorrenti

La maturità di facciata. Il programma si autovaluta rispetto a un modello di capacità e comunica progressi senza alcuna prova a sostegno del punteggio. La dichiarazione del management non costituisce evidenza.

Lo strumento prima della regola. Si acquista un catalogo prima ancora che sia stata scritta la politica che dovrebbe applicare. Lo strumento finisce per codificare le convenzioni di chi lo ha configurato.

L’assenza di un responsabile dei dati di addestramento. I sistemi sorgente hanno un titolare. Il set derivato, composto a partire da quattro di essi, filtrato, rietichettato e congelato per una versione del modello, di norma non ne ha alcuno.

Registri mai congiunti. Il catalogo dei dati e l’inventario dei sistemi di IA risiedono in strumenti diversi, gestiti da strutture diverse, sicché nessuna interrogazione può stabilire quale modello abbia impiegato quali dati. È la causa più frequente di un audit dell’IA che non trova nulla di utilizzabile.

Perimetro fermo ai dati personali. I programmi di protezione dei dati coprono bene il dato personale. L’articolo 10 abbraccia l’intero corredo di addestramento, compresi dati operativi, di sensoristica e sintetici privi di qualunque componente personale.

Domande frequenti

Quali sono i quattro pilastri della governance dei dati?

Politiche e standard, ruoli e responsabilità, processi e tecnologia. Alcuni fornitori li declinano in cinque, sette o dieci componenti, ma le aggiunte costituiscono suddivisioni e non categorie nuove: qualità, gestione dei metadati e tracciabilità rientrano nei processi e nella tecnologia. Quando sono coinvolti sistemi di IA, occorre trattare come obbligatorio un quinto profilo, raramente elencato: le prove prodotte, ossia schede, tracciati e relazioni sui bias che un’autorità possa effettivamente leggere.

Quali sono i principi fondamentali?

La rendicontabilità con un responsabile nominato per ciascun set, la trasparenza su origine e trasformazioni, una qualità definita rispetto a una finalità dichiarata anziché in astratto, una protezione proporzionata alla sensibilità e alla base giuridica, e la tracciabilità dalla sorgente all’utilizzo. Sotto l’AI Act qualità e tracciabilità pesano di più, poiché l’articolo 10, paragrafo 3, introduce un criterio relativo alla finalità e non un requisito generale.

Che differenza c’è fra governance dei dati e governance dell’IA?

La prima governa il dato. La seconda governa i sistemi costruiti su di esso, oltre ai modelli, alle decisioni di impiego, alla sorveglianza umana e alla gestione degli incidenti. Si sovrappongono in un punto soltanto, i dati di addestramento, ed è esattamente lì che l’AI Act colloca gli obblighi documentali più gravosi. In concreto le due funzioni dovrebbero condividere inventario e tassonomia del rischio, mantenendo però responsabili e cadenze di riesame distinti.

Quale modello adottare: DAMA-DMBOK, DCAM o DGI?

Di rado occorre scegliere in via esclusiva. Il DAMA-DMBOK fornisce definizione di prassi e lessico, il DCAM la misura della maturità, il DGI il disegno dei diritti decisionali. Lo schema corrente abbina il primo per la prassi e il secondo per misurare l’avanzamento. Se rientrano sistemi di IA, nessuno dei tre basta da solo, poiché nessuno specifica i documenti richiesti dall’allegato IV: occorre sovrapporvi l’allegato A.7 della ISO/IEC 42001.

L’AI Act impone una governance dei dati?

Per i sistemi ad alto rischio, nella sostanza sì. L’articolo 10, paragrafo 2, impone che i set di addestramento, convalida e prova siano sottoposti a pratiche adeguate di governance e gestione, elencando poi otto profili da coprire. Il testo non indica alcun modello e non ne impone uno specifico, sicché un impianto esistente e adattato può risultare sufficiente. Ciò che il regolamento impone è semmai l’esito documentale, per il tramite dell’allegato IV.

A chi compete la titolarità dell’impianto?

Compete di norma al chief data officer o a una figura equivalente, affiancata da un organo di indirizzo per le decisioni trasversali. Più del titolo contano due condizioni: che la responsabilità sul singolo set sia personale e che chi la detiene abbia il potere di bloccare un rilascio. Ove siano coinvolti sistemi di IA, il responsabile della governance dei dati e quello della governance dell’IA devono decidere congiuntamente sui dati di addestramento, poiché nessuno dei due può approvare da solo.

Conclusione

Le trattazioni disponibili vi diranno che la governance dei dati poggia su quattro pilastri e che conviene scegliere un modello. È vero, ed è il punto in cui la maggior parte dei consigli si ferma. La domanda difficile è un’altra: che cosa consegnate quando un soggetto esterno alla vostra organizzazione chiede come sia stato composto il set di addestramento di un modello, se rappresentasse le persone alle quali il modello sarebbe stato applicato e chi lo abbia approvato.

Se oggi la risposta onesta si esaurisce in una politica e in una schermata del catalogo, la debolezza non risiede nei pilastri, bensì nei documenti che a essi non sono mai stati richiesti. Cominciate dal registro dei set collegato all’inventario dei sistemi di IA: il resto della catena probatoria troverà dove ancorarsi.

Scoprite come AI Sigil trasforma gli obblighi di governance dei dati in prove opponibili.