Een gedeeld draaiboek voor betrouwbare evaluaties door derden

Onafhankelijke, vertrouwde evaluaties door derden spelen een kritieke rol⁠ bij het versterken van het veiligheidsecosysteem. Deze evaluaties worden uitgevoerd op frontier-modellen om aanvullend bewijs te leveren voor claims over kritieke capaciteiten en veiligheidsmaatregelen. In dit bericht delen we lessen die we tot nu toe hebben geleerd en bevelen we benaderingen aan voor het ontwerpen van evaluaties die frontier-modellen valide kunnen beoordelen, in de hoop zo bij te dragen aan opkomende standaarden in dit domein.

Voorheen werden modellen bij veel evaluaties als chatbots behandeld: de evaluatie gaf een model een prompt alsof het een gebruiker was die een vraag stelde, het model antwoordde en een evaluator beoordeelde de output. De frontier-modellen van vandaag kunnen veel meer: ze kunnen tools gebruiken, informatie over veel stappen heen bijhouden en handelen binnen een grotere workflow. Dit betekent dat prestaties niet alleen afhangen van het model, maar ook van de omgeving waarin de taak plaatsvindt en van de opzet die zijn handelingen mogelijk maakt. Deze omliggende opzet, die wij de 'harness' noemen, kan belangrijke aspecten van de prestaties van het systeem veranderen, waaronder hoe het tools gebruikt, informatie bijhoudt of herstelt van fouten.

Dit verandert hoe evaluaties moeten worden uitgevoerd en waar lezers op moeten letten in evaluatierapporten. Volgens ons beschrijven de nuttigste rapporten expliciet twee zaken naast het resultaat zelf: ten eerste welke claim de evaluatie-opzet moest testen, en ten tweede welk beschikbaar bewijs er is dat het evaluatieresultaat valide is.

Claims die in evaluaties worden getest, vallen doorgaans in een van drie categorieën¹:

• Capaciteitselicitatie: Kan een model de geëvalueerde capaciteit op geloofwaardige wijze vertonen? 
• Prestaties van safeguards: Hoe robuust zijn de geteste safeguards tegen het gedrag of de aanval die wordt geëvalueerd?
• Vergelijking: Hoe presteren verschillende modellen onder gelijkwaardige omstandigheden?

Evaluatierapporten moeten ook uitleggen hoe evaluatoren hebben gecontroleerd op effecten die de validiteit van een resultaat kunnen beïnvloeden. Daaronder vallen:

• Reward hacking: Misbruik maken van sluiproutes in de taak of scoremethode, zodat het systeem punten krijgt zonder het gedrag te tonen dat de evaluatie probeert te meten.
• Weigeringen: Weigeren op manieren die het geteste gedrag verhullen.
• Contaminatie: Beter presteren omdat evaluatietaken, antwoorden of sterk gelijkende varianten in trainingsdata voorkwamen of tijdens de evaluatie vindbaar waren, bijvoorbeeld via browsen.
• Defecte problemen: Slechter presteren omdat taken ongeldig zijn. Redenen kunnen onder meer oneerlijke scoring zijn (bijv. als het juiste antwoord niet-gespecificeerde implementatiedetails vereist) en onoplosbare omgevingen (bijv. ontbrekende kritieke bestanden of onbetrouwbare tools).
• Sandbagging: Opzettelijk onderpresteren zodra het model weet dat het geëvalueerd wordt.

We hebben vastgesteld dat de rol van de harness vooral belangrijk is voor systemen die over langere trajecten handelen. Wanneer modellen tools kunnen gebruiken, status kunnen bijhouden en over een groot aantal stappen van fouten kunnen herstellen, kan de harness het waargenomen prestatieniveau veranderen en zelfs bepalen of de beoordeelde capaciteit überhaupt in de evaluatie zichtbaar wordt. Een harness die de status bewaart en mislukte acties opnieuw probeert, kan er bijvoorbeeld voor zorgen dat een model een taak met meerdere stappen afrondt die hetzelfde model in een eenvoudigere harness nooit voltooit.

