AI Strategie

Hoe weet je of je AI het goed doet? Kwaliteit meten zonder datascientist

Kwaliteit van AI meten zonder datascientist: de gouden set, twee soorten fouten en een steekproef die je zelf bijhoudt. Een werkwijze voor het mkb.

AI WorkTalent Redactie · 29 juli 2026 · 10 min leestijd

Een AI-toepassing live zetten is inmiddels het makkelijke deel. Het moeilijke deel begint daarna: hoe weet je, drie maanden verder, nog of hij goed werkt? De meeste mkb-bedrijven hebben daar geen antwoord op. Ze merken pas dat er iets misgaat zodra een klant erover belt of een collega het toevallig ziet. Dit artikel laat zien hoe je dat zonder datascientist wél kunt meten.

Waarom "het lijkt goed te werken" niets zegt

Als je zelf af en toe meekijkt met wat je AI-toepassing doet, valt het meestal wel mee. Dat is geen toeval, het is een vertekening: de fouten die je ziet, zijn de fouten die opvallen. Een klant die boos belt omdat een offerte totaal verkeerd was, een collega die per ongeluk een rare AI-reactie doorstuurt in de groepsapp — dat soort dingen bereikt je vanzelf. Fouten die niemand hardop meldt, bereiken je niet.

En de meeste mensen melden een fout niet hardop. Een klant die een net iets te formeel of net iets te vaag antwoord krijgt, klaagt zelden — hij haakt af, belt de concurrent, of zoekt het antwoord toch zelf op. Een medewerker die merkt dat een AI-samenvatting een detail mist, corrigeert het stilletjes en gaat verder, zonder dat ergens vast te leggen. Die stille gevallen bepalen precies je kwaliteit. Het zijn ook precies de gevallen die "het lijkt goed te werken" niet meet. Je onderbuikgevoel is gebaseerd op een steekproef die zichzelf heeft geselecteerd op de meest opvallende fouten. En dat is de slechtst mogelijke steekproef om een oordeel op te baseren.

De oplossing is niet nog scherper opletten. De oplossing is een systeem dat niet afhankelijk is van wat toevallig opvalt.

Kwaliteit van AI meten met een gouden set: je eigen meetlat

De belangrijkste techniek in dit artikel is ook de eenvoudigste: een vaste verzameling echte voorbeelden uit je eigen praktijk, met daarbij het antwoord dat er destijds goed uitkwam. Ook de makers van de grote taalmodellen werken zelf zo. OpenAI en Anthropic publiceren hier eigen richtlijnen over, waarin ze aanraden het aantal voorbeelden belangrijker te vinden dan de perfectie ervan. Voor een mkb-bedrijf zijn vijftig tot honderd voorbeelden in de praktijk een haalbaar startpunt. Zo bouw je er een op.

• Verzamel vijftig tot honderd echte gevallen. Geen verzonnen voorbeelden, maar e-mails, aanvragen, tickets of transacties uit je eigen historie. Neem vooral gevallen die representatief zijn voor wat er dagelijks binnenkomt, en meng daar bewust een aantal lastige of grensgevallen doorheen — juist die zeggen het meest over kwaliteit.
• Leg voor elk geval het juiste antwoord vast. Iemand die het onderwerp kent, bepaalt wat het correcte antwoord of de juiste beslissing had moeten zijn. Dat hoeft geen technisch iemand te zijn — een medewerker volstaat. Schrijf dat antwoord op naast het voorbeeld. Dit is de referentie waar je later tegen afzet.
• Bewaar de set apart en vast. Dit is geen document dat je steeds aanpast naar wat op dat moment goed uitkomt. De waarde zit er juist in dat de set hetzelfde blijft, zodat je resultaten van verschillende momenten eerlijk kunt vergelijken.
• Reken de set opnieuw door bij elke wijziging. Verandert er iets — een nieuwe versie van het onderliggende model, een aangepaste instructie, een andere leverancier, of een nieuw stukje van je aanbod? Laat de AI-toepassing dan opnieuw alle vijftig tot honderd voorbeelden verwerken en vergelijk de nieuwe antwoorden met de vastgelegde juiste antwoorden.
• Tel wat er goed gaat. Het percentage juiste antwoorden is je meetbare kwaliteitscijfer. Ging dat percentage na een wijziging omlaag, dan weet je dat voordat een klant het je vertelt — niet erna.
• Vul de set aan met wat er in de praktijk misgaat. Iedere keer dat er in het echte gebruik een fout opduikt, voeg je dat geval, met het juiste antwoord erbij, toe aan de gouden set. Zo wordt je meetlat vanzelf strenger op precies de plekken waar het eerder misging.

