Model card IA: dal template Hugging Face all’AI Act

Una model card IA è un documento breve e strutturato che accompagna un modello di intelligenza artificiale addestrato: dice a che cosa serve, come è stato addestrato e verificato, dove sbaglia. Alcuni ricercatori di Google l’hanno proposta tra il 2018 e il 2019; Hugging Face l’ha trasformata nel README.md di ogni repository di modelli. Dal 2 agosto 2025 l’AI Act chiede ai fornitori di modelli una documentazione che somiglia a una scheda, ma è più lunga e giuridicamente esigibile; dal 2 dicembre 2027 i fornitori di sistemi ad alto rischio dovranno tenere un fascicolo tecnico di cui la scheda è soltanto il primo capitolo. Questa guida legge la model card come farebbe un auditor o un’autorità di vigilanza del mercato: che cosa contiene, che cosa le manca, quale norma può pretenderla, come trasformarla in una prova.

In sintesi

• La model card è un formato di documentazione volontario in nove sezioni canoniche (Mitchell et al., 2019), non un documento legale.
• Il template Hugging Face è lo standard di fatto, ma copre circa metà dei campi dell’Allegato XI e del Model Documentation Form.
• Dal 2 agosto 2025 i fornitori GPAI tengono la documentazione del modello (Allegato XI), la condividono a valle (Allegato XII) e pubblicano una sintesi dei contenuti di addestramento; il fascicolo tecnico (Allegato IV) segue dal 2 dicembre 2027.
• La trasparenza cala: media 41 su 100 nel Foundation Model Transparency Index di dicembre 2025, 17 punti sotto il 2024; su Hugging Face le sezioni meno compilate sono impatto ambientale, limiti, valutazione.
• Una scheda diventa prova se versionata, firmata da tre ruoli, scritta con i nomi di campo del regolatore e collegata al fascicolo del sistema.

Che cos’è una model card

Il termine nasce con l’articolo «Model Cards for Model Reporting», presentato alla conferenza FAT\* di Atlanta nel gennaio 2019 e depositato su arXiv nell’ottobre 2018 (arXiv 1810.03993); tra gli autori figurano Margaret Mitchell e Timnit Gebru. La definizione, in sostanza: documenti brevi che accompagnano i modelli di apprendimento automatico addestrati e ne presentano una valutazione su benchmark in condizioni diverse, per esempio tra gruppi culturali, demografici o fenotipici. L’articolo porta due esempi, un classificatore di volti sorridenti addestrato su CelebA e il modello di tossicità dell’API Perspective, e si rivolge a sviluppatori, decisori pubblici e persone interessate (sull’oggetto in sé: che cos’è un modello di IA). Hugging Face ha reso il formato operativo: la model card è il file README.md del repository del modello, un testo Markdown preceduto da un blocco YAML con license, language, datasets, base_model, pipeline_tag, library_name, i risultati di valutazione strutturati e le emissioni di CO2 (documentazione Hugging Face). Il Model Card Guidebook (Ozoani, Gerchick, Mitchell, 2022) precisa che compilare bene una scheda richiede tre ruoli: lo sviluppatore, il «sociotecnico» (giurista, esperto di etica, difensore dei diritti) e chi organizza il progetto. Una scheda compilata da una sola persona in un pomeriggio si riconosce quasi sempre dalla sezione sui limiti.

Model card, system card, data card: tre documenti, tre oggetti

La system card descrive il prodotto messo in servizio: prompt di sistema, guardrail, strumenti collegati, valutazioni di sicurezza; OpenAI l’ha resa popolare con la GPT-4 System Card del marzo 2023 e Anthropic la usa per i modelli Claude. Un dettaglio chiarisce la logica: nell’agosto 2025 OpenAI ha pubblicato per i modelli open-weight gpt-oss una model card, non una system card, perché ciò che viene rilasciato sono i pesi e non un servizio. La data card, o datasheet, descrive il dataset («Datasheets for Datasets», Gebru e colleghi, 2018). La regola è una sola: un artefatto per oggetto, e la model card descrive i pesi.

