Kort samengevat: geen enkel bedrijf heeft een nieuwe manier bedacht om mensen te verifiëren op het moment dat het een AI Voice Agent invoerde. Banken bevestigen risicovolle acties nog altijd via hun eigen app. Retailers controleren nog altijd een bestelnummer en een postcode. Contactcenters stellen nog altijd een handvol kennisgebaseerde vragen. Een AI Voice Agent vervangt niets daarvan — het is de conversationele laag die de juiste vraag stelt, op de juiste bevestiging wacht, en weigert door te gaan totdat de verificatie die het bedrijf al vertrouwt, ook daadwerkelijk is doorlopen.

Dat laatste punt is belangrijker dan het klinkt. Een voice agent die simpelweg vraagt “wat is uw geboortedatum?” en het antwoord voor waar aanneemt, verifieert niemand — die verzamelt informatie die een fraudeur in dertig seconden had kunnen opzoeken. Echte verificatie hangt af van waar de controle daadwerkelijk plaatsvindt: in een bankapp, tegen een gemeentelijk register, in een CRM-record, of helemaal nergens.

Hoe verschillende sectoren bellers vandaag daadwerkelijk verifiëren

Niemand begint hier bij nul. Elke sector die telefonisch met vreemden praat, heeft al een verificatiemodel gebouwd rond wat die zich kan veroorloven fout te doen.

Banken en financiële dienstverleners vertrouwen het telefoongesprek zelf grotendeels niet meer. Een risicovolle actie — een grote overschrijving, het deblokkeren van een kaart, een wachtwoordreset — wordt steeds vaker doorgeschoven naar de bankapp: een pushnotificatie die de klant goedkeurt met een vingerafdruk, gezichtsscan of pincode, binnen een omgeving die de bank volledig zelf beheert. Dit is in de EU niet slechts een voorkeur van de bank — de regels voor Strong Customer Authentication onder PSD2 (Verordening (EU) 2018/389) vereisen twee onafhankelijke authenticatiefactoren voor precies dit soort acties, en dat is waarom de app, en niet het telefoongesprek, het daadwerkelijke bewijs levert. Het telefoongesprek kan de klant vragen die stap te voltooien. Het kan die stap niet namens de klant afronden, en dat moet het ook niet proberen.

E-commerce en retail hebben doorgaans niet dat niveau van zekerheid nodig voor een vraag over retouren of orderstatus, dus gebruiken ze het ook niet. Een bestelnummer plus een postcode van het factuuradres — hetzelfde patroon dat adresverificatiesystemen al jaren gebruiken — volstaat meestal om de vraag “waar is mijn pakket” te beantwoorden, juist omdat er niets gevoeligs wordt geautoriseerd.

Contactcenters in bredere zin — verzekeraars, nutsbedrijven, telecom, zorgverleners — leunen nog altijd zwaar op kennisgebaseerde verificatie: naam, geboortedatum, klantnummer, adres zoals bekend in het systeem. Het is vrijwel overal de standaard, niet omdat het sterk is, maar omdat het goedkoop is en omdat de backendsystemen daar al op zijn ingericht.

De zwakke schakel: vertrouwen op het telefoongesprek zelf

Banken hebben verificatie naar de app verplaatst omdat het gesprek zelf weinig bewijst.

Beller-ID is geen identiteitsbewijs — het is een label dat het netwerk standaard vertrouwt. Ongeautoriseerde simswaps die op dat vertrouwen inspelen, stegen met 1.055% op jaarbasis in zaken die in 2024 bij de Britse National Fraud Database werden gemeld, waarbij mobiele accounts 48% van alle meldingen van accountovername uitmaakten (Cifas, Fraudscape 2025).

Toezichthouders trekken dezelfde conclusie. In de VS verplicht de FCC providers inmiddels om klanten te authenticeren vóór elke simswap of nummerportering, en om direct een melding te sturen zodra dat gebeurt (FCC-regel over simswap- en nummerporteringsfraude) — een directe erkenning door de toezichthouder dat een telefoonnummer alleen nooit een veilige manier was om iemand te herkennen.

Kennisgebaseerde verificatie heeft een eigen, beter gedocumenteerde zwakte. Dezelfde feiten die een legitieme klant verifiëren — geboortedatum, adres, een klantnummer — zijn ook de feiten die het vaakst zijn blootgesteld bij eerdere datalekken. Dat is precies waarom de Amerikaanse norm NIST SP 800-63-4 (van kracht sinds augustus 2025) nu expliciet stelt dat kennisgebaseerde verificatie niet mag worden gebruikt voor identiteitsverificatie, en dit voorbehoudt aan een beperkt aantal uitzonderingen binnen fraudebeheer (NIST SP 800-63A).

