Evaluation Loop

In de AI-wereld worden meerdere termen door elkaar gebruikt voor in essentie hetzelfde idee. Anthropic en OpenAI spreken van evals (informeel meervoud), academische bronnen van evaluation of benchmark, het NIST-raamwerk hanteert TEVV (Test, Evaluate, Verify & Validate), en de EU AI Act spreekt over risk management, accuracy testing en post-market monitoring. De definitie van Anthropic uit 2025 is de helderste werkdefinitie: “An evaluation (or ‘eval’) is a test for an AI system: give an AI an input, then apply grading logic to its output to measure success.”

Het loop-kenmerk maakt het verschil. Eén meting is een eval. Een verzameling metingen is een eval-suite. Een eval die periodiek terugkeert, leidt tot bevindingen, leidt tot acties en wordt opnieuw gedraaid: dat is de evaluation loop. Zonder die terugkoppeling is er alleen registratie.

Waar de loop op rust: het evaluatie-raamwerk

Onder de loop zit een evaluatie-raamwerk (in de Anthropic-taxonomie de evaluation harness): de software-infrastructuur die de testen automatisch draait. Het raamwerk bestaat uit zes onderdelen die op elke pagina van een productie-eval terugkomen:

• Taak: een specifiek probleem met inputs en gedefinieerde succescriteria. De atomaire eenheid van de eval-suite.
• Trial: één uitvoering van een taak. Omdat AI-modellen waarschijnlijkheidsmatig zijn (één input kan twee verschillende outputs opleveren), is één trial zelden representatief; meerdere trials geven een statistisch zinvol beeld.
• Grader: de logica die de prestatie scoort. Drie hoofdvormen, verderop behandeld in de uitvouw Beoordelen onder onzekerheid.
• Transcript (spoor): het volledige logboek van redenering, tool-aanroepen en tussenstappen, niet alleen het eindantwoord. Onmisbaar voor het analyseren van stille fouten en wettelijk verplicht onder EU AI Act Art. 12 voor hoogrisico-systemen.
• Uitkomst: de eindstaat in de externe wereld. Bij een agent die een afspraak inboekt: niet wat de agent zegt te hebben gedaan, maar of de agenda-vermelding daadwerkelijk staat.
• Evaluatie-suite: een verzameling gerelateerde taken (bijvoorbeeld alle eval-cases voor klantenservice, of alle cases voor financiële rapportage). Meet specifieke capaciteiten of gedragspatronen.

De grens met aangrenzende begrippen

Evaluation loop wordt vaak verward met begrippen die ernaast liggen maar niet hetzelfde zijn:

• Observability: het zichtbaar maken van wat intern in een systeem gebeurt (traces, logs). Voedingsstof voor de loop, niet de loop zelf.
• Monitoring: continu signaleren van afwijkingen in productie (latentie, foutpercentages). Ook input, maar geen beoordeling van outputkwaliteit.
• Benchmark: eenmalige meting op een standaard-dataset. Bouwsteen voor de loop, maar zelf niet cyclisch.
• MLOps: het geheel van processen rondom AI-modellen in productie (training, versiebeheer, deployment, monitoring). Evaluation loop is daarvan één onderdeel.

Dit raakt direct aan de Accountability-guardrail (GR_07: duidelijk wie verantwoordelijk is en hoe daarop wordt toegezien). Zonder onderscheid tussen meten en handelen wordt verantwoording afleggen onmogelijk; je kunt niet aantonen dat een bevinding is opgevolgd als de loop nooit sluit.

Een volwassen evaluation loop bestaat uit zes fasen die elke significante wijziging doorloopt: prompt-update, modelwissel, nieuwe context-bron, uitgebreide toolset of aangepaste agent-architectuur. Voor één-op-één-veranderingen kunnen sommige fasen worden ingekort; voor een hoogrisico-toepassing zijn alle zes verplicht.

Fase 1, pre-deploy offline eval: gecontroleerde testset met bekende verwachte uitkomsten, geen echte gebruikers betrokken. Elke significante wijziging triggert een run. Output: een go/no-go-beslissing voor doorstroom naar de volgende fase. Doel: regressies vroeg vangen, voordat ze gebruikers raken.

Fase 2, schaduw-modus: het nieuwe model draait parallel aan productie. Antwoorden worden vastgelegd voor analyse, maar niet getoond aan eindgebruikers. Maakt het mogelijk om kwaliteitsverschillen, latentie en kosten te meten zonder gebruikersimpact. Verplicht startpunt voor een grote prompt-herziening of modelwisseling.

