Cosa deve contenere una Model Card per la governance dell'IA?

Risposta breve

Una Model Card per la governance dell’IA non dovrebbe limitarsi a descrivere quale modello di IA viene utilizzato, ma dovrebbe documentare in modo strutturato a cosa serve il modello, quale versione è in uso, chi è il fornitore o il gestore, quali fonti di dati vengono utilizzate, quali informazioni relative a prestazioni, sui pregiudizi e sui rischi, quali limitazioni sono note, in che modo il modello sia collegato a un caso d’uso concreto dell’IA, quali autorizzazioni siano state concesse e quando sia prevista la prossima revisione.

Affinché una Model Card rimanga valida anche durante il funzionamento, non deve essere considerata un semplice allegato PDF statico. Non appena cambiano la versione del modello, la fonte dei dati, il fornitore, lo scopo, le metriche o la valutazione del rischio, anche la Model Card deve essere aggiornata, verificata e contrassegnata con un numero di versione.

Perché è necessario continuare a utilizzare una Model Card anche dopo il go-live

In molte organizzazioni, le schede dei modelli vengono ancora considerate alla stregua di un allegato alla documentazione, che una volta redatto viene archiviato. Spesso un documento di questo tipo contiene alcune informazioni tecniche sul modello, dettagli sui dati di addestramento, metriche o limitazioni note, nonché un link alla Documentazione del fornitore. Tuttavia, non appena il caso d'uso dell'IA viene implementato in produzione, proprio quei presupposti su cui si basava l'originale Documentazione si basa.

• Il modello è in fase di aggiornamento.
• Il fornitore lancia una nuova versione.
• Viene aggiunta una fonte di dati.
• Il dipartimento utilizza i risultati in modo diverso rispetto a quanto descritto inizialmente.
• Si stanno individuando nuovi rischi.
• Un indicatore di prestazione sta cambiando.
• Rimane aperta una segnalazione relativa al monitoraggio.
• Una condizione di autorizzazione sta per scadere.

Se la Model Card non tiene conto di tali modifiche, non riflette più la realtà del modello in produzione, ma solo uno stato precedente. Ciò che conta, quindi, non è se una Model Card sia stata creata una volta, ma se i suoi contenuti continuino a corrispondere all’effettivo utilizzo del modello. In assenza di tale corrispondenza, sorge un problema di governance, poiché verifiche, approvazioni e responsabilità potrebbero basarsi su dati obsoleti.

Perché le “model cards” devono essere interpretate in modo diverso nella governance dell’IA

La governance dell’IA non consiste solo nel descrivere tecnicamente un modello, ma nel rendere il suo utilizzo all’interno dell’azienda controllabile, verificabile e responsabile. Un documento statico non è sufficiente a tal fine, poiché un modello può essere utilizzato in diversi casi d’uso, lo stesso fornitore può mettere a disposizione diverse versioni del modello, uno strumento di IA può utilizzare più modelli e la valutazione del rischio varia notevolmente a seconda dello scopo, della fonte dei dati o dell’influenza sul processo decisionale.

Una Model Card dovrebbe quindi essere intesa, all’interno di una piattaforma di governance dell’IA, come un oggetto operativo dinamico che collega tra loro modello, fornitore, dati, caso d’uso, rischio, approvazione, monitoraggio e revisione. È solo grazie a questo collegamento che una descrizione tecnica diventa parte integrante del processo di governance in corso.

Il problema della comprensione dei PDF

Un PDF può rivelarsi utile per un’esportazione, una verifica, una documentazione nei confronti di clienti, revisori o organi interni, oppure come istantanea della situazione. Come modello operativo, tuttavia, è adatto solo in misura limitata, poiché un documento statico non riconosce automaticamente se la versione documentata è ancora attiva, se un caso d’uso ora accede a un’altra fonte di dati, se è necessaria una revisione, se un’approvazione è ancora valida per la versione attuale del modello o se vi sono rischi e misure ancora in sospeso.