In de onderstaande tabel onderscheiden we drie soorten claims die evaluatoren mogelijk willen doen en de harness die volgens ons voor elk type claim nodig is.

Capaciteitsclaims zijn slechts zo sterk als de elicitatie die eraan voorafgaat: evaluatoren moeten de harness kiezen die het best past bij de taak en de capaciteit die de evaluatie probeert te meten. Een gestandaardiseerde harness kan geschikt zijn om systemen onder identieke omstandigheden te vergelijken, maar kan capaciteit onderschatten wanneer specifieke harness-functies ontbreken die het model helpen de taak uit te voeren. De prestaties van GPT‑5.5 op OpenAI’s cyberranges laten bijvoorbeeld zien hoe een harness-keuze de gemeten capaciteit wezenlijk kan veranderen bij taken die langdurig, meerstaps toolgebruik vereisen: het model presteert beter wanneer de harness compaction⁠ gebruikt om taakrelevante context te behouden naarmate de interactie langer wordt. Dit laat zien dat voor bepaalde modellen een harness zonder compaction de prestaties onvoldoende uitlokt.

Andere gepubliceerde evaluaties² laten ook zien dat keuzes voor harness en budget evaluatieresultaten veranderen. Het verhogen van de rekenkracht tijdens de testfase kan aanzienlijk veranderen welke capaciteit een evaluatie uitlokt, vooral in domeinen waar succes eenvoudig te verifiëren is, zoals veel cybertaken. In de cyberrange-evaluatie van UK AISI⁠(opent in een nieuw venster) verbeterde het verhogen van het budget van 10M naar 100M tokens de prestaties met tot wel 59%, en de prestaties stegen nog steeds bij het hoogste geteste budget. Het vermelden van deze details maakt de evaluatie beter interpreteerbaar: het laat lezers zien hoe het resultaat afhangt van de geteste elicitatie-opzet. Wanneer prestaties nog steeds verbeteren met extra budget, moet de score worden beschreven als prestatie onder die harness en dat budget, niet als een gemeten bovengrens van capaciteit. Capaciteit is vaak afhankelijk van middelen in plaats van een een vaste grootheid die eens en voor altijd nauwkeurig kan worden gemeten. Waar succes over herhaalde pogingen kan worden gemeten, moeten rapporten ook kijken naar de verwachte kosten per succesvolle oplossing, niet alleen naar het succespercentage bij een vast tokenbudget. Dit kan de ernst van makkelijker interpreteerbaar maken: een laag succespercentage kan in de praktijk nog steeds betekenisvol zijn als de kosten van herhaalde pogingen binnen het relevante dreigingsmodel vallen. Voor capaciteitsclaims is vermijdbare onder-elicitatie een meetfout: als de harness of het budget verhindert dat het systeem gedrag vertoont dat het anders zou kunnen produceren, meet de score niet de geclaimde capaciteit. Waar evaluatoren elicitatie zo ver hebben doorgevoerd als haalbaar is en de prestaties nog steeds verbeteren, moeten rapporten dat duidelijk vermelden en duidelijk maken dat het resultaat slechts een ondergrensschatting is.

