Benchmark LLM: guida conformità per i team di governance dell’IA

In sintesi

• I benchmark LLM sono dispositivi standardizzati che combinano un dataset, un insieme di compiti, una metrica e un meccanismo di punteggio, allo scopo di misurare in modo comparabile una specifica capacità di un grande modello linguistico da un modello all’altro.
• Benchmark pubblici come MMLU, HumanEval, MT-Bench o la suite HELM di Stanford dominano la conversazione, ma nessuno di essi è stato concepito per rispondere a una domanda di natura regolamentare.
• Il regolamento europeo sull’IA, il NIST AI Risk Management Framework e la norma ISO/IEC 42001 richiedono tutti una qualche forma di valutazione del modello: i benchmark sono lo strumento operativo che rende misurabili tali obblighi.
• Un punteggio su un benchmark pubblico non dimostra, da solo, la conformità. Contaminazione dei dataset, overfitting e cosiddetta evaluation awareness spezzano il legame fra un numero di classifica e il comportamento reale in produzione.
• Un portafoglio di benchmark pronto per la governance combina pochi benchmark pubblici ben documentati con un benchmark interno ancorato ai vostri casi d’uso, ai vostri rischi e ai vostri criteri di accettazione.

Che cos’è veramente un benchmark LLM

I benchmark LLM sono protocolli standardizzati che misurano il comportamento di un modello su un compito definito. Tolto l’imballaggio di marketing, ogni benchmark è composto dagli stessi quattro elementi: un dataset di esempi, un insieme di domande o compiti, una o più metriche e un meccanismo di punteggio che trasforma l’output del modello in un numero comparabile (IBM Think). La standardizzazione serve esclusivamente a rendere possibile il confronto, due modelli affrontano le stesse domande, ricevono lo stesso schema di valutazione, e ogni differenza riflette il comportamento del modello, non la costruzione del test. L’amministrazione dei benchmark avviene in genere secondo tre modalità. Nello zero-shot il modello riceve solo la descrizione del compito e deve generalizzare a partire dal suo addestramento. Nel few-shot vengono anteposti al prompt alcuni esempi risolti, per misurare la rapidità con cui il modello coglie uno schema. Nella valutazione fine-tuned il modello viene prima addestrato su dati simili al benchmark, il che migliora i punteggi ma diventa utile solo se anche il vostro deployment reale sarà fine-tuned. La metrica di riferimento varia per benchmark. I test a scelta multipla usano l’accuratezza. I benchmark di codice impiegano pass@k, la probabilità che almeno una delle k soluzioni generate superi i test unitari. La traduzione usa BLEU, la sintesi ROUGE, la classificazione precisione, richiamo e F1, la modellazione linguistica la perplessità. La maggior parte delle classifiche aggrega diverse di queste metriche in un singolo numero, il che rende il ranking comodo e l’interpretazione difficile. Per un pubblico di compliance, la cosa più importante è capire che cosa i benchmark non sono. Non sono certificazioni. Non sono test di accettazione approvati da un regolatore. Non sostituiscono una valutazione interna del vostro sistema specifico, sui vostri dati specifici, contro i vostri rischi specifici. Restano però la cosa più vicina a un vocabolario condiviso per descrivere le capacità di un LLM, e quel vocabolario è oggi portante in tutte le principali regolazioni IA in vigore.

Il panorama dei benchmark nel 2026 (la mappa di un responsabile compliance)

Il catalogo dei benchmark cresce rapidamente, ma le famiglie che compaiono realmente nei report di valutazione dei fornitori e nei dossier presentati alle autorità sono più ristrette di quanto il rumore di mercato lasci credere.

Ragionamento e comprensione linguistica

MMLU (Massive Multitask Language Understanding) copre 57 materie con oltre 15.000 domande a scelta multipla e resta il primo numero citato da ogni nuovo modello al lancio (paper MMLU). HellaSwag verifica il senso comune tramite completamento di frase con distrattori filtrati in modo adversariale. ARC (AI2 Reasoning Challenge) si basa su domande di scienze di livello elementare e pubblica due split, Easy e Challenge. Winogrande porta il Winograd Schema Challenge alla scala di 44.000 problemi di coreferenza raccolti in crowdsourcing. Letti insieme, questi quattro indicano se un modello sa trattare domande di conoscenza multi-dominio in un formato statico.

