Voice AI in het bankwezen: BaFin- en DORA-regels voor 2026

Voice AI in het bankwezen: Wat de BaFin-richtlijnen voor AI onder DORA betekenen voor AI-telefoonagenten

Ja, banken en verzekeraars kunnen AI-telefoonagenten inzetten, maar sinds de BaFin-richtlijn over AI onder DORA (februari 2026) niet meer als een innovatieproject dat losstaat van de IT. Een AI-telefoonagent is nu een reguliere ICT-asset binnen het bestaande ICT-risicobeheerkader. De doorslaggevende stap: de toezichthouder stapt af van de risicoclassificatie van de EU AI Act en definieert AI-systemen in puur technische termen als "netwerk- en informatiesystemen". AI verliest hiermee zijn speciale toezichtstatus.

Voor besluitvormers bij kredietinstellingen is dit concreet: de vraag is niet langer "is onze voice-agent AI met een hoog risico?" maar "staat hij in de asset-inventaris, is hij risicogeclassificeerd, gemonitord, gedekt door continuïteitsplanning en ondersteund door een geteste exitstrategie?" Dit artikel vertaalt de richtlijnen naar een praktisch kader voor telefonie.

De kernboodschap: AI is een ICT-asset, geen speciaal onderwerp

De EU AI Act deelt AI-systemen in op basis van risico, van verboden toepassingen tot AI met een hoog risico of een minimaal risico. Aan die classificatie zijn graduele verplichtingen verbonden: transparantie, documentatie, datakwaliteit en menselijk toezicht.

Voor financiële instellingen schiet die productgerichte visie tekort. Het beantwoordt niet de feitelijke governance-vraag: hoe integreer je een AI-toepassing — ongeacht de ethische risicoklasse — veilig in het bestaande IT-landschap en houd je deze operationeel onder controle? Dat is waar BaFin ingrijpt.

De redenering van de toezichthouder is eenvoudig en effectief. Een AI-systeem is "machinegebaseerd", wat betekent dat het uit hardware en software bestaat. Dat maakt het een "netwerk- en informatiesysteem" onder DORA en dus een reguliere ICT-asset. Dit heeft drie gevolgen:

• Integratie in plaats van isolatie: AI is geen geïsoleerd innovatieonderwerp meer. Het moet worden ingebed in het bestaande, gedocumenteerde ICT-risicobeheerkader. Een voice-agent die door een business unit naast de IT wordt "uitgeprobeerd", is in toezichttermen schaduw-IT.
• Focus op de levenscyclus: in plaats van een eenmalige risicobeoordeling vóór de lancering, verwacht BaFin continu toezicht gedurende de gehele technische levenscyclus, van ontwikkeling en training tot live gebruik en veilige buitengebruikstelling en dataverwijdering.
• Aansprakelijkheid en veerkracht: compliance wordt niet alleen gemeten aan de hand van algoritmische transparantie, maar aan de operationele veerkracht van het totale systeem tegen uitval, manipulatie zoals data poisoning en cyberaanvallen.

Hiermee dicht BaFin het gat tussen de abstracte vereisten van de AI Act en de operationele realiteit in de datacenters en cloudomgevingen van de financiële sector. Als je de EU AI Act compliance-checklist voor voice AI al hebt doorlopen, ben je er nog niet: de DORA-laag komt daar nog bovenop.

Voor wie de richtlijnen gelden

BaFin leidt het toepassingsgebied direct af uit de structuur van DORA zelf. Het richt zich primair op financiële instellingen die het volledige ICT-risicobeheerkader onder Art. 5–15 DORA moeten toepassen, in het bijzonder CRR-kredietinstellingen en verzekeringsondernemingen onder Solvency II.

Voor deze instellingen moeten de richtlijnen worden beschouwd als de gezaghebbende interpretatie van de verwachtingen van de toezichthouder, ook al wordt het document formeel bestempeld als een "niet-bindend hulpmiddel". In de praktijk definieert het de toekomstige audit-benchmark. Financiële instellingen die onder het vereenvoudigde kader van Art. 16 DORA vallen, zoals kleine beleggingsondernemingen of kleine betaalinstellingen, zijn geen directe geadresseerden; daar is een afzonderlijke beoordeling nodig.

Proportionaliteit: waar je voice-agent daadwerkelijk staat

