La model card che nessuno legge

Anthropic pubblica una model card per ogni rilascio di Claude. OpenAI pubblica una system card per ogni rilascio di GPT. Google DeepMind pubblica report tecnici per Gemini. Meta pubblica model card per Llama. Mistral le pubblica per i propri modelli. Sono i documenti fonte primaria — scritti dalle persone che hanno costruito i modelli — che descrivono esattamente cosa il modello sa fare, cosa non sa fare, dove fallisce e in quali condizioni i suoi output non dovrebbero essere considerati attendibili.

Quasi nessuno le legge.

La pagina marketing riceve milioni di visite. La model card riceve migliaia. Il blog post che annuncia il modello viene condiviso in ogni newsletter IA e feed LinkedIn. La model card — il documento che ti dice realmente se questo modello è adatto al tuo caso d’uso — sta quieta su un sito di documentazione, non letta, non citata, non utilizzata.

Questo è un problema. In particolare, è il tipo di problema che costa denaro alle aziende, produce deployment scadenti e erode la fiducia negli strumenti IA — tutto perché il documento più importante distribuito con ogni modello viene trattato come un’appendice tecnica anziché come un manuale operativo.

Cosa contiene realmente una model card

Il termine “model card” deriva da un paper del 2019 di Margaret Mitchell, Simone Wu, Andrew Zaldivar, Parker Barnes, Lucy Vasserman, Ben Hutchinson, Elena Spitzer, Inioluwa Deborah Raji e Timnit Gebru. Il paper proponeva un framework di documentazione standardizzato per i modelli di machine learning — analogo all’etichetta nutrizionale per il cibo o alla scheda di sicurezza per i prodotti chimici.

Il framework originale specificava: dettagli del modello, uso previsto, fattori (demografici o contestuali rilevanti), metriche, dati di valutazione, dati di addestramento, analisi quantitative, considerazioni etiche, e avvertenze e raccomandazioni.

In pratica, le model card dei principali laboratori IA si sono evolute oltre questo template, ma lo scopo fondamentale resta: documentazione onesta delle capacità, dei limiti e dei casi d’uso appropriati di un modello, scritta dalle persone che lo conoscono meglio.

Le model card di Claude di Anthropic, per esempio, contengono:

Valutazioni delle capacità con benchmark specifici. Non “Claude è bravo nel ragionamento” ma “Claude raggiunge X% sul benchmark MMLU, Y% su HumanEval, Z% su MATH.” Questi numeri sono comparabili tra modelli. Ti dicono, specificamente, come il modello performa su test standardizzati di conoscenza, capacità di programmazione e ragionamento matematico.

Limiti noti documentati esplicitamente. La model card dichiara dove il modello fallisce. Dove produce allucinazioni. Dove i suoi output non dovrebbero essere considerati attendibili senza verifica umana. Questa informazione non è sepolta nei disclaimer — è messa in primo piano come guida operativa.

Valutazioni di sicurezza. Come il modello è stato testato per output dannosi, bias e potenziale di abuso. Quali mitigazioni sono state applicate. Quali rischi residui rimangono. È la valutazione più onesta del profilo di sicurezza di un modello disponibile — più onesta di un blog post di marketing, più specifica del riassunto di un giornalista.

Casi d’uso previsti e potenziale di abuso. Per cosa il modello è stato progettato, per cosa non è stato progettato e quali usi gli sviluppatori sconsigliano specificamente. Per una PMI che valuta se distribuire questo modello per un compito specifico, questa sezione è il singolo pezzo di orientamento più prezioso esistente.

Le system card di OpenAI forniscono informazioni equivalenti in un formato diverso, con particolare profondità sulla loro metodologia di valutazione della sicurezza — risultati del red-teaming, pipeline di valutazione automatizzata e le categorie specifiche di rischio che testano.

Questi documenti non sono materiali di marketing. Sono divulgazioni tecniche. Sono la cosa più vicina a un’autovalutazione onesta che l’industria IA produce. E vengono ignorati.

Perché nessuno le legge

Tre ragioni, tutte strutturali.