Le nove sezioni di una model card e la domanda a cui ciascuna risponde

L’articolo del 2019 propone nove sezioni. La tabella le elenca con la domanda a cui ciascuna dovrebbe rispondere e con la debolezza più frequente in sede di revisione. <table header-row=”true”> <tr> <td>Sezione</td> <td>Domanda a cui risponde</td> <td>Debolezza tipica</td> </tr> <tr> <td>Model Details</td> <td>Chi l’ha costruito, versione, data, tipo, licenza, contatto</td> <td>Versione assente, contatto generico</td> </tr> <tr> <td>Intended Use</td> <td>Usi primari, utenti primari, usi fuori ambito</td> <td>Scritta come marketing, usi esclusi mai elencati</td> </tr> <tr> <td>Factors</td> <td>Quali gruppi, strumenti o ambienti modificano le prestazioni</td> <td>Fattori dichiarati ma mai disaggregati</td> </tr> <tr> <td>Metrics</td> <td>Quali misure, quali soglie di decisione, come si riporta la variabilità</td> <td>Metriche senza soglie né intervalli</td> </tr> <tr> <td>Evaluation Data</td> <td>Quali dataset, perché quelli, come pre-elaborati</td> <td>Identici ai dati di addestramento</td> </tr> <tr> <td>Training Data</td> <td>Da che cosa ha imparato il modello, o perché non si può dire</td> <td>«Proprietari», senza categorie di provenienza</td> </tr> <tr> <td>Quantitative Analyses</td> <td>Risultati unitari e intersezionali</td> <td>Soltanto la media aggregata</td> </tr> <tr> <td>Ethical Considerations</td> <td>Dati sensibili, rischi per la vita umana, mitigazioni</td> <td>Un disclaimer al posto di un’analisi</td> </tr> <tr> <td>Caveats and Recommendations</td> <td>Che cosa la valutazione non ha coperto</td> <td>Sezione vuota o di circostanza</td> </tr> </table> Il template annotato di Hugging Face riorganizza le nove voci in una struttura più lunga: Model Details; Uses (diretto, a valle, fuori ambito); Bias, Risks and Limitations con Recommendations; Training Details; Evaluation (dati di test, fattori, metriche, risultati); Environmental Impact; Technical Specifications; Citation; Glossary; Authors; Contact; How to Get Started. Il Guidebook fissa inoltre tre definizioni utili in qualunque revisione: un bias è uno scostamento di prestazione a danno di alcune sottopopolazioni; un rischio è una questione socialmente rilevante che il modello potrebbe causare; un limite è una modalità di guasto probabile, alla quale le raccomandazioni dovrebbero rispondere punto per punto.

Che cosa una model card non è: volontaria, autodichiarata, disomogenea

Nessuna norma impone il formato. Nessuno verifica ciò che vi è scritto. Chi redige la scheda sceglie che cosa misurare, su quali dati e con quali soglie, e sceglie anche che cosa tacere. La prima misura del problema è il Foundation Model Transparency Index 2025 dello Stanford CRFM, terza edizione, dicembre 2025: tredici aziende valutate su cento indicatori, punteggio medio 41 su 100, diciassette punti in meno rispetto al 2024. IBM raggiunge 95; xAI e Midjourney si fermano a 14. La trasparenza diminuisce proprio mentre la regolazione la rende obbligatoria. La seconda riguarda la base. Liang e colleghi hanno analizzato 32.111 model card pubblicate su Hugging Face (febbraio 2024): la sezione sull’addestramento è la più compilata con costanza; impatto ambientale, limiti e valutazione sono le meno compilate. Lo stesso studio ha aggiunto schede dettagliate a 42 modelli popolari e ha osservato una correlazione moderata con l’aumento dei download settimanali: documentare paga, ma non abbastanza da indurre la maggioranza a farlo. Per un team di governance la conseguenza è netta. Una scheda ricevuta da un fornitore è un’affermazione, non un accertamento: i punteggi che riporta vanno letti con i criteri che applichiamo a qualunque benchmark di IA presentato come prova. Una scheda pubblicata dalla propria organizzazione è invece una dichiarazione di cui si risponde davanti a un cliente, a un auditor o a un’autorità. In entrambi i casi la scheda fotografa il modello a una data precisa: dopo sei mesi di deriva del modello in produzione la fotografia resta vera e il soggetto no.