Een sleutelelement is het proportionaliteitsbeginsel onder Art. 4 DORA. Vereisten schalen mee met het risicoprofiel en de systemische relevantie. Voor de governance-praktijk betekent dit differentiëren op basis van de kritiekheid van de ondersteunde functie:

• Kritieke of belangrijke functies: AI-toepassingen die materiële bedrijfsprocessen aansturen of beslissingen nemen met een directe impact op de financiële positie of resultaten, zoals algoritmen voor kredietscores of straight-through schadeafhandeling. Uitgebreide controles en beveiligingsmaatregelen zijn hier verplicht, inclusief uitgebreide veerkrachttests en intensieve documentatieplichten.
• Ondersteunende functies: AI-systemen met een lager risico onder continu menselijk toezicht die geen autonome beslissingen nemen. Hier kunnen waarborgen in passende mate worden verminderd onder het proportionaliteitsbeginsel.

Voor telefonietoepassingen is dit onderscheid de belangrijkste ontwerpbeslissing. Een voice-agent is niet inherent kritiek; hij wordt kritiek door wat je hem laat beslissen. De volgende tabel toont typische bankscenario's:

De praktische implicatie: je classificatie van AI-systemen met betrekking tot de ondersteuning van kritieke functies moet gedocumenteerd zijn, zodat de adequaatheid van de genomen maatregelen aantoonbaar is voor auditors en de toezichthouder. Instellingen die bij de uitrol bewust bij ondersteunende functies blijven — en alles met een financiële impact aan een mens overlaten — verkorten de time-to-production aanzienlijk. Het doorverbinden naar een menselijke agent is daarom geen detail, maar een regulerende controlehefboom.

Het fundament: strategie en governance

Strategie en governance vormen de basis van continu risicobeheer. De richtlijnen noemen drie bouwstenen.

Strategische integratie en roadmap. Het managementorgaan moet een AI-strategie aannemen die consistent is ingebed in de bredere bedrijfs- en DORA-strategie. In tegenstelling tot standaard-IT vereist AI een technologieroadmap om specifieke behoeften aan middelen — rekenkracht, datavolumes — en de noodzakelijke investeringen tijdig aan te sturen.

Verantwoordelijkheid van de directie en AI-geletterdheid. De ultieme verantwoordelijkheid voor AI-risico's ligt bij het managementorgaan onder Art. 5 DORA — de volledige directie. Dat veronderstelt aantoonbare expertise om onafhankelijk te kunnen beoordelen hoe algoritmische beslissingen het bedrijfsmodel beïnvloeden. De verantwoordelijkheid voor AI-outputs moet zonder gaten tussen IT en de business worden toegewezen.

Procesgereedheid en integratie van interne controles. Vóór de technische implementatie moeten bedrijfsprocessen worden gevalideerd op hun geschiktheid om om te gaan met probabilistische — dat wil zeggen niet-deterministische — outputs. Betrokken ICT-derden vereisen een afzonderlijke risicobeoordeling. Interne controlefuncties — risicobeheer, compliance, interne audit — moeten vroegtijdig en proportioneel bij de levenscyclus worden betrokken.

Dat laatste punt wordt in de praktijk het meest onderschat. Een taalmodel antwoordt probabilistisch: dezelfde vraag kan twee licht verschillende formuleringen opleveren. Een proces dat afhankelijk is van woord-identieke output is ongeschikt voor AI, hoe goed het model ook is.

Ontwikkeling en testen: schaduw-IT en de toeleveringsketen

Voor de inrichtingsfase belicht de richtlijn twee thema's.

Integriteit van de toeleveringsketen. Ongereguleerde schaduw-IT in business units moet worden voorkomen; low-code oplossingen vallen eveneens onder de DORA-normen. Dit is vooral belangrijk voor voice AI, omdat moderne platforms bewust zo eenvoudig zijn dat een business unit zonder IT live zou kunnen gaan. Dat is precies de fout. De integriteit van de toeleveringsketen moet ook worden gewaarborgd: strikte validatie van trainingsdata tegen data poisoning, plus rigoureuze controle van open-source bibliotheken en door AI gegenereerde code.