I documenti sono scritti per ricercatori, non per operatori. Le model card usano il linguaggio della ricerca in machine learning: nomi di benchmark, metodologie di valutazione, misure statistiche. Un direttore acquisti che valuta se distribuire Claude per la classificazione delle richieste dei clienti non sa cosa significhi MMLU, non ha una base per interpretare un punteggio HumanEval e non sa come tradurre una valutazione di sicurezza in una valutazione del rischio operativo. L’informazione è preziosa. Manca lo strato di traduzione.

Il marketing è più facile da consumare. Un blog post che annuncia un nuovo modello è 1.500 parole di prosa accessibile con affermazioni chiare: “più veloce”, “più preciso”, “migliore nella programmazione”. La model card è 15.000 parole di documentazione tecnica con avvertenze, limiti e affermazioni condizionali. Il blog post conferma quello che vuoi sentire. La model card ti dice quello che devi sapere. Sono pubblici diversi, e il marketing vince sempre la competizione per l’attenzione.

Il lavoro di nessuno include leggere le model card. In un’azienda di 200 persone che valuta un deployment IA, nessuno è responsabile di leggere la model card. Il CTO potrebbe avere il background tecnico ma non ha il tempo. Il project manager ha il tempo ma non ha il background tecnico. Il consulente esterno ha già una raccomandazione di modello pronta prima che la model card sia stata scaricata. La model card cade in un vuoto di responsabilità — troppo tecnica per il decisore aziendale, troppo operativa per il team di ricerca, troppo dettagliata per i tempi del consulente.

Cosa ti dice una model card che nient’altro può dirti

Dimostro con un esempio specifico. Analizzerò tre categorie di informazioni dalle model card che influenzano direttamente se una PMI europea dovrebbe distribuire un modello specifico per un caso d’uso specifico.

Categoria 1: Varianza delle prestazioni linguistiche

Le model card riportano benchmark di performance multilingue. Questi benchmark rivelano divari di prestazione tra le lingue che i materiali di marketing non menzionano mai.

Un modello che ottiene l’89% nel question answering in inglese potrebbe ottenere il 72% in tedesco e il 58% in portoghese. La pagina marketing dice “supporta 95+ lingue.” La model card ti mostra il gradiente di prestazione reale — e per una PMI UE che opera in più mercati, la differenza tra 89% e 58% è la differenza tra uno strumento utile e una responsabilità.

Quando un cliente portoghese invia una richiesta e l’accuratezza di comprensione del modello è 31 punti percentuali più bassa che per una richiesta in inglese, la qualità dell’output degrada. Il cliente riceve una risposta meno accurata. Se la risposta comporta una raccomandazione, una classificazione o una decisione, il divario di accuratezza diventa un divario di qualità, un divario di equità e potenzialmente un divario legale ai sensi dell’Articolo 22 del GDPR.

La model card te lo dice. Il blog post no.

Categoria 2: Tassi di allucinazione per dominio

Le model card riportano sempre più i tassi di allucinazione — la frequenza con cui il modello genera informazioni che suonano plausibili ma sono fattualmente errate. Questi tassi variano drasticamente per dominio.

Un modello potrebbe allucinare al 2% su domande di conoscenza generale e al 12% su domande tecniche specifiche del dominio. Per una PMI che distribuisce il modello per rispondere alle richieste dei clienti su una linea di prodotti specializzata, il tasso di allucinazione rilevante è quello specifico del dominio, non il numero headline.

Più criticamente, le model card descrivono i tipi di allucinazioni a cui il modello è incline. Alcuni modelli allucinano dettagli specifici (date, numeri, nomi) mantenendo corretta la direzione generale. Altri allucinano intere catene causali — producendo spiegazioni che suonano autorevoli e sono completamente inventate. Il tipo di allucinazione determina il tipo di supervisione umana richiesta.

Un modello che a volte sbaglia le date ha bisogno di uno strato di verifica dei fatti. Un modello che inventa spiegazioni ha bisogno di un revisore esperto del dominio. La risposta operativa è diversa. La model card ti dice quale risposta serve.

Categoria 3: Risultati delle valutazioni di sicurezza

Le model card dei laboratori IA responsabili includono risultati del red-teaming — gli esiti di tentativi sistematici di far produrre al modello output dannosi, distorti o inappropriati.

Per una PMI UE, le considerazioni di sicurezza rilevanti sono specifiche: se il modello genera output distorti che potrebbero influenzare decisioni occupazionali (rilevante ai sensi dell’Articolo 22 del GDPR e dell’Articolo 6 del Regolamento UE sull’IA), se produce contenuti discriminatori in applicazioni rivolte al cliente e se rivela dati di addestramento che includono informazioni personali.

