Wanneer je benchmark zelf een risico wordt

Je bent nu verplicht om te verifiëren dat de evaluaties waarop je AI-systemen goedkeurt, zelf nog geldig zijn. Een benchmark die niet meer meet wat hij pretendeert te meten, kan een bedrijfskritische beslissing rechtvaardigen op basis van illusie.

De aanleiding is een analyse van 26 augustus 2026 van hoe benchmarks voor bedrijfskritische AI zelf een risicolaag zijn geworden, die aantoont dat evaluatiefouten net zo ernstig kunnen zijn als modelfouten. Het concrete geval: een audit concludeert dat ongeveer 30% van de taken in een veelgebruikte codebenchmark niet langer valide zijn. In onze beoordeling betekent dit dat benchmarkkwaliteit een expliciet onderdeel van je AI-governance moet worden — niet iets dat je aanneemt, maar iets dat je actief controleert en documenteert.

Welke foutmodes ontstaan wanneer je op één accuracyscore vertrouwt?

Een benchmark kan op twee manieren falen. Ten eerste kan het model slecht presteren op een valide test — dat is het klassieke probleem. Ten tweede kan de benchmark zelf degraderen: taken worden ongeldig, de omgeving verandert, of de test meet niet meer wat hij pretendeert te meten. Die tweede categorie is gevaarlijker omdat je hem niet ziet. Een model dat hoog scoort op een gebroken benchmark lijkt betrouwbaar terwijl het dat niet is.

GuardianAgentBench illustreert het eerste probleem in realistische omstandigheden. Populaire agentstacks bereikten 74,8% overall accuracy over 580 scenario's in klantservice, financiële processen en data-toegang. Dat betekent dat één op de vier acties problematisch was. In een labbenchmark klinkt dat redelijk; in een workflow waarin een agent klantgegevens raadpleegt of een transactie voorbereidt, is het onacceptabel zonder verdere controle. Het probleem is niet de score zelf, maar dat organisaties geen expliciete drempel hebben vastgesteld voor welke restfout acceptabel is per workflow.

• Gebroken benchmarktaken — evaluaties die niet langer meten wat ze pretendeert te meten, maar toch hoog scoren.
• Ontbrekende domeinspecificiteit — generieke accuracy-scores zeggen niets over geschiktheid voor een bepaalde bedrijfscontext.
• Gebrek aan herhaalbaarheidsmetingen — een model kan inconsistent presteren zonder dat dit in een gemiddelde score zichtbaar wordt.
• Afwezigheid van robuustheidstests — modellen kunnen onder verstoringen of edge cases drastisch degraderen.
• Geen expliciete restfout-drempels — organisaties weten niet welke foutpercentage acceptabel is voor hun workflow.

Hoe bouw je een beoordelingsarchitectuur die meer dan één score vraagt?

De oplossing is niet één betere benchmark, maar een combinatie van metingen die samen een vollediger beeld geven. Herhaalbaarheid is een eerste laag. De EDA Benchmark voert tien data-analysetaken vijf keer per model uit en berekent naast de gemiddelde score ook een reliability-adjusted score, waarin de spreiding over herhalingen wordt meegewogen. Modellen met vergelijkbare gemiddelde scores kunnen wezenlijk verschillen in stabiliteit, en juist die stabiliteit is voor productiegebruik relevant.

Robuustheid onder verstoringen is een tweede laag. Medische foundation models zijn getest met 40 soorten perturbaties over acht imaging-modaliteiten. De resultaten tonen dat sommige medische modellen minder dan 20% performance-daling laten zien, terwijl algemene modellen in bepaalde scenario's tot 54% daling kennen. Een generieke accuracy-score zegt niets over geschiktheid voor een hoog-consequente zorgcontext; daar zijn domeinspecifieke robuustheidstests voor nodig.

Governance is een derde laag. Veiligheidsniveaus (ASL-1 tot ASL-3) definiëren niet alleen technische eisen, maar ook welke risk identification, risk analysis en risk treatment per niveau verplicht zijn. Evaluatie van bedrijfskritische AI is daarmee niet alleen een technische meting, maar een risicoklassificatieproces.

1. Definieer per workflow welke benchmarks je gebruikt en waarom — documenteer welke evaluaties relevant zijn voor je specifieke taak.
2. Verifieer dat benchmarktaken nog geldig zijn — controleer periodiek of de taken nog meten wat ze pretendeert te meten.
3. Meet herhaalbaarheid en stabiliteit, niet alleen gemiddelde accuracy — test hoe consistent een model presteert over meerdere runs.
4. Test robuustheid onder domeinspecifieke verstoringen — voer stress-tests uit die relevant zijn voor je bedrijfscontext.
5. Stel expliciete restfout-drempels vast — bepaal welk foutpercentage acceptabel is en monitorteer dit actief.
6. Koppel je evaluatie aan een veiligheidsniveau — classificeer je AI-systeem expliciet naar risicoklasse en pas je governance daaraan aan.

Wat kunnen tools doen en wat blijft jouw verantwoordelijkheid?

Verificatielagen kunnen transparantie vergroten. Een verificatiesysteem kan een taak door onafhankelijke modellen routeren en de stappen, correcties en bronnen zichtbaar maken voor inspectie. Dat garandeert geen correctheid, maar het geeft meer zicht op hoe een uitkomst tot stand kwam. Voor gevoelige documenten kunnen privacycontroles waardes vervangen door synthetische equivalenten voordat AI-verwerking plaatsvindt; de workflow is fail-closed, zodat niets wordt doorgestuurd als de controle mislukt. In een auditspoor wordt zichtbaar welke stappen zijn doorlopen.

Maar tools kunnen niet beslissen welke benchmark geschikt is voor jouw workflow, welke restfout acceptabel is, of wanneer een evaluatie aan een audit toe is. Die vragen vereisen domeinkennis, bedrijfscontext en professioneel oordeel. Een benchmark is een hulpmiddel met beperkingen, geen bewijs. Het eindoordeel — of een AI-workflow betrouwbaar genoeg is voor een bepaalde taak — blijft bij de mensen die ermee werken en verantwoordelijk zijn voor de gevolgen.

De ontwikkelingen van deze zomer zijn geen reden voor paniek, maar wel voor discipline. Benchmarks blijven onmisbaar. Maar je moet nu actief controleren dat ze nog geldig zijn, en je moet weten welke foutmarge je accepteert voordat je een model bedrijfskritisch inzet.