Dove la model card incontra l’AI Act

Il regolamento (UE) 2024/1689 non usa mai l’espressione model card, ma chiede in due punti una documentazione che ne ricalca la struttura e la supera per estensione e forza giuridica.

Modelli di IA per finalità generali: articolo 53, Allegato XI e il Model Documentation Form

L’articolo 53, paragrafo 1, si applica dal 2 agosto 2025 e impone ai fornitori di modelli di IA per finalità generali quattro obblighi: (a) una documentazione tecnica aggiornata con almeno gli elementi dell’Allegato XI, a disposizione dell’Ufficio per l’IA e delle autorità nazionali su richiesta; (b) una documentazione per i fornitori a valle con almeno gli elementi dell’Allegato XII, perché comprendano capacità e limiti del modello; (c) una politica sul diritto d’autore; (d) una sintesi pubblica dei contenuti di addestramento, sul modello pubblicato dall’Ufficio per l’IA il 24 luglio 2025. Il paragrafo 2 esonera dagli obblighi (a) e (b) i modelli liberi e open source con parametri pubblici, salvo rischio sistemico (quadro completo nell’articolo sull’IA per finalità generali). La sezione 1 dell’Allegato XI chiede in parte ciò che una buona scheda contiene già (compiti e integrazione, usi accettabili, rilascio e distribuzione, architettura e parametri, modalità, licenza), poi metodologia di progettazione e addestramento con le motivazioni, dati (tipo, provenienza, cura, numero di punti, bias), calcolo in operazioni in virgola mobile, tempo di addestramento, energia. La sezione 2, per il rischio sistemico, aggiunge valutazioni, test avversariali e red teaming, architettura del sistema. Il Codice di buone pratiche GPAI, testo finale del 10 luglio 2025 avallato dalla Commissione e dal Consiglio per l’IA il 1° agosto 2025, traduce l’allegato nel Model Documentation Form (pagina della Commissione). Misura 1.1: documentare ogni campo all’immissione sul mercato, aggiornarlo, conservare le versioni precedenti dieci anni. Misura 1.2: punto di contatto pubblico, campi applicabili ai fornitori a valle entro 14 giorni, all’Ufficio per l’IA quanto richiesto. Misura 1.3: controllo di qualità, integrità, protezione contro le alterazioni. Il Form è, in pratica, una model card con una terza colonna: per ogni campo, tre caselle dicono se l’informazione va all’Ufficio per l’IA, alle autorità nazionali competenti o, in via proattiva, ai fornitori a valle. Chiede denominazione legale, data di immissione sul mercato dell’Unione, hash o endpoint di autenticità, dipendenze (da che cosa il modello è stato affinato), numero di parametri (due cifre significative per l’Ufficio, intervalli da 1-500 milioni a oltre 1.000 miliardi per gli altri), dimensioni massime di input e output, distribuzione, licenza e usi accettabili, usi previsti in circa 200 parole, tipi di sistema di IA ammessi ed esclusi, processo di addestramento in circa 400 parole con le motivazioni, provenienza dei dati per categoria (dal web crawling ai dati sintetici), misure contro fonti non idonee (inclusi CSAM e NCII) e bias, tempo di addestramento in ore solari e giorni-hardware, FLOP, megawattora, calcolo per l’inferenza. Quanto va alle autorità resta coperto dal segreto commerciale dell’articolo 78.

Sistemi di IA ad alto rischio: Allegato IV, articolo 13 e la scheda per il deployer

