Un playbook condiviso per valutazioni affidabili di terze parti

Valutazioni indipendenti e affidabili di terze parti svolgono un ruolo critico⁠ nel rafforzare l’ecosistema della sicurezza. Queste valutazioni vengono condotte su modelli di frontiera per fornire ulteriori prove a sostegno di affermazioni su capacità critiche e mitigazioni di sicurezza. In questo articolo condividiamo le lezioni apprese finora e raccomandiamo approcci per progettare valutazioni che possano misurare validamente i modelli di frontiera, nella speranza che contribuiscano a informare gli standard emergenti nel settore.

In passato, molte valutazioni trattavano i modelli come chatbot: la valutazione sottoponeva un prompt a un modello come se fosse un utente che pone una domanda, il modello rispondeva e un valutatore giudicava l’output. I modelli di frontiera di oggi possono fare molto di più: possono usare strumenti, tenere traccia delle informazioni attraverso molti passaggi e agire all’interno di un flusso di lavoro più ampio. Questo significa che la prestazione dipende non solo dal modello, ma anche dall’ambiente in cui si svolge l'attività e dalla configurazione che ne facilita le azioni. Questa configurazione circostante, che chiamiamo “harness”, può cambiare aspetti chiave della prestazione del sistema, incluso il modo in cui usa gli strumenti, tiene traccia delle informazioni o si riprende dagli errori.

Questo cambia il modo in cui le valutazioni devono essere condotte e ciò che i lettori dovrebbero cercare nei report di valutazione. A nostro avviso, i report più utili descrivono esplicitamente due aspetti oltre al risultato stesso: primo, specificano quale affermazione la configurazione di valutazione è stata progettata per testare e, secondo, condividono le prove disponibili a sostegno della validità del risultato.

Le affermazioni testate nelle valutazioni rientrano in genere in una di tre categorie¹:

• Elicitazione della capacità: un modello può plausibilmente produrre la capacità oggetto della valutazione? 
• Prestazione delle salvaguardie: quanto sono robuste le salvaguardie testate rispetto al comportamento o all’attacco oggetto della valutazione?
• Confronto: come si comportano modelli diversi in condizioni equivalenti?

I report di valutazione devono anche spiegare come i valutatori hanno verificato gli effetti che potrebbero incidere sulla validità di un risultato. Tra questi rientrano:

• Reward hacking: sfruttare scorciatoie nell'attività o nel sistema di scoring, così che il sistema ottenga credito senza dimostrare il comportamento che la valutazione intende misurare.
• Rifiuti: rifiutare in modi che oscurano il comportamento oggetto del test.
• Contaminazione: prestazioni superiori al reale perché attività di valutazione, risposte o varianti simili erano presenti nei dati di addestramento o erano reperibili durante la valutazione, ad esempio tramite la navigazione web.
• Problemi difettosi: sottoperformance perché le attività non sono valide. Le ragioni possono includere scoring ingiusto (ad es. la risposta corretta richiede dettagli di implementazione non dichiarati) e ambienti irrisolvibili (ad es. file critici mancanti o strumenti inaffidabili).
• Sandbagging: sottoperformare deliberatamente quando mostrano consapevolezza di essere valutati.

Abbiamo osservato che il ruolo dell’harness è particolarmente importante per i sistemi che agiscono su traiettorie più lunghe. Quando i modelli possono usare strumenti, mantenere lo stato e recuperare dagli errori attraverso molti passaggi, l’harness può cambiare il livello di prestazione osservato e persino determinare se la capacità oggetto della valutazione compaia o meno nella valutazione stessa. Per esempio, un harness che preserva lo stato e ritenta le azioni fallite può consentire a un modello di completare un'attività in più fasi che lo stesso modello non completerebbe mai in un harness più semplice.

Nella tabella seguente distinguiamo tre tipi di affermazioni che i valutatori potrebbero voler formulare e l’harness che riteniamo ciascun tipo richieda.

Le affermazioni sulle capacità sono solide solo quanto l’elicitazione che le sostiene: i valutatori devono scegliere l’harness più adatto all'attività e alla capacità che la valutazione cerca di misurare. Un harness standardizzato può essere appropriato per confrontare sistemi in condizioni identiche, ma può sottostimare la capacità quando omette specifiche funzionalità dell’harness che aiutano il modello a svolgere l'attività. Per esempio, la prestazione di GPT‑5.5 sui cyber range di OpenAI mostra come la scelta dell’harness possa cambiare materialmente la capacità misurata in attività che richiedono un uso prolungato e multi-step degli strumenti: il modello ottiene risultati migliori quando l’harness usa compaction⁠ per preservare il contesto rilevante per l'attività man mano che l’interazione si allunga. Questo dimostra che, per alcuni modelli, un harness che omette la compaction farebbe emergere una prestazione inferiore a quella reale.

