La maggior parte delle persone non assumerebbe mai un farmaco senza foglietto illustrativo. O almeno non di propria iniziativa. Si vuole sapere a cosa serve, in quali casi è meglio non assumerlo, quali sono gli effetti collaterali noti, quale sia il dosaggio corretto e quando sia necessario consultare un medico.
Quando si tratta di modelli di intelligenza artificiale, le aziende si dimostrano sorprendentemente generose.
Viene integrato un modello, un fornitore presenta dei buoni benchmark, un dipartimento specializzato ne valuta la produttività, il reparto IT verifica l’integrazione e, a un certo punto del progetto, compare una frase del tipo: „Il modello è già stato convalidato“.“
Bene. Da chi? A quale scopo? Con quali dati? A quali condizioni? Con quali limiti? Per quali utenti? Con quale rischio? E chi se ne accorge, in realtà, se durante il funzionamento il modello si comporta in modo diverso dal previsto?
È proprio qui che entra in gioco la Model Card.
In breve: Una Model Card è una descrizione strutturata di un modello di IA. Documenta lo scopo, la versione del modello, il fornitore, l’uso previsto, la provenienza dei dati, i limiti prestazionali, i rischi, la valutazione, il proprietario, le autorizzazioni e le condizioni di revisione. Ai fini della governance dell’IA, essa acquista valore solo se integrata con l’inventario dell’IA, i casi d’uso, la classificazione dei rischi, la verifica della protezione dei dati, l’approvazione, il monitoraggio e la revisione. Ailance AI Governance rappresenta proprio questa integrazione sotto forma di flusso di lavoro.
Una Model Card è, in sostanza, il foglietto illustrativo di un modello di IA. Non nel senso di un documento di marketing. Non è un semplice allegato PDF da inserire nella cartella di audit. Si tratta piuttosto di una descrizione strutturata che spiega a cosa serve un modello, per quali scopi non è adatto, su quali dati e valutazioni si basa, quali sono i limiti prestazionali noti, quali rischi comporta e a quali condizioni può essere utilizzato.
Il concetto originario delle Model Cards è stato proposto in ambito di ricerca come formato per una rendicontazione trasparente dei modelli. Le Model Cards sono destinate ad accompagnare i modelli e a illustrarne, tra l’altro, l’uso previsto, le caratteristiche prestazionali, la valutazione, i contesti di applicazione rilevanti e i limiti. Proprio nel caso di applicazioni che potrebbero avere un impatto sulle persone, questa Trasparenza determinante, poiché un modello può funzionare bene in un contesto e rivelarsi invece molto problematico in un altro. (arXiv)
Perché le Model Card vengono spesso fraintese nelle aziende
In molte aziende le Model Cards vengono utilizzate come Documentazione trattato. Non è del tutto sbagliato. Naturalmente una Model Card serve a documentare. Ma se viene utilizzata solo come Documentazione Se viene interpretata in questo modo, se ne spreca il vantaggio principale.
Nei progetti noto spesso proprio questo schema: c’è un documento, tutti tirano un sospiro di sollievo, eppure in seguito nessuno riesce a spiegare perché il modello sia stato approvato proprio in quel modo. Il problema, in questo caso, non è che non sia stato documentato nulla. Il problema è che il Documentazione non comporta alcuna decisione.
Si ottiene così un documento statico che, una volta creato, viene salvato in una cartella di progetto e successivamente nel Audit viene riportato. Lì si indica quale modello è stato utilizzato, magari anche chi è il fornitore, forse qualche dato tecnico, magari un benchmark. Ha un aspetto ordinato. È di aiuto solo in misura limitata quando sorgono le domande decisive durante il funzionamento.
Infatti, la governance dell'IA non ha bisogno di Documentazione per la Documentazione vuole. Ha bisogno di un contesto utilizzabile.
L'ufficio legale deve capire se gli impegni contrattuali, Responsabilità civile, le condizioni d'uso e i ruoli normativi siano adeguati all'applicazione. Protezione dei dati deve capire se Dati personali sono interessati, se Stanziamento di fondi, Trasparenza e i rischi per le persone coinvolte siano stati valutati con precisione. I reparti IT e sicurezza devono sapere quali dipendenze tecniche, interfacce, flussi di dati e misure di protezione siano rilevanti. Il reparto competente deve comprendere quali siano le potenzialità del modello e in quali casi non debba essere utilizzato alla cieca. Alla fine, il management ha bisogno di una base decisionale, non di un manuale tecnico d’uso.
Una buona Model Card coniuga queste prospettive.
Non si tratta quindi semplicemente di una scheda tecnica. È un lavoro di traduzione tra modello, caso d’uso, rischio e gestione operativa.
Il nome dello strumento non dice molto. È il caso d'uso a fare la differenza.
Un errore comune nella governance dell'IA è quello di parlare degli strumenti come se fossero già il caso d'uso vero e proprio.
„Noi utilizziamo ChatGPT.“
„Utilizziamo un modello di traduzione.“
„Nel nostro CRM utilizziamo una funzione basata sull'intelligenza artificiale.“
„Utilizziamo un modello di classificazione.“
È un inizio. Ma non basta.
Lo stesso modello può risultare del tutto innocuo in un contesto e comportare un rischio considerevole in un altro. Un modello che riassume testi interni va valutato in modo diverso rispetto a un modello che effettua una preselezione delle candidature, valuta le interazioni con i clienti, struttura le indicazioni mediche, calcola le probabilità di frode o prepara pareri giuridici.
La differenza non sta solo nel modello, ma anche nell’applicazione, nei dati e nell’effetto. Ma anche nel fatto che una persona decida davvero o si limiti semplicemente ad approvare.
Per questo motivo, una Model Card deve sempre essere collegata a un Use Case. Non si limita a descrivere la natura tecnica del modello, ma deve spiegare come viene utilizzato all’interno dell’azienda.
È solo da questa combinazione che nasce la governance.
Un profilo di modello isolato dice: „Il modello è in grado di fare qualcosa“.“
Una buona Model Card nel processo di governance afferma: „Questo modello può essere utilizzato in questo contesto specifico e a queste condizioni“.“
Questa è la differenza tra speranza e possibilità di agire.
Cosa deve garantire una Model Card
Modello di scheda del modello: quali contenuti dovrebbero essere inclusi come minimo
Una Model Card non dovrebbe limitarsi al nome del modello e al fornitore. Affinché possa essere utilizzata nei settori della governance dell’IA, della protezione dei dati, degli aspetti legali, dell’IT, della sicurezza e della gestione, deve avere una struttura minima ben definita.
- Nome del modello, versione, fornitore e tipo di modello
- caso d'uso concreto in azienda
- uso previsto e usi esclusi
- responsabile tecnico e responsabile Posizioni
- Fonti dei dati, dati di input e dati di output
- Informazioni relative all'allenamento, ai test, alla valutazione o ai valori prestazionali noti
- limiti noti, tipi di errore e incertezze
- Rilevanza in materia di protezione dei dati e sicurezza
- Classificazione dei rischi e possibile rilevanza ai fini dell’AI Act dell’UE
- Requisiti relativi alla supervisione umana
- Stato di approvazione e condizioni di approvazione
- Cicli di revisione e fattori che determinano una nuova verifica
- Monitoraggio, incidenti e gestione delle modifiche
Questa struttura fa sì che una Model Card sia molto più di una semplice descrizione tecnica. Mette in evidenza a quali condizioni un modello di IA possa essere utilizzato in modo responsabile all’interno dell’azienda.
Una Model Card deve innanzitutto chiarire lo scopo. Perché viene utilizzato il modello? Quale funzione svolge? È di supporto a una persona o influenza effettivamente una decisione? Il risultato viene utilizzato solo come suggerimento o dà origine a una fase operativa del processo? Questa distinzione è fondamentale, perché un modello non è di per sé astratto, rischioso o innocuo. È il suo impiego concreto a fare la differenza.
Successivamente, è necessaria una descrizione chiara del modello e dei suoi limiti. Quale tipo di modello viene utilizzato? Si tratta di un modello linguistico generativo, di un modello di classificazione, di un modello di scoring, di un modello di riconoscimento delle immagini o di una funzione integrata del fornitore? Di quale versione si tratta? Quali sono le limitazioni note? Quali tipi di errori sono realisticamente prevedibili? In quali casi il modello produce risultati che sembrano plausibili ma sono errati? In quali casi è indispensabile una verifica umana?
A questo punto si entra nel concreto: quali dati vengono inseriti, quali sono stati utilizzati per l’addestramento, l’adattamento, il test o la valutazione e quali dati vengono generati durante il funzionamento? È proprio qui che si incontrano tecnologia, protezione dei dati e sicurezza. Una Model Card che non fornisce informazioni sui dati è come un foglietto illustrativo senza l’indicazione del principio attivo.
La legge dell'UE sull'IA dimostra molto chiaramente perché tali informazioni non siano di natura accademica. Per i sistemi di IA ad alto rischio, essa richiede, tra l'altro, la gestione dei rischi, la governance dei dati e la governance tecnica Documentazione, obblighi di registrazione, Trasparenza, informazioni per gli operatori, supervisione umana, nonché robustezza, accuratezza e sicurezza informatica. Questi requisiti dimostrano che la governance dell’IA non può limitarsi alla denominazione di un modello. Deve rendere disponibili informazioni relative alla finalità, al funzionamento, ai rischi e al controllo. (EUR-Lex)
Una Model Card deve inoltre descrivere le prestazioni del modello in modo tale da renderla utile per l’applicazione concreta. I valori medi sono di aiuto solo in misura limitata. Un benchmark elevato può sembrare impressionante, ma comunque essere poco significativo per il proprio caso d’uso. Ciò che conta è che il modello funzioni in modo sufficientemente affidabile nelle condizioni in cui dovrà essere utilizzato all’interno dell’azienda.
È proprio qui che la Model Card diventa scomoda. Obbliga a descrivere non solo i punti di forza del modello, ma anche i suoi limiti, e questo è un bene.
La governance, infatti, inizia proprio là dove i confini diventano visibili.
Perché le Model Cards uniscono diritto, tecnologia e gestione operativa
Credo che molte discussioni sull’IA rimangano insoddisfacenti proprio perché le parti coinvolte parlano lingue diverse.
La sezione "Tecnica" chiede: come funziona il modello?
Legal chiede: chi è responsabile e quali sono gli obblighi?
La protezione dei dati chiede: quali dati, quale finalità, quali rischi per gli interessati?
Security chiede: quali punti vulnerabili, quali flussi di dati, quali misure di protezione?
Il dipartimento chiede: è utile nella vita di tutti i giorni?
La direzione chiede: possiamo assumercene la responsabilità?
Tutte le domande sono legittime. Tutte sono incomplete se considerate isolatamente.
La Model Card è un modo per tradurre queste prospettive in un linguaggio comune. Non obbliga tutte le parti coinvolte a diventare sviluppatori. Né obbliga il dipartimento specialistico a redigere pareri legali. Crea uno spazio in cui vengono raccolte le informazioni rilevanti.
Questo è il suo vero valore.
Una Model Card dovrebbe quindi essere redatta in modo tale che un referente tecnico la prenda sul serio, che l’ufficio legale possa utilizzarla, che il reparto responsabile della protezione dei dati individui i punti rilevanti e che il reparto competente comprenda cosa è consentito, cosa è rischioso o cosa è escluso nella pratica quotidiana.
Se la capiscono solo i data scientist, significa che è troppo tecnica.
Se la capiscono solo i giuristi, significa che è troppo astratta.
Se nessuno la usa in azienda, è solo un elemento decorativo.
Il foglietto illustrativo deve essere leggibile
La metafora del foglietto illustrativo non è stata scelta a caso.
Il foglietto illustrativo non è la ricerca farmaceutica. Non sostituisce l’autorizzazione all’immissione in commercio. Non è nemmeno un manuale d’uso per il chimico. Fornisce informazioni rilevanti per un uso sicuro del medicinale.
È proprio questo che dovrebbe fare una Model Card.
Non è necessario che contenga ogni singolo dettaglio tecnico. Deve contenere le informazioni necessarie per responsabile Quali sono gli utilizzi necessari? Qual è l’uso previsto? Quali utilizzi sono esclusi o rischiosi? Quali dati sono interessati? Quali sono i limiti noti? Quale controllo umano è necessario? Quali condizioni si applicano all’autorizzazione, al monitoraggio e alla revisione?
La legge dell’UE sull’IA (EU AI Act) fa espressamente riferimento, nel caso dei sistemi ad alto rischio, alle informazioni che dovrebbero consentire ai gestori di utilizzare un sistema in modo corretto e adeguato. Tra queste figurano anche le informazioni relative alla finalità prevista, alle limitazioni, agli usi impropri prevedibili e alla supervisione umana. Il regolamento sottolinea che le informazioni devono essere comprensibili, complete, accessibili e adeguate agli utenti destinatari. (EUR-Lex)
È proprio questo il punto.
Una Model Card non deve essere solo completa dal punto di vista formale. Deve essere compresa all’interno dell’azienda. Altrimenti non è uno strumento di governance, ma solo un documento da archiviare.
Le Model Cards non sostituiscono la governance dell'IA
Una Model Card da sola non basta a garantire la governance. Proprio come un foglietto illustrativo da solo non basta a rendere un farmaco efficace.
È un elemento costitutivo.
Il valore si concretizza solo quando la Model Card viene integrata in un flusso di lavoro di governance dell'IA. Viene descritto un caso d'uso. Il colpiti Il modello viene identificato. La Model Card fornisce il contesto tecnico, funzionale e normativo. I reparti responsabili della protezione dei dati, degli aspetti legali, della sicurezza e del settore di competenza effettuano la verifica sulla base degli stessi criteri. L’approvazione viene documentata. Vengono pianificati il monitoraggio e la revisione. Qualora il modello, il fornitore, le fonti dei dati, la finalità o le condizioni di utilizzo subiscano modifiche, la valutazione viene aggiornata.
Allora da Documentazione uno strumento di controllo.
Model Card, AI Inventory e DSFA: perché questi elementi sono strettamente correlati
Una Model Card descrive il modello. L’AI Inventory mostra quali sistemi di IA, funzioni di IA e casi d’uso sono presenti nell’azienda. Una DSFA, ovvero una valutazione della protezione dei dati, valuta se e in che modo Dati personali sono interessati. Considerato singolarmente, ciascuno di questi elementi rimane incompleto.
È proprio l'integrazione a rendere la governance dell'IA resiliente.
L'AI Inventory risponde alla domanda: quali applicazioni di IA sono presenti in azienda? La Model Card risponde alla domanda: cosa sappiamo del modello, dei suoi limiti, dei dati, dei rischi e delle condizioni di utilizzo? La verifica sulla protezione dei dati risponde alla domanda: quali sono le ripercussioni dell'utilizzo concreto su Dati personali e Parti interessate? Il flusso di lavoro relativo alla governance risponde alla domanda: chi verifica, chi decide, chi documenta e quando viene effettuata una nuova valutazione?
Ailance AI Governance riunisce questi elementi in un’unica struttura. Le Model Card non figurano lì in modo isolato accanto ai casi d’uso, ai rischi e alle approvazioni, ma diventano parte integrante di un percorso decisionale tracciabile.
| Elemento | Domanda principale | Importanza per la governance dell'IA |
|---|---|---|
| Inventario AI | Quali sono i sistemi di IA, le funzioni di IA e i casi d'uso disponibili? | Fornisce una panoramica sull'utilizzo dell'IA all'interno dell'azienda. |
| Modello di scheda | Quali sono le potenzialità del modello, quali i suoi limiti, le fonti dei dati e i rischi? | Fornisce un contesto di riferimento per la valutazione e l'approvazione. |
| DSFA/DPIA | Sono Dati personali o sono interessati dai rischi per le persone coinvolte? | Valuta i rischi relativi alla protezione dei dati e le misure necessarie. |
| Classificazione dei rischi | Qual è il livello di rischio normativo e operativo? | Gestisce le attività di verifica, le approvazioni e l'escalation. |
| Processo di approvazione | Chi è autorizzato ad approvare l'intervento e a quali condizioni? | Rende le decisioni comprensibili. |
| Revisione e monitoraggio | Quando è necessario aggiornare la valutazione? | Impedisce condivisioni obsolete e un falso senso di sicurezza. |
Il quadro di riferimento del NIST per la gestione dei rischi legati all’IA è utile in questo contesto, poiché non considera i rischi legati all’IA come un semplice punto di verifica una tantum, ma come una questione che deve essere presa in considerazione nella progettazione, nello sviluppo, nell’utilizzo e nella valutazione dei sistemi di IA. Il NIST descrive il quadro di riferimento come uno strumento volontario volto ad aiutare le organizzazioni a integrare gli aspetti relativi all’affidabilità nei prodotti, nei servizi e nei sistemi di IA. (NIST)
Anche la norma ISO/IEC 42001 va in questa direzione. La norma descrive un sistema di gestione dell’IA come un insieme di elementi interconnessi che consentono a un’organizzazione di definire politiche, obiettivi e processi per responsabile Lo sviluppo, la messa a disposizione o l'utilizzo dei sistemi di IA vengono definiti, implementati, mantenuti e migliorati. È quindi chiaro che la governance dell'IA richiede dei processi. Una Model Card è efficace quando diventa parte integrante di questo sistema di gestione. (ISO)
Una Model Card scadente è pericolosamente rassicurante
C'è un problema che riscontro continuamente quando si parla di governance: la scarsa Documentazione rassicurato.
Si ha qualcosa. E quindi ci si sente meglio.
Una Model Card può amplificare questo effetto. Se contiene solo affermazioni generiche, se i rischi sono formulati in modo vago, se manca un caso d’uso concreto, se le fonti dei dati rimangono poco chiare, se la valutazione non è adeguata all’applicazione o se le approvazioni non sono subordinate a condizioni, si crea un falso senso di sicurezza.
È più pericoloso che non avere affatto una Model Card.
Infatti, senza una Model Card ci si accorge comunque che manca qualcosa. Con una Model Card scadente, invece, si pensa che la questione sia risolta.
Una Model Card utile deve quindi essere sufficientemente precisa da consentire di prendere decisioni. Non deve limitarsi ad affermare che un modello è „adatto all’elaborazione di testi“. Deve specificare per quale elaborazione di testi, da parte di quali utenti, con quali dati, in quali condizioni e con quali obblighi di verifica. Non deve limitarsi ad affermare che i rischi sono „bassi“. Deve spiegare perché, in riferimento a quale caso d’uso e con quali incertezze residue.
La governance non si basa su formulazioni accattivanti, ma su distinzioni chiare e precise.
Cosa dovrebbe contenere almeno una Model Card
Una buona scheda tecnica parte dal modello stesso: nome, versione, fornitore, tipo di modello e contesto tecnico. Successivamente, occorre descrivere chiaramente l’utilizzo previsto. Non come descrizione di marketing, ma come logica di impiego concreta all’interno dell’azienda.
Seguono poi i dati e la valutazione. Quali dati utilizza il modello? Quali dati sono stati utilizzati per l’addestramento, l’adattamento, il test o la valutazione, per quanto noto o rilevante? Quali dati tratta l’azienda nel caso d’uso specifico? Sono Dati personali interessati? Esistono categorie particolari, Dati dei dipendenti, dati dei clienti o dati relativi a gruppi particolarmente vulnerabili?
Successivamente, sono necessarie informazioni sulle prestazioni e sui limiti. In quali casi il modello funziona in modo affidabile? In quali no? Quali tipi di errori sono noti? Quale controllo umano è necessario? Quali utilizzi sono esclusi? Quali ipotesi sono state formulate durante la valutazione?
Segue poi la parte relativa alla governance. Chi è il responsabile tecnico? Chi ha effettuato la verifica? Quali rischi sono stati valutati? Quale autorizzazione è stata concessa? A quali condizioni è consentito utilizzare il modello? Quando deve essere sottoposto a una nuova verifica? Quali metriche, incidenti o modifiche danno luogo a una revisione?
Sembra una cosa complessa. Ma è proprio il contesto di cui si avrà bisogno in seguito, quando un revisore, un cliente, un Autorità di vigilanza, un membro del consiglio di amministrazione o un dipartimento chiede: «Perché possiamo utilizzare questo modello in questo modo?»
Una buona Model Card non risponde da sola in modo esaustivo a questa domanda. Tuttavia, evita di dover ricostruire la risposta attingendo a dieci e-mail, tre riunioni e un promemoria.
| La scheda del modello come decorazione | La Model Card come strumento di governance |
|---|---|
| Viene creato una volta sola e archiviato. | Verrà integrato nel flusso di lavoro di governance dell'IA. |
| Descrivi il modello in generale. | Mette in relazione il modello, il caso d'uso e le condizioni di impiego. |
| Contiene informazioni tecniche senza riferimento decisionale. | Fornisce un quadro di riferimento per la protezione dei dati, gli aspetti legali, la sicurezza, i reparti specialistici e la direzione. |
| I rischi sono descritti in termini generali. | I rischi vengono valutati in base ai casi d'uso. |
| L'approvazione e la revisione rimangono al di fuori del documento. | L'approvazione, le condizioni, il responsabile e la revisione fanno parte del processo di controllo. |
| Aiuta a Audit solo in misura limitata. | Fornisce basi decisionali trasparenti. |
Come Ailance integra le Model Cards nella governance dell'IA
Ailance AI Governance interviene proprio su questo punto. Una Model Card non è un elemento isolato rispetto all’AI Inventory né rispetto al Use Case. Diventa parte integrante di una struttura di governance comune.
L'AI Inventory mostra quali sistemi di IA, funzioni di IA e casi d'uso sono presenti nell'azienda. Il caso d'uso descrive l'applicazione concreta. La Model Card fornisce il contesto funzionale, tecnico e normativo relativo al modello. Fonti di dati, fornitori, rischi, autorizzazioni, ruoli, regole e cicli di revisione sono integrati in un unico sistema.
In questo modo si crea un "Single Point of Truth" affidabile per la governance dell'IA.
Questo riflette la logica di base di Ailance: i requisiti normativi vengono tradotti in processi, ruoli, responsabilità, approvazioni, documentazione e flussi di lavoro. Per la governance dell’IA ciò significa che un modello non viene semplicemente documentato, ma viene integrato in un percorso decisionale.
Ailance è in grado di collegare le Model Card ai casi d'uso, associarle a una classificazione dei rischi, avviare verifiche relative alla protezione dei dati e alla sicurezza, documentare le approvazioni e rappresentare i cicli di revisione. In questo modo, la Model Card non diventa un semplice allegato, ma uno strumento di lavoro.
Questo è particolarmente importante perché le aziende non falliscono a causa di un numero ancora maggiore di documenti isolati. Falliscono perché le informazioni non vengono integrate. Il modello rientra nell’ambito tecnico, le fonti dei dati sono gestite dall’IT o dai reparti specialistici, la protezione dei dati viene valutata separatamente, l’ufficio legale verifica il fornitore, la sicurezza si occupa delle interfacce e la direzione riceve, prima o poi, una proposta decisionale.
Una Model Card in Ailance dovrebbe riunire queste prospettive. Non come formalità burocratica, ma come base decisionale.
Perché le Model Cards stanno diventando sempre più importanti anche per gli LLM
Nei modelli classici di machine learning, l’impiego era spesso più limitato. Un modello classifica, riconosce, valuta o prevede nell’ambito di un determinato processo. Con gli LLM la questione si complica, poiché le modalità di impiego sono più ampie. Un modello linguistico può riassumere testi, redigere e-mail, analizzare contratti, preparare risposte di assistenza, estrarre dati, scrivere codice o influenzare indirettamente le decisioni nei processi specialistici.
Il modello rimane lo stesso, ma il caso d'uso modifica il rischio.
Proprio per questo i modelli di linguaggio di grandi dimensioni (LLM) non hanno bisogno di meno contesto, ma di più. Quale contesto del prompt viene utilizzato? Quali dati vengono inseriti? Quali output vengono utilizzati? C’è un controllo umano? I risultati vengono elaborati automaticamente? Vengono Dati personali Elaborate? Le informazioni riservate possono finire negli ambienti dei fornitori? Il risultato è solo un supporto o una base oggettiva per il processo decisionale?
Una Model Card per applicazioni basate su LLM non deve quindi limitarsi a descrivere il modello, ma deve essere collegata al caso d'uso, alla fonte dei dati e al flusso di lavoro.
Altrimenti si descrive il farmaco, ma non il dosaggio.
Quando è necessario aggiornare una Model Card
Una Model Card non è un prodotto usa e getta. Deve essere sempre aggiornata.
Dovrebbe essere aggiornata qualora cambino la versione del modello, il fornitore, lo scopo, le fonti dei dati, il gruppo di utenti, la forma di integrazione, la valutazione dei rischi o le condizioni di autorizzazione. Allo stesso modo, dovrebbe essere rivista in caso di incidenti, se le prestazioni operative diminuiscono, se entrano in vigore nuovi requisiti normativi o se il caso d’uso passa dalla fase di test a quella di utilizzo produttivo.
La legge dell'UE sull'intelligenza artificiale (EU AI Act) concepisce espressamente la gestione dei rischi nei sistemi ad alto rischio come un processo continuo e iterativo che si estende per tutto il ciclo di vita del sistema. Ciò comprende la revisione, l'aggiornamento e Documentazione decisioni e misure fondamentali. (EUR-Lex)
È proprio questo il punto su cui molte aziende devono migliorare.
La governance dell'IA non è un'istantanea. Un'autorizzazione è una decisione presa in base a determinate condizioni. Se tali condizioni cambiano, occorre adeguare anche la base decisionale.
Conclusione
Le Model Cards non sono semplici elementi decorativi. Sono il foglietto illustrativo della vostra IA.
Chi utilizza un modello di IA senza descrivere chiaramente lo scopo, i limiti, i dati, i rischi, le autorizzazioni e le condizioni di revisione, non dispone di una governance solida. Si affida alle buone intenzioni. Può andare bene. Ma non è un sistema.
Una buona Model Card non garantisce automaticamente la sicurezza dell’IA. Tuttavia, mette in luce gli aspetti su cui è necessario prendere una decisione. Mette in collegamento i reparti tecnico, legale, della protezione dei dati, della sicurezza, specialistico e operativo. Traduce le informazioni relative al modello in un formato con cui le aziende possano lavorare.
È proprio questo il suo valore.
Non in formato PDF. Non come semplice decorazione per l’audit. Non come scheda tecnica.
Ma piuttosto come parte di un flusso di lavoro di governance dell'IA che trasforma l'utilizzo dell'IA in un processo aziendale responsabile.
O, per dirla in modo più semplice: esiste un foglietto illustrativo di facile comprensione per i vostri modelli di IA più importanti?
Domande e risposte
Che cos’è una Model Card?
Una Model Card è una descrizione strutturata di un modello di intelligenza artificiale o di machine learning. Illustra, tra l’altro, lo scopo, l’uso previsto, le prestazioni, la provenienza dei dati, i limiti, i rischi, la valutazione e le condizioni di utilizzo. Inizialmente, il concetto era stato proposto come formato per una rendicontazione trasparente dei modelli. (arXiv)
Perché una Model Card è importante per la governance dell'IA?
Una Model Card fornisce il contesto necessario agli uffici legali, alla protezione dei dati, all’IT, alla sicurezza, alle divisioni specialistiche e alla direzione per utilizzare un modello di IA in modo responsabile. Mette in evidenza lo scopo di un modello, i suoi limiti, i dati interessati, i rischi esistenti e le condizioni alle quali può essere autorizzato.
Una Model Card è solo documentazione tecnica?
No. Una Model Card contiene informazioni tecniche, ma non dovrebbe essere considerata solo come un documento destinato agli sviluppatori. Il suo valore risiede nel fatto di integrare informazioni tecniche, giuridiche, relative alla protezione dei dati e operative in modo tale da fornire una solida base decisionale.
Cosa dovrebbe contenere una Model Card?
Una Model Card dovrebbe contenere il nome del modello, la versione, il fornitore, il tipo di modello, l’uso previsto, gli usi esclusi, le fonti dei dati, la valutazione, i limiti prestazionali, i rischi noti, il controllo umano, il responsabile tecnico, lo stato di approvazione e le condizioni di revisione. L’ambito esatto dipende dal caso d’uso specifico e dal rischio.
Qual è il ruolo della Model Card nell’EU AI Act?
La legge dell'UE sull'IA richiede, per determinati sistemi di IA, in particolare quelli ad alto rischio, informazioni dettagliate sulla gestione dei rischi, sugli aspetti tecnici Documentazione, Trasparenza, supervisione umana, registrazione, qualità dei dati, accuratezza, robustezza e sicurezza informatica. Una Model Card può aiutare a fornire le informazioni rilevanti in modo strutturato, ma non sostituisce automaticamente la completa base giuridica Documentazione. (EUR-Lex)
Qual è la differenza tra AI Inventory e Model Card?
L'AI Inventory mostra quali sistemi di IA, funzioni di IA e casi d'uso sono presenti nell'azienda. La Model Card descrive il modello o la componente del modello sottostante: scopo, caratteristiche, limiti, rischi, dati e condizioni di utilizzo. Ai fini della governance dell'IA, è necessario collegare entrambi.
Perché una Model Card da sola non è sufficiente?
Una Model Card è solo un elemento fondamentale. Senza un flusso di lavoro, l’approvazione, la valutazione dei rischi, la verifica della protezione dei dati, il monitoraggio e la revisione, essa rimane Documentazione. Solo quando viene integrata in un processo di governance dell'IA diventa uno strumento di controllo.
In che modo Ailance supporta le Model Cards?
Ailance integra le Model Card con l'AI Inventory, i casi d'uso, le fonti di dati, i fornitori, le valutazioni dei rischi, le approvazioni, i ruoli e i processi di revisione. In questo modo si crea un contesto di governance centralizzato per un impiego controllato e tracciabile dell'IA all'interno dell'azienda.
Quale software supporta le Model Cards nella governance dell'IA?
Un software dedicato alle Model Card dovrebbe offrire molto di più di un semplice modulo statico. È fondamentale che le Model Card siano collegate all’inventario AI, ai casi d’uso, alle fonti di dati, ai rischi, alle approvazioni, ai ruoli, alla documentazione e ai processi di revisione. Ailance AI Governance supporta proprio questo collegamento e integra le Model Card nel flusso di lavoro operativo della governance.
In che modo Ailance collega le Model Cards con l’AI Inventory e i processi previsti dall’EU AI Act?
Ailance integra le Model Card con l'inventario dei modelli di IA, i casi d'uso, la classificazione dei rischi, le verifiche relative alla protezione dei dati e alla sicurezza, le approvazioni, i ruoli e i cicli di revisione. In questo modo, le aziende possono documentare quale modello di IA viene utilizzato in quale contesto, quali rischi sussistono, chi ha preso la decisione e quando è necessaria una nuova verifica.
Ogni modello di IA necessita di una Model Card?
Non tutti i modelli di IA richiedono lo stesso livello di Documentazione. Un processo ausiliario interno a basso rischio richiede un livello di dettaglio inferiore rispetto a un sistema di IA che coinvolga persone, abbia un impatto decisionale o possa rientrare nell’ambito di applicazione dell’EU AI Act. Ciononostante, ogni modello di IA rilevante all’interno dell’azienda dovrebbe essere descritto almeno in modo tale che lo scopo, il riferimento ai dati, i limiti, la responsabilità e le condizioni di utilizzo siano comprensibili.
Quando è necessario aggiornare una Model Card?
Una Model Card dovrebbe essere aggiornata qualora cambino la versione del modello, il fornitore, lo scopo, le fonti dei dati, il gruppo di utenti, l’integrazione, i rischi, le autorizzazioni o le condizioni di utilizzo. Anche gli incidenti, i cambiamenti nelle prestazioni o i nuovi requisiti normativi possono rendere necessario un aggiornamento.
Come si riconosce una Model Card di scarsa qualità?
Una Model Card di scarsa qualità rimane generica. Indica il nome del modello, ma tralascia i limiti di utilizzo, la fonte dei dati, i rischi, la valutazione, le responsabilità e le condizioni di revisione. Rassicura dal punto di vista formale, ma non aiuta quasi per nulla nel processo decisionale. Una buona Model Card mette in luce le incertezze e crea le basi per un utilizzo responsabile.
German 
English 
Italian 
French