Per i sistemi ad alto rischio il documento centrale è la documentazione tecnica dell’articolo 11, redatta prima dell’immissione sul mercato secondo i nove punti dell’Allegato IV: descrizione generale (finalità prevista, fornitore, versioni, interazioni, hardware, istruzioni per l’uso); sviluppo (metodi, modelli pre-addestrati di terzi, specifiche, architettura, dati con provenienza, etichettatura e pulizia, sorveglianza umana, modifiche predeterminate, convalida e prova con metriche di accuratezza, solidità e impatto discriminatorio, cibersicurezza); monitoraggio e controllo (prestazioni per persone o gruppi specifici, esiti indesiderati prevedibili, dati di input); adeguatezza delle metriche; gestione dei rischi (articolo 9); modifiche nel ciclo di vita; norme armonizzate; dichiarazione di conformità UE; piano di monitoraggio successivo all’immissione sul mercato (articolo 72). L’articolo 18 ne impone la conservazione per dieci anni. Se un caso d’uso rientri nell’alto rischio lo chiarisce la guida alla classificazione dei sistemi ad alto rischio. L’articolo 13, paragrafo 3, descrive le istruzioni per l’uso, cioè la scheda destinata al deployer: identità del fornitore, finalità prevista, accuratezza con le relative metriche, solidità, cibersicurezza, rischi di uso improprio prevedibili, prestazioni per gruppi specifici, specifiche dei dati di input, modifiche predeterminate, sorveglianza umana, risorse di calcolo, durata attesa e manutenzione, registrazione. Agli occhi di un deployer è il documento che più somiglia a una model card. Le date seguono il Digital Omnibus sull’IA, regolamento (UE) 2026/1744 (Gazzetta ufficiale del 24 luglio 2026, in vigore dal 27 luglio 2026): sistemi ad alto rischio autonomi dell’Allegato III dal 2 dicembre 2027, sistemi integrati in prodotti dell’Allegato I dal 2 agosto 2028. PMI e, ora, piccole imprese a media capitalizzazione possono usare il modulo semplificato della Commissione: le stesse nove aree, meno testo. Su quel fascicolo si appoggia la valutazione della conformità. I deployer (articolo 26) usano il sistema secondo le istruzioni e, per i casi d’uso dell’Allegato III nel settore pubblico e in alcuni ambiti privati, conducono la valutazione d’impatto sui diritti fondamentali dell’articolo 27, che parte da quella scheda (guida completa: documentazione del sistema di IA).

Verifica dei divari: il template Hugging Face a confronto con i campi previsti dalla legge

