Verzonnen antwoorden zijn het grootste bezwaar tegen AI in de klantenservice, en het is vooral een zoek- en rechtenprobleem in plaats van een modelprobleem. De maatregelen die echt helpen.
Ook beschikbaar in het Engels: How to stop your support AI from making things up
Vraag een klantenservicemanager waarom er nog geen AI vooraan staat en je krijgt een variant op: straks verzint hij een beleid dat we niet hebben. Dat is een terechte zorg. Het is in een supportcontext ook een van de beter oplosbare, want de fout ontstaat bijna nooit in de fantasie van het model. Hij ontstaat in wat het model kreeg aangeleverd, en in wat het mocht doen toen dat materiaal opraakte.
Ze op één hoop gooien is precies waarom het probleem onoplosbaar voelt. Uit elkaar getrokken heeft elke fout een andere en tamelijk saaie oplossing.
| Fout | Hoe het eruitziet | De echte oplossing |
|---|---|---|
| Zoekfout | De klant vraagt naar beleid dat wél bestaat, maar de zoekstap leverde niets relevants op en het model vulde de leegte met algemene kennis. | Een contentprobleem, geen modelprobleem. Zoek de vragen die niets opleveren en schrijf het ontbrekende artikel. |
| Verouderde bron | Het antwoord komt met overtuiging en klopte vorig kwartaal nog. Het artikel is nooit bijgewerkt. | Herzieningsdata en één canonieke pagina per feit. Het model herhaalt trouw wat jij hebt opgeschreven. |
| Ongeremd genereren | Het materiaal was dun, de instructie verbood doorredeneren niet, en het model produceerde een geloofwaardig klinkend beleid. | Expliciete instructies om alleen uit bronmateriaal te antwoorden, plus een nooduitgang die loont. Alleen dit is echt modelgedrag. |
Een model zonder acceptabele manier om te falen, faalt op een onacceptabele manier. Moet elke beurt een antwoord opleveren terwijl het bronmateriaal er geen bevat, dan moet er iets wijken — en wat wijkt is de juistheid. De oplossing is weinig spectaculair: instrueer het systeem alleen te antwoorden uit aangeleverd materiaal, nooit beleid, prijzen of ordergegevens te verzinnen, en als het iets niet weet dat gewoon te zeggen en over te dragen aan een mens. Die instructie is alleen iets waard als de overdracht echt bestaat en werkt; een nooduitgang die op een muur uitkomt leert hetzelfde gedrag aan als helemaal geen uitgang.
De schadelijkste verzinsels in support zijn niet verkeerde beleidsregels maar verkeerde specifieke gegevens: een bezorgdatum, de status van een terugbetaling, een abonnementsvorm. Die horen nooit uit de redenering van een model te komen. Ze komen uit een opzoeking in het systeem, ná verificatie van de identiteit van de klant, of ze worden niet genoemd. Dat onderscheid weegt genoeg dat de identiteitscontrole en het neutrale antwoord bij een mismatch in de zoekroute zitten en niet in de instructie — een instructie is een verzoek, geen beheersmaatregel. Waar dat zit staat op het functie-overzicht.
In Nederland heeft dit bovendien een juridische kant die vaak wordt vergeten. Verzint je assistent een ruimere bedenktijd of een coulanceregeling die je niet voert, dan is dat richting de consument een mededeling die je lastig terugneemt. Wat er wél geldt en hoe je dat vastlegt staat in retourrecht en bedenktijd in je klantenservice.
De meeste demo's draaien op zorgvuldig ingerichte content waarin de zoekstap nooit faalt, waardoor het interessante gedrag nooit langskomt. Vraag daarom: wat doet het systeem als de zoekstap niets oplevert — weigeren of improviseren? Kan ik de bronpassages zien achter een gegeven antwoord? Zijn die bronnen zichtbaar voor mijn medewerkers, en apart daarvan: kunnen ze aan klanten getoond worden? Kan ik een grens instellen waaronder hij opschaalt in plaats van antwoordt? En wat bewaart het logboek, zodat een klacht te reconstrueren is? Onze eigen antwoorden staan in de documentatie en op hoe wij meten.
Eén voorbehoud dat leveranciers zelden hardop maken: hiermee gaat het foutpercentage niet naar nul, en wie anders suggereert is aan het verkopen. Het realistische doel is dat fouten zeldzaam zijn, zichtbaar, begrensd tot omkeerbare acties, en herleidbaar tot een bron die je kunt repareren. Dat is haalbaar. Perfectie niet, en daarom weegt de goedkeuringswachtrij uit AI-agent of chatbot zwaarder dan welke instructie ook.
In een supportcontext komt dat meestal doordat de zoekstap niets relevants opleverde of een verouderd artikel teruggaf, terwijl het systeem niet verplicht was om af te haken toen het bronmateriaal tekortschoot. Veel minder vaak ligt het aan slecht redeneren door het model. Dat is belangrijk, want de eerste twee oorzaken los je op met content schrijven en onderhouden, wat gewoon operationeel werk is.
Beperk hem tot antwoorden uit aangeleverd bronmateriaal, benoem de verboden categorieën expliciet zoals beleid, prijzen en ordergegevens, en geef hem de uitdrukkelijke opdracht te zeggen dat hij het niet weet en op te schalen naar een medewerker als het materiaal de vraag niet dekt. Die uitweg werkt alleen als de overdracht daadwerkelijk bij een mens uitkomt, anders leert het systeem dat afhaken geen begaanbare route is.
Ja, en dat is de beter oplosbare helft van het probleem. Order- en accountgegevens horen uit een geverifieerde systeemopzoeking te komen in plaats van uit het model, wat betekent dat de identiteit van de klant eerst wordt vastgesteld en dat een mismatch een neutraal antwoord oplevert in plaats van een gok. Dat afdwingen in de zoekroute in plaats van in de formulering van de instructie maakt er een beheersmaatregel van in plaats van een verzoek.
Vraag hem naar beleid waarvan je zeker weet dat je het nergens hebt vastgelegd. Een goed ingericht systeem zegt dat het dat niet zeker weet en biedt een medewerker aan; een slecht ingericht systeem produceert een overtuigend en geloofwaardig antwoord. Herhaal dit met vragen waarvan het antwoord recent is veranderd, want fouten door verouderde bronnen zijn onzichtbaar voor het model en komen even overtuigend naar buiten als juiste antwoorden.
Het percentage heropende gesprekken binnen een vastgestelde termijn, want een overtuigend gebracht fout antwoord scoort identiek op oplospercentage, eerste reactietijd en vaak ook op de directe tevredenheidsscore. De klant ontdekt de fout later en komt terug, dus elke oplostelling zonder wachtperiode overschat de kwaliteit juist daar waar die het slechtst is.
2026-08-20 · 10 min leestijd
Google schrapte de FAQ-resultaten in juni 2026, maar AI-assistenten citeren supportcontent nog volop. Wat een citatie oplevert en welke structuurwijzigingen je artikelen citeerbaar maken.
2026-08-09 · 9 min leestijd
Gesloten tickets, afhandeltijd en een kale klanttevredenheidsscore overleven in rapportages omdat ze er altijd goed uitzien. Dit meet je in plaats daarvan, en zo zie je of een cijfer wordt bespeeld.
2026-08-09 · 9 min leestijd
Je klanten antwoord geven in hun eigen taal zonder je kennisbank drie keer te onderhouden kan prima — maar alleen als je weet welke artikelen wél meeverhuizen naar een andere markt en welke stiekem onjuist worden.
Kijk hoe eerlijk gemeten AI-oplossingen je supportdruk verlagen — begin op het gratis plan, zonder creditcard en zonder verkoopgesprek.