Deze werkwijze staat in de sector bekend als het bouwen van een "evaluatieset" of "eval" — een term die je bij de grote AI-aanbieders vaak tegenkomt. Vertaald naar het mkb komt het neer op wat hierboven staat: een vaste toets met bekende juiste antwoorden, die je herhaalt zodra er iets verandert. Geen wiskunde, geen model nodig — alleen discipline om de set aan te leggen en trouw te blijven doorrekenen. In de praktijk doe je dat niet met de hand: laat iemand de voorbeelden in een keer door de toepassing halen en de uitkomsten naast de goede antwoorden in een spreadsheet zetten. Reken op een dagdeel voor de eerste keer, en daarna op een uur per ronde zodra de opzet staat. Kan de leverancier de voorbeelden in een batch verwerken, dan is het nog minder werk.

Een voorbeeld ter illustratie

Een webshop in elektronica zet een AI-tool in die retourverzoeken beoordeelt: mag dit artikel zonder verdere vragen retour, of moet een medewerker er eerst naar kijken? De ondernemer verzamelt zeventig retourverzoeken uit het afgelopen half jaar, met daarbij wat er toen terecht is besloten. Daaronder zitten bewust ook een aantal twijfelgevallen, zoals een product dat net buiten de garantietermijn viel of een klacht zonder aankoopbewijs. Verandert er iets aan de tool — een nieuwe instructie, een nieuwe versie van het onderliggende model — dan rekent hij deze zeventig gevallen opnieuw door en telt hij hoeveel de tool er goed heeft. Toen een leverancier het model op de achtergrond verving, zakte dat percentage merkbaar. Zonder de gouden set zou dat pas zijn opgevallen zodra klanten zich begonnen te melden over ten onrechte afgewezen retouren.

Twee soorten fouten — en waarom je er maar één tegelijk kunt terugdringen

Bij vrijwel elke AI-toepassing die een beslissing neemt of een actie onderneemt, zijn er twee verschillende manieren om fout te zitten. De eerste is iets ten onrechte doorlaten: de AI keurt iets goed, beantwoordt een vraag, of voert een actie uit, terwijl dat eigenlijk niet had gemogen. Bij de webshop hierboven is dat een retour goedkeuren die de tool eigenlijk had moeten afwijzen — bijvoorbeeld omdat het product zichtbaar is gebruikt op een manier die niet onder de garantie valt. De tweede is iets ten onrechte tegenhouden: de AI wijst iets af of stuurt het onnodig door naar een mens, terwijl het gewoon had gemogen. Bij de webshop is dat een volkomen legitieme retour die de tool afwijst of doorstuurt, met een geïrriteerde klant en extra werk voor een medewerker tot gevolg.

Het punt waar veel ondernemers overheen kijken: deze twee fouten staan tegenover elkaar. Stel de tool strenger in — laat hem sneller doorverwijzen bij twijfel — dan verkleint dat het aantal ten onrechte goedgekeurde retouren. Maar dan stuurt de tool ook vanzelf meer retouren onnodig door naar een mens. Stel hem soepeler in, en het is precies andersom. Er bestaat geen instelling die beide foutsoorten tegelijk naar nul brengt. Dat is geen tekortkoming van de tool — het is een wiskundig gegeven dat voor elk beoordelingssysteem geldt, van een AI tot een menselijke keurmeester.

