Benchmark AI: dai punteggi alle prove per l’audit

In sintesi

• Un benchmark AI misura come un modello si comporta su un insieme fisso di compiti, secondo una regola di punteggio nota. Risponde alla domanda su quale modello sia più forte in quel test, non a quella sull’idoneità alla finalità prevista del vostro sistema.
• L’AI Act impone ai fornitori di sistemi ad alto rischio di dichiarare le proprie metriche di accuratezza nelle istruzioni per l’uso. L’obbligo riguarda la vostra metrica, non la classifica di un terzo.
• I punteggi pubblici stanno perdendo valore probatorio: i test più citati sono saturi e le loro domande, essendo pubblicate, finiscono nei corpus di addestramento.
• Un risultato diventa evidenza solo quando è possibile dimostrare che cosa è stato eseguito, su quali dati, contro quale versione del modello, da chi e quando.
• L’evidenza che supera un audit proviene quasi sempre da un set di test interno derivato dalla finalità prevista, non da una classifica pubblica.

Che cosa misura davvero un benchmark AI

Un benchmark AI è un test standardizzato: un insieme fisso di dati di input, un insieme di output attesi e una regola di punteggio che converte il comportamento del modello in un numero confrontabile. Poiché tutti i modelli affrontano gli stessi input sotto la stessa regola, il benchmark trasforma un’impressione in un valore su cui due interlocutori possono discutere avendo davanti gli stessi fatti. Si tratta di uno strumento realmente utile, ed è esattamente qui che cominciano i problemi. Un benchmark è un campione finito estratto da una distribuzione. Il lavoro a cui destinate un modello di IA appartiene invece a un insieme aperto di situazioni tratte da una distribuzione assai più disordinata. Il punteggio resta sempre una misura indiretta, e la distanza fra questa misura e ciò che vi interessa non compare mai sulla classifica.

I tre componenti di un benchmark

Ogni benchmark si compone di tre elementi, ciascuno dei quali può venire meno in modo indipendente.

• Il dataset: gli input e, di norma, gli output di riferimento rispetto ai quali si assegna il punteggio.
• Il metodo di valutazione: la regola che converte gli output in punteggio. Confronto delle risposte per i quesiti a scelta multipla, esecuzione di test unitari per il codice, oppure un giudice algoritmico per le produzioni aperte.
• La classifica: la rappresentazione che rende comparabili i risultati e che, per inciso, li rende anche convenienti da manipolare.

Merita particolare attenzione la verità di riferimento, perché pone silenziosamente un tetto a tutto ciò che vi si appoggia. Se la chiave di correzione è sbagliata, una risposta corretta del modello viene conteggiata come errore e l’intero risultato eredita quel rumore.

Le famiglie di capacità e i loro punti ciechi

Nessun singolo test cattura ciò che un modello sa fare, ragione per cui la disciplina suddivide la valutazione per capacità. Solo una lettura trasversale restituisce un quadro onesto.

• Conoscenza (MMLU, MMLU-Pro): ampiezza del richiamo fattuale. L’MMLU originario è ormai in gran parte saturo, sicché gli scarti fra modelli di frontiera non portano più alcun segnale.
• Ragionamento (GPQA Diamond, Humanity’s Last Exam): risoluzione in più passaggi su domande deliberatamente difficili. Difficili oggi, bersaglio di contaminazione domani.
• Codice (SWE-bench Verified, LiveCodeBench): correzione di segnalazioni reali in un repository anziché scrittura di funzioni isolate. I test a livello di funzione hanno perso gran parte del loro potere discriminante.
• Agenti (GAIA): pianificazione e uso di strumenti lungo più passaggi. I risultati dipendono dall’impalcatura attorno al modello quanto dal modello stesso.
• Multimodale (MMMU): ragionamento su testo, immagini e diagrammi. Un modello testuale solido può ottenere qui un punteggio sorprendentemente debole.
• Preferenza umana (Arena Elo): quale risposta le persone preferiscano in confronti alla cieca. Si misurano preferenza e stile, non correttezza, e le due divergono più spesso di quanto la classifica lasci intendere.

Per i team che lavorano specificamente sui modelli linguistici, il dettaglio famiglia per famiglia si trova nella nostra guida ai benchmark LLM. Quanto segue vale per qualsiasi classe di modello.

Quando il punteggio diventa un obbligo normativo

La maggior parte dei contributi tratta il benchmark AI come un’abitudine ingegneristica. Per chiunque immetta un sistema sul mercato europeo, esso somiglia piuttosto a un obbligo documentale, e questo cambio di inquadramento modifica ciò che si intende per buon benchmark.

