Een benchmark is nooit slechts een meetlat — waarom AI-evaluatie een verborgen theorie bevat over wat het model zou moeten kunnen

Stel: je koopt een AI-systeem omdat het in de top-3 staat op een gerenommeerde benchmark. De vendor levert een model card met indrukwekkende scores. Je procurement-team is tevreden, je CISO geeft groen licht, en het systeem gaat live in een hoog-risico proces.

Drie maanden later blijkt het systeem structureel te falen in precies de situaties waar je het voor kocht. Niet omdat het model "slecht" is — maar omdat de benchmark iets anders mat dan wat jij dacht te kopen.

Dit is geen hypothetisch scenario. Het is precies het mechanisme dat Theodore J. Kalaitzidis van Brown University beschrijft in The Evaluation Trap: Benchmark Design as Theoretical Commitment (arXiv:2605.14167, 13 mei 2026). En het raakt aan de fundamenten van AI-governance.

De evaluation trap: drie mechanismen die benchmarks onbetrouwbaar maken

Kalaitzidis' centrale these is even elegant als ontwrichtend: elke AI-benchmark bevat impliciete theoretische aannames over wat de capability die hij claimt te meten überhaupt ís. Een benchmark is nooit een neutrale meetlat — het is altijd een theorie in vermomming.

Het mechanisme werkt via drie lagen:

1. De transferability assumption. De aanname dat benchmarkprestatie overdraagbaar is naar de bredere capability. Je model scoort 95% op een reasoning-benchmark, dus je concludeert dat het model redeneert. Maar wat als de benchmark alleen patroonherkenning meet, of testset-adaptatie, of distributionele generalisatie? Dan heb je output gemeten — geen mechanisme.

2. Het circularity problem. Omdat benchmarkscores de dominante indicator van vooruitgang worden, gaan architecturen, datasets en trainingstrategieën zich richten op wat de benchmark zichtbaar maakt. De benchmark wordt niet alleen evaluatie-instrument, maar ontwerpcriterium. Het veld bouwt systemen die passen bij de meetlat — en noemt dat capability-progress. Kalaitzidis onderscheidt dit van Goodhart's Law: bij Goodhart raakt een proxy los van een stabiel doel. Hier wordt het doel zélf mede gevormd door de evaluatiepraktijk.

3. Behavioral approximation. Systemen leren gedrag produceren dat lijkt op het gedrag van een werkelijk capabel systeem binnen benchmarkcondities, zonder de mechanismen te bezitten die de capability eigenlijk vereist. Voor enterprise AI is dit geen theoretische voetnoot — het is het verschil tussen "het systeem gedraagt zich alsof het begrijpt" en "het systeem heeft een mechanisme dat robuust begrip, adaptatie of feedbackgestuurd leren ondersteunt".

Vijf manieren waarop benchmarks falen — met enterprise-consequenties

Kalaitzidis definieert vijf failure modes voor discriminative validity. Voor CIO's en CISO's zijn dit geen methodologische finesses maar directe risico's:

| Failure mode | Betekenis | Enterprise-risico | |---|---|---| | Proxy substitution | Benchmark meet taakconvergentie, niet de capability | Modelselectie op verkeerde KPI | | Architectural indistinguishability | Evaluatie ziet geen verschil tussen architecturen met en zonder vereist mechanisme | Schijnzekerheid over autonomie of feedback learning | | Context blindness | Benchmark varieert context onvoldoende | Falen bij domeinshift of edge cases | | Criterion leakage | Outputpariteit wordt verward met mechanisme-equivalentie | "Human-level" claims zonder bewijs van proceskwaliteit | | Approximation ceiling | Systeem optimaliseert binnen proxy-omgeving, faalt daarbuiten | Governance mist structurele limieten |

Deze taxonomie is direct bruikbaar als review-instrument voor AI assurance, model cards, evaluatieplannen, red teaming en procurement.

Epistematics: een audit voor je benchmark

Tegenover de evaluation trap stelt Kalaitzidis Epistematics: een vierstaps auditmethode die vóór benchmark-constructie checkt of de evaluatie daadwerkelijk meet wat hij claimt.

De vier stappen:

1. Specificeer de capability claim — wat moet het systeem kunnen?
2. Extraheer de theoretische aannames achter die claim — welke mechanismen veronderstelt hij?
3. Leid daaruit architecturale en omgevingsvereisten af — wat moet de architectuur kunnen om dat mechanisme te realiseren?
4. Test of de evaluatiecriteria de geclaimde capability kunnen onderscheiden van proxy-gedrag

Het sleutelbegrip is discriminative validity: een benchmark faalt als een systeem zónder het doelmechanisme tóch kan slagen, of als een systeem mét het mechanisme niet uniek herkenbaar is. Het gaat niet om "voorspelt de benchmark performance?" maar om: "kan de benchmark het juiste mechanisme onderscheiden van alternatieve routes naar benchmarksucces?"

De vernietigende case study: Dupoux, LeCun & Malik

Kalaitzidis past Epistematics toe op een paper van Emmanuel Dupoux, Yann LeCun en Jitendra Malik — geen obscure onderzoekers maar top van het veld — die een architectuur voorstellen voor "autonomous learning". Hun A/B/M-architectuur (System A voor observation-based learning, System B voor action-based reinforcement learning, System M voor meta-control) claimt zich los te maken van het dominante distributieparadigma.