Veilige ontwikkeling en uitgebreide teststrategieën. Om het black-box-probleem te beheersen, moet het ontwikkelproces als vangnet fungeren: volledige versiebeheer van code, trainingsdata en modelparameters, plus strikt wijzigingsbeheer voor modelupdates inclusief geteste rollback-strategieën. Omdat conventionele functionele tests vaak falen bij probabilistische AI, moet het testen worden verbreed: adversarial testing simuleert gerichte aanvallen, en voor generatieve AI zorgt human-in-the-loop review voor outputveiligheid.

Voor voice-agents omvat "versiebeheer" niet alleen het model, maar ook de systeemprompt en de kennisbank. Het wijzigen van de prompt van een live bankagent zonder goedkeuring en zonder rollback-pad is een ongedocumenteerde wijziging, met dezelfde toezichtgevolgen als een ongedocumenteerde implementatie in het kernbanksysteem.

Live gebruik en buitengebruikstelling: de vier actiegebieden

Voor de operationele fase vertaalt de richtlijn DORA Art. 8–11 naar vier actiegebieden. De onderstaande tabel vertaalt deze naar vereisten voor een voice AI-platform:

Opvallend is dat de levenscyclus pas eindigt bij een veilige buitengebruikstelling: verouderde modellen en data moeten onherstelbaar worden verwijderd om lekken of misbruik te voorkomen. Bijna niemand plant dit vooraf, en auditors vragen er betrouwbaar naar.

Aan de platformkant zijn dit geen exotische vereisten. Gesprekshistorie en post-call analyse leveren de inference-logs die Art. 8 en Art. 10 eisen; via API en webhooks kan die data worden gespiegeld naar het bestaande SIEM of datawarehouse van de instelling in plaats van in een dashboard van derden te blijven staan.

Integratie en cloud: de echte hindernis

Omdat capabele AI-systemen meestal via externe cloudinfrastructuur worden geleverd in plaats van in een eigen datacenter, concentreert de richtlijn zich op het beheersen van die outsourcing-risico's. Voor voice AI is dit het kritieke gedeelte: vrijwel elk platform is een outsourcing-overeenkomst.

Uitgebreide risicobeoordeling en due diligence. Vóór ondertekening van het contract moet de risico-inventaris anticiperen op dynamische factoren zoals hertraining van modellen of wijzigingen in de modelstructuur. Due diligence kan niet stoppen bij de aanbieder; het moet expliciet het risico van ongeoorloofde data-uitstroom en de geschiktheid van de aanbieder tegen technische en wettelijke normen beoordelen.

Cloud-specifieke cyberbeveiliging. Voor extern gehoste trainings- of inference-omgevingen moeten aanvalsvectoren zoals data poisoning of adversarial aanvallen worden geïdentificeerd en afgeweerd. Waar kritieke of belangrijke functies worden uitbesteed, is een "adequaat" beveiligingsniveau niet genoeg: de aanbieder moet aantoonbaar voldoen aan de hoogste huidige normen.

Transparantie in de contractketen. Het beheersen van subcontracting zonder gaten is doorslaggevend, omdat AI-systemen vaak afhankelijk zijn van complexe toeleveringsketens. De instelling moet te allen tijde weten waar gegevensverwerking fysiek plaatsvindt. SLA's moeten bindend ingaan op de gevoeligheid van AI-modellen voor latentie en rekenkracht, ondersteund door afdwingbare auditrechten diep in de keten.

Exitstrategie en vendor lock-in. Omdat propriëtaire cloud AI-diensten lock-in aanmoedigen, moeten contracten de export van modellen, trainingsdata en metadata in interoperabele formaten veiligstellen. Regelmatige back-ups op onafhankelijke opslag plus gevalideerde migratiescenario's zijn verplicht.

Voor leveranciersselectie betekent dit: een platform dat jouw telefoonnummer bezit, het model niet openbaart en export van gespreksdata blokkeert, is onder DORA moeilijk te rechtvaardigen. Omgekeerd ontkracht BYOC — bring your own carrier twee punten tegelijk: de instelling behoudt de controle over haar nummers en haar telefoniecontract, en overstappen van leverancier blijft mogelijk zonder dat klanten een nieuw nummer hoeven te bellen. Dat is een exitstrategie die daadwerkelijk standhoudt, in plaats van een intentieverklaring. De verwerkersovereenkomst en de bijbehorende disclosures vormen de basis voor je due diligence-dossier.

Implementatie stap voor stap