Articolo 15: dichiarare la propria metrica di accuratezza

L’articolo 15 dell’AI Act impone ai sistemi ad alto rischio di conseguire un livello adeguato di accuratezza, robustezza e cibersicurezza e di operare in modo costante sotto tali profili lungo l’intero ciclo di vita. La frase decisiva per i team di governance è la successiva: i livelli di accuratezza e le pertinenti metriche di accuratezza devono essere dichiarati nelle istruzioni per l’uso allegate. Questa formulazione capovolge il riflesso abituale. L’obbligo non consiste nell’ottenere un buon risultato su un test pubblico riconosciuto, bensì nel nominare la metrica che ritenete pertinente per il vostro sistema, nell’indicare il livello raggiunto e nel rispondere di entrambi. Una posizione in classifica non assolve questo dovere, e citarla al posto di una misurazione propria costituisce una lacuna che un valutatore individua rapidamente. Il testo prevede comunque riferimenti condivisi. Incarica la Commissione, in cooperazione con i portatori di interessi e con organizzazioni quali le autorità di metrologia e di analisi comparativa, di incoraggiare lo sviluppo di parametri di riferimento e metodologie di misurazione. Il cantiere è aperto più che concluso, e per ora l’onere di scegliere e giustificare una metrica ricade sul fornitore. L’articolo 15 si applica dal 2 agosto 2026, scadenza che rientra nell’orizzonte di pianificazione descritto nella nostra guida operativa al regolamento UE.

Modelli per finalità generali: articolo 55 e codice di buone pratiche

I fornitori di modelli per finalità generali sono soggetti a un obbligo di valutazione autonomo e assai più esplicito. Il codice di buone pratiche GPAI pubblicato dall’Ufficio europeo per l’IA nel luglio 2025 impone ai fornitori di modelli con rischio sistemico, soglia attualmente ancorata a una potenza di calcolo di addestramento superiore a 10^25 FLOPs, di mantenere un quadro di sicurezza che copra valutazioni del modello, esercizi di red teaming, monitoraggio successivo all’immissione sul mercato, cibersicurezza e segnalazione degli incidenti. Qui la valutazione non è più un esercizio comparativo, bensì un’argomentazione di sicurezza, da mantenere dopo il rilascio anziché da produrre una sola volta al lancio. I deployer che costruiscono su questi modelli ne ereditano le conseguenze, ragione per cui la nostra scheda sull’IA per finalità generali tratta le evidenze di valutazione del fornitore come un dato di acquisto e non come una curiosità tecnica.

ISO 42001 e NIST AI RMF: la lettura da sistema di gestione

Due riferimenti volontari trasformano il benchmarking da attività a processo governato. La norma ISO/IEC 42001 colloca la valutazione delle prestazioni dentro un sistema di gestione certificabile. Nel momento in cui una campagna di misura ricade sotto il punto 9, cessa di essere una diapositiva e diventa una registrazione dotata di responsabile, periodicità e pista di audit. Il NIST AI Risk Management Framework è più diretto. La sua funzione MEASURE applica metriche, parametri di riferimento, test e analisi alle caratteristiche di affidabilità, e richiede un’analisi comparativa periodica tanto del sistema quanto della pratica di gestione del rischio che lo circonda. I lavori del NIST su test, valutazione, verifica e validazione fissano l’asticella senza giri di parole: tali processi devono essere obiettivi, ripetibili o scalabili, istituiti, seguiti e documentati, e devono rispettare le norme scientifiche, giuridiche ed etiche in un procedimento aperto e trasparente. Questa singola frase è la specificazione più utile di un benchmark difendibile che sia mai stata scritta. Vale la pena notare ciò che non dice: nulla su quale test eseguire, e tutto sulla possibilità che un terzo lo riesegua ottenendo lo stesso risultato.

Perché un punteggio pubblico è un’evidenza debole

La critica ai punteggi pubblicati non è una posizione di parte: proviene dalla letteratura della valutazione stessa.

Saturazione e contaminazione

I test più citati sono saturi. I modelli di frontiera si raggruppano entro uno o due punti l’uno dall’altro, e lo scarto residuo dipende spesso da domande ambigue o mal etichettate anziché da una differenza di capacità. Un esame in cui tutti ottengono il massimo non può più svolgere la sua unica funzione. Più acuto è il problema della contaminazione. I benchmark vengono pubblicati apertamente affinché la comunità possa riprodurli, e ciò porta le loro domande e risposte dentro i corpus web con cui si addestra la generazione successiva. Un modello che ha di fatto visto il test durante l’addestramento lo supera senza generalizzare. Le rassegne sulla contaminazione lo dicono senza mezzi termini: il punteggio misura memorizzazione e non capacità, e dalla classifica la differenza non si vede.