Daarom is de belangrijkste stap er een die je voor de techniek doet: bepaal vooraf welke fout voor jouw bedrijf duurder is. Voor de webshop is een ten onrechte goedgekeurde retour een direct financieel verlies en een mogelijke opening voor misbruik — die fout is duur. Een retour die onnodig naar een medewerker gaat, kost een paar minuten werk en soms een geïrriteerde klant — vervelend, maar zelden schadelijk. Deze webshop kiest er dus bewust voor de tool aan de strenge kant in te stellen, wetend dat dit meer werk voor medewerkers oplevert. Een ander bedrijf, waar snelheid en klanttevredenheid zwaarder wegen dan een enkel financieel verlies, zou bewust de andere kant op kunnen kiezen. Er is geen universeel juist antwoord — er is alleen een antwoord dat je zelf vooraf bepaalt, in plaats van dat de instelling van de tool het toevallig voor je beslist.

Wanneer is een verschil groot genoeg om iets te betekenen?

Een meting is pas bruikbaar als je weet wat ruis is. Bij een set van zeventig gevallen is een verschil van één of twee gevallen niets: zo'n verschil krijg je ook door toeval in welke gevallen je koos en door de natuurlijke variatie van het model. Een verschuiving van een paar procentpunt zegt op die schaal weinig. Vuistregel: bij enkele tientallen gevallen neem je pas iets serieus vanaf een verschil van ongeveer tien procentpunt, en kijk je vooral naar de richting over meerdere metingen. Zakt het percentage drie metingen op rij, dan is het tijd om te kijken wat er speelt, ook als elke stap op zichzelf klein is. Eén uitschieter is nog geen trend.

Spreek daarnaast vooraf af welk niveau "goed genoeg" is. Dat niveau is geen honderd procent, maar wat je nu met mensenwerk haalt. Meet dat eerst, en gebruik het als ondergrens.

Waar deze methode niet werkt

Wees eerlijk over de grens van deze aanpak. Tellen wat er goed gaat werkt alleen als er een juist antwoord bestaat: wel of geen retour, de juiste categorie, het juiste bedrag. Laat je AI een e-mail schrijven of een gesprek samenvatten, dan is er geen enkel goed antwoord om tegen af te tellen. Daar meet je anders: laat twee collega's onafhankelijk een cijfer geven op een paar punten (klopt het feitelijk, is de toon goed, staat het er begrijpelijk), en kijk of dat cijfer over de tijd zakt. Dat is subjectiever, maar wel herhaalbaar zolang dezelfde mensen dezelfde punten beoordelen.

Steekproefsgewijze controle zodra de AI draait

De gouden set vertelt je of een wijziging de kwaliteit heeft aangetast. De set vertelt je niet hoe de AI het doet op de aanvragen van vandaag, die per definitie niet in je vaste set zitten. Daarvoor heb je een lopende steekproef nodig: een klein, vast aantal recente gevallen dat een mens er regelmatig doorheen haalt.

Klein hoeft geen probleem te zijn. Neem bijvoorbeeld twintig recente gevallen per week bij hoog volume, of alle gevallen van de afgelopen maand bij laag volume — dat is al genoeg om een trend te zien voordat die een probleem wordt. Waar het om gaat, is regelmaat: dezelfde persoon of dezelfde criteria, op een vast moment, zodat je de uitkomst van de ene periode eerlijk kunt vergelijken met de volgende. Doe je de steekproef alleen als er toevallig tijd voor is, dan levert dat geen trend op — alleen losse momentopnames.