Niets hiervan is uniek voor voice AI — het is exact dezelfde reden waarom een menselijke medewerker die diezelfde drie vragen stelt, precies even kwetsbaar is. De FTC registreerde in 2024 bijna 850.000 meldingen van identiteitsfraude (FTC), onderdeel van de 12,5 miljard dollar aan fraudeschade die consumenten dat jaar in alle categorieën samen rapporteerden (FTC Consumer Sentinel Network Data Book 2024) — een herinnering dat wie er ook aan de andere kant van de lijn zit, mens of AI, werkt met hetzelfde onvolmaakte signaal.

Waar een AI Voice Agent daadwerkelijk past

Dit is het punt waarop het makkelijk misgaat: een AI Voice Agent is geen beveiligingsproduct. Het beheert geen identiteitsdatabase, doet niet aan stembiometrie, en is geen vervanging voor de app van een bank of de fraudestack van een retailer. Waar het wél goed in is: consistent, elke keer opnieuw, afdwingen welk verificatieproces het bedrijf al goed genoeg heeft bevonden — en weigeren om door te gaan wanneer daar niet aan is voldaan.

AssistYou’s Flow Builder behandelt Identificatie & Verificatie als een strikte poort, niet als een suggestie waar de AI zich uit kan praten. Zoals we eerder schreven in waarom enterprise voice agents strikte schema’s nodig hebben, kunt u een taalmodel niet zomaar een CRM-API in handen geven en erop vertrouwen dat het identiteitsverificatie zelf wel uitzoekt — een conversationeel model zonder vangrails laat zich mogelijk verleiden tot herhaalde verificatiepogingen die geleidelijk accountgegevens blootleggen waar een aanvaller aanvankelijk geen toegang toe had. Een schema sluit die deur: het legt precies vast welke gegevens verzameld en tegen de backend bevestigd moeten worden voordat de flow überhaupt een gevoelige API mag aanroepen.

In de praktijk is die backend altijd iets wat het bedrijf al zelf bezit:

• Een CRM of klantendatabase, gecontroleerd op dezelfde manier waarop IVR-systemen al jaren bellers opzoeken — naam, klantnummer en adres worden vergeleken met het record in het systeem voordat er iets gevoeligs gebeurt.
• Een officieel extern register — hetzelfde patroon dat onze adresvalidatie-nodes gebruiken om een gesproken adres te toetsen aan het Nederlandse BAG-register, in plaats van aan te nemen dat de AI simpelweg weet hoe een geldig adres eruitziet. Identiteit werkt op dezelfde manier: de voice agent stelt de vraag, en het register of de backend die de klant al vertrouwt, geeft het antwoord.
• Een live overdracht naar welke bevestiging de eigen systemen van de klant ook vereisen — als een bank al app-gebaseerde pushbevestiging heeft ingericht, is het de taak van de voice agent om de beller te vragen de app te controleren en te wachten op een bevestigde status voordat het gesprek doorgaat, niet om zelf een eigen versie van die controle te verzinnen.

Dat is ook waarom AssistYou geen stembiometrie als product aanbiedt. Los van de complexiteit rond nauwkeurigheid en toestemming, valt biometrische identificatie onder de hoogrisicocategorie van Bijlage III van de EU AI Act, samen met kredietscoring en wervingssystemen (zie onze uitleg over de EU AI Act) — een zwaardere compliance-verplichting die de meeste contactcenters niet hoeven aan te gaan wanneer de bankapp, het CRM-record of de registercontrole van de klant zelf de klus al klaart.

Hoe dit eruitziet in een echte flow

Drie patronen dekken het merendeel van wat bedrijven daadwerkelijk nodig hebben, en alle drie leiden naar een systeem dat de klant al heeft, niet een dat AssistYou levert:

Patroon	Wat de voice agent doet	Waar de daadwerkelijke controle plaatsvindt
Kennisgebaseerde verificatie	Verzamelt naam, klantnummer en nog één identificerend gegeven, afgedwongen via het schema zodat niets wordt overgeslagen of in een lus te raden valt	De eigen CRM of klantendatabase van de klant
Register- of database-check	Vraagt om het detail (een adres, een polisnummer), en houdt de flow aan totdat dit is bevestigd	Een officieel register (bijv. BAG) of de backend van de klant
Bevestiging via app of code aan klantzijde	Vraagt de beller om de actie in de eigen app goed te keuren, of om een code voor te lezen die het systeem van de klant heeft gegenereerd, en wacht op een bevestigde status voordat het proces doorgaat	De bankapp, sms-gateway of bestaande authenticatiedienst van de klant

De rode draad is dezelfde die loopt door hoe AssistYou gesprekken overdraagt aan menselijke collega’s: het geverifieerde gegeven — een bevestigd klantnummer, een goedgekeurde status — reist mee met het gesprek, of het nu wordt gebruikt om een selfservice-actie te ontgrendelen, of wordt overgedragen aan een medewerker zodat niemand dezelfde vraag twee keer hoeft te stellen.

Wat u moet controleren voordat u voice AI inzet voor iets gevoeligs

Voordat u ervan uitgaat dat een AI Voice Agent “de verificatie wel regelt”, loont het om eerlijk te zijn over wat er al staat:

• Wat controleert uw huidige telefonische verificatie vandaag daadwerkelijk — kennisgebaseerde vragen, een opzoeking van het account, of iets sterkers? Een voice agent kan dat consistent afdwingen, bij elk gesprek, maar erft daarbij wel de sterkte (of zwakte) van het proces dat wordt afgedwongen.
• Heeft u al een app-gebaseerde bevestigingsflow voor risicovolle acties? Zo ja, dan is het de taak van de voice agent om daarnaar door te verwijzen, niet om deze te dupliceren.
• Is er al een sms- of eenmalige-codegateway die uw organisatie elders gebruikt? Een voice agent die is gebouwd op een flexibele flow builder kan die controle activeren en op het resultaat wachten — het versturen en verifiëren blijft gebeuren in het systeem dat dit al doet.
• Wat gebeurt er als de verificatie mislukt? Een goed gebouwde flow — zoals we beschrijven in onze uitleg over CRM-integratie — escaleert naar een mens met volledige context, in plaats van de beller in een lus vast te houden of, erger nog, te gaan gokken.

Veelgestelde vragen

Kan een AI Voice Agent identiteit even veilig verifiëren als een bankapp? Nee, niet op zichzelf. De biometrische of pincode-bevestiging van een bankapp vindt plaats binnen een omgeving die de bank volledig zelf beheert. De rol van een voice agent is om de beller te sturen bij het voltooien van die stap en te wachten op bevestiging voordat het gesprek doorgaat — de beveiliging blijft in het eigen systeem van de bank.

Biedt AssistYou stembiometrie of een eigen identiteitsinfrastructuur aan? Nee. AssistYou’s Flow Builder handhaaft identificatie- en verificatiestappen tegen welke backend, welk register of welk app-bevestigingssysteem de klant ook al heeft. Het levert geen biometrische matching of een eigen identiteitsdatabase.

Kan een AI Voice Agent nummerspoofing tegenhouden? Niet op zichzelf — beller-ID was nooit een identiteitsbewijs, en dat is precies waarom simswapfraude en nummerspoofing nog altijd toenemen. Wat een voice agent wél kan doen, is weigeren om het binnenkomende nummer als voldoende te beschouwen, en in plaats daarvan doorschakelen naar een sterkere controle, zoals een sms-code of app-bevestiging, als de klant die heeft.

Wat is een redelijke minimale verificatiestap voor een contactcenter dat vandaag niets sterkers heeft dan kennisgebaseerde vragen? Kennisgebaseerde verificatie, consistent afgedwongen en gecontroleerd tegen het account in het systeem voordat er iets gevoeligs gebeurt, is een redelijke ondergrens — dezelfde die de meeste door mensen bemande contactcenters al gebruiken. Het is niet sterk tegen een vastberaden aanvaller met gelekte gegevens, en dat is precies waarom het alleen risicoarme acties zou moeten afdekken, waarbij alles met een hoger risico escaleert naar welke sterkere controle het bedrijf ook al heeft.

Verifieer tegen wat u al vertrouwt

De bedrijven die dit goed doen, zijn niet de bedrijven die van hun AI Voice Agent een beveiligingsproduct proberen te maken. Het zijn de bedrijven die al precies weten wat “geverifieerd” voor hun organisatie betekent — een app-bevestiging, een registermatch, een accountopzoeking — en die de voice agent gebruiken om dit elke keer, zonder uitzondering, af te dwingen, en die het gesprek netjes overdragen zodra dat niet lukt.

Als u een AI Voice Agent overweegt voor iets waarbij gevoelige acties komen kijken, is de juiste eerste vraag niet “kan de AI mijn klanten verifiëren”. Het is: “wat vertrouwen we al, en kan dit daarop aansluiten.”

← Terug naar blog