Legge di Goodhart e validità di costrutto

Quando una misura diventa un obiettivo, cessa di essere una buona misura. Nel momento in cui un benchmark è il numero che i laboratori pubblicizzano e su cui gli acquirenti filtrano, l’incentivo si sposta dalla costruzione di modelli migliori all’ottenimento di punteggi migliori. Il fenomeno è ormai documentato. Una meta-rassegna interdisciplinare collegata al Centro comune di ricerca della Commissione europea, Can We Trust AI Benchmarks?, individua nove problemi sistemici del benchmarking, fra cui incentivi disallineati, carenze di validità di costrutto e rischi di manipolazione. La validità di costrutto è la questione più silenziosa: chiede se un test misuri davvero ciò che dichiara di misurare, e una quota sorprendente di benchmark pubblicati non riesce a dimostrarlo. Il testo divulgativo Benchmarks 101 di Aspen Digital propone una tassonomia dei fallimenti in tre voci: dati di scarsa qualità, misurazione o progettazione difettosa, risultati mal interpretati. Il suo esempio conviene tenerlo a mente al prossimo punteggio da prima pagina. Alcuni ricercatori hanno rilevato che circa il 30 per cento delle domande di biologia e chimica di Humanity’s Last Exam, benchmark concepito proprio per essere difficile, prevedeva risposte errate o non sostenibili.

Il divario fra laboratorio e campo

I benchmark misurano in laboratorio, non sul campo. Intervengono inoltre prima di quanto si immagini nel ciclo di vita, alla definizione degli obiettivi e alla costruzione del modello, mentre valutazione d’impatto e red teaming arrivano dopo, quando esiste un sistema da sondare. Le conseguenze non sono teoriche. Aspen Digital documenta modelli di dermatologia valutati sul dataset della International Skin Imaging Collaboration: il punteggio complessivo era elevato, e le prestazioni peggioravano sensibilmente sulle pelli scure non appena le metriche venivano disaggregate per fototipo. Il numero aggregato era corretto e la conclusione che se ne traeva era sbagliata. Questo esempio traccia il confine di cui tratta l’articolo. Un punteggio di capacità non equivale a una garanzia in materia di diritti fondamentali, e nessuna quantità di punteggio sostituisce i test disaggregati descritti nella nostra guida al bias dell’IA. La valutazione dell’equità è un obbligo distinto, con un metodo distinto, e non una sottosezione della misurazione delle prestazioni.

Che cosa un benchmark può e non può dimostrare

I team di governance hanno bisogno di un confine applicabile senza riaprire ogni volta il dibattito scientifico. Questo è il nostro.

Un benchmark PUÒ dimostrare	Un benchmark NON PUÒ dimostrare
Una capacità relativa su un compito definito, in un dato momento	L’idoneità alla vostra finalità prevista
Una regressione fra due versioni del modello su un set interno congelato	Da solo, la metrica di accuratezza dichiarata richiesta dall’articolo 15
Che esiste ed è stata seguita una procedura di misura documentata e ripetibile	L’assenza di impatto discriminatorio sui gruppi interessati
Un filtro preliminare per costruire una rosa ristretta	La resistenza a input avversari o fuori distribuzione
Il progresso aggregato di una capacità nel tempo	La tenuta delle prestazioni dopo un aggiornamento silenzioso lato fornitore
Che una affermazione precisa è stata verificata e non solo enunciata	Da solo, la conformità a un qualsiasi riferimento

La lettura sta in una frase. Un benchmark è ammissibile come evidenza solo se potete dimostrare che cosa è stato eseguito, su quali dati, contro quale versione del modello, da chi e quando. Tutto ciò che compare nella colonna di sinistra dipende dall’esistenza di quella registrazione. Nulla nella colonna di destra diventa vero perché un punteggio era alto. Là dove il benchmark non regge il peso, esso ricade sui controlli descritti nella nostra guida alla gestione del rischio IA.

Costruire un benchmark interno che regga a un audit

La conclusione pratica di quanto precede è che il benchmark su cui vale la pena investire è di solito quello che costruite voi.

Partire dalla finalità prevista, non dalla classifica