La model card affronta queste domande con risultati di test specifici. Non “abbiamo testato per il bias” ma “abbiamo testato per il bias demografico attraverso X categorie usando la metodologia Y, e abbiamo osservato un pattern Z di bias residuo nelle seguenti condizioni.”

Questa informazione è essenziale per la valutazione della conformità richiesta dal Regolamento UE sull’IA per i sistemi IA ad alto rischio. L’Articolo 9 richiede un sistema di gestione del rischio che includa l’identificazione e l’analisi dei rischi noti e prevedibili. La model card è la fonte primaria per i rischi noti. Ignorarla non è solo operativamente sciocco — potrebbe essere giuridicamente insufficiente.

Come leggere una model card

Per una PMI che valuta un deployment IA, ecco l’approccio operativo alla lettura di una model card. Richiede circa due ore, che è meno della riunione media del comitato direttivo e produce informazioni più utili.

Passo 1: Leggi prima la sezione sull’uso previsto. L’uso previsto corrisponde al tuo caso d’uso? Se la model card dice che il modello è “progettato per assistenza conversazionale e generazione di contenuti” e tu vuoi usarlo per il credit scoring automatizzato, c’è una discrepanza. La discrepanza non significa che il modello non possa farlo. Significa che gli sviluppatori non lo hanno testato per quello scopo, il che significa che la responsabilità del testing ricade su di te.

Passo 2: Controlla i benchmark multilingue. Trova i numeri di performance per ogni lingua che il tuo deployment utilizzerà. Se il divario di performance tra la tua lingua principale e le lingue secondarie supera i 10 punti percentuali, pianifica uno strato di assicurazione qualità nelle lingue con prestazioni inferiori.

Passo 3: Leggi la sezione limiti completamente. È la sezione più preziosa. Gli sviluppatori ti stanno dicendo dove il loro modello fallisce. Lo sanno, perché lo hanno testato. Ignorare questa sezione è l’equivalente IA dell’ignorare il report dell’ingegnere strutturale prima di costruire su un terreno. L’informazione c’è. Le conseguenze dell’ignorarla sono prevedibili.

Passo 4: Esamina la valutazione di sicurezza. Identifica le categorie di output dannoso che sono state testate e i rischi residui che rimangono. Mappali sul tuo caso d’uso. Se il tuo deployment coinvolge popolazioni vulnerabili (clienti che richiedono prodotti finanziari, candidati a un posto di lavoro, pazienti), la valutazione di sicurezza non è lettura supplementare. È un requisito di conformità.

Passo 5: Confronta tra modelli. Le model card sono comparabili. Gli stessi benchmark, le stesse categorie, le stesse metodologie di valutazione compaiono nelle model card di laboratori diversi. Leggi tre model card di modelli concorrenti e le differenze di performance — comprese quelle non ovvie sepolte nelle appendici — diventano chiare.

Categoria 4: Documentazione sull’uso appropriato e l’abuso

Le model card includono sempre più elenchi espliciti di casi d’uso previsti e scenari di abuso documentati. Questi elenchi non sono ipotetici. Derivano dal comportamento degli utenti osservato durante i test e il deployment.

Per una PMI che distribuisce un modello linguistico per applicazioni rivolte al cliente, la documentazione sull’abuso è operativamente critica. La model card potrebbe specificare: “Questo modello non è progettato per la diagnosi medica, la consulenza legale o le raccomandazioni finanziarie.” Se il tuo deployment usa il modello per generare raccomandazioni di prodotti finanziari, la model card ti ha appena detto — per iscritto, dalle persone che hanno costruito il modello — che il tuo caso d’uso è al di fuori dell’ambito previsto.

Questo non significa che il modello non possa svolgere il compito. Potrebbe svolgerlo adeguatamente. Ma la documentazione sull’abuso della model card significa che gli sviluppatori del modello non hanno testato o validato il modello per quella specifica applicazione. Le valutazioni di sicurezza non coprono il tuo caso d’uso. I benchmark di performance non sono calibrati per il tuo dominio. La responsabilità, in caso di output dannoso, ricade interamente su di te — perché la model card ha esplicitamente dichiarato che il tuo uso non era previsto.