Fase 3, canary-release: na succesvolle schaduw-modus stroomt een klein percentage echt verkeer door het nieuwe systeem. Typische staffeling: 1% van het verkeer in week één, 5% in week twee, 20% in week drie, 50% in week vier, 100% in week vijf. Metrieken worden continu vergeleken met de baseline. Bij overschrijding van een vooraf gedefinieerde drempel: automatische rollback. Voor hoogrisico-toepassingen (medisch, juridisch): start op 0,1% in plaats van 1%.

Fase 4, post-deploy online evaluation: continue meting op echt verkeer. Drie typen feedback komen samen:

• Impliciete feedback: klikgedrag, hoe vaak gebruikers vroegtijdig afhaken, en hoe vaak dezelfde vraag binnen één sessie wordt herhaald (een sterk signaal voor systemisch falen, want de gebruiker kreeg duidelijk niet wat hij zocht).
• Expliciete feedback: duim omhoog of omlaag, sterrenrating, correctie-acties.
• Escalatie-rate: hoe vaak de gebruiker terugvalt op een mens.

Fase 5, drift-monitoring: er zijn drie vormen van drift die afzonderlijk gemonitord moeten worden. Data-drift betekent dat de verdeling van input-vragen verschuift (gebruikers stellen andere soorten vragen dan een jaar geleden). Concept-drift betekent dat de relatie tussen input en juist antwoord verandert (de werkelijkheid evolueert: regelgeving verandert, prijzen wijzigen, definities herzien). Performance-drift is de gevaarlijkste variant: kwaliteitsmetrieken dalen zonder dat de applicatie veranderde; het model degradeert stilletjes, of de werkelijkheid is van het model af gegroeid.

Fase 6, verbeteractie: bevindingen leiden tot aanpassingen. Een nieuwe prompt-versie, een andere modelversie, verbeterd ophalen van context, een uitgebreide of versmalde toolset. De cyclus herstart bij fase 1. Zonder deze stap is de loop open: er wordt gemeten, maar niet bijgestuurd.

Dit raakt aan twee guardrails. Robustness (GR_02: betrouwbaarheid onder alle omstandigheden) wordt operationeel via fase 4 en 5: alleen door drift te detecteren voordat de schade ontstaat, blijft een systeem betrouwbaar. Human Agency (GR_01: mensen behouden controle) hangt aan fase 6: zonder mens die beslist over een verbeteractie is “automatische optimalisatie” een mooi woord voor verlies van regie.

Het hart van de evaluation loop is de grader: de logica die bepaalt of een output goed of slecht is. In 2026 is de consensus dat een hybride benadering de enige weg is naar schaalbare betrouwbaarheid. Drie typen graders met verschillende afwegingen tussen snelheid, kosten en geschiktheid.

Code-gebaseerde grader: scripts, reguliere expressies, schema-validatie of unit-tests (geautomatiseerde tests die één onderdeel van een systeem controleren). Onmisbaar voor checks waar de juiste output een vast formaat heeft (geldige JSON, een numerieke waarde binnen een bereik, een verplicht veld aanwezig). Snel, gratis, deterministisch, maar kan geen subjectieve kwaliteit of nuance meten.

Model-gebaseerde grader (LLM-als-rechter): een krachtig taalmodel beoordeelt de output van een ander systeem. Schaalbaar voor open-ended antwoorden zoals samenvattingen, toonbeoordeling en redenering. Vereist kalibratie (het rechter-oordeel afstemmen tegen dat van menselijke beoordelaars) en heeft bekende biases — systematische voorkeuren die het oordeel vertekenen — die hieronder worden behandeld.

Menselijke grader: de goudstandaard voor het kalibreren van de andere twee. Onmisbaar bij hoogrisico-toepassingen, eerste opzet van een nieuwe rubric, en grensgevallen. Duur en traag, dus alleen inzetten waar machinale grading aantoonbaar onbetrouwbaar is. Productie-aanbeveling: combineer altijd deterministische checks (snel, gratis), met LLM-als-rechter (voor nuance) en periodieke menselijke steekproef (voor kalibratie).

De rechter-paradox: rubric-kwaliteit boven judge-kracht

In 2025 is een opmerkelijk patroon gedocumenteerd: een relatief zwak model met een gedetailleerde, multidimensionale rubric presteert systematisch beter dan een superieur model met een vage instructie. De kwaliteit van het oordeel wordt gedomineerd door de structuur van de rubric, niet door de rekenkracht van de beoordelaar. Dit ondersteunt de praktijk van analytische rubrics: elke dimensie (feitelijke juistheid, veiligheid, merktoon, beknoptheid) krijgt een eigen score in plaats van één samengevat cijfer. Voordeel bij kwaliteitsdaling: root-cause-analyse kan direct aanwijzen of de degradatie zit in feitelijkheid of in toon, en niet alleen “een lager cijfer” op iets vaags.

Cohen’s Kappa als kalibratiemaat