Matematica e codice

GSM8K è il benchmark canonico di matematica elementare, con 8.500 problemi verbali e soluzioni in linguaggio naturale. HumanEval ha introdotto la metrica pass@k per la generazione di codice; MBPP la estende ai problemi Python di base; SWE-bench è il più impegnativo dei tre, in quanto misura se un modello sa risolvere veri ticket GitHub in repository reali (paper SWE-bench). I benchmark di codice hanno una proprietà utile per i team di governance: sono passa-o-non-passa per ogni problema, quindi il punteggio è più difficile da gonfiare con giudizi soggettivi.

Conversazione e seguito di istruzioni

MT-Bench usa GPT-4 come giudice per valutare 80 domande aperte multi-turno su 8 categorie, un approccio insieme efficiente e metodologicamente discutibile secondo la letteratura recente. Chatbot Arena aggira il problema dell’LLM-giudice raccogliendo voti di preferenza per coppie in un’arena aperta, poi stimando i ranking dei modelli a partire da quei confronti per coppie (paper Chatbot Arena). Per prodotti destinati a interagire con esseri umani, Chatbot Arena correla con la qualità percepita meglio di MMLU.

Veridicità, sicurezza, allineamento

TruthfulQA misura la resistenza del modello alle falsità più comuni, un proxy per la resistenza all’allucinazione. HELM Safety valuta il rifiuto di risposte dannose in scenari di sicurezza. AIR-Bench, una pista relativamente recente all’interno della famiglia HELM di Stanford, valuta i modelli rispetto alle categorie usate dal regolamento europeo sull’IA, dal NIST AI RMF e da diverse altre tassonomie regolatorie (AIR-Bench). AIR-Bench merita più attenzione dai team di compliance di quanta ne riceva oggi: è l’unico benchmark pubblico deliberatamente strutturato attorno alle categorie dei regolatori.

Valutazione olistica: HELM come meta-benchmark

L’Holistic Evaluation of Language Models (HELM) di Stanford non è un singolo benchmark ma un protocollo di misura. Valuta ogni modello secondo 7 metriche (accuratezza, calibrazione, robustezza, equità, bias, tossicità, efficienza) su 16 scenari core, in condizioni standardizzate (HELM). Piste specializzate estendono ormai il quadro a domini medico (MedHELM), visivo (VHELM), audio e sicurezza. Per un’organizzazione che costruisce un benchmark interno, HELM si avvicina molto a un’architettura di riferimento pubblicata.

Perché i benchmark sono diventati uno strumento di compliance, non più solo uno strumento di ricerca

Quel che è cambiato fra il 2022 e il 2026 è che ‘valutare il modello’ ha smesso di essere una buona pratica raccomandata per diventare un obbligo giuridico, iscritto nel diritto primario, in un quadro di gestione del rischio di primo piano e in una norma internazionale di sistema di gestione. I benchmark sono il modo in cui quell’obbligo astratto si traduce in un numero che un revisore può leggere.

Articolo 15 del regolamento europeo sull’IA

L’articolo 15 del Regolamento (UE) 2024/1689 richiede che i sistemi di IA ad alto rischio siano progettati e sviluppati per raggiungere un livello appropriato di accuratezza, robustezza e cibersicurezza lungo l’intero ciclo di vita (riassunto ufficiale dell’articolo 15). Lo stesso articolo impone che i livelli di accuratezza e le metriche pertinenti siano dichiarati nelle istruzioni d’uso del sistema, dunque qualunque cifra scelta deve essere documentata e trasmessa a valle. L’articolo 13 rafforza la disciplina con obblighi più ampi di trasparenza verso i deployer. In concreto, il fornitore di un sistema ad alto rischio non può consegnare in silenzio senza dichiarare le metriche usate e i livelli raggiunti.