Allo stesso modo, un PDF non è in grado di distinguere in modo affidabile tra una versione storica e una produttiva, né di indicare chi abbia verificato per ultimo una modifica. La domanda fondamentale non è quindi: „Abbiamo una Model Card come documento?“, ma: „La Model Card viene gestita nell’ambito del processo di governance dell’IA in corso?“

Cosa deve garantire una Model Card

In AI Governance, una Model Card dovrebbe svolgere almeno cinque funzioni che vanno oltre la semplice descrizione del modello.

1. Descrizione strutturata del modello: Essa riporta il nome, la versione, il fornitore, il tipo di modello, la finalità, i limiti di utilizzo e le informazioni tecniche di base.
2. Collegamento con casi d'uso concreti dell'IA: Essa stabilisce un collegamento con l'utilizzo effettivo, poiché un rischio di modello può essere valutato in modo significativo solo nel contesto concreto di utilizzo.
3. Documentazione da recensioni: Tra le altre cose, tiene conto di performance, bias, spiegabilità, robustezza, Protezione dei dati, sicurezza delle informazioni e limitazioni note.
4. Supporto decisionale: Essa getta le basi per associare le approvazioni a una versione specifica del modello e a un caso d'uso specifico.
5. Novità in azienda: Rende tracciabili le modifiche apportate alla versione, alla fonte dei dati, al provider, allo scopo, alle metriche o al rischio.

Queste funzioni trasformano una Model Card in una documentazione operativa che non solo descrive lo stato attuale, ma può anche essere integrata nei processi di verifica, approvazione e revisione.

Quali campi sono davvero necessari

Una buona Model Card non dovrebbe essere costituita prevalentemente da testo libero, ma contenere campi strutturati, in modo che le informazioni possano essere verificate, filtrate, riportate e aggiornate. Quali campi siano necessari nel dettaglio dipende dal rispettivo modello di governance; in genere, tuttavia, sono inclusi i seguenti ambiti.

Identità del modello

• Nome del modello
• ID modello interno
• Versione del modello
• Tipo di modello
• Fornitore
• Gestore
• Modello di hosting o di distribuzione
• Stato
• Valido a partire dal
• ultima modifica
• recensione successiva

Contesto di utilizzo

• Casi d'uso correlati dell'IA
• Finalità dell’intervento
• colpiti Processi aziendali
• Gruppi di utenti
• Tipo di output
• Influenza sul processo decisionale
• controllo umano
• Limiti di impiego
• usi non consentiti

Dati e fonti dei dati

• Dati relativi agli allenamenti, per quanto noti
• Dati di input nel caso d'uso specifico
• fonti di dati collegate
• Dati personali
• categorie particolari di dati personali
• dati aziendali riservati
• Origine dei dati
• Qualità dei dati
• Attualità dei dati
• Flusso dei dati e sedi di archiviazione

Prestazioni e metriche

• indicatori di prestazione rilevanti
• Data del test
• Ambiente di test
• Set di dati di prova
• scostamenti noti
• Tassi di errore
• Valori soglia
• Risultati del monitoraggio
• Confronto con la versione precedente

Pregiudizio, equità e spiegabilità

• rischi noti di distorsione
• gruppi o scenari testati
• Valutazioni di equità
• Approccio basato sulla spiegabilità
• I limiti della spiegabilità
• modelli di errore noti
• valutazione umana necessaria

Rischi e controlli

• Classificazione dei rischi
• Rischi relativi alla protezione dei dati
• Rischi per la sicurezza
• rischi legali
• rischi operativi
• Rischi di reputazione
• Misure di controllo
• misure in corso
• rischio residuo
• Accettazione del rischio

Fornitori e approvvigionamento da terzi

• Fornitore
• Base contrattuale
• Documentazione del fornitore
• Fornitori di servizi secondari o terze parti rilevanti
• Luoghi di conservazione e trattamento
• Informazioni sull'assistenza e sulle modifiche
• SLA o informazioni operative
• Obbligo di informazione in caso di modifiche al modello

Approvazione e governance