Een LLM-als-rechter wordt gekalibreerd door zijn oordelen te vergelijken met die van menselijke experts op dezelfde set, gecorrigeerd voor toeval. Die correctie heet Cohen’s Kappa. De gangbare interpretatiedrempels (Landis & Koch, 1977):

• Onder 0,40: slechte overeenstemming. Niet productiegeschikt; rubric of judge-prompt herzien.
• 0,40 tot 0,60: matige overeenstemming. Bruikbaar voor exploratie, niet voor productie.
• 0,60 tot 0,80: goede overeenstemming. Productiegeschikt voor niet-kritische toepassingen.
• Boven 0,80: uitstekende overeenstemming. Vereist voor hoogrisico of compliance-gevoelige systemen.

Vier voorkeuren die het rechter-oordeel vertekenen

Een LLM-als-rechter is geen neutrale beoordelaar. Vier biases zijn empirisch vastgesteld en moeten actief worden gemitigeerd: positie-bias (het eerste antwoord in een vergelijking wordt vaak hoger gescoord), lengte-bias (langere antwoorden ogen “behulpzamer” en krijgen hogere scores, ook als ze redundant zijn), zelf-voorkeur (modellen scoren output die ze zelf hebben gegenereerd hoger dan output van andere modellen) en stijl-bias (voorkeur voor een formele of overtuigende toon, los van feitelijke juistheid). Mitigaties: gebruik nooit hetzelfde model als rechter en kandidaat; pas order swapping toe (twee runs met omgewisselde posities); en neem beknoptheid expliciet op in de rubric zodat lengte geen verkapt voordeel wordt.

Een eval-set is alleen zo goed als zijn samenstelling. Een set die alleen gemakkelijke cases bevat geeft hoge scores zonder voorspellende waarde voor productie. Een set die alleen randgevallen bevat trekt de score onnodig omlaag. Een set die nooit wordt vernieuwd verliest in zes tot twaalf maanden zijn relevantie omdat de werkelijkheid verschuift.

Grootte: van klein beginnen naar productie schalen

• Eerste testset: 20 tot 50 cases. Snel te bouwen, geeft een eerste signaal, geschikt voor een eerste loop. Kan suboptimaal zijn omdat statistische significantie nog ver weg is.
• Productie-betrouwbaar: 100 tot 500 cases. Voldoende voor statistisch zinvolle uitspraken bij de meeste toepassingen.
• Hoogrisico (medisch, juridisch, financieel): 1.000 of meer cases. Onder die grens geeft de set een misleidende zekerheid.

Samenstelling: drie zones, drie verhoudingen

Voor een evenwichtige set:

• Doorsnee-vragen (60 tot 70%): de gemakkelijke gevallen die het systeem in productie verreweg het vaakst tegenkomt. Bewaakt de hoofd-functionaliteit.
• Edge cases (20 tot 30%): ongebruikelijke, meerduidige of complexe inputs. Test waarbij de grenzen van het systeem worden opgezocht.
• Adversariële inputs (5 tot 10%): inputs die het systeem expliciet proberen te misleiden. Combinatie van prompt-injectie-pogingen, dubbelzinnige formuleringen en bekende valkuilen voor het type taak.

Gouden testset versus synthetische data

Een gouden testset is een gecureerde, versie-beheerde collectie inputs, contexten en verwachte uitkomsten, hand-gecontroleerd door domeinexperts. Versiebeheer is verplicht: elke wijziging in schema of labels wordt getraceerd als nieuw experiment, anders zijn metingen van vandaag niet vergelijkbaar met die van vorige maand.

Synthetische data versnelt de opbouw maar heeft een specifieke valkuil: gebruik nooit hetzelfde model voor het genereren én het valideren van eval-cases. Promoveer “zilveren” synthetische data pas naar “goud” via menselijke review door domeinexperts. Een eval-set die met hetzelfde model is gegenereerd dat ook de evaluatie uitvoert, meet voornamelijk hoe consistent een model met zichzelf is.

Eval-set-lekkage als stille faalmodus

Eval-set-lekkage treedt op wanneer testdata is terechtgekomen in de trainingsdata van het model dat geëvalueerd wordt. Het model “kent” de antwoorden uit eerdere training en reproduceert ze, zonder dat het de onderliggende redenering hoeft toe te passen op een nieuwe input. Benchmark-scores zien er daardoor hoog uit, maar bij vragen die net iets anders zijn faalt het systeem alsnog. Onderzoek gepresenteerd op de ICML-conferentie in 2025 toonde aan dat wanneer onderzoekers gecontamineerde voorbeelden uit een eval-set verwijderden, de nauwkeurigheid van het model 5 tot 15 procentpunt daalde. Voor de wiskunde-benchmark GSM8K (een veelgebruikte verzameling rekenopgaven om redeneer-vaardigheid te testen) lag die daling op 13 procentpunt.