Anche altre valutazioni pubblicate² mostrano che le scelte relative a harness e budget cambiano i risultati delle valutazioni. Aumentare il calcolo in fase di test può cambiare in modo significativo quale capacità una valutazione riesce a elicitarе, soprattutto in domini in cui il successo è facile da verificare, come molte attività cyber. Nella valutazione dei cyber range di UK AISI⁠(si apre in una nuova finestra), aumentare il budget da 10M a 100M token ha migliorato la prestazione fino al 59%, e la prestazione continuava ancora a crescere al budget più alto testato. Esplicitare questo aspetto rende la valutazione più interpretabile: mostra ai lettori come il risultato dipenda dalla configurazione di elicitazione testata. Quando la prestazione continua a migliorare con budget aggiuntivo, il punteggio dovrebbe essere descritto come prestazione sotto quell’harness e quel budget, non come un tetto di capacità misurato. La capacità dipende spesso dalle risorse, più che essere una quantità fissa misurabile una volta per tutte. Laddove il successo possa essere misurato su tentativi ripetuti, i report dovrebbero considerare anche il costo atteso per ogni soluzione riuscita, non solo il tasso di successo a un budget fisso di token. Questo può rendere più facile interpretare la gravità: un basso tasso di successo può comunque essere praticamente significativo se il costo dei tentativi ripetuti rientra nel modello di minaccia rilevante. Per le affermazioni sulle capacità, una sotto-elicitazione evitabile è un fallimento di misurazione: se l’harness o il budget impediscono al sistema di mostrare un comportamento che altrimenti potrebbe produrre, il punteggio non misura la capacità dichiarata. Quando i valutatori hanno spinto l’elicitazione quanto più possibile e la prestazione continua comunque a migliorare, i report dovrebbero dirlo chiaramente e chiarire che il risultato è solo una stima del limite inferiore.

I test delle salvaguardie possono sottostimare se un attacco possa avere successo e quanto potrebbe essere grave, se non tengono conto delle risorse disponibili agli attaccanti, inclusi harness personalizzati. Nella valutazione cyber di GPT‑5.5 di UK AISI⁠(si apre in una nuova finestra), il loro red teaming esperto ha trovato un jailbreak universale che ha fatto emergere contenuti cyber in violazione su tutte le query malevole fornite da OpenAI, anche in contesti agentici multi-turno. Hanno usato Codex per creare un harness personalizzato volto a rafforzare la prestazione d’attacco del modello: incorporava nell’interazione uno schema riutilizzabile di aggiramento delle salvaguardie, lo preservava tra turni e blocchi e lo applicava alle query cyber malevole fornite da OpenAI. I test delle salvaguardie dovrebbero corrispondere all’avversario. Se l’affermazione riguarda la robustezza rispetto a un uso improprio da parte di esperti, il test dovrebbe valutare la strategia di attacco end-to-end credibile più forte entro un budget definito, incluso qualsiasi harness necessario a preservare e riutilizzare tale strategia. In caso contrario, i risultati rischiano di essere mal calibrati: potrebbero supportare solo un’affermazione più ristretta sulla resistenza a prompt più semplici, potrebbero non cogliere né quanto l’attacco diventi grave né la sua probabilità di successo una volta operativizzato il metodo di elicitazione, e potrebbero anche sopravvalutare la probabilità o la gravità di un problema se viene concesso troppo budget.

Esiste un momento e un contesto per i confronti con harness standardizzati, ma i valutatori dovrebbero essere espliciti sul perché sia appropriato usare un insieme coerente di harness e su quale affermazione ciò possa supportare. La valutazione dell’orizzonte temporale di METR⁠(si apre in una nuova finestra) è un esempio di configurazione di valutazione più ampia e opportunamente fissa: è progettata per produrre risultati comparabili tra i sistemi che valuta. METR definisce un esito comune, la durata tipica di un'attività umana alla quale si prevede che un agente IA abbia successo a un dato livello di affidabilità. Applica una suite condivisa di attività, un metodo di scoring, un metodo di fitting e un piccolo insieme di scaffold riutilizzabili come Triframe e ReAct⁠(si apre in una nuova finestra) all’interno di ciascun gruppo di stime riportate insieme. Quando METR ha ampliato la suite di attività e spostato l’infrastruttura di valutazione da un framework chiamato Vivaria a uno chiamato Inspect, ha riportato il cambiamento (aggiornamento Time Horizon 1.1⁠(si apre in una nuova finestra)) e ha rivalutato i modelli nella nuova configurazione di valutazione. Questo è il valore di una configurazione di valutazione standardizzata, incluso un insieme coerente di harness: può dare ai lettori fiducia che una differenza nei punteggi rifletta davvero una differenza tra i sistemi confrontati, piuttosto che un cambiamento nella configurazione di misurazione.