Het testen van safeguards kan onderschatten of een aanval kan slagen, en hoe ernstig die kan zijn, wanneer geen rekening wordt gehouden met de middelen die aanvallers beschikbaar hebben, waaronder aangepaste harnesses. In de GPT‑5.5‑cyberevaluatie van UK AISI⁠(opent in een nieuw venster) vond hun expert-red-teaming een universele jailbreak die overtredende cybercontent uitlokte bij de kwaadaardige query's die OpenAI had aangeleverd, ook in meervoudige interactierondes binnen agentische systemen. Ze gebruikten Codex om een aangepaste harness te maken om de aanvalsprestaties van het model te versterken: die bouwde een herbruikbaar patroon voor het omzeilen van safeguards in de interactie in, behield dat patroon over beurten en blokken heen en paste het toe op de kwaadaardige cyberquery's die OpenAI had aangeleverd. Het testen van safeguards moet aansluiten bij de tegenstander. Als de claim gaat over robuustheid tegen misbruik door experts, moet de test de sterkste geloofwaardige end-to-end-aanvalsstrategie onder een gedefinieerd budget evalueren, inclusief elke harness die nodig is om die strategie te behouden en te hergebruiken. Anders lopen de resultaten het risico slecht gekalibreerd te zijn: ze kunnen slechts een beperktere claim ondersteunen over weerstand tegen eenvoudigere prompting, kunnen missen hoe ernstig de aanval wordt en hoe groot de kans op succes is zodra de elicitatiemethode is geoperationaliseerd, en kunnen ook overschatten hoe waarschijnlijk of ernstig een probleem is als er te veel budget wordt gegeven.

Er is een tijd en plaats voor vergelijkingen met gestandaardiseerde harnesses, maar evaluatoren moeten expliciet zijn over waarom het gebruik van een consistente set harnesses passend is en welke claim die kan ondersteunen. De tijdshorizon-evaluatie van METR⁠(opent in een nieuw venster) is een voorbeeld van een bredere, voor dit doel terecht vastgelegde evaluatie-opzet: die is ontworpen om vergelijkbare resultaten op te leveren voor de systemen die zij evalueert. METR definieert een gemeenschappelijke uitkomst: de typische duur van een menselijke taak waarbij wordt voorspeld dat een AI-agent met een gegeven betrouwbaarheidsniveau zal slagen. Binnen elke batch van samen gerapporteerde schattingen past METR een gedeelde taaksuite, scoremethode, fitmethode en een kleine set herbruikbare scaffolds toe, zoals Triframe en ReAct⁠(opent in een nieuw venster). Toen METR de taaksuite uitbreidde en de evaluatie-infrastructuur verplaatste van een framework genaamd Vivaria naar een framework genaamd Inspect, rapporteerde het die verandering (Time Horizon 1.1-update⁠(opent in een nieuw venster)) en evalueerde het modellen opnieuw onder de nieuwe evaluatie-opzet. Dat is de waarde van een gestandaardiseerde evaluatie-opzet, inclusief een consistente set harnesses: lezers kunnen erop vertrouwen dat een verschil in scores echt een verschil tussen de vergeleken systemen weerspiegelt, en niet een verandering in de meetopzet.

We raden aan dat evaluatierapporten van derden vermelden welk soort claim hun evaluatie-opzet moet ondersteunen; beschrijven in hoeverre de uitgevoerde test die bredere claim weerspiegelt; de harness-keuzes beschrijven die het resultaat hebben gevormd; toelichten wanneer die keuzes tussen evaluaties veranderen; en ondersteunend bewijs opnemen om te laten zien hoe het resultaat tot stand kwam en in hoeverre dit te generaliseren valt naar de claim.

Naarmate modellen capabeler worden, worden evaluatiescores makkelijker verkeerd geïnterpreteerd. Ten opzichte van werkelijke capaciteiten kunnen evaluatiescores kunstmatig lager uitvallen als een model herkent dat het wordt geëvalueerd en strategisch onderpresteert. Ze kunnen hoger uitvallen als het model een sluiproute in de taak, prompt, scoring of harness uitbuit. Ze kunnen ook worden vertekend door contaminatie (waarbij een model een antwoord al kent of kan vinden zonder de taak op te lossen) of door 'defecte' problemen die ambigu, onjuist gescoord, onoplosbaar of kwetsbaar voor onbedoelde sluiproutes zijn. Evaluatierapporten moeten hoofdscores daarom combineren met een bespreking van deze risico’s, zodat lezers kunnen beoordelen of de scores het bedoelde gedrag weerspiegelen.