Mitigaties: voer periodieke overlap-checks uit tussen eval-set en trainingsdata en hanteer methoden zoals AntiLeakBench (een evaluatie-aanpak gepresenteerd op de ACL-conferentie in 2025 die testgevallen genereert met kennis die aantoonbaar niet in de trainingsdata van bekende modellen voorkomt).

Een single-turn-systeem heeft één input en één output. Een agentisch systeem (een AI-systeem dat zelfstandig acties uitvoert) zet een reeks stappen: het kiest een tool, geeft parameters mee, ontvangt een resultaat, kiest een volgende tool en herhaalt dat tot de taak klaar is. Evaluatie van zo’n systeem vraagt een fundamenteel andere aanpak.

Traject-evaluatie

Naast de eindoutput meten teams in 2026 het traject zelf. Concrete metrieken uit publiek beschikbare evaluatie-suites zoals TRAJECT-Bench (een academische benchmark uit 2025 specifiek voor agent-trajecten) en LangChain AgentEvals (een open-source toolkit voor het testen van agent-keuzes):

• Trajectory-exact-match: het pad is identiek aan de verwachte route (strikte modus, voor compliance-gevoelige flows).
• Tool-selection-accuracy: is de juiste tool gekozen voor de taak? Volgens recent onderzoek de grootste enkelvoudige bron van agentische fouten.
• Tool-parameter-accuracy: zijn de juiste parameters meegegeven aan de tool?
• Multi-turn function calling accuracy: blijft de agent over meerdere beurten consistent in zijn tool-keuzes?
• Tool-call-error-rate: welk percentage van de tool-aanroepen mislukt?

Onderzoek wijst uit dat tool-gebruik een van de meest voorkomende faalpunten is in agentische systemen: foutpercentages tot 36% in complexe conversaties bij sommige frontier-modellen. Een evaluation loop voor agenten moet daarom expliciet testen op tool-routing en de afhandeling van fouten van externe diensten.

Variabiliteit als signaal, niet als ruis

In agentische systemen is de variantie in uitkomsten zelf een signaal. Een agent die in 80% van de gevallen slaagt maar af en toe catastrofaal faalt, is in productie minder betrouwbaar dan een agent met 75% slaagkans en stabiel gedrag. De evaluation loop moet die stabiliteit zichtbaar maken over tijd en over verschillende omgevingen (ontwikkel, staging, productie). Eén score per release zegt te weinig; de spreiding zegt veel.

Twee stille faalmodi specifiek voor agenten

• Hallucinaties uit trainingsdata: het model vertrouwt op verouderde of onjuiste informatie uit de trainingsfase in plaats van op de meegeleverde context (RAG-resultaten, opgehaalde documenten). De gebruiker kan vaak niet verifiëren of een bewering uit de bron komt of “verzonnen” is. Eval-eis: faithfulness-checks (tests die meten of het antwoord daadwerkelijk uit de aangeleverde bronnen komt) moeten expliciet de bron-traceerbaarheid toetsen, niet alleen de plausibiliteit.
• Context-drift in lange conversaties: naarmate een gesprek vordert, verliest de agent de oorspronkelijke instructie of het doel uit het oog. Eval-eis: tests over lange gesprekken of agent-trajecten waarbij per beurt wordt gecontroleerd of de agent nog binnen de oorspronkelijke taak blijft.

Praktijkles van een Amazon-evaluatie van een agentische winkelassistent: slecht gedefinieerde tool-schema’s zijn de grootste bron van agentische fouten. Een voorbeeld: een tool die “product_zoeken” heet maar onduidelijk laat of de input een productnaam, een artikelnummer of een vrije zoekterm verwacht. De agent gokt en krijgt regelmatig de verkeerde resultaten terug. Voordat een evaluation loop überhaupt zinvol resultaat oplevert, moet de Tool Integration (BB_05: AI verbinden met de buitenwereld) op orde zijn.

In 2026 is de evaluation loop niet langer een vrijwillige kwaliteitsmaatregel. Voor hoogrisico-AI-systemen — een categorie uit de EU AI Act die onder andere medische hulpmiddelen, werving en selectie, kritieke infrastructuur en rechtshandhaving omvat — is de loop wettelijk afdwingbaar geworden via de EU AI Act, ISO/IEC 42001 en het NIST AI RMF.

De zeven artikelen hieronder gelden specifiek voor hoogrisico-systemen. Voor beperkt-risico-systemen (chatbots, deepfakes, biometrische categorisatie) geldt vooral een transparantieplicht (Art. 50): gebruikers moeten weten dat ze met AI te maken hebben. Voor minimaal-risico-systemen (de meeste alledaagse AI-toepassingen) is alleen Art. 4 verplicht: AI-geletterdheid van personeel dat met het systeem werkt. Verdere evaluatie is voor die categorieën vrijwillig, maar wel sterk aanbevolen om kwaliteit te borgen.