La tabella è una nostra lettura, non una mappatura ufficiale: ciascuna sezione del template Hugging Face di fronte a ciò che chiedono l’Allegato IV, l’Allegato XI o il Model Documentation Form, e dove la scheda si ferma. <table header-row=”true”> <tr> <td>Sezione del template</td> <td>Che cosa chiedono Allegato IV, Allegato XI o il Form</td> <td>Divario</td> </tr> <tr> <td>Model Details</td> <td>Denominazione legale, data di immissione sul mercato dell’Unione, hash di autenticità, dipendenze</td> <td>Mancante</td> </tr> <tr> <td>Uses</td> <td>Link alla politica di uso accettabile, tipi di sistema di IA ammessi ed esclusi, in 200-300 parole</td> <td>Parzialmente mancante</td> </tr> <tr> <td>Bias, Risks and Limitations</td> <td>Misure per individuare fonti non idonee e bias identificabili</td> <td>Mancante: il template registra gli esiti, il Form chiede i metodi</td> </tr> <tr> <td>Training Details</td> <td>Motivazioni delle scelte, categorie di provenienza, numero di punti dati, cura, misure contro CSAM e NCII</td> <td>Mancante</td> </tr> <tr> <td>Evaluation</td> <td>Allegato XI sezione 2 e Allegato IV punto 2(g): strategie di valutazione, test avversariali, metriche di impatto discriminatorio, soglie</td> <td>Parzialmente presente</td> </tr> <tr> <td>Environmental Impact</td> <td>Il campo CO2 è vicino; il Form vuole megawattora con due cifre significative e metodologia</td> <td>Parzialmente presente</td> </tr> <tr> <td>Technical Specifications</td> <td>Parametri, dimensioni massime di input e output, FLOP, giorni-hardware</td> <td>Parzialmente presente</td> </tr> <tr> <td>Nessuna sezione</td> <td>Allegato IV punti da 2(e) a 2(h) e da 3 a 9: sorveglianza umana, modifiche predeterminate, cibersicurezza, gestione dei rischi, ciclo di vita, norme, dichiarazione di conformità, monitoraggio successivo all’immissione sul mercato</td> <td>Mancante</td> </tr> <tr> <td>Nessuna sezione</td> <td>Articolo 13, paragrafo 3, lettere (e) e (f): durata attesa, manutenzione, registrazione</td> <td>Mancante</td> </tr> </table> Il confronto porta a una conclusione forse controintuitiva: ciò che il template contiene e la legge non chiede (citazione, glossario, istruzioni per iniziare, autori) è ciò che rende la scheda leggibile da un ingegnere che la apre per la prima volta. Conviene tenerlo e aggiungere sotto i campi legali, invece di sostituire la scheda con un modulo che nessuno aprirà volentieri.

Oltre l’UE: dove altro ci si aspetta una model card

L’Unione non è la sola ad aspettarsi una scheda.

• Stati Uniti, FDA. La bozza di guida del 7 gennaio 2025 sulle funzioni software dei dispositivi medici abilitati dall’IA propone nell’Appendice E un esempio di model card per utenti e professionisti sanitari e nell’Appendice F una sintesi 510(k) con scheda compilata. La FDA non richiede una model card né un formato specifico, ma osserva che la scheda accresce la fiducia degli utenti. Resta, per ora, una bozza.
• California, SB 53. Il Transparency in Frontier Artificial Intelligence Act, firmato il 29 settembre 2025 e in vigore dal 1° gennaio 2026, impone a chi sviluppa modelli di frontiera addestrati con più di 10\^26 operazioni un rapporto di trasparenza al rilascio: data, lingue e modalità, usi previsti, restrizioni, contatto. I grandi sviluppatori, oltre 500 milioni di dollari di ricavi, aggiungono le sintesi delle valutazioni dei rischi catastrofici; sanzioni fino a 1 milione di dollari per violazione, applicate dall’Attorney General.
• New York, RAISE Act. Firmato il 19 dicembre 2025, modificato il 27 marzo 2026, in vigore dal 1° gennaio 2027: protocolli di sicurezza pubblicati, incidenti segnalati entro 72 ore, sanzioni fino a 1 milione di dollari alla prima violazione e 3 milioni alle successive. La segnalazione degli incidenti di IA si intreccia qui con la documentazione del modello.
• NIST AI RMF. Il Playbook elenca model card e system card tra le pratiche di documentazione suggerite, su base volontaria (NIST AI RMF).
• Europa, fuori dall’AI Act. La checklist di audit algoritmico commissionata dall’EDPB (Gemma Galdon Clavell, gennaio 2023) apre con una sezione intitolata proprio «Model Card», incrociata con gli articoli del GDPR; l’AI Impact Assessment v2.0 del Ministero olandese delle Infrastrutture (dicembre 2024) chiede se esista una model card o una documentazione equivalente; un audit dell’IA pone la stessa domanda.
• Norme tecniche. ISO/IEC 42001 prevede tra le aree di controllo dell’Annex A la documentazione tecnica del sistema di IA, la documentazione e le informazioni per gli utenti, la provenienza dei dati, la verifica e la convalida; l’auditor chiede dove risieda la documentazione e come sia tenuta aggiornata (norma ISO 42001).
• Catena di fornitura software. CycloneDX 1.5, giugno 2023, ha introdotto la distinta base per il machine learning con un componente di tipo modello i cui campi ricalcano una model card: la scheda può viaggiare dentro un SBOM.