1. Bepaal de scope van de use case. Begin bewust met ondersteunende functies: openingstijden, afspraken boeken, routering, FAQ's. Alles met een financiële impact blijft voorlopig bij mensen.
2. Documenteer de kritiekheid. Schrijf op waarom de agent geen kritieke of belangrijke functie ondersteunt. Die redenering is je bewijs van proportionaliteit onder Art. 4 DORA.
3. Voeg het toe aan de asset-inventaris. Model, promptversie, kennisbank, stem, telefoonnummer, aanbieder en sub-aanbieders — met een benoemde eigenaar.
4. Voer de outsourcing-review uit. Due diligence van de leverancier, verwerkingslocaties verduidelijken, de keten van sub-verwerkers openbaren, auditrechten en SLA's over latentie en beschikbaarheid afspreken.
5. Testen vóór go-live. Functionele tests, belastingtests bij realistische gespreksdichtheid, adversarial testing tegen prompt injection, human-in-the-loop beoordeling van de antwoordkwaliteit.
6. Monitoring instellen. Niet alleen beschikbaarheid: drop-off percentage, escalatiepercentage, antwoordkwaliteit, latentie. Waarschuwingen bij drift. Spiegel logs naar je eigen systemen.
7. Test BCM en exit. Fallback naar routering of een aankondiging bij uitval. Voer de export van artefacten een keer in het echt uit — neem niet zomaar genoegen met een contractuele garantie.
8. Stel wijzigingsbeheer in. Elke prompt- of modelwijziging gaat door goedkeuring, testen en een gedocumenteerd rollback-pad.
9. Plan buitengebruikstelling. Definieer nu hoe verouderde modelversies en gespreksdata veilig worden verwijderd.

Best practices en veelgemaakte fouten

• Fout: de business unit begint alleen. Marketing of filiaaloperaties "proberen snel even" een voice-agent uit. Dat is precies de schaduw-IT waar BaFin op doelt — no-code inbegrepen.
• Fout: promptwijzigingen zonder wijzigingsproces. De prompt is productieconfiguratie, geen tekstveld. Versioneer het, keur het goed, houd een rollback klaar.
• Fout: alleen beschikbaarheid monitoren. Een agent kan 100% bereikbaar zijn en toch al drie weken slechter antwoorden. Art. 10 vraagt om anomaliedetectie, niet om uptime.
• Fout: exit alleen op papier. Een exit-clausule zonder geteste export is geen exit. Oefen de migratie een keer.
• Best practice: authenticeer vóór openbaarmaking. Alles buiten publieke informatie alleen na een schone identificatie — idealiter via toetsenbord-invoer in plaats van een uitgesproken rekeningnummer.
• Best practice: escalatie als standaard. Een agent die bij onzekerheid netjes overdraagt aan een mens, blijft een ondersteunende functie — de goedkoopste compliance-hefboom die er is.
• Best practice: houd logs in eigen beheer. Als gespreksdata alleen in een leveranciersdashboard staan, is data-lineage moeilijk aan te tonen. Spiegel het naar je SIEM.

Praktijkvoorbeeld: een regionale bank met 40 filialen

Een regionale bank met 40 filialen en ongeveer 600 medewerkers heeft een klassiek probleem: op maandagochtend tussen 9 en 11 uur piekt het gespreksvolume zo hard dat een aanzienlijk deel van de bellers de wachtrij verlaat. De verzoeken zijn meestal alledaags — openingstijden, afspraken met adviseurs, vragen over welke documenten men moet meenemen.

De toezichttechnisch schone scope: de voice-agent neemt op, beantwoordt vragen over openingstijden en documenten vanuit een onderhouden kennisbank, boekt afspraken met adviseurs en routeert al het andere naar een mens. Geen rekeninginformatie, geen kaartblokkering, geen pre-kwalificatie. Dat maakt het een ondersteunende functie — gedocumenteerd, gerechtvaardigd, opgenomen in de inventaris.

Telefoonnummers blijven bij de bestaande carrier van de instelling via BYOC, gespreksdata stromen via webhook naar het eigen datawarehouse van de bank, en de fallback tijdens een platformincident is klassieke routering naar het filiaalnummer. DORA-bewijsvoering blijft proportioneel — en de weg naar de volgende uitbreidingsfase is open, omdat inventaris, wijzigingsproces en monitoring al bestaan.

Conclusie