Raccomandiamo che i report di valutazione di terze parti indichino quale tipo di affermazione la loro configurazione di valutazione intende supportare; descrivano quanto strettamente ciò che è stato testato rifletta quell’affermazione più ampia; descrivano le scelte di harness che hanno plasmato il risultato; specifichino quando tali scelte cambiano tra valutazioni; e includano prove di supporto per mostrare come il risultato è stato prodotto e quanto bene si generalizza all’affermazione.

Man mano che i modelli diventano più capaci, i punteggi delle valutazioni diventano più facili da interpretare in modo errato. Rispetto alle capacità reali, i punteggi di valutazione possono essere artificialmente ridotti se un modello riconosce di essere valutato e sottoperforma strategicamente. Possono essere gonfiati se il modello sfrutta una scorciatoia nell'attività, nel prompt, nel sistema di scoring o nell’harness. Possono anche essere distorti dalla contaminazione (quando un modello conosce già o può trovare una risposta senza completare l'attività) o da problemi “difettosi” che sono ambigui, valutati in modo errato, irrisolvibili o vulnerabili a scorciatoie indesiderate. I report di valutazione dovrebbero quindi affiancare ai punteggi principali una discussione di questi rischi, così che i lettori possano valutare se i punteggi riflettano il comportamento previsto.

Harness, budget, strumenti, regole di scoring, monitor e procedure di revisione influenzano tutti se un agente stia risolvendo l'attività prevista, evitandola, memorizzandola o trovando un modo per aggirarla. Un report affidabile rende visibili questi controlli: i valutatori dovrebbero esaminare campioni di questi comportamenti ogni volta che viene eseguita una valutazione complessiva.

Reward hacking

Per reward hacking si intende ottenere punteggi elevati nella valutazione in modi che non riflettono la capacità prevista. Qui la preoccupazione è che il sistema ottenga credito sfruttando l'attività, il sistema di scoring, il prompt o l’harness invece di svolgere il lavoro che la valutazione intendeva misurare. La valutazione di GPT 5.4 di METR⁠(si apre in una nuova finestra) mostra perché questo conta: nonostante il modello riuscisse nelle attività con una frequenza che a prima vista avrebbe corrisposto a un orizzonte temporale di circa 13 ore, la revisione umana ha mostrato che alcuni di quei successi derivavano da reward hacking, e la revisione dei risultati per considerare solo i casi senza reward hacking ha abbassato la stima a circa 6 ore. I valutatori dovrebbero verificare la necessità di tali aggiustamenti e, quando servono, riportarli chiaramente: una stima della capacità è molto più utile quando i lettori possono vedere quali successi apparenti sono stati squalificati, perché lo sono stati e quanto il risultato dipenda da quel giudizio.

Rifiuti

I modelli possono anche sottoperformare nelle valutazioni di capacità a causa delle salvaguardie. Un modello può avere una prestazione di valutazione inferiore a quella di cui è capace perché rifiuta le attività di valutazione invece di completarle. I report dovrebbero quindi spiegare se i rifiuti hanno fatto parte dei risultati della valutazione e, in caso affermativo, quanti campioni ne sono stati compromessi.

Contaminazione

La contaminazione conta soprattutto per i benchmark pubblici o riutilizzati⁠. Se attività, risposte o varianti simili compaiono nei dati di addestramento o possono essere trovati da un agente con capacità di navigazione, la prestazione può riflettere memorizzazione o recupero invece della prestazione del modello. I valutatori dovrebbero preferire, ove possibile, attività private o costruite di recente e verificare se i modelli riproducono dettagli specifici dell'attività prima di risolverla.

Problemi difettosi

I problemi difettosi includono situazioni come un problema che accidentalmente non può essere risolto. I problemi difettosi sono abbastanza comuni⁠(si apre in una nuova finestra) da dover essere trattati come un rischio standard per la validità. Includono ground truth errata, prompt ambigui, file mancanti, servizi instabili, criteri di scoring ingiusti e ambienti che espongono scorciatoie come file di risposta nascosti o cronologia del repository contenente la patch di ground truth.