• Proprietario
• Proprietario del modello
• Responsabile del caso d'uso
• Recensore
• DPO / Verifica della protezione dei dati
• Revisione legale
• Analisi della sicurezza informatica
• Approvazione del dipartimento
• Approvazione da parte della direzione, se necessario
• Data di rilascio
• Condizioni di autorizzazione
• Intervallo di revisione

Modifiche e gestione delle versioni

• Cronologia delle modifiche
• Valori prima/dopo
• Motivo della modifica
• persona o ruolo all'origine dell'evento
• colpiti Casi d'uso
• nuove autorizzazioni necessarie
• versioni precedenti
• Stato attuale della produzione

L'elenco è ampio, ma ciò non è fine a se stesso. Una Model Card non è una semplice copertina, bensì uno strumento operativo che riunisce le informazioni rilevanti per la governance in modo tale che rimangano tracciabili e analizzabili durante il normale svolgimento delle attività.

Perché il caso d'uso è fondamentale

Un modello di per sé dice poco sul rischio effettivo, poiché lo stesso modello linguistico può essere utilizzato, ad esempio, per bozze di testi interni o per la valutazione preliminare di reclami, candidature, richieste dei clienti o casi di rischio. Sebbene il modello tecnico sia identico o simile, i requisiti di governance variano notevolmente a seconda dell’utilizzo.

Per questo motivo, una Model Card deve sempre essere collegata al caso d’uso specifico per il quale è rilevante sapere con quali dati opera il modello, quale output genera, quale influenza tale output ha sulle decisioni e chi ne è responsabile. Senza questo collegamento, la Model Card rimane un elemento puramente tecnico; solo attraverso il contesto operativo diventa uno strumento di governance.

Le versioni dei modelli non sono una nota a margine

Molte organizzazioni sottovalutano l’importanza delle versioni di prova, sebbene già una nuova versione possa avere ripercussioni rilevanti dal punto di vista tecnico. Essa può migliorare la qualità delle risposte, ma allo stesso tempo generare nuovi modelli di errore, interpretare in modo diverso i prompt esistenti, richiedere soglie diverse o includere nuovi meccanismi di sicurezza. Anche i provider-Documentazione, le autorizzazioni, le informazioni sui clienti o le linee guida interne potrebbero esserne interessate.

Una Model Card affidabile dovrebbe quindi documentare non solo il nome del modello, ma anche la versione produttiva e la relativa cronologia delle modifiche. In caso di audit, incidenti o successive decisioni gestionali, deve essere possibile risalire a quale versione sia stata verificata e approvata, quale versione fosse in produzione, da quali casi d’uso dipendesse e quale modifica abbia dato origine a una nuova revisione.

Le fonti dei dati modificano il rischio

Una Model Card deve tenere conto non solo del modello, ma anche del contesto concreto in cui viene utilizzata, poiché lo stesso tipo di modello può essere valutato in modo completamente diverso a seconda dei dati trattati. È quindi rilevante, tra l’altro, se si tratti di informazioni pubbliche sui prodotti, dati dei clienti, Dati sui dipendenti, se vengono trattati dati personali appartenenti a categorie particolari o informazioni aziendali riservate, se viene impiegata la “Retrieval-Augmented Generation”, quali sistemi interni sono collegati e se i dati vengono utilizzati per l’addestramento o la messa a punto oppure vengono memorizzati presso il fornitore.

Se una fonte di dati subisce modifiche, anche la valutazione del rischio potrebbe cambiare. Per questo motivo è necessario stabilire chi, in tal caso, aggiorni la Model Card e chi verifichi se la modifica richieda una nuova revisione o una nuova approvazione.

È necessario aggiornare le informazioni relative al provider

Molti sistemi di IA si basano su modelli esterni, piattaforme, API o funzionalità di IA integrate; per questo motivo, anche le informazioni relative al fornitore dovrebbero essere incluse nella Model Card. Tra queste figurano in particolare il fornitore, la base contrattuale, i dati tecnici Documentazione, versione utilizzata, informazioni sulle modifiche, Trasmissione dei dati, sedi di archiviazione, informazioni sulla sicurezza e sulla protezione dei dati, fornitori di servizi ausiliari rilevanti, nonché informazioni relative al funzionamento e alla disponibilità.