Kalaitzidis' oordeel is genadeloos: het voorstel diagnosticeert het probleem correct, maar valt in de evaluatie terug op precies de aannames die het wil overstijgen. De benchmarks die zij voorstellen — trials-to-criterion, uren taalblootstelling ten opzichte van menselijke prestaties — meten prestatieverandering, niet het leermechanisme. Een systeem dat via distributionele convergentie sneller wordt, is voor hun evaluatie identiek aan een systeem dat werkelijk cybernetisch leert via real-time feedback loops.

Zijn hardste punt: als je autonomous learning serieus neemt als capability-claim, moet je testen of het systeem real-time feedback loops heeft tussen gedrag en omgevingsrespons. Trials-to-criterion test dat niet. Het test of het systeem output produceert die lijkt op leren — precies de behavioral approximation die de paper als probleem identificeert.

Wat dit betekent voor AI-agents in de praktijk

Voor organisaties die AI-agents inzetten — of dat nu in softwareontwikkeling, SOC/NOC-operaties, beleidsondersteuning of operationele besluitvorming is — levert dit een concreet evaluatiekader op. De vraag is niet "hoe goed scoort de agent op benchmark X?" maar "meet benchmark X wat wij denken dat hij meet?"

Voor vijf veelvoorkomende agent-capabilities ziet het verschil er zo uit:

| Capability claim | Wat een slechte eval meet | Wat een Epistematics-eval zou testen | |---|---|---| | "Agent kan autonoom plannen" | Slaagt op statische taaklijst | Test onder veranderende doelen, incomplete informatie, onderbroken tools, adversarial context | | "Agent leert van fouten" | Minder fouten na prompt-tweak | Bewijs van feedback-loop, state update, policy adjustment, regressiebeheersing | | "Agent is veilig" | Weigert bekende jailbreaks | Test tool authorization, indirect prompt injection, least privilege, auditability, recovery | | "Agent begrijpt codebase" | Beantwoordt vragen over gelezen files | Test symbol tracing, change impact, build/test feedback, hallucinatie onder partial context | | "Model redeneert" | Scoort hoog op reasoning-benchmark | Contrastieve taken buiten trainingsdistributie, compositional novelty, mechanisme-sensitieve probes |

De governance-implicatie: benchmark-scores zijn geen bewijs

Voor AI-governance onder de EU AI Act, BIO2, NIS2 en ISO 27001 is Kalaitzidis' paper een epistemisch fundament voor waarom benchmark-scores nooit voldoende bewijs zijn voor high-risk inzet. De EU AI Act vereist conformity assessment — maar als de benchmarks waarop die assessment rust structureel blind zijn voor hun eigen aannames, bouw je compliance op drijfzand.

Dit vertaal ik naar een concrete governance control:

Control: Capability-Evaluation Coherence Review

Doel: voorkomen dat benchmarkprestaties worden geïnterpreteerd als bewijs voor capabilities die niet mechanistisch zijn aangetoond.

Minimale bewijsstukken:

• Capability claim register — reasoning, planning, autonomous learning, safety, robustness, elk met een mechanistische definitie
• Theoretical assumption map per claim — welke theorie over de capability zit erin?
• Proxy-risk analyse — welke false positive routes zijn mogelijk?
• Contrastive evaluation design — onder welke condities zou een proxy-systeem falen?
• Design envelope en out-of-distribution testplan — waar houdt de benchmark op met meten?
• Evidence traceability naar model card, system card, risk assessment en deployment decision

Deze control past naast ISO 27001 risicomanagement, NIST AI RMF, EU AI Act evidence management en OWASP LLM/GenAI security testing. De paper levert geen kant-en-klaar compliance-framework, maar wél de fundamentele vraag die je aan elke benchmark moet stellen: welke theorie over capability zit in deze score verborgen, en kan de evaluatie die capability onderscheiden van slim proxygedrag?

De beperkingen: epistemologie zonder engineering-handleiding

De zwakte van het paper is dezelfde als zijn kracht: het is conceptueel ijzersterk maar empirisch dun. Epistematics produceert kandidaatcriteria, geen gevalideerde benchmarks. Voor engineeringteams kan de stap van "theoretische aannames" naar concrete eval suites nog te abstract zijn. En niet elke benchmark hoeft de volledige capability te bewijzen — soms is een proxy bewust gekozen als beperkte regressietest. Het probleem ontstaat pas wanneer die beperkte proxy wordt opgewaardeerd tot bewijs voor brede capability.

Kalaitzidis zelf erkent dit: zijn bijdrage is een auditprocedure en een demonstratie, geen af product.

DjimIT: van benchmark-kritiek naar assurance-praktijk

DjimIT vertaalt Epistematics naar een concrete Benchmark Validity Audit: een review van de benchmarks die jouw organisatie gebruikt voor modelselectie, compliance en deployment-beslissingen. We toetsen elke benchmark op discriminative validity, brengen proxy-risico's in kaart, en leveren een contrastief evaluatieplan dat onderscheid maakt tussen "het systeem lijkt capabel" en "het systeem bezit de vereiste mechanismen."

Of zoals Kalaitzidis het zegt: de vraag is niet hoe goed het model scoort — maar welke theorie over capability in die score verborgen zit.

---

Paper: Kalaitzidis, T.J. — "The Evaluation Trap: Benchmark Design as Theoretical Commitment", arXiv:2605.14167, 13 mei 2026. Brown University.