EU AI Act: zeven artikelen die de loop voor hoogrisico-systemen verplicht stellen

Artikel 9, risicobeheer: verplicht een doorlopend, iteratief proces gedurende de hele levenscyclus van het systeem (in de wettekst: “continuous iterative process throughout the entire lifecycle”). Tests moeten worden uitgevoerd met vooraf gedefinieerde metrieken en drempels die passen bij het beoogde gebruik. Dat geldt vóór het AI-systeem op de markt wordt gebracht (“marktplaatsing”) én periodiek daarna. Signalen uit gebruik in productie (post-market monitoring, zie Art. 72) moeten worden geanalyseerd en teruggekoppeld in het systeem-ontwerp.

Artikel 10, datagovernance en biasbestrijding: het detecteren en bestrijden van bias (systematische scheefstand in de uitkomsten) is verplicht. Trainingsdata moeten representatief zijn voor de gebruikscontext: een wervingstool getraind op CV’s uit één sector presteert slecht in een andere. Documentatie van datamanagement maakt deel uit van de verplichte technische dossiers.

Artikel 12, logging van gebeurtenissen: het AI-systeem moet automatisch loggen gedurende zijn levenscyclus. Voor de evaluation loop betekent dat: volledige trajecten met tijdstempels bewaren, niet alleen eindscores. Dit artikel beschrijft alleen wát logbaar moet zijn; hoe lang de logs bewaard moeten blijven staat in twee andere artikelen. Artikel 19 lid 1 verplicht providers (degene die het systeem ontwikkelt en op de markt brengt, bijvoorbeeld OpenAI of Anthropic) tot minimaal zes maanden bewaartermijn; Artikel 26 lid 6 verplicht deployers (degene die het systeem inzet in eigen processen, bijvoorbeeld een ziekenhuis dat AI inzet voor triage — het sorteren van patiënten op urgentie) tot dezelfde minimale zes maanden.

Artikel 13, transparantie voor afnemers: afnemers (de organisaties die het systeem inzetten) moeten de instructies en eigenschappen van het AI-systeem kunnen begrijpen. Voor de evaluation loop betekent dit dat scores moeten worden onderbouwd: niet één enkel cijfer, maar een uitsplitsing per criterium (bijvoorbeeld feitelijke juistheid, toon en veiligheid afzonderlijk) met de redenering die tot de scores leidde. Dit sluit aan bij de eerder beschreven analytische rubrics.

Artikel 14, menselijk toezicht: hoogrisico-systemen moeten menselijk ingrijpen mogelijk maken. Voor de evaluation loop betekent dit twee ontwerp-eisen: een kill-switch (een knop die het AI-systeem direct stilzet en geen nieuwe acties meer toelaat) én een mechanisme dat beslissingen die de agent niet zelf mag of kan nemen automatisch in een wachtrij plaatst voor menselijke beoordeling (bijvoorbeeld grensgevallen in kredietverlening die naar een credit-officer gaan). De escalatie-rate (percentage gevallen dat naar een mens wordt doorgezet) is een reguliere eval-metriek: een te lage rate kan betekenen dat het systeem te veel zelf afhandelt, een te hoge rate dat het zijn werk niet aankan.

Artikel 15, nauwkeurigheid en robuustheid: nauwkeurigheidsniveaus en de gebruikte metrieken moeten gedocumenteerd zijn in de gebruikersinstructies. Continu-lerende systemen (AI die zichzelf op basis van nieuwe data verder traint) moeten voorkomen dat hun eigen productie-output ongecontroleerd terugvloeit in de volgende trainingsronde. Dat doe je door trainingsdata strikt te scheiden van productie-output, door menselijke review-stappen tussen output en hertraining te plaatsen en door periodiek snapshots van het model te maken die je tegen elkaar kunt vergelijken. Zonder deze maatregelen ontstaat “feedback-loop-contaminatie”: het model leert van zijn eigen fouten en versterkt ze.

Artikel 72, post-market monitoring: actief en systematisch verzamelen van prestatiedata gedurende de gehele levensduur van het systeem, vergelijkbaar met farmacovigilantie bij medicijnen (het structureel volgen van bijwerkingen na markttoelating) of post-market surveillance bij medische hulpmiddelen. Verplicht op basis van een formeel monitoring-plan dat onderdeel is van de technische documentatie. Afdwingbaarheid: 2 december 2027 voor Bijlage III hoog-risico systemen (verschoven van 2 augustus 2026 via het Digital Omnibus-akkoord van 7 mei 2026); 2 augustus 2028 voor Bijlage I.