La finalità prevista è la nozione cardine dell’AI Act ed è il punto di partenza corretto per un set di test. Mettete per iscritto a che cosa serve il sistema, chi tocca e quanto costa una risposta errata in ciascun caso. Raccogliete poi input reali, comprese le occorrenze scomode: richieste ambigue, casi limite, dati in ingresso malformati. Richiede più lavoro della lettura di una classifica, e la valutazione che ne risulta non si generalizzerà oltre il vostro caso d’uso. È precisamente questo il punto. Un modello in testa a un riferimento pubblico e mediocre sul vostro compito resta il modello sbagliato per la vostra implementazione, quali che siano i suoi punteggi.

Provenienza dei dati e set riservati

Tre proprietà separano un set di test affidabile da uno che vi svia in silenzio.

1. Il modello non ha visto i dati. Usate dati riservati, dati generati appositamente oppure dati successivi alla data di taglio dell’addestramento. In caso contrario state misurando memorizzazione.
2. I dati riflettono il vostro dominio reale. Un testo web generico non dice nulla su come un modello tratti referti clinici, pratiche di credito o segnalazioni interne, il cui lessico, struttura e ambiguità non somigliano in nulla a un paragrafo enciclopedico.
3. La verità di riferimento è realmente corretta. Ogni punteggio si misura contro una chiave di correzione, e una chiave errata pone un tetto a un buon modello premiando i comportamenti sbagliati.

Queste esigenze si oppongono fra loro, e conviene dirlo apertamente. I dati più realistici sono di norma i più sensibili, dunque non pubblicabili, e pubblicarli contaminerebbe comunque i modelli futuri. L’etichettatura manuale su larga scala introduce esattamente gli errori di riferimento da cui la terza proprietà mette in guardia. I team se la cavano con la generazione sintetica, una pseudonimizzazione accurata oppure set ristretti ma curati con rigore. Nessuna opzione elimina del tutto il compromesso.

Versionamento, riproducibilità e conservazione

Ripetibilità e riproducibilità non sono qui raffinatezze ingegneristiche. Il quadro di test AI Verify le tratta come principio di governance a pieno titolo e struttura ogni controllo in tre momenti: il risultato atteso, il processo e l’evidenza che lo convalida. Questo schema coincide con ciò che un valutatore chiederà. Una campagna di misura deve lasciare dietro di sé una registrazione che contenga almeno:

• il protocollo di test e la regola di punteggio
• la versione del dataset e la sua impronta
• l’identificativo del modello, la sua versione e l’endpoint utilizzato
• l’ambiente di esecuzione, i parametri e il carattere zero-shot o few-shot della campagna
• la data, l’operatore e gli output grezzi conservati accanto al punteggio calcolato
• il periodo di conservazione e la collocazione degli artefatti

Questo elenco è ciò che trasforma un numero in un artefatto. È anche ciò che distingue un sistema verificabile da uno che si è semplicemente comportato bene una volta, distinzione che approfondiamo in auditabilità dell’IA. Queste registrazioni appartengono alla documentazione tecnica richiesta dall’AI Act e non a una cartella separata in capo al team di data science.

Come interrogare i punteggi dichiarati da un fornitore

Le tabelle di benchmark sono la prima evidenza che ogni fornitore mette sul tavolo, e vengono raramente contestate. Sette domande svolgono quasi tutto il lavoro.

1. Quale regola di punteggio è stata usata, e corrisponde al nostro confronto? Accuratezza, pass@k ed Elo non sono intercambiabili. Un pass@1 e un pass@10 dello stesso modello misurano cose diverse, e uno scarto Elo descrive una percentuale di vittorie nel confronto diretto, non una percentuale di capacità.
2. Zero-shot o few-shot? I valori few-shot risultano sistematicamente più alti.
3. Set completo o sottoinsieme verificato? I sottoinsiemi rivisti da persone, ripuliti dagli item difettosi, restituiscono numeri più puliti e più alti.
4. Chi ha condotto la valutazione? Un punteggio prodotto dal fornitore sul proprio ambiente non è confrontabile con una misurazione indipendente.
5. Il set di test è pubblico, e potrebbe essere finito nell’addestramento? Chi non ha esaminato la contaminazione consegna un punteggio inutilizzabile.
6. Quando è stata effettuata la misura, rispetto alla versione servita oggi dall’API? I fornitori aggiornano i modelli in silenzio dietro nomi di API invariati.
7. Siete disposti a rieseguire la campagna sul nostro set riservato, sotto accordo di riservatezza? La risposta a questa è la più istruttiva di tutte.

Un fornitore che non sappia rispondere vi chiede di accettare un numero di marketing come artefatto di garanzia. È un rilievo di rischio di terze parti, non una nota tecnica a piè di pagina, e rientra nella stessa valutazione delle questioni trattate nel nostro articolo su conformità e governance.

