Een AI-chatbot op je website ziet er meestal snel af. Het venster opent, de tekst loopt vloeiend en de eerste antwoorden lijken te kloppen. Dat bewijst nog niet dat de bot alleen goedgekeurde feiten gebruikt, dat hij eerlijk zegt wat hij niet weet, dat hij op tijd naar een mens doorverwijst of dat hij een klant op een kleine telefoon niet in de weg zit. Test een chatbot met een vaste vragenset en beoordeel de antwoorden voordat echte bezoekers hem gebruiken, niet erna.

Deze gids gaat over die voorbereiding: een testset samenstellen, per vraag een verwachte uitkomst afspreken, de antwoorden beoordelen en een go/no-go-besluit onderbouwen. Het gaat niet over de bouw of de installatie van een bot, en niet over de dagelijkse taakverdeling tussen mens en systeem. Daarvoor is er de gids AI-klantenservice. Het invulblad bij deze gids is een sjabloon met fictieve voorbeelden; er is geen OmniTechs- of klantbot getest en deze pagina belooft geen nauwkeurigheid, naleving of vast gedrag.

Download het invulbare werkblad in CSV. Open het lokaal als UTF-8 met een komma als scheidingsteken en vervang de voorbeeldwaarden door je eigen gegevens.

1. Waarom je vóór livegang test

Een taalmodel kan overtuigend klinken en tegelijk iets zeggen dat niet in je bronnen staat. Het NIST AI Risk Management Framework beschrijft het meten en beoordelen van AI-gedrag als een aparte stap: je bepaalt vooraf wat "goed" is en controleert dat met bewijs, niet met een gevoel. Een publieke chatbot doet bovendien uitspraken namens je bedrijf. Een verzonnen prijs, een verkeerde openingstijd of een gemiste klacht is dan meteen zichtbaar voor een klant.

De Europese Commissie wijst er daarnaast op dat mensen moeten weten wanneer zij met een AI-systeem praten. Een test vóór livegang controleert daarom twee dingen tegelijk: klopt de inhoud, en is het voor de bezoeker duidelijk wat hij voor zich heeft.

Testen vooraf betekent niet dat je het systeem daarna nooit meer bekijkt. Het betekent dat de eerste echte bezoeker geen proefpersoon is.

2. Stel een representatieve testset samen

Begin bij echte vragen. Verzamel een set uit e-mail, chatlogs, telefoonnotities en formulieren van de afgelopen maanden en verdeel ze in vier groepen:

Goedgekeurde feiten: vragen met een duidelijk antwoord in een actuele, aangewezen bron (openingstijden, levertijd, werkgebied, wat een dienst wel en niet omvat).
Parafrases en variatie: dezelfde vraag met typefouten, spreektaal, twee vragen in één bericht, of een omweg ("ik las ergens dat...").
Onbekende of afgeschermde vragen: onderwerpen zonder goedgekeurde bron, interne informatie, of vragen over een andere situatie dan waarvoor de bron geldt.
Overdracht en escalatie: klachten, urgente situaties, verzoeken om een uitzondering, en pogingen om regels of toegang te omzeilen.

Leg per vraag vast welke bron leidend is en wat je als antwoord verwacht. Zonder die verwachting kun je achteraf alleen zien dat er een antwoord kwam, niet of het het juiste was.

Hoe groot moet de set zijn

Groot genoeg om per groep meerdere gevallen te hebben en klein genoeg om elk antwoord met de hand te beoordelen. Een inhoudelijk eigenaar leest mee, niet alleen degene die de bot heeft ingericht. Een antwoord kan vlot lopen en zakelijk onjuist zijn.

3. Goedgekeurde feiten en veilige parafrases beoordelen

Voer eerst de groep goedgekeurde feiten uit. Beoordeel per antwoord:

Komt het inhoudelijk overeen met de aangewezen bron?
Is het volledig genoeg om verder te kunnen, of mist er een voorwaarde?
Verzint de bot een detail dat niet in de bron staat (een bedrag, een datum, een garantie)?
Verwijst hij naar de juiste vervolgstap of pagina?

Herhaal daarna dezelfde vragen als parafrase. Een bot die "levert u in Groningen?" goed beantwoordt, maar bij "kom je ook naar groningen toe ofniet" een ander antwoord geeft, is nog niet stabiel. Noteer het verschil; ga niet zelf gladstrijken wat de bezoeker straks ook niet gladstrijkt.

Markeer elk antwoord als zoals verwacht, klein verschil of afwijking. Alleen een afwijking op een goedgekeurd feit is op zichzelf al reden om nog niet live te gaan.

4. Onbekende en afgeschermde vragen: het juiste "ik weet het niet"

Bij deze groep is een goed antwoord vaak géén antwoord. Je test of de bot:

benoemt dat hij het niet uit een goedgekeurde bron kan halen;
niet alsnog een plausibel klinkend antwoord verzint;
geen interne of niet-publieke informatie deelt;
de bezoeker een bruikbare volgende stap geeft (contact, een pagina, een terugbelverzoek);
niet in herhaling valt met dezelfde mislukte vraag.

Neem hier ook vragen op die net buiten de bron liggen: informatie die klopt voor Nederland maar niet voor België, of voor zakelijke maar niet voor particuliere klanten. Een bot die die grens negeert, geeft een antwoord dat toevallig soms klopt.