Harnesses, budgetten, tools, scoringsregels, monitors en beoordelingsprocedures beïnvloeden allemaal of een agent de bedoelde taak oplost, die vermijdt, uit het hoofd kent of er een weg omheen vindt. Een betrouwbaar rapport maakt die controles zichtbaar: evaluatoren zouden bij elke evaluatie steekproeven moeten controleren op dit soort gedrag.

Reward hacking

Reward hacking betekent hoge evaluatiescores behalen op manieren die de bedoelde capaciteit niet weerspiegelen. Hier is de zorg dat het systeem punten krijgt door de taak, scoremethode, prompt of harness uit te buiten in plaats van het werk te doen dat de evaluatie bedoeld was te meten. De evaluatie van GPT 5.4 door METR⁠(opent in een nieuw venster) laat zien waarom dit ertoe doet: hoewel het model taken voltooide met een succespercentage dat op het eerste gezicht zou duiden op een tijdshorizon van ongeveer 13 uur, liet menselijke beoordeling zien dat sommige van die successen voortkwamen uit reward hacking. Na herziening van de resultaten zodat alleen gevallen zonder reward hacking meetelden daalde de schatting tot ongeveer 6 uur. Evaluatoren moeten beoordelen of zulke aanpassingen nodig zijn en, als dat zo is, die duidelijk rapporteren: een capaciteitsinschatting is veel nuttiger wanneer lezers kunnen zien welke schijnbare successen zijn afgekeurd, waarom dat gebeurde en in welke mate het resultaat van dat oordeel afhangt.

Weigeringen

Modellen kunnen ook slechter presteren in capaciteitsevaluaties door safeguards. Een model kan in een evaluatie onder zijn werkelijke niveau presteren, doordat het evaluatietaken weigert in plaats van ze te voltooien. Rapporten moeten daarom uitleggen of weigeringen deel uitmaakten van de evaluatieresultaten en zo ja, hoeveel testgevallen daardoor zijn aangetast.

Contaminatie

Contaminatie is vooral belangrijk bij openbare of hergebruikte benchmarks⁠. Als taken, antwoorden of nauwe varianten in trainingsdata voorkomen of door een agent met browsefunctie kunnen worden gevonden, kunnen prestaties memorisatie of retrieval weerspiegelen in plaats van modelprestaties. Evaluatoren moeten waar mogelijk de voorkeur geven aan niet-openbare of nieuw geconstrueerde taken en testen of modellen taakspecifieke details reproduceren voordat ze aan de oplossing beginnen.

Defecte problemen

Defecte problemen omvatten situaties zoals een probleem dat per ongeluk niet kan worden opgelost. Defecte problemen komen vaak genoeg voor⁠(opent in een nieuw venster) om als een standaard validiteitsrisico te worden behandeld. Daaronder vallen onjuiste ground truth, dubbelzinnige prompts, ontbrekende bestanden, instabiele services, oneerlijke scorecriteria en omgevingen die sluiproutes blootleggen, zoals verborgen antwoordbestanden of repository-geschiedenis met de ground-truth-patch.

Sandbagging

Sandbagging door een model of systeem betekent strategisch onderpresteren wanneer sterke prestaties in strijd zouden zijn met een bepaald doel. De GPT‑5.5‑evaluatie⁠(opent in een nieuw venster) van Apollo testte dit door een context te creëren waarin het model begreep dat hoge evaluatiescores het actief wissen van kennis (unlearning) konden triggeren of de uitrol konden blokkeren. GPT‑5.5 gaf nog steeds correcte antwoorden, wat wijst op weinig gedragsmatig bewijs voor strategisch onderpresteren³. Maar hun beoordeling van redeneringssporen voegde belangrijke context toe: Apollo vond in 52% van de voorbeelden onder sandbagging-condities matige of sterkere signalen van alignment-evaluatiebewustzijn, vergeleken met 0% in controle-scenario's. Dat bewijs maakt de interpretatie van het resultaat complexer, maar geeft lezers uiteindelijk een duidelijker signaal: ze zien zowel het geruststellende gedragsresultaat als de reden om voorzichtig te zijn met overinterpretatie.