In Italia la legge 23 settembre 2025, n. 132, ha designato AgID e ACN, l’Agenzia per la Cybersicurezza Nazionale, come autorità nazionali ai fini dell’AI Act: a loro un fornitore o un deployer italiano potrà vedersi chiedere la documentazione dell’Allegato XI o dell’Allegato IV. Il Garante privacy, con i procedimenti nei confronti di OpenAI del 2024 e del 2025, ha mostrato quanto conti la provenienza dei dati di addestramento: in Italia i campi sulla provenienza per categoria e sulla base giuridica sono la parte della scheda letta per prima.

Come scrivere una model card che superi un audit: sei passaggi

Sei passaggi trasformano la scheda da pagina di presentazione a documento probatorio; ciascuno produce un record esibibile.

1. Una scheda per versione, immutabile dopo il rilascio. Ogni versione del modello riceve la propria scheda, congelata al rilascio, con un registro delle modifiche che indichi che cosa è cambiato nei dati, nell’addestramento, nella valutazione o nell’uso previsto (Allegato IV, punto 6; Misura 1.1, dieci anni di conservazione). Record prodotto: la cronologia delle versioni.
2. I campi legali prima, nel vocabolario del regolatore. Denominazione legale, date di rilascio e di immissione sul mercato dell’Unione, dipendenze, licenza, politica di uso accettabile, usi previsti ed esclusi, tipi di sistema di IA ammessi, scritti con i nomi del Form per evitare la traduzione affannosa al momento della richiesta. Record prodotto: la sezione «informazioni generali» compilata.
3. Valutazione disaggregata, riportata come vuole l’articolo 13. Accuratezza con metriche e soglie, solidità, cibersicurezza, prestazioni per gruppi specifici, con i criteri che applichiamo ai benchmark e i requisiti di sicurezza dell’IA. Record prodotto: il rapporto di valutazione per sottogruppo.
4. Dati per categoria di provenienza. Web crawling, dataset privati di terzi, dati degli utenti, dataset pubblici, dati sintetici, con il numero di punti dati e le misure adottate contro fonti non idonee e bias. Record prodotto: il registro di provenienza dei dati.
5. Tre firme, un responsabile, una cadenza. Sviluppatore, sociotecnico e organizzatore del progetto firmano la scheda; un responsabile nominativo ne risponde; la revisione avviene a ogni rilascio e comunque almeno una volta l’anno. Record prodotto: il verbale di approvazione.
6. Collegamento al fascicolo del sistema. La scheda rimanda alla voce dell’inventario dei sistemi di IA, al registro dei rischi, alle istruzioni per l’uso, al registro degli incidenti e al contratto con il fornitore. Ai fornitori vanno chiesti i campi dell’Allegato XII; nel contratto vanno scritti l’obbligo dei 14 giorni e un aggiornamento trimestrale, come propone anche una guida pratica per avvocati (le clausole sono nel nostro articolo sulla due diligence dei fornitori di IA). Record prodotto: la mappa dei collegamenti.

Sei passaggi, sei record: insieme formano il fascicolo che un regolatore può chiedere oggi ai sensi dell’articolo 53 e, dal dicembre 2027, dell’Allegato IV.

Le model card nel fascicolo del sistema di IA

Una scheda parla di un modello; un’autorità chiede conto di un sistema. Fra i due sta il registro. Ogni voce del registro dei sistemi di IA elenca i modelli usati come componenti; ogni componente porta con sé i campi della propria model card e il numero di versione; una modifica alla scheda, che si tratti di un nuovo addestramento, di una metrica peggiorata o di un uso escluso aggiunto, riapre la valutazione dei rischi e le istruzioni per l’uso. In AI Sigil la scheda vive accanto ai controlli del framework applicato: il registro dei sistemi di IA e l’inventario tengono insieme modello, sistema, rischi e gestione del rischio di modello, così che alla domanda «mostratemi la documentazione di questo modello» si risponda con un report e non con una ricerca.