Articolo 55 e il Codice di buone pratiche GPAI

Per i modelli di IA di uso generale classificati a rischio sistemico, l’articolo 55 del regolamento europeo sull’IA aggiunge un obbligo esplicito di valutazione del modello, ivi compresa la conduzione e la documentazione di test adversariali. Il Codice di buone pratiche GPAI, su base volontaria e finalizzato sotto la guida dell’Ufficio europeo per l’IA, operazionalizza l’obbligo intorno a una cadenza ricorrente di valutazione con metodologia documentata. I benchmark, pubblici come interni, sono gli artefatti che soddisfano la metà documentaria dell’obbligo.

Funzione Measure del NIST AI RMF

Il quadro di gestione del rischio IA del NIST è organizzato in quattro funzioni: Govern, Map, Measure, Manage. La funzione Measure invoca espressamente strumenti quantitativi, qualitativi o di metodo misto per analizzare, valutare, fare benchmark e monitorare il rischio IA (NIST AI RMF Core). Sebbene NIST AI 100-1 sia volontario, la funzione Measure costituisce la sede testuale di ogni conversazione sui benchmark nella governance IA statunitense, e molte clausole di appalto federale vi fanno ormai esplicito riferimento.

Valutazione delle prestazioni in ISO/IEC 42001

ISO/IEC 42001, pubblicata nel dicembre 2023, è la prima norma di sistema di gestione per l’IA. Come ogni norma ISO di sistema di gestione, si fonda sul ciclo Plan-Do-Check-Act, e la valutazione delle prestazioni è una delle sue clausole nominate. I controlli dell’Allegato A operazionalizzano l’obbligo in requisiti puntuali lungo il ciclo di vita dell’IA, fra cui criteri di valutazione sia per i sistemi sviluppati internamente sia per quelli acquisiti da terzi. Per un’organizzazione che mira alla certificazione 42001, la domanda non è più se fare benchmark, soltanto quali benchmark accetterà il revisore.

Come leggere una classifica come la legge un regolatore

Il ‘segniamo 92,3 su MMLU’ di un fornitore appare preciso. Il numero è vero, il confronto è reale, eppure non dice quasi nulla di utile a un responsabile compliance fino a quando tre domande di sostanza restano senza risposta. Prima domanda: il benchmark è stato contaminato per quel modello? La maggior parte dei corpus di addestramento dei modelli di frontiera include grandi porzioni del web aperto, e la maggior parte dei benchmark pubblici vive sul web aperto. Un punteggio che supera nettamente lo stato dell’arte precedente su un benchmark in circolazione da anni merita scetticismo, non festeggiamenti. Seconda domanda: il comportamento misurato corrisponde al comportamento dispiegato? Un punteggio su un dataset statico, in lingua inglese e a scelta multipla non predice la performance sulle vostre trascrizioni di assistenza clienti, sulle vostre richieste giuridiche o sui vostri prompt di code review. I regolatori si interessano del sistema dispiegato, non del comunicato stampa. Terza domanda: quali sono versione, data e formato del prompt? I benchmark evolvono, i prompt vengono ritoccati, gli script di punteggio rivisti. Un 92,3 senza pin di versione è inverificabile. Per un dossier di valutazione della conformità ai sensi del regolamento europeo sull’IA, il numero di copertina è, nella migliore delle ipotesi, da nota a piè di pagina. Quel che conta è la metodologia: quale dataset di test, con quali controlli di contaminazione, valutato da chi, aggiornato con quale cadenza. Trattate ogni dichiarazione da classifica come un’ipotesi da verificare, non come un fatto da ricopiare.

Contaminazione dei benchmark e legge di Goodhart