Bouw de steekproef bovendien niet uit willekeurige gevallen, maar met een lichte voorkeur voor de gevallen waar twijfel over kan bestaan — grensgevallen, ongebruikelijke aanvragen, situaties die niet in de gouden set zaten. De simpele, voor de hand liggende gevallen gaan vrijwel altijd goed en zeggen weinig; de twijfelgevallen zijn waar kwaliteitsverlies zich het eerst laat zien. Dezelfde discipline die bij de webshop hierboven de gouden set opbouwt, geldt hier: wat de steekproef laat zien, voegt zich toe aan die set.

Signalen dat je AI stilletjes is verslechterd

Een AI-toepassing die achteruitgaat, geeft zelden een foutmelding. Hij blijft gewoon antwoord geven, maar de kwaliteit daarvan zakt onopgemerkt. Drie situaties waarin dat vaker gebeurt dan ondernemers verwachten:

• Een modelupdate bij de leverancier. De partij achter het onderliggende AI-model vervangt of verbetert dat model regelmatig, vaak zonder dat jij daar als afnemer een melding van krijgt. Meestal wordt een model daardoor beter, maar niet gegarandeerd op precies de taak waar jij hem voor gebruikt — een verbetering op het ene vlak kan op een ander vlak net iets anders uitpakken.
• Veranderde invoer. Denk aan een nieuwe lay-out van je webformulier, een andere manier waarop een leverancier zijn facturen aanlevert, of een gewijzigd sjabloon van een e-mailprogramma. Dat soort schijnbaar kleine wijzigingen aan de kant van de invoer kan subtiel verstoren hoe de AI die invoer leest.
• Een nieuw soort aanvraag. Zodra je bedrijf een nieuw product, een nieuwe dienst of een nieuwe klantgroep toevoegt, komen er vragen binnen waarop het systeem nooit is getest. De gouden set bevat daar dan nog geen voorbeeld van. Breidt de webshop hierboven bijvoorbeeld uit met tweedehands elektronica, dan gelden voor retouren heel andere afwegingen dan voor nieuwe producten — en daar heeft de tool nog geen enkel bewezen antwoord op.

Geen van deze drie situaties veroorzaakt een foutmelding. Precies daarom zijn twee dingen geen overbodige luxe: een gouden set die je periodiek herhaalt, en een steekproef die blijft doorlopen zodra de toepassing draait. Ze zijn het enige dat dit soort stille achteruitgang zichtbaar maakt — lang voordat een klant het je vertelt. Dat sluit aan bij een les die vaker naar voren komt bij het klaarmaken van een AI-toepassing voor dagelijks gebruik: een werkende proef is nog geen systeem waar je op kunt vertrouwen.

Wat je meet, hoe vaak, en wie het bekijkt

Een overzicht om dit meetsysteem concreet in te richten voor een gemiddeld mkb-bedrijf:

Dit hoeft geen zwaar systeem te zijn — voor de meeste mkb-bedrijven past het in een spreadsheet en een terugkerende afspraak in de agenda. Wat telt, is dat het gebeurt, ook als er niets lijkt mis te gaan. Vermoed je dat de AI niet alleen de verkeerde dingen doet, maar ook onjuiste feiten opschrijft, dan is dat een verwant probleem met een eigen aanpak. Dat beperk je aan de invoerkant: laat het model alleen antwoorden op basis van bronnen die je zelf meestuurt, en sta het expliciet toe om te zeggen dat het iets niet weet. Helemaal uitsluiten kun je verzonnen antwoorden daarmee niet, wel flink terugdringen.

Kwaliteit van AI meten vraagt geen datascientist, wel discipline: een gouden set die je bij elke wijziging opnieuw doorrekent, een bewuste keuze voor welke fout je erger vindt, en een kleine steekproef die blijft doorlopen zodra de toepassing draait. Wil je dit meetsysteem laten inrichten of vind je het lastig om zelf te bepalen wat de duurste fout is voor jouw situatie, zie de gids voor het inhuren van een AI-expert. Op AI WorkTalent vind je specialisten die kwaliteitsbewaking als vast onderdeel van een AI-implementatie meenemen.