Domande frequenti

Che cos’è una model card, in parole semplici? È la carta d’identità di un modello di IA: poche pagine che dicono chi lo ha costruito, a che cosa serve, con quali dati è stato addestrato, come è stato misurato e dove funziona peggio. Il formato nasce da un articolo del 2019 e si è diffuso perché Hugging Face lo ha reso il README.md di ogni modello. Non è un certificato: riporta ciò che l’autore ha scelto di dichiarare. Una model card è obbligatoria? Nessuna norma impone il formato in quanto tale. Sono però obbligatori i contenuti che una buona scheda anticipa: dal 2 agosto 2025 la documentazione dell’articolo 53 e dell’Allegato XI per i fornitori GPAI, dal 2 dicembre 2027 la documentazione tecnica dell’Allegato IV per i sistemi ad alto rischio, dal 1° gennaio 2026 i rapporti di trasparenza della legge californiana SB 53. La scheda è il modo più economico di arrivarci preparati. Qual è la differenza tra model card e system card? La model card descrive i pesi: architettura, dati di addestramento, metriche, limiti del modello in sé. La system card descrive il prodotto in cui il modello è inserito: prompt di sistema, guardrail, strumenti collegati, valutazioni di sicurezza. OpenAI ha reso popolare la seconda con GPT-4 nel 2023 e ha pubblicato la prima per i modelli open-weight gpt-oss nel 2025, perché rilasciava il modello e non un servizio. Una model card di Hugging Face soddisfa l’AI Act? No. A nostra lettura il template copre circa metà dei campi dell’Allegato XI e del Model Documentation Form: mancano denominazione legale, data di immissione sul mercato dell’Unione, hash di autenticità, categorie di provenienza dei dati, misure contro le fonti non idonee, energia in megawattora. Nessuno dei punti di governance dell’Allegato IV (sorveglianza umana, gestione dei rischi, dichiarazione di conformità, monitoraggio) è previsto. È il punto di partenza, non quello di arrivo. Chi dovrebbe scrivere la model card? Tre ruoli, secondo il Guidebook di Hugging Face: lo sviluppatore che conosce dati e architettura, il sociotecnico (giurista, esperto di etica o di diritti) che legge rischi e limiti dal punto di vista delle persone interessate, l’organizzatore del progetto che risponde dell’insieme. A questi va aggiunto un responsabile nominativo, che tiene la scheda aggiornata e ne risponde davanti a un auditor. Una scheda firmata da una sola funzione è di norma incompleta. Ogni quanto va aggiornata una model card? A ogni nuova versione del modello: un nuovo addestramento, un cambio dei dati, un uso aggiunto o escluso, una metrica peggiorata in produzione richiedono una nuova scheda, e la precedente resta archiviata. Il Codice di buone pratiche GPAI chiede di conservare le versioni precedenti per dieci anni e di consegnare ai fornitori a valle i campi aggiornati entro 14 giorni. Una revisione almeno annuale conferma che la fotografia corrisponda ancora al modello.

Conclusione

La model card è il vocabolario più diffuso per descrivere un modello di IA, ed è stata pensata per la trasparenza, non per la conformità. L’AI Act ne ha ora scritto una versione più lunga nella legge per i fornitori di modelli per finalità generali e farà lo stesso, dal dicembre 2027, per i fornitori di sistemi ad alto rischio; gli Stati americani chiedono rapporti di trasparenza con lo stesso scheletro. Per un team di governance il compito non è sostituire la scheda, ma completarla con i campi del regolatore, versionarla, farla firmare e collegarla al sistema che serve. AI Sigil conserva la model card di ciascun modello accanto al fascicolo del sistema di IA, ai suoi rischi e ai suoi controlli, perché la documentazione che un’autorità potrà chiedere esista già prima della richiesta.