ISO/IEC 42001 als managementkader

ISO/IEC 42001:2023 standaardiseert het AI Management System (AIMS): de organisatorische structuur en processen rondom de inzet van AI. Clausule 9 (Performance Evaluation) eist drie zaken: (1) doorlopend meten van AI-prestaties, (2) minimaal jaarlijks een interne audit (vaker bij hoogrisico-systemen) en (3) een formele beoordeling door het topmanagement. Clausule 10 (Continuous Improvement) eist dat bevindingen worden omgezet in concrete verbetering. Een certificering is drie jaar geldig, met jaarlijkse tussentijdse audits en een hercertificering aan het einde. In 2026 wordt ISO 42001-certificering steeds vaker gezien als bewijs van due diligence voor de EU AI Act.

NIST AI RMF: TEVV als regulier proces

Het NIST AI RMF bestaat uit vier kernfuncties: Govern (cultuur en beleid), Map (context en risico’s identificeren), Measure (analyseren en monitoren) en Manage (prioriteren en reageren). TEVV (Test, Evaluate, Verify & Validate) is binnen dit raamwerk een doorlopend lifecycle-proces, niet een eenmalige check. De Measure-functie hanteert volgens de officiële tekst “quantitative, qualitative, or mixed-method tools, techniques, and methodologies to analyze, assess, benchmark, and monitor AI risk.” Het NIST-raamwerk is in de Verenigde Staten niet wettelijk verplicht, maar wordt door bedrijven die in meerdere landen opereren in de praktijk gebruikt als gemeenschappelijke taal voor zowel Amerikaanse als Europese eisen.

Nederlandse toezichtsstructuur

Per ontwerpwet (april 2026) heeft Nederland gekozen voor decentraal toezicht. De vijf primaire AI Act-toezichthouders:

• Autoriteit Persoonsgegevens (AP): privacy en grondrechten.
• Rijksdienst voor Digitale Infrastructuur (RDI): digitale infrastructuur en marktcoördinatie.
• Autoriteit Consument en Markt (ACM): consumentenrecht en markttoezicht.
• Autoriteit Financiële Markten (AFM): financiële sector.
• De Nederlandsche Bank (DNB): bancaire sector.

Aanvullend, per sector: Inspectie Gezondheidszorg en Jeugd (IGJ: kwaliteit en veiligheid in de zorg, AI als medisch hulpmiddel), Nederlandse Zorgautoriteit (NZa: markttoezicht en bekostiging in de zorg) en Inspectie van het Onderwijs. De definitieve aanwijzing per AI-toepassingsgebied ligt nog niet limitatief vast. Voor agent-systemen in zorg, financiën of overheid betekent dit dat eval-keuzes ook moeten standhouden tegenover sectorale toezichthouders en hun specifieke regelgeving, niet alleen tegenover de Europese AI Act.

Dit raakt direct aan de Accountability-guardrail (GR_07: duidelijk wie verantwoordelijk is en hoe daarop wordt toegezien). Voor hoogrisico-systemen is een volledige audit-trail bij elke evaluatieronde geen extra-mile meer die je vrijwillig kiest, maar een wettelijke vereiste.

Een evaluation loop kan op acht herkenbare manieren falen, ook als hij technisch lijkt te draaien. Elke valkuil heeft een eigen tegenmaatregel.

1. Vibe-checking: AI-output op gevoel beoordelen door een handvol voorbeelden te bekijken. Niet schaalbaar, geen statistische basis. Het werkt voor een prototype met tien gebruikers; het breekt zodra het systeem honderd of meer gebruikers bedient. Tegenmaatregel: zodra je een systeem in productie hebt, vervang vibe-checking door een gouden testset met expliciete beoordelingsregels (welke score hoort bij welke uitkomst).

2. Demo-driven development: de eval-set bestaat precies uit de cases die in een flitsende demo aan het management worden getoond. Het systeem scoort 95% op de eval, maar faalt in 30% van echte gebruiks-cases. Grensgevallen (situaties op de rand van wat het systeem aankan), invoer die het systeem actief probeert te misleiden (in eval-jargon adversarial inputs) en scenario’s voor minder vaak voorkomende gebruikersgroepen ontbreken. Tegenmaatregel: stel de eval-set samen op basis van productie-logs en gerapporteerde incidenten, niet op basis van wat zich goed laat presenteren in een demo.

3. Single-metric tunnel-vision: optimaliseren op één metriek terwijl andere dimensies (veiligheid, faithfulness, bias, kosten) onbeheerd blijven. Het klassieke principe van Goodhart’s law vat dit precies samen: “When a measure becomes a target, it ceases to be a good measure.” Concreet voorbeeld uit 2025: meerdere grote AI-laboratoria publiceerden selectief alleen hun beste scores op de Chatbot Arena, de publieke ranglijst waarin gebruikers head-to-head twee modellen vergelijken. Tegenmaatregel: bewaak meerdere onafhankelijke metrieken naast elkaar, zoals het HELM-raamwerk doet over zeven dimensies.