Sterke claims vereisen zowel de juiste harness om het gedrag uit te lokken als validiteitscontroles om te laten zien dat het resultaat deugdelijk is. Onze opvatting dat harnesses en validiteitscontroles deel uitmaken van het evaluatieresultaat bepaalt hoe wij evaluaties door derden in de praktijk ondersteunen: 

• We delen specifieke richtlijnen voor maximale elicitatie met evaluatoren.
• We vragen capaciteitsevaluatoren om Codex te gebruiken als gemeenschappelijke ondergrens voor OpenAI-modellen: tests moeten op zijn minst een nulmeting uitvoeren via dezelfde agentische interface waarop gebruikers waarschijnlijk zullen vertrouwen, en niet alleen via een uitgeklede modelinterface.
• We stellen ook redeneringssporen en andere tussentijdse artefacten beschikbaar waar die nodig zijn om misleiding, sandbagging of evaluatiebewustzijn te beoordelen. METR en Apollo maken sinds GPT‑5 al gebruik van deze toegang bij OpenAI-evaluaties. 
• Tot slot geven we prioriteit aan onderzoek om dieper te begrijpen wanneer en hoe keuzes voor harnesses resultaten wezenlijk veranderen, van contextbeheer en tooltoegang tot gedrag bij herhaalpogingen, scoremethodes en beschikbare budgetten.

Deze aanbevelingen zijn niet alleen bedoeld om individuele evaluatierapporten te verbeteren, maar ook om opkomende nationale ⁠(opent in een nieuw venster)en internationale ⁠(opent in een nieuw venster)standaarden voor evaluatie en rapportage van frontier-AI te helpen vormgeven. In de toekomst moeten standaarden voor evaluaties door derden voldoende details voorschrijven zodat besluitvormers kunnen begrijpen welke claims de specifieke evaluaties ondersteunen, welk systeem is getest, hoe het resultaat is uitgelokt en hoe evaluatoren de validiteit ervan hebben gecontroleerd. Voor frontier-systemen die worden getest op taken waarbij agentische capaciteiten ertoe doen, moeten details het volgende omvatten (behoudens eventuele veiligheids- of vertrouwelijkheidszorgen):

• De claim: of de evaluatie systemen vergelijkt, de bovengrens van een capaciteit inschat of safeguards test.
• Evaluatie-inhoud: voldoende details over de taken of taakverdeling zodat lezers begrijpen welke vaardigheden, gedragingen of faalmechanismen de evaluatie daadwerkelijk test.
• Het geteste systeem: het model, de redeneringsinstelling, tooltoegang, harness en safeguards.
• Het budget: turns, tokens, pogingen/herhaalpogingen, doorlooptijd, inferentiekosten en, waar van toepassing, de verwachte kosten per succesvolle oplossing.
• Elicitatiemethoden: harness-keuzes die zijn gebruikt om het resultaat uit te lokken, en in hoeverre de uitgevoerde test aansluit bij de bredere claim die wordt gemaakt.
• Validiteitscontroles: hoe beoordelaars hebben gecontroleerd op reward hacking, evaluatiebewustzijn, contaminatie, weigeringen, sandbagging en ander gedrag dat het resultaat zou kunnen ondermijnen, inclusief de invloed van bevestigde gevallen op de scoremethode of de interpretatie.

Standaarden die keuzes voor harnesses of validiteitscontroles weglaten, kunnen onderschatten wat een systeem kan doen of het vertrouwen in een veiligheidsclaim overschatten. Het bouwen van sterke harnesses en elicitatiemethoden blijft een open onderzoeksgebied en zou een aandachtspunt moeten zijn voor verder onderzoek en investeringen.