Poiché i fornitori possono modificare modelli, funzioni, condizioni d'uso, opzioni di trattamento dei dati, documentazione sulla sicurezza o interfacce, anche queste informazioni devono essere aggiornate. In caso contrario, la Model Card perde di significato, poiché le condizioni generali documentate non corrispondono più al servizio effettivamente utilizzato.

Le prestazioni sono rilevanti solo se corrispondono al caso d'uso

Le schede dei modelli contengono spesso metriche quali accuratezza, precisione, recall, punteggio F1, tasso di errore, robustezza, tasso di allucinazioni, nonché falsi positivi o falsi negativi. Tali indicatori sono tuttavia significativi solo se è chiaro a cosa si riferiscono, poiché un benchmark globale del produttore non costituisce automaticamente una prova attendibile per l’applicazione concreta in azienda.

Per la governance è quindi fondamentale stabilire quale metrica sia rilevante per il singolo caso d’uso, su quale set di dati di test e in quale ambiente sia stata effettuata la misurazione, quali siano i valori soglia applicabili, quali errori siano critici, chi valuti i risultati e quali misure vengano attivate qualora le prestazioni scendano al di sotto di un limite definito. Allo stesso modo, occorre documentare se e in che modo le prestazioni continuano a essere monitorate dopo la messa in produzione.

Il pregiudizio e l'imparzialità non devono essere relegati in una nota a piè di pagina

In molte applicazioni di intelligenza artificiale, il bias non è un tema teorico, ma una questione concreta di governance, poiché determinati gruppi possono essere sistematicamente svantaggiati, i dati di addestramento o di input possono essere sbilanciati oppure i risultati possono rivelarsi peggiori per singoli gruppi di casi. Una Model Card dovrebbe quindi indicare quali rischi di bias sono noti, quali gruppi o scenari sono stati testati, quali sono i limiti dei test, quali misure di protezione sono previste e in quali casi rimane necessaria una verifica umana.

Anche questa valutazione non è valida a lungo termine. Se le fonti dei dati, le versioni del modello, i valori soglia o il contesto di applicazione cambiano, è necessario verificare se la valutazione precedente relativa al bias e alla correttezza sia ancora valida.

La spiegabilità dipende dal contesto

Non tutti i casi d’uso dell’IA richiedono lo stesso tipo di spiegabilità. Per uno strumento interno di sintesi, i requisiti sono diversi rispetto a quelli di un sistema che stabilisce le priorità dei rischi, prepara le decisioni o tratta le persone in modo diverso. Una Model Card non dovrebbe quindi limitarsi a indicare se un modello è „spiegabile“, ma descrivere quale tipo di spiegazione è disponibile, a chi è destinata, come viene verificata la plausibilità dei risultati, quali sono i limiti esistenti e quale verifica umana è prevista.

La spiegabilità non è quindi una semplice voce da spuntare, ma una componente del modello operativo che deve essere adeguata al contesto specifico di utilizzo e al possibile impatto sulle decisioni.

L'approvazione deve riferirsi alla versione specifica

Un'approvazione è attendibile solo se è possibile risalire con chiarezza allo stato a cui si riferisce. Se un caso d'uso dell'IA viene verificato e approvato sulla base di una determinata Model Card, devono poter essere chiaramente identificati la versione del modello, le fonti dei dati, la valutazione dei rischi e le condizioni di approvazione.

In caso di modifiche sostanziali, quali ad esempio una nuova versione del modello, un nuovo fornitore, una fonte di dati aggiuntiva, una modifica della finalità, una diversa cerchia di utenti, un output modificato, nuove indicazioni relative al bias o misure di sicurezza e protezione dei dati ancora in fase di definizione, è necessario verificare se l’approvazione esistente sia ancora valida o se sia necessaria una nuova revisione. La Model Card dovrebbe quindi essere integrata nel processo di approvazione e non fungere semplicemente da allegato.