4. Eval-set-veroudering: de eval-set wordt eenmalig aangemaakt en nooit bijgewerkt. Na zes tot twaalf maanden meet hij niet meer wat in productie relevant is omdat de werkelijkheid is verschoven. Tegenmaatregel: vernieuw de eval-set elk kwartaal met cases uit recente productie-logs en gerapporteerde fouten.

5. Judge-model-contaminatie: hetzelfde model wordt ingezet als rechter (de beoordelaar) én als kandidaat (het model dat beoordeeld wordt). Zelf-voorkeur leidt tot systematisch hoge scores die niet correleren met daadwerkelijke kwaliteit. Tegenmaatregel: gebruik altijd een ander model als rechter, of een ensemble van meerdere rechter-modellen.

6. Alleen happy-path: de eval-set bevat alleen succesvolle gevallen waarin het systeem goed werkt. Het lijkt 98% nauwkeurig maar faalt volledig bij onverwachte inputs. Tegenmaatregel: eis structureel 20 tot 30% grensgevallen en 5 tot 10% misleidende invoer in elke productie-eval-set.

7. Eval-set-lekkage in trainingsdata: zoals besproken in de eval-set-uitvouw, komt benchmarkdata terecht in trainingsdata van het model dat geëvalueerd wordt. Tegenmaatregel: periodieke overlap-checks plus methoden zoals AntiLeakBench die testgevallen genereren met expliciet nieuwe kennis.

8. Rapportage-theater: de loop produceert dashboards maar geen beslissingen. Metrieken worden bijgehouden zonder dat bevindingen leiden tot aanpassingen in prompts, modellen of processen. De loop is open. Tegenmaatregel: koppel een verbeterlogboek aan de loop; per evaluatieronde wordt een concrete actie of een expliciete onderbouwde no-action vastgelegd. Dit is ook wat EU AI Act Art. 9 als audit-trail vereist.

De productie-naar-eval-loop als 2026-trend

Tegenover de valkuil van eval-set-veroudering staat een opkomende praktijk: tools zoals Braintrust en LangSmith maken het mogelijk om productie-trajecten met één klik om te zetten in regressie-testgevallen voor de eval-set. Daardoor groeit de eval-set automatisch mee met de werkelijkheid in productie. Het effect is een vliegwiel: hoe meer het systeem in productie ziet, hoe meer relevante testgevallen de eval-set bevat, hoe sneller drift wordt opgemerkt. Voor teams die net starten met een evaluation loop is dit een pragmatische manier om weg te groeien uit het handmatig samenstellen van testgevallen, zonder de set te laten verstarren.

Een evaluation loop ontwerpen op papier is één ding, hem in productie laten leveren is een ander. Drie publiek gedocumenteerde cases laten zien wat een goed-gesloten loop kan opleveren.

• Nippon India Mutual Fund: een AI-assistent voor klantvragen ging van 75% nauwkeurigheid naar boven de 90% door over te stappen van een eenvoudige RAG-implementatie naar een continu geëvalueerd systeem met een gouden testset, continue bewaking op drift (sluipende kwaliteitsdaling over tijd) en wekelijkse herijking van de beoordelingsleidraad (rubric). De doorlooptijd voor het genereren van rapportages daalde van twee dagen naar ongeveer tien minuten.
• Huron Health: 90% nauwkeurigheid op sentimentclassificatie van patiëntfeedback, bereikt door modellen continu te evalueren tegen 10.000 handmatig geannoteerde notities per week. De omvang van de menselijke kalibratie-set maakt de Cohen’s Kappa-meting (statistische maat voor overeenstemming tussen beoordelaars) statistisch hard, niet anekdotisch.
• Klarna: doorlooptijd van pull requests (voorstellen tot codewijziging die door collega’s worden gereviewd vóór samenvoeging) in software-ontwikkeling verdubbeld door geautomatiseerde codekwaliteit- en compliance-evaluaties direct in de ontwikkelomgeving. De evaluation loop is hier niet alleen een productie-instrument maar ook een ontwikkel-instrument.

De gemene deler: in alle drie de cases sloot de loop pas wanneer de evaluatie expliciet werd gekoppeld aan een verbeteractie (een RAG-upgrade, een rechter-kalibratie, een ontwikkel-poort), niet wanneer alleen dashboards werden ingericht.

Tooling: twee duidelijke segmenten in 2026

De markt is in 2026 volwassen geworden, met twee herkenbare segmenten.