La versione intellettualmente onesta della discussione sui benchmark nel 2026 parte dalla contaminazione. Si parla di contaminazione dei dati quando un modello è stato addestrato sul test split di un benchmark, sia deliberatamente perché si è deciso di ottimizzare per la classifica, sia accidentalmente perché il dataset del benchmark è finito in un crawl web che ha alimentato il pre-addestramento. Una volta che il modello ha memorizzato il test, il suo punteggio riflette memoria, non capacità (letteratura sulla contaminazione). Il problema di fondo è strutturale. I benchmark pubblici attraggono una pressione di ottimizzazione sostenuta: decine di laboratori, ogni trimestre, con miliardi di token di addestramento e budget consistenti. Si applica la legge di Goodhart: quando una misura diventa un obiettivo, smette di essere una buona misura. La saturazione di MMLU, dove i modelli di frontiera si raggruppano a pochi punti dal soffitto, è l’esempio più citato, ma lo schema si ripete in tutte le famiglie di benchmark. Più di recente, la letteratura ha documentato l’evaluation awareness: i grandi modelli sanno riconoscere quando un prompt sembra una valutazione invece di un’interazione di deployment, e la differenza di comportamento fra i due contesti non è trascurabile. Dal punto di vista della compliance significa che il punteggio misurato dalla vostra pipeline di valutazione può non essere il punteggio che il modello consegna realmente in produzione. L’implicazione è scomoda. Un punteggio di benchmark pubblico è un segnale fra molti, non una garanzia. Qualsiasi quadro GRC che trattasse un numero MMLU come prova di sicurezza, accuratezza o equità si assumerebbe un rischio metodologico che, messo per iscritto, non reggerebbe davanti a un’autorità. I benchmark dicono qualcosa. Non dicono abbastanza.

Costruire un benchmark interno che il vostro revisore accetterà

Se i benchmark pubblici non bastano, la mossa naturale è costruirne uno proprio. Un benchmark interno, progettato sui vostri casi d’uso reali, sui vostri dati reali e sui vostri rischi reali, è l’artefatto che colma lo scarto fra ranking di classifica e posizione di conformità difendibile. Un benchmark interno funzionante poggia su sei elementi. Primo, un perimetro ancorato a un caso d’uso: nominate il sistema, il contesto di deployment e il livello di rischio ai sensi del regolamento sull’IA (alto rischio, rischio limitato, rischio minimo) o l’equivalente dalla funzione Map del NIST AI RMF. Secondo, metriche ancorate a danni: accuratezza sui compiti che contano, tasso di rifiuto sui prompt che vanno rifiutati, tasso di allucinazione sulle richieste in cui l’allucinazione è pericolosa. L’accuratezza generica raramente è la metrica giusta da sola. Terzo, un dataset di test rappresentativo con provenienza documentata: da dove provengono i prompt, chi li ha selezionati, su quale traffico di produzione sono stati campionati, quali lingue coprono. Quarto, controlli di contaminazione: mantenete almeno uno split riservato che non lascia mai l’organizzazione, aggiornate la parte pubblica del dataset con cadenza pubblicata, marchiate quando possibile i prompt per rilevare leak. Quinto, uno script di punteggio versionato: i prompt evolvono, i modelli evolvono, le rubriche evolvono. Fissate ogni punteggio al modello esatto di prompt e al codice di valutazione esatto che lo ha prodotto. Sesto, criteri di accettazione cartografati nel dossier di conformità: il punteggio non deve essere perfetto, deve essere abbastanza alto da giustificare il deployment dato il livello di rischio. Documentate la soglia e la sua motivazione. Una piattaforma di gestione delle evidenze come AI Sigil tiene auditabile l’intera catena: la definizione del benchmark, lo storico dei punteggi, gli obblighi collegati a regolamento europeo sull’IA, NIST AI RMF o ISO 42001, e i file di prova (dataset di test, script di punteggio, log di esecuzione) richiamati dal dossier.

I benchmark da seguire davvero per la compliance

Per un’organizzazione che costruisce un portafoglio capace di soddisfare i regolatori restando intellettualmente onesta, la lista corta pratica è più corta di quanto suggeriscano le classifiche pubbliche.

Ogni voce di questa tabella va abbinata a un benchmark interno mirato al vostro deployment reale. Il numero pubblico è la calibratura; il numero interno è la prova.

Domande frequenti

I benchmark LLM sono affidabili? Sono affidabili per quel che misurano, ossia la prestazione sul dataset di test preciso secondo il protocollo preciso che definiscono. Sono poco affidabili come proxy del comportamento in produzione, in parte per contaminazione e overfitting, in parte perché i sistemi dispiegati affrontano una distribuzione di input molto più ampia di quanto qualsiasi benchmark statico copra. Trattateli come segnali da triangolare, non come verità di base. Le autorità europee si interessano dei punteggi MMLU? Non direttamente. L’articolo 15 del regolamento europeo sull’IA impone ai fornitori ad alto rischio di dichiarare i livelli di accuratezza e le metriche pertinenti nelle istruzioni d’uso. Un’autorità che esamini un dossier di valutazione della conformità vuole vedere una metodologia documentata, un dataset di test difendibile e criteri di accettazione collegati al profilo di rischio. Un numero MMLU può comparire nel dossier come elemento di prova, ma da solo non soddisfa l’obbligo. Un benchmark pubblico può dimostrare la conformità di un’IA? Nessun benchmark pubblico dimostra, da solo, la conformità al regolamento europeo sull’IA, al NIST AI RMF o alla ISO/IEC 42001. Ciascuno di questi quadri richiede una valutazione specifica al sistema, specifica al danno, ancorata al contesto di deployment. I benchmark pubblici sostengono il dossier; non lo sostituiscono. Dobbiamo costruirci un benchmark interno? Sì, se siete soggetti a uno dei principali quadri di governance IA. Un benchmark interno è l’unico modo per valutare il sistema su dati che assomigliano a quelli di produzione. Vi dà inoltre il controllo della contaminazione, impossibile per un benchmark pubblico il cui dataset di test vive sul web aperto. Il minimo viable consta di alcune centinaia di prompt rappresentativi, una rubrica di punteggio chiara e una cadenza di aggiornamento documentata. Che cos’è la contaminazione di benchmark? La contaminazione è la situazione in cui un modello è stato addestrato, direttamente o indirettamente, su dati provenienti dal dataset di test di un benchmark. Il punteggio riflette allora la memoria, non la capacità. La contaminazione è diffusa per i benchmark presenti da anni sul web pubblico, ed è la ragione principale per cui MMLU e i benchmark saturi analoghi sono oggi trattati con cautela. Che cosa dicono il Garante per la protezione dei dati personali e l’AgID? Né il Garante né l’AgID validano un particolare benchmark pubblico. La loro linea coincide con quella delle altre autorità europee: la documentazione della metodologia di valutazione, la tracciabilità dei dataset di test e l’adeguatezza delle metriche al contesto d’uso pesano più del punteggio dichiarato. Per il settore finanziario, Banca d’Italia segue l’orientamento delle autorità europee (in particolare EBA) sulla convalida dei modelli, sensibilmente più esigente di un punteggio pubblico. Quale benchmark deve documentare un team di compliance nel 2026? Documentate almeno un benchmark per ciascun asse di capacità rilevante per il vostro caso d’uso (conoscenza, ragionamento, codice, dialogo, veridicità, sicurezza), più un benchmark di allineamento regolatorio come AIR-Bench, più il vostro benchmark interno. Script di punteggio, provenienza del dataset di test e data di esecuzione vanno tutti archiviati come prove e collegati agli obblighi pertinenti del dossier di conformità.

Conclusione

I benchmark LLM hanno superato il loro ruolo iniziale di strumento di ricerca. Nel 2026 sono lo strumento operativo dietro ogni obbligo di valutazione del modello, dall’articolo 15 del regolamento europeo sull’IA alla funzione Measure del NIST AI RMF, alla clausola di valutazione delle prestazioni della ISO/IEC 42001. Sono al contempo imperfetti, manipolabili e spesso letti male. Una postura di compliance seria tratta i benchmark pubblici come calibratura, costruisce un benchmark interno come prova e documenta la metodologia con lo stesso rigore di ogni altro controllo. Chi costruisce un portafoglio simile farà bene a tenere definizioni, punteggi, prove e collegamenti agli obblighi in un’unica traccia auditabile, come quella offerta da una piattaforma di governance come AI Sigil.