Revisioni e rielaborazioni

Una Model Card mantiene la propria validità solo se viene verificata regolarmente; per questo motivo deve essere possibile risalire a quando è stata effettuata l’ultima verifica, chi l’ha eseguita, quali modifiche sono state riscontrate, quali misure ne sono scaturite e quando è prevista la prossima verifica. Altrettanto importante è la logica di processo relativa alle verifiche in ritardo, ai promemoria e alle escalation.

Molti processi di governance dell’IA non falliscono già al primo tentativo Documentazione, ma dal fatto che, dopo la messa in produzione, non vi è una chiara attribuzione delle responsabilità per la manutenzione ordinaria. Per questo motivo, una Model Card deve avere un responsabile ben definito, una data di revisione e una logica di escalation ben definita.

Cosa vogliono davvero sapere i revisori e le richieste di offerta (RFP)

Nelle richieste di offerta (RFP) viene spesso chiesto se le Model Card siano supportate, sebbene questa domanda, di per sé, non dica molto sulla reale solidità del processo di governance. È più significativo verificare se le Model Cards siano oggetti strutturati, se possano essere collegate a casi d’uso concreti, se supportino il controllo delle versioni e le revisioni, se rappresentino le approvazioni in relazione alle versioni e se le modifiche alle versioni del modello o alle fonti di dati possano innescare nuove verifiche.

Altrettanto rilevante è verificare se le informazioni sui provider vengano aggiornate, se sia possibile documentare in modo strutturato i bias, le prestazioni e i rischi, se siano previsti termini di revisione e promemoria, se i dati storici rimangano tracciabili al momento dell’audit e se le azioni in sospeso siano collegate alla Model Card. Sono proprio queste questioni a distinguere una governance operativa dell’IA da una semplice archiviazione di documenti.

La Model Card come oggetto operativo in Ailance AI Governance

In una piattaforma di governance dell’IA come Ailance, una Model Card non dovrebbe essere considerata isolatamente, ma dovrebbe essere collegata agli oggetti e ai processi rilevanti per il funzionamento effettivo. Tra questi figurano in particolare i casi d’uso dell’IA, gli strumenti di IA, i fornitori, le fonti di dati, i rischi, le misure, le approvazioni, le revisioni, le linee guida, i ruoli e le responsabilità, la documentazione, le versioni e i risultati del monitoraggio.

Da queste interconnessioni emerge un contesto di governance in cui i diversi ruoli possono accedere alle informazioni per loro rilevanti: il responsabile del modello visualizza lo stato attuale del modello, l’ufficio legale le informazioni relative ai fornitori e ai contratti, l’ufficio protezione dei dati gli aspetti relativi alla protezione dei dati, l’ufficio sicurezza informatica i requisiti tecnici e organizzativi e il reparto specialistico i limiti di utilizzo e le condizioni di approvazione vigenti. Per il management, lo stato, il rischio e le azioni in sospeso diventano chiari senza dover raccogliere informazioni da documenti diversi.

Un semplice confronto

Il confronto evidenzia che una Model Card diventa idonea ai fini della governance solo se non solo è documentata, ma viene anche aggiornata durante il funzionamento, collegata ai processi rilevanti e rivalutata in caso di modifiche.

La questione gestionale più importante

La domanda più importante riguardo alla Model Card non è se un’organizzazione ne possieda una Documentazione non chi la possiede, ma chi ha la responsabilità di mantenerla aggiornata. Tale responsabilità comprende, tra l’altro, l’aggiornamento in caso di nuove versioni del modello o fonti di dati, la rivalutazione in caso di modifiche alle metriche di performance, la verifica delle approvazioni esistenti nonché la Documentazione e l'aggravarsi dei rischi manifesti.

Se non vengono definiti ruoli e procedure chiari a tal fine, la Model Card rimane un documento che, pur contenendo informazioni, non è integrato in modo affidabile nel processo di governance dell'IA.

Conclusione