Open source eval-as-code raamwerken integreren in de ontwikkelpijp en draaien evals als reguliere tests:

• DeepEval (MIT-licentie): brede LLM-evaluatie, vijftig-plus metrieken, integreert met Pytest (de standaard test-tool voor Python) en CI/CD-pijplijnen — geautomatiseerde stromen die code bij elke wijziging bouwen, testen en uitrollen (continuous integration & delivery). Eerste keuze voor engineering-teams met sterke testcultuur.
• Ragas (Apache 2.0, een permissieve open-source-licentie die ook commerciële inzet vrijlaat): metrieken specifiek voor RAG, zoals feitelijke grond (komt het antwoord echt uit de bronnen?) en context-relevantie (sluit de opgehaalde context aan op de vraag?). Eerste keuze voor wie een Dynamic Context (BB_03: de juiste informatie op het juiste moment) in productie brengt.
• Inspect AI (UK AISI, MIT): sandboxed agentische evaluaties via Docker, reproduceerbaar en auditeerbaar. Sterkste open-source-keuze voor compliance-teams die evaluatie als productie-infrastructuur behandelen en moeten kunnen aantonen aan toezichthouders.
• Langfuse (MIT, self-hostbaar): observability gecombineerd met evaluatie, lichtgewicht.

Commerciële platforms bieden samenwerking, dashboards en managed infrastructuur:

• LangSmith: diepe integratie met LangChain en LangGraph (populaire raamwerken voor het bouwen van LLM-applicaties en agentische workflows), sterk in traject-evaluatie: beoordeling van de volledige stappenreeks die een agent zet, niet alleen de eindoutput.
• Braintrust: snelle CI/CD-poorten, prompt-optimalisatie, vlakke prijsstructuur.
• Humanloop: focus op samenwerking met niet-technische product-eigenaren in de loop, prompt-management.
• Arize Phoenix: gebouwd op OpenTelemetry (een open standaard voor het loggen van events, metrieken en traces in productie-systemen), stack-onafhankelijk (werkt met elk LLM-app-raamwerk zoals LangChain en LlamaIndex en met elke modelaanbieder, zoals OpenAI en Anthropic), self-hostbaar.

Beslis-vuistregels: voor een engineering-team met sterke testcultuur: DeepEval plus Braintrust. Voor een RAG-pijplijn: Ragas plus Langfuse of Phoenix. Voor agentische systemen onder compliance-regime: Inspect AI. Voor een team dat al diep in LangChain zit: LangSmith. Voor leveranciersneutraliteit met self-hosting: Phoenix.

Het koppelpunt met andere bouwstenen en guardrails

De evaluation loop staat nooit op zichzelf. Hij raakt elk van de andere zes BeeHaive-bouwstenen: Knowledge (BB_01: domein-expertise externaliseren tot reproduceerbare kwaliteitscriteria) levert eval-criteria en een bron-van-waarheid, Client Blueprint (BB_02: van waarde-stroom naar AI-ontwerp) bepaalt welke succescriteria überhaupt waardevol zijn, Dynamic Context wordt geëvalueerd op verankering in de bronnen (grounding) en feitelijke grond (faithfulness), Prompt Design (BB_04: de kunst van de juiste instructie) doorloopt regressietests bij elke wijziging — geautomatiseerde controles of een aanpassing eerder werkende functionaliteit niet kapotmaakt — Tool Integration wordt getoetst op tool-correctheid (klopt elke tool-aanroep en het gekozen pad door de tools heen), en Model Engines (BB_06: modelkeuze als ontwerpvraag) worden onderling vergeleken op de daadwerkelijke use case.

Tegelijk raakt de loop direct aan vier guardrails:

• Human Agency-guardrail (GR_01: mensen behouden controle): zonder mens die beslist op bevindingen is “automatische optimalisatie” een mooi woord voor regie kwijt; de loop sluit alleen via menselijk eigenaarschap.
• Robustness-guardrail (GR_02: betrouwbaarheid onder alle omstandigheden): bewaking op drift (sluipende kwaliteitsdaling) en regressietests zijn de operationele invulling van betrouwbaarheid.
• Fairness-guardrail (GR_05: gelijke behandeling, geen systematische benadeling): structurele bewaking op bias (systematische scheefstand in uitkomsten over groepen) binnen de evaluation loop, niet een eenmalige controle.
• Accountability-guardrail (GR_07: duidelijk wie verantwoordelijk is): elke evaluatieronde gekoppeld aan een verbeteractie of een gemotiveerde no-action maakt verantwoording afdwingbaar; vanaf 2 december 2027 is dat wettelijk verplicht voor Bijlage III hoogrisico-systemen (verschoven van augustus 2026 via het Digital Omnibus-akkoord van 7 mei 2026).