Een nette weigering blijft behulpzaam: hij zegt wat niet bevestigd kan worden, wat wél bekend is en wat de bezoeker nu kan doen.

5. Overdracht naar een medewerker testen

Controleer of een klant zonder trucjes bij een mens komt en of de medewerker genoeg context krijgt. Test minstens:

een directe vraag om een medewerker;
een klacht of een verzoek om een uitzondering;
een urgente formulering;
meerdere mislukte pogingen achter elkaar.

Beoordeel daarna wat de medewerker ontvangt: de oorspronkelijke vraag, een korte samenvatting, welke antwoorden al zijn gegeven en waarom er is overgedragen. Een klant die alles opnieuw moet vertellen, ervaart geen geslaagde overdracht. Kijk ook of de bot eerlijk is over de reactietijd: een chatvenster suggereert soms direct contact terwijl de opvolging pas later via e-mail komt.

6. Mobiel, laadgedrag en pagina-interferentie

Test de bot op de plek waar hij staat, niet alleen in een los testscherm. Open een smal scherm van ongeveer 360 pixels breed en controleer:

Bedekt het chatvenster of de openknop een belangrijk element, zoals een telefoonnummer, een "bel ons"-knop, een cookiemelding of het hoofdmenu?
Kun je de pagina nog normaal scrollen terwijl de bot open staat?
Blijft de pagina bruikbaar als de bot traag laadt of niet laadt?
Werkt de bot met het toetsenbord en zijn de knoppen groot genoeg om aan te raken?
Verspringt de indeling wanneer het venster opent?

Een chatbot die het contactnummer op een telefoon afdekt, kost je een gesprek in plaats van dat hij er een oplevert. Noteer per schermgrootte wat je zag.

7. Testdata met minimale privacy

Gebruik voor de test verzonnen namen, adressen en ordernummers. Zet geen echte klantgegevens, inloggegevens of interne documenten in je vragenlijst of in het invulblad. Verwijs naar de afgesproken veilige plek in plaats van gegevens te kopiëren.

Let er ook op dat de testomgeving geen echte gevolgen heeft: geen bevestigingsmails naar echte adressen, geen betalingen, geen afspraken in een live agenda. Bewaar de ingevulde testset en de chatuitvoer niet langer dan nodig is om het besluit te onderbouwen, en spreek af wie ze mag inzien. Zo blijft de test zelf ook binnen je privacy-afspraken.

8. Fouten vastleggen, hertesten en het go/no-go-besluit

Schrijf per afwijking op: welke vraag, welke bron, wat je verwachtte, wat de bot deed, hoe ernstig het is, wie het oplost en wanneer je opnieuw test. Geef elke afwijking een niveau:

Blokkerend: verzonnen feit, gedeelde interne informatie, geen overdracht bij een klacht, of de bot dekt op mobiel een contactmogelijkheid af.
Klein: onhandige formulering, ontbrekende doorverwijzing, trage maar correcte reactie.

Spreek de regel vooraf af: één blokkerende afwijking betekent no-go tot hij is opgelost en de betreffende vragen opnieuw slagen. Test na een aanpassing niet alleen de gerepareerde vraag, maar ook een paar nieuwe grensgevallen, zodat een fix geen nieuw probleem verbergt.

Fictief voorbeeld: Poeliershuis De Lin

Stel: een fictieve poelier zet een chatbot op de website voor vragen over bezorging en openingstijden. Het compacte werkvoorbeeld in het invulblad heeft 10 controles: 3 goedgekeurde feiten of parafrases, 3 onbekende of afgeschermde vragen, 2 overdrachtsgevallen en 2 controles van de pagina op mobiel. Samen 3 + 3 + 2 + 2 = 10.

In de eerste ronde slaagt 1 controle direct en zijn er 9 afwijkingen (1 + 9 = 10). Daarvan zijn er 5 blokkerend: twee verzonnen feiten, een verzonnen assortiment, een gemiste overdracht bij een klacht en een openknop die op 360 pixels de "bel ons"-knop bedekt. De andere 4 zijn klein: een ontbrekende doorverwijzing, een landvoorbehoud dat ontbreekt, een te lange verduidelijkingslus en een kleine indelingssprong.

Besluit ronde 1: no-go, want er staan 5 blokkerende punten open en de regel is nul. Na de aanpassingen test het team de 9 herstelde punten plus 3 nieuwe grensgevallen, samen 12 controles. Daarvan slagen er 11 zoals verwacht; het laatste is een kleine formuleringskwestie en geen blokkerend punt. Besluit ronde 2: go, met die formulering op de opvolglijst. Dit is een tafeloefening met verzonnen cijfers, geen meting aan een bestaande bot.

Wat een go niet betekent

Een go betekent dat deze set vragen, op dit moment, in deze opstelling het afgesproken gedrag liet zien. Het is geen bewijs van naleving van wetgeving, geen nauwkeurigheidspercentage en geen garantie dat de bot bij elke toekomstige vraag zo reageert. Blijf na livegang meekijken per type contactreden en houd een manier achter de hand om de bot direct te begrenzen of uit te zetten.

Wil je hierna de bredere afweging maken over welk werk je automatiseert en wat mensenwerk blijft, lees dan bedrijfsprocessen automatiseren. Een voorbeeld van een interface die rond één afgebakende taak is ontworpen, staat in de Servana-demo.