Nella governance dell'IA, le Model Cards non devono essere intese come allegati PDF statici, bensì come documentazione operativa che viene aggiornata anche dopo la messa in produzione. Affinché mantengano il loro valore probatorio, devono essere strutturate, aggiornate, versionate e soggette a revisione, oltre ad essere collegate a casi d’uso, fonti di dati, fornitori, rischi, approvazioni e monitoraggio.

Solo su questa base sarà possibile in seguito ricostruire quale versione del modello fosse in uso, quali fonti di dati siano state utilizzate, quali metriche fossero applicate, quali rischi di bias o di performance fossero noti, quale autorizzazione fosse stata concessa e quali modifiche abbiano dato luogo a una nuova revisione. È proprio questa tracciabilità a contraddistinguere una governance solida—Documentazione da una descrizione del modello inserita una sola volta.

Chi si occupa di aggiornare la Model Card nella vostra azienda quando cambiano la fonte dei dati o la versione?

Domande e risposte

Cosa deve contenere una Model Card per la governance dell'IA?

Una Model Card dovrebbe contenere il nome del modello, la versione, il fornitore, lo scopo, il riferimento al caso d’uso, le fonti dei dati, le metriche di prestazione, le informazioni relative al bias e alla spiegabilità, i rischi, i controlli, le approvazioni, il responsabile, la data di revisione e la cronologia delle modifiche.

Perché una Model Card in formato PDF non è sufficiente?

Un PDF può rappresentare un’istantanea, ma non gestisce un processo in corso. Non avvia revisioni, non mostra automaticamente la versione produttiva, non collega i rischi alle misure e rende difficile tracciare le modifiche.

Perché è necessario aggiornare una Model Card dopo la messa in produzione?

Poiché le versioni del modello, le fonti dei dati, le informazioni sui provider, le prestazioni, i rischi e il contesto di utilizzo possono cambiare. Senza un aggiornamento, la realtà del modello documentata non corrisponde più a quella del modello in produzione.

Chi dovrebbe essere responsabile della Model Card?

Di norma è necessario un “Model Owner” o una figura analoga responsabile Ruolo. A seconda dell’organizzazione, possono essere coinvolti anche il responsabile dei casi d’uso, il responsabile della protezione dei dati, l’ufficio legale, la sicurezza informatica, la scienza dei dati e Conformità essere coinvolto.

In che modo una Model Card è collegata a un caso d’uso dell’IA?

Il rischio di modello deriva dal contesto operativo. Per questo motivo, la Model Card dovrebbe essere collegata ai casi d’uso concreti in cui il modello viene impiegato.

Che ruolo ha il controllo delle versioni nelle Model Card?

Il controllo delle versioni indica quale versione del modello è stata verificata, approvata e messa in produzione. È fondamentale per poter tracciare in seguito le modifiche e le approvazioni.

Quali fonti di dati dovrebbero essere documentate?

In particolare, dovrebbero essere documentati i dati di input, i sistemi interni collegati, i dati di addestramento o di ottimizzazione, se pertinenti, Dati personali, dati riservati, provenienza dei dati e qualità dei dati.

Cosa significa “revisione” in una Model Card?

La "revisione" implica che una Model Card venga verificata regolarmente, abbia un responsabile, una data di revisione, che le modifiche siano tracciabili e che le azioni in sospeso vengano monitorate.

Cosa dovrebbe chiedere una richiesta di offerta (RFP) riguardo alle schede modello?

Una richiesta di offerta (RFP) dovrebbe chiedere se le Model Card sono oggetti strutturati, se possono essere collegate a casi d’uso, se sono supportate la gestione delle versioni e le revisioni, se le approvazioni sono legate alle versioni e se le modifiche alla versione del modello o alla fonte dei dati possono attivare nuove verifiche.

In che modo Ailance supporta le AI Governance Model Cards?

Ailance AI Governance dovrebbe trattare le Model Card come oggetti operativi strutturati e collegarle a casi d'uso, strumenti, fornitori, fonti di dati, rischi, approvazioni, revisioni, misure e prove.