Domande frequenti

Che cos’è un benchmark AI? Un benchmark AI è un test standardizzato, composto da un dataset fisso e da una regola di punteggio, che produce numeri di prestazione confrontabili fra modelli. Serve a confrontare candidati, seguire il progresso fra versioni e individuare regressioni. Misura le prestazioni sui compiti del test, i quali possono somigliare oppure no a quelli che vi interessano. L’AI Act impone di eseguire benchmark? Non in questi termini. L’articolo 15 richiede ai sistemi ad alto rischio un livello adeguato di accuratezza, robustezza e cibersicurezza, prestazioni costanti lungo il ciclo di vita e la dichiarazione dei livelli e delle pertinenti metriche di accuratezza nelle istruzioni per l’uso. Ciò presuppone una pratica di misurazione difendibile, senza prescrivere un riferimento pubblico nominato. Il testo incarica inoltre la Commissione di incoraggiare lo sviluppo di parametri di riferimento e metodologie di misurazione con le autorità di metrologia e di analisi comparativa, lavoro tuttora in corso. I fornitori di modelli per finalità generali con rischio sistemico sono soggetti a un obbligo di valutazione più esplicito ai sensi dell’articolo 55 e del codice di buone pratiche GPAI. I benchmark pubblici conservano una loro utilità? Sì, come primo filtro e non come verdetto. Restringono in fretta un campo di candidati e mettono in luce le debolezze evidenti. Non possono dire come si comporti un modello sui vostri dati, nel vostro dominio e sotto i vostri vincoli, e saturazione e contaminazione hanno ampliato questo divario. Trattate una posizione in classifica come un’ipotesi da verificare. Che cos’è la contaminazione dei dati di benchmark? Si ha contaminazione quando le domande e le risposte di un benchmark compaiono nei dati di addestramento di un modello. Poiché i benchmark sono pubblicati apertamente per consentirne la riproduzione, finiscono abitualmente nei corpus di addestramento. Un modello contaminato restituisce risposte memorizzate e ottiene un punteggio elevato che crolla su problemi inediti dello stesso tipo. Il fenomeno è difficile da rilevare, di rado dichiarato, ed è la ragione principale dello scostamento fra punteggi pubblici e prestazioni reali. In che cosa il benchmarking differisce da un audit dell’IA? Un benchmark misura le prestazioni di un modello su un compito definito. Un audit dell’IA esamina il sistema e l’organizzazione attorno a esso: governance, gestione del rischio, provenienza dei dati, supervisione umana, documentazione e le evidenze a sostegno di ciascuna affermazione. I risultati di benchmark sono un dato in ingresso dell’audit. Presi da soli rispondono a una domanda tecnica ristretta, e il revisore chiederà come la campagna sia stata progettata, versionata e conservata prima di accettare il numero. Quanti benchmark eseguire su un sistema ad alto rischio? Meno di quanti i team immaginino, ma scelti con maggiore cura. Un set di test interno derivato dalla finalità prevista vale più di cinque riferimenti pubblici, perché è l’unico i cui risultati parlino di idoneità allo scopo. Aggiungete una valutazione dell’equità con risultati disaggregati per gruppo interessato e una prova di tenuta su input avversari e fuori distribuzione. Queste tre campagne, versionate e ripetibili, compongono un fascicolo più solido di qualsiasi raccolta di citazioni da classifica.

Conclusione

Il benchmark AI non è guasto, è archiviato nel posto sbagliato. Trattato come esercizio di classifica, produce teatro d’acquisto: una tabella di numeri che nessuno può rieseguire, su compiti che nessuno dei presenti ha esaminato, riferiti a versioni di modello nel frattempo sostituite. Trattato come pratica di misurazione, produce qualcosa che un valutatore può davvero utilizzare. Il passaggio è modesto e soprattutto organizzativo. Derivate il test dalla finalità prevista. Tenete i dati riservati. Registrate protocollo, versioni, operatore e data. Collocate gli artefatti dove risiede il resto del fascicolo tecnico. Dite con chiarezza che cosa il risultato non dimostra. Quest’ultima disciplina è la più importante. La posizione più solida davanti a un’autorità non è un punteggio elevato, bensì una misurazione documentata, un’esposizione onesta dei suoi limiti e controlli che coprano tutto ciò che la misurazione lascia aperto. Collegare queste registrazioni ai controlli che sostengono, anziché disperderle fra presentazioni e taccuini, è il lavoro concreto di un framework di governance dell’IA.