Per la conformità al Regolamento UE sull’IA, questa documentazione è direttamente rilevante. L’Articolo 13 richiede trasparenza sullo scopo previsto di un sistema IA. Se la model card dice che il modello non è previsto per il tuo caso d’uso, e tu lo distribuisci per quel caso d’uso, hai creato una lacuna di conformità che nessuna documentazione a posteriori può colmare.

La model card te lo ha detto. Hai scelto di non leggerla. La conseguenza è prevedibile.

Il principio della fonte primaria

Leggo i report della BCE, non quello che i giornalisti dicono dei report della BCE. Leggo i dataset Eurostat, non quello che i commentatori dicono dei dataset Eurostat. Leggo gli articoli del Regolamento UE sull’IA, non quello che le società di consulenza dicono del Regolamento UE sull’IA.

La model card è la fonte primaria per cosa un modello IA sa e non sa fare. Tutto il resto — il blog post, il report dell’analista, la raccomandazione del consulente, il commento su LinkedIn — è commento. Il commento ha i suoi usi. Ma il commento introduce bias, compressione e agenda. La fonte primaria no.

La model card non è perfetta. È scritta dal laboratorio che ha costruito il modello, e i laboratori hanno incentivi a presentare i propri modelli favorevolmente. Ma la model card è vincolata dalla riproducibilità — i benchmark possono essere verificati indipendentemente, i limiti possono essere testati indipendentemente e le valutazioni di sicurezza possono essere replicate indipendentemente. Il marketing non è vincolato da nessuno di questi.

Quando valuto un modello IA per un deployment Bluewaves, la model card è il primo documento che leggo e l’ultimo documento che consulto. Non il primo perché è facile — perché è onesta. Non l’ultimo perché è esaustiva — perché le decisioni che prendiamo sul deployment sono ancorate a ciò che gli sviluppatori sanno realmente del loro modello, non a ciò che il loro team marketing vuole farci credere.

L’implicazione operativa

Per ogni deployment IA nella tua azienda, una persona dovrebbe leggere la model card. Completamente. Non scorrere. Non il sommario esecutivo. L’intero documento.

Quella persona dovrebbe tradurre le valutazioni tecniche della model card in tre documenti operativi:

Una valutazione delle capacità che dichiari, in linguaggio chiaro, cosa il modello sa e non sa fare per il tuo caso d’uso specifico, basandosi sui benchmark e sui limiti della model card.

Un registro dei rischi che mappi le valutazioni di sicurezza e i limiti noti della model card sul tuo contesto specifico di deployment, identificando quali rischi sono rilevanti, quali mitigazioni sono necessarie e quali rischi residui devono essere accettati.

Un piano di monitoraggio che specifichi come verificherai, in produzione, che le prestazioni reali del modello corrispondano alle prestazioni documentate dalla model card — perché i modelli possono degradare, i casi d’uso possono deviare, e l’unica verifica sulle affermazioni della model card è la tua osservazione diretta.

Questi tre documenti richiedono a una persona circa quattro ore per essere prodotti. Non costano nulla. Prevengono i fallimenti più comuni e più costosi dei deployment IA: distribuire un modello per un caso d’uso per cui non è mai stato progettato, distribuire in una lingua dove le prestazioni sono materialmente inferiori e distribuire senza un sistema di monitoraggio che intercetti il degrado prima degli utenti.

La model card è gratuita. Leggerla è gratuito. Agire in base ad essa è gratuito.

Il costo di non leggerla è il deployment che fallisce e il team che perde fiducia negli strumenti IA perché nessuno ha letto il documento che avrebbe previsto il fallimento.

Leggi la model card.

La fonte primaria è disponibile. La fonte primaria è gratuita. La fonte primaria contiene informazioni che nessuna fonte secondaria — nessun blog post, nessun report dell’analista, nessuna raccomandazione del consulente — può replicare.

La model card è scritta dalle persone che hanno costruito il modello. Sanno cose sul suo comportamento che nessun altro sa. Hanno documentato quelle cose — onestamente, specificamente, con benchmark e avvertenze — in un documento che è pubblicamente disponibile e sistematicamente ignorato.

Il divario tra la pagina marketing e la model card è il divario tra ciò che vuoi sentire e ciò che devi sapere. La model card è ciò che devi sapere.

Leggila.