"Het werkte perfect toen we het demonstreerden."
Dat is zowat de meest gehoorde zin in AI-projecten. Meestal komt hij drie maanden na de oplevering. De demo liep vlot, de eerste tien facturen werden correct geboekt, en dan sluipt er iets binnen dat niemand opmerkt.
Dat is meteen het eigenaardige aan AI-software: ze faalt stil. Klassieke software crasht, gooit een foutmelding, of stopt gewoon. Een taalmodel geeft altijd een antwoord, en dat antwoord klinkt even overtuigend of het nu klopt of niet. Een verkeerd geboekte factuur ziet er precies hetzelfde uit als een juiste, tot iemand bij de btw-aangifte begint te zoeken.
Daarom is testen bij AI geen extraatje op het einde. Het is het enige wat je onderscheidt van hopen dat het goed gaat.
Waarom je hier niet omheen kan
Drie redenen, van praktisch naar juridisch.
Je weet anders niet of je vooruitgaat. Iemand past een prompt aan om één klacht op te lossen. Werkt die aanpassing? Waarschijnlijk wel, voor dat ene geval. Maar wat heeft ze stukgemaakt? Zonder meting is elke wijziging een gok, en na tien wijzigingen weet niemand meer waar je staat.
Het model onder je verandert. Providers brengen nieuwe versies uit, oude worden uitgefaseerd. Een nieuw model dat op alle benchmarks beter scoort, kan op jouw specifieke taak slechter presteren, omdat je prompt deels op het oude model gefit was. Dat is normaal, maar je wil het weten voor je klant het weet.
En sinds deze zomer staat het ook in de wet. Daar komen we zo op terug.
Begin met het onderscheid dat alles bepaalt
Voor je iets meet, splits je je taak op in twee soorten.
Taken met één juist antwoord. Een bedrag van een factuur, een btw-nummer, de juiste grootboekrekening, een classificatie. Hier is kwaliteit gewoon meetbaar: klopt het of niet.
Taken zonder één juist antwoord. Een samenvatting, een supportantwoord, een e-mail. Er is geen enkele juiste versie, maar er zijn wel duidelijk foute versies.
De fout die we het vaakst zien, is dat mensen alles in de tweede categorie duwen ("AI is nu eenmaal moeilijk te meten") terwijl doorgaans het grootste deel van het werk in de eerste categorie zit en dus perfect hard te meten is. Dat onderscheid is ook precies de reden waarom sommige processen zich beter lenen tot automatisering dan andere. We hadden het daar eerder over in wanneer AI niet het antwoord is.
De golden set: saai, en het belangrijkste dat je bouwt
De kern van alles is een vaste verzameling testgevallen met het verwachte resultaat erbij.
Concreet: vijftig tot tweehonderd echte gevallen uit de praktijk, met de hand nagekeken. Geen verzonnen voorbeelden, want die missen net de rommel die in het echt fout gaat: scheve scans, creditnota's, buitenlandse leveranciers, een klant die drie vragen in één bericht propt. Ongeveer zestig procent normale gevallen, veertig procent randgevallen.
Dat labelen is een paar dagen vervelend werk. Het is ook de beste investering in het hele project. Een prompt herschrijf je op een namiddag, maar een geverifieerde testset bouw je niet zomaar opnieuw op.
Eén regel houdt hem levend: elke fout in productie wordt een testgeval. Je set groeit vanzelf mee met de werkelijkheid, en na een jaar is hij meer waard dan de code eromheen.
Zet hem bij je code in versiebeheer. Prompt, modelversie en testset horen samen in één commit, zodat je later altijd kan terugkijken naar wat er precies draaide toen een bepaald resultaat behaald werd.
Meet twee cijfers, geen "accuraatheid"
Voor iets als factuurverwerking zijn er twee getallen die tellen, en ze werken tegen elkaar in:
- Automatiseringsgraad: welk deel gaat zonder mens door.
- Precisie op die stroom: welk deel daarvan klopt effectief.
Een boekhouding accepteert vlot dat zeventig procent automatisch doorgaat als daarvan bijna alles klopt. Ze accepteert nooit dat vijfennegentig procent doorgaat met acht procent fouten, want één verkeerd geboekte factuur kost meer tijd dan tien die je gewoon zelf doet.
Praktisch betekent dat: laat het systeem per veld aangeven hoe zeker het is, en stuur alles onder de drempel naar een mens. Dan stem je die drempel af op je testset in plaats van te hopen. Voor documentverwerking beschreven we die aanpak al uitgebreider in documenten verwerken met AI.
Voor chatsupport is het equivalent: hoeveel gesprekken raken opgelost zonder escalatie, tegenover hoe vaak de bot iets beweert dat niet klopt of buiten scope valt.
Wat de AI Act hiervan verwacht
Welke verplichtingen precies op jou rusten, hangt af van je rol en je risicocategorie. Dat hebben we uitgeschreven in De AI Act: wat is de impact op KMO's?. Hier beperken we ons tot het stuk dat over testen gaat, want daar is de wet opvallend concreet.
Voor systemen met een hoog risico (denk aan software die cv's sorteert of kredietwaardigheid inschat) staat testen letterlijk in de tekst. Artikel 9 van de AI-verordening vraagt dat je test tegen vooraf gedefinieerde metrieken en drempelwaarden. Artikel 15 vraagt dat je de behaalde nauwkeurigheid en de gebruikte metrieken vermeldt in je gebruiksinstructies. Die verplichtingen gaan in op 2 december 2027.
Lees dat stuk even opnieuw: vooraf gedefinieerd. Je legt vast wat je aanvaardbaar vindt, en dan meet je. Niet omgekeerd.
Met andere woorden: wat gewoon goede engineering is, is voor hoogrisicosystemen ook je bewijsmateriaal. Wie zijn evaluatie nu degelijk opzet, moet later vooral opschrijven wat hij al doet. Wie dat niet doet, begint in 2027 opnieuw met labelen.
En bouw je een chatbot, dan geldt er sinds 2 augustus 2026 sowieso iets, ongeacht risicocategorie: die moet duidelijk maken dat hij een AI is. De uitzondering voor gevallen waar dat evident is, is smal. Een klantendienstbot die vlot converseert valt er niet onder. De Europese Commissie publiceerde er richtlijnen over, en de tekst van artikel 50 staat online.
En de GDPR loopt daar los doorheen. Artikel 22 blijft gewoon gelden: geen uitsluitend geautomatiseerde beslissingen met een aanzienlijke impact op iemand. Er moet een mens in de lus zitten die effectief kan afwijken, niet iemand die op "goedkeuren" klikt.
Hoe wij het aanpakken
Bij elk AI-project dat we opleveren hoort een testsuite. Dat betekent in de praktijk:
- Samen de golden set opbouwen uit echte data van de klant, inclusief de gevallen waarvan zij weten dat ze lastig zijn.
- Drempels vooraf vastleggen en dateren, per veld of per criterium.
- De evaluatie in de pijplijn zetten, zodat elke wijziging aan een prompt of model automatisch wordt doorgemeten, met een overzicht van welke gevallen omsloegen. Niet alleen het gemiddelde. Een wijziging die er vijf wint en vier verliest, ziet er in het gemiddelde uit als vooruitgang.
- De modelversie vastpinnen op een exacte snapshot, nooit op een alias die stilletjes verandert.
- Bij een modelwissel eerst in schaduw draaien op echte input zonder dat de output gebruikt wordt, dan geleidelijk uitrollen, met de mogelijkheid om terug te schakelen.
- Correcties van gebruikers terugvoeren naar de testset. Als een boekhouder een voorgestelde boeking aanpast, is dat gratis en geverifieerd testmateriaal.
We werken daarvoor met tooling die je zelf kan draaien, op Europese servers. Dat past bij hoe we alles bouwen: geen vendor lock-in, de klant houdt zijn code, data en infrastructuur.
Als je morgen zou beginnen
Neem vijftig echte gevallen. Label ze met de hand. Schrijf een script dat per veld de correctheid uitrekent en zorg dat het automatisch draait bij elke wijziging.
Dat alleen al zet je verder dan de meeste AI-implementaties die we in het wild tegenkomen. De rest bouw je daarop, en het sluit naadloos aan bij de aanpak die we sowieso aanraden: begin klein, denk groot.
En een AI-implementatie zonder testset is geen implementatie. Dat is een demo die toevallig in productie staat.
Zit je met een AI-implementatie waarvan je niet zeker weet of ze nog doet wat ze moet doen? Of wil je er een opzetten die je wél kan opvolgen? Neem contact op, we kijken er graag samen naar.
Dit artikel is algemene informatie, geen juridisch advies. Voor een concrete inschatting van je verplichtingen onder de AI Act raden we een gesprek met een jurist aan.