Met deze richtlijnen vertaalt BaFin abstracte wettelijke vereisten naar een operationeel kader. Zelfs zonder de status van een circulaire definieert het document effectief de toekomstige gouden standaard voor auditpraktijken. Voor AI-telefoonagenten in het bankwezen loopt de route niet via de vraag of het mag, maar via asset-inventarisatie, gedocumenteerde kritiekheidsclassificatie, echte monitoring, geteste continuïteitsplannen en een geloofwaardige exitstrategie.

Het goede nieuws: instellingen die de use case beperken tot ondersteunende functies en acties met een financiële impact aan mensen overlaten, kunnen proportioneel te werk gaan en veel sneller in productie gaan. Famulor is precies daarvoor gebouwd — EU-hosting, een verwerkersovereenkomst, BYOC voor volledige controle over nummers en carrier, exporteerbare gesprekslogs voor data-lineage en een schoon overdrachtspad naar menselijke medewerkers.

Volgende stap: praat met ons enterprise-team over je specifieke use case en outsourcing-documentatie, of bekijk hoe Famulor vandaag financiële diensten ondersteunt. Als je eerst de business case nodig hebt, laat de ROI-calculator in minuten zien wat het automatiseren van je gesprekken oplevert.

FAQ

Kan een bank een AI-telefoonagent inzetten?

Ja. BaFin verbiedt AI-telefonie niet; het classificeert AI-systemen als reguliere ICT-assets onder DORA. Inzet is toegestaan als de agent is opgenomen in de asset-inventaris, risicogeclassificeerd, gemonitord en gedekt door continuïteitsplanning.

Wat is de kernboodschap van de BaFin-richtlijn over AI onder DORA?

AI-systemen zijn "netwerk- en informatiesystemen" en dus reguliere ICT-assets. Ze verliezen hun speciale toezichtstatus en moeten volledig worden geïntegreerd in het bestaande ICT-risicobeheerkader gedurende de gehele levenscyclus.

Voor wie gelden de richtlijnen?

Primair voor financiële instellingen die het volledige ICT-risicobeheerkader onder Art. 5–15 DORA toepassen, met name CRR-kredietinstellingen en Solvency II-verzekeraars. Bedrijven onder het vereenvoudigde kader van Art. 16 DORA zijn geen directe geadresseerden.

Is een voice-agent een kritieke functie?

Niet automatisch. Het gaat erom of de agent autonome beslissingen neemt die de financiële positie of resultaten beïnvloeden. Informatie en afspraken boeken zijn meestal ondersteunende functies; kaartblokkering of krediet-pre-kwalificatie niet.

Wat eist BaFin bij outsourcing naar een cloudprovider?

Uitgebreide due diligence inclusief risico op data-uitstroom, transparantie in de volledige keten van sub-verwerkers, SLA's over latentie en rekenkracht, afdwingbare auditrechten en een exitstrategie met export in interoperabele formaten.

Wie is verantwoordelijk voor AI-risico's binnen de instelling?

De ultieme verantwoordelijkheid ligt bij het managementorgaan onder Art. 5 DORA — de volledige directie. Dat vereist aantoonbare expertise ("AI-geletterdheid") en een gatloze toewijzing van verantwoordelijkheden tussen IT en de business.

Is voldoen aan de EU AI Act voldoende?

Nee. De AI Act regelt product- en toepassingsgerelateerde plichten per risicoklasse. DORA en de BaFin-richtlijnen voegen daar operationele vereisten voor veerkracht, monitoring, outsourcing en continuïteitsbeheer aan toe.

Wat telt als schaduw-IT in een voice AI-context?

Een business unit die een voice-agent live brengt zonder IT, compliance en interne audit. BaFin maakt duidelijk dat low-code en no-code oplossingen eveneens onder de DORA-normen vallen.

Hoe helpt BYOC bij de exitstrategie?

Met bring your own carrier blijven telefoonnummers en het telefoniecontract bij de instelling. Wisselen van leverancier wordt mogelijk zonder nummers te wijzigen — een exitstrategie die in de praktijk standhoudt in plaats van alleen een contractclausule.

Wanneer eindigt de levenscyclus van een AI-systeem?

Pas bij een veilige buitengebruikstelling. Verouderde modellen, modelartefacten en bijbehorende data moeten onherstelbaar worden verwijderd om datalekken en misbruik te voorkomen. Plan dit vóór de go-live, niet daarna.