Sandbagging

Il sandbagging da parte di un modello o sistema significa sottoperformare strategicamente quando una prestazione elevata entrerebbe in conflitto con qualche obiettivo. La valutazione di GPT‑5.5 di Apollo⁠(si apre in una nuova finestra) ha testato questo creando un contesto in cui il modello capiva che punteggi elevati nella valutazione avrebbero potuto attivare un unlearning o bloccare il deployment. GPT‑5.5 ha comunque risposto correttamente, suggerendo poche evidenze comportamentali di sottoperformance strategica³. Ma la loro revisione delle tracce di ragionamento ha aggiunto un contesto importante: Apollo ha riscontrato segnali moderati o superiori di consapevolezza della valutazione di allineamento nel 52% dei campioni in condizione di sandbagging, rispetto allo 0% nei controfattuali. Queste prove complicano l’interpretazione del risultato, ma alla fine forniscono ai lettori più segnali: possono vedere sia il rassicurante risultato comportamentale sia il motivo per essere cauti nel sovrainterpretarlo.

Affermazioni forti richiedono sia l’harness giusto per elicitarne il comportamento sia controlli di validità che mostrino che il risultato è solido. La nostra visione, secondo cui harness e controlli di validità fanno parte del risultato della valutazione, orienta il modo in cui supportiamo nella pratica le valutazioni di terze parti: 

• Stiamo condividendo con i valutatori indicazioni specifiche per l’elicitazione massima.
• Stiamo chiedendo ai valutatori delle capacità di usare Codex come base comune minima per i modelli OpenAI: i test dovrebbero almeno eseguire una baseline tramite la stessa interfaccia agentica su cui gli utenti probabilmente faranno affidamento, invece che solo tramite un’interfaccia del modello ridotta all’essenziale.
• Stiamo anche rendendo disponibili, dove necessario per valutare inganno, sandbagging o consapevolezza della valutazione, le tracce di ragionamento e altri artefatti intermedi. METR e Apollo hanno usato questo accesso nelle valutazioni OpenAI sin da GPT‑5. 
• Infine, stiamo dando priorità alla ricerca per comprendere più a fondo quando e come le scelte dell’harness cambino materialmente i risultati, dalla gestione del contesto e dall’accesso agli strumenti fino al comportamento di retry, allo scoring e ai budget di risorse.

Queste raccomandazioni mirano non solo a migliorare i singoli report di valutazione, ma anche a informare gli standard emergenti nazionali ⁠(si apre in una nuova finestra)e internazionali ⁠(si apre in una nuova finestra)per la valutazione e il reporting dell’IA di frontiera. In futuro, gli standard per le valutazioni di terze parti dovrebbero richiedere dettagli sufficienti affinché i decisori possano capire quali affermazioni le specifiche valutazioni supportano, quale sistema è stato testato, come il risultato è stato elicitato e come i valutatori ne hanno verificato la validità. Per i sistemi di frontiera testati su attività in cui le capacità agentiche contano, i dettagli dovrebbero includere (fatte salve eventuali esigenze di sicurezza o riservatezza):

• L’affermazione: se la valutazione confronta sistemi, stima un tetto di capacità o testa le salvaguardie.
• Contenuto della valutazione: dettagli sufficienti sulle attività o sulla distribuzione delle attività perché i lettori capiscano quali abilità, comportamenti o modalità di fallimento la valutazione stia effettivamente testando.
• Il sistema testato: il modello, l’impostazione di ragionamento, l’accesso agli strumenti, l’harness e le salvaguardie.
• Il budget: turni, token, tentativi/retry, tempo di esecuzione reale, costo di inferenza e, ove applicabile, costo atteso per ogni soluzione riuscita.
• Metodi di elicitazione: le scelte di harness usate per far emergere il risultato e quanto strettamente ciò che è stato testato rifletta l’affermazione più ampia formulata.
• Controlli di validità: come i valutatori hanno verificato la presenza di reward hacking, consapevolezza della valutazione, contaminazione, rifiuti, sandbagging e altri comportamenti che potrebbero compromettere il risultato, incluso come i casi confermati abbiano influito sullo scoring o sull’interpretazione.

Standard che omettono le scelte di harness o i controlli di validità possono sottostimare ciò che un sistema può fare o sopravvalutare la fiducia in un’affermazione di sicurezza. La costruzione di harness solidi e metodi di elicitazione resta un’area di ricerca aperta e dovrebbe essere al centro di ulteriori indagini e investimenti.