Voice AI in Banken: BaFin-Orientierungshilfe & DORA

Voice AI in Banken: Was die BaFin-Orientierungshilfe zu KI unter DORA für KI-Telefonassistenten bedeutet

Ja, Banken und Versicherer dürfen KI-Telefonassistenten einsetzen — aber seit der BaFin-Orientierungshilfe zu KI unter DORA (Februar 2026) nicht mehr als Innovationsprojekt neben der IT, sondern als regulär inventarisiertes IKT-Asset im bestehenden IKT-Risikomanagementrahmen. Die entscheidende Weichenstellung: Die Aufsicht löst sich von der reinen Risikoklassifizierung des EU AI Act und definiert KI-Systeme technisch nüchtern als „Netzwerk- und Informationssysteme". Damit verliert KI ihren regulatorischen Sonderstatus.

Für Entscheider in Kreditinstituten heißt das konkret: Die Frage ist nicht mehr „Ist unser Voice-Agent Hochrisiko-KI?", sondern „Ist er im Asset-Inventar erfasst, risikobasiert klassifiziert, überwacht, notfallgeplant und mit einer getesteten Exit-Strategie versehen?" Dieser Artikel übersetzt die Orientierungshilfe in einen konkreten Handlungsrahmen für die Telefonie — vom Asset-Inventar über die Auslagerungsprüfung bis zur Stilllegung.

Die Kernaussage: KI ist ein IKT-Asset, kein Sonderthema

Der EU AI Act schafft erstmals einen europaweit einheitlichen Rechtsrahmen für KI und teilt Systeme risikobasiert ein — von unzulässigen Anwendungen über Hochrisiko-KI bis zu Systemen mit begrenztem oder minimalem Risiko. An diese Einstufung knüpfen abgestufte Pflichten für Anbieter und Betreiber: Transparenz, Dokumentation, Datenqualität, menschliche Aufsicht.

Für Finanzunternehmen greift diese produktbezogene Betrachtung jedoch zu kurz. Sie beantwortet nicht die eigentliche Governance-Frage: Wie lässt sich eine KI-Anwendung — unabhängig von ihrer ethischen Risikoklasse — technisch sicher in die bestehende IT-Landschaft integrieren und operativ beherrschen? Genau hier setzt die BaFin an.

Die Argumentation der Aufsicht ist schlicht und wirkungsvoll: Ein KI-System ist „maschinengestützt", besteht also aus Hard- und Software. Damit ist es ein „Netzwerk- und Informationssystem" im Sinne der DORA — und folglich ein reguläres IKT-Asset. Drei Konsequenzen ergeben sich daraus für die Praxis:

• Integration statt Isolation: KI ist kein isoliertes Innovationsthema mehr, sondern muss zwingend in den bestehenden, dokumentierten IKT-Risikomanagementrahmen eingebettet werden. Ein Voice-Agent, der neben der IT im Fachbereich „ausprobiert" wird, ist aufsichtsrechtlich Schatten-IT.
• Fokus auf den Lebenszyklus: Statt einer einmaligen Risikoprüfung vor Markteinführung fordert die BaFin eine lückenlose Überwachung des gesamten technischen Lebenszyklus — von Entwicklung und Training über den laufenden Betrieb bis zur sicheren Deinstallation und Datenlöschung.
• Haftung und Resilienz: Compliance bemisst sich nicht an der Transparenz des Algorithmus allein, sondern an der operationalen Widerstandsfähigkeit des Gesamtsystems gegenüber Ausfällen, Manipulationen wie Data Poisoning und Cyberangriffen.

Damit schließt die BaFin die Lücke zwischen den abstrakten Anforderungen der KI-Verordnung und der operativen Wirklichkeit in Rechenzentren und Cloud-Umgebungen der Finanzindustrie. Wer die EU-AI-Act-Compliance-Checkliste für Voice AI bereits abgearbeitet hat, ist damit noch nicht fertig — die DORA-Ebene kommt obendrauf.

Wen die Orientierungshilfe adressiert

Die BaFin leitet den Anwendungsbereich direkt aus der DORA-Systematik ab. Adressiert sind primär jene Finanzunternehmen, die den vollständigen IKT-Risikomanagementrahmen nach Art. 5–15 DORA anzuwenden haben — insbesondere CRR-Kreditinstitute und Versicherungsunternehmen unter Solvency II.

Für diese Institute ist die Orientierungshilfe als maßgebliche Auslegung der Aufsichtserwartung zu betrachten, auch wenn das Papier formal als „nicht verpflichtende Hilfestellung" bezeichnet wird. Praktisch definiert es den künftigen Prüfungsmaßstab. Finanzunternehmen, die unter den vereinfachten Rahmen nach Art. 16 DORA fallen — etwa kleine Wertpapierfirmen oder kleine Zahlungsinstitute — sind nicht direkter Adressat; hier ist eine gesonderte Betrachtung erforderlich.

Proportionalität: Wo Ihr Voice-Agent wirklich einzuordnen ist

Ein wesentliches Element ist der Grundsatz der Verhältnismäßigkeit nach Art. 4 DORA. Die Anforderungen skalieren mit Risikoprofil und Systemrelevanz. Für die Governancepraxis bedeutet das eine Differenzierung nach der Kritikalität der unterstützten Funktion:

• Kritische oder wichtige Funktionen: KI-Anwendungen, die wesentliche Geschäftsprozesse steuern oder Entscheidungen mit direkter Auswirkung auf die Vermögens-, Finanz- oder Ertragslage treffen — etwa Algorithmen zur Kreditwürdigkeitsprüfung oder Dunkelverarbeitung in der Schadenregulierung. Hier sind umfassende Kontroll- und Sicherheitsmaßnahmen zwingend, inklusive erweiterter Resilienztests und intensiver Dokumentationspflichten.
• Unterstützende Funktionen: KI-Systeme mit geringerem Risiko, die unter ständiger menschlicher Überwachung stehen und keine autonomen Entscheidungen treffen. Hier können die Sicherheitsvorkehrungen nach dem Proportionalitätsprinzip in angemessenem Umfang reduziert werden.

Genau diese Unterscheidung ist für Telefonie-Anwendungen die wichtigste Designentscheidung. Ein Voice-Agent ist nicht per se kritisch — er wird es durch das, was Sie ihn entscheiden lassen. Die folgende Einordnung zeigt typische Bankszenarien:

Die praktische Implikation: Die Klassifizierung Ihrer KI-Systeme hinsichtlich der Unterstützung kritischer Funktionen ist dokumentarisch festzuhalten, um die Angemessenheit der getroffenen Maßnahmen gegenüber Prüfern und der Aufsicht nachweisbar zu machen. Wer in der Einführungsphase bewusst bei unterstützenden Funktionen bleibt und Aktionen mit Vermögensbezug an einen Menschen übergibt, verkürzt die Zeit bis zum Produktivbetrieb erheblich. Der Call-Transfer an einen menschlichen Mitarbeiter ist damit kein Feature-Detail, sondern ein regulatorisches Steuerungsinstrument.

Das Fundament: Strategie und Governance

Grundlage des laufenden Risikomanagements sind Strategie und Governance. Die Orientierungshilfe benennt drei Bausteine:

Strategische Integration und Roadmap. Das Leitungsorgan muss eine KI-Strategie verabschieden, die konsistent in die übergeordnete Geschäfts- und DORA-Strategie eingebettet ist. Anders als bei Standard-IT erfordert der KI-Einsatz zwingend eine Technologie-Roadmap, um den spezifischen Ressourcenbedarf — Rechenleistung, Datenvolumina — und die notwendigen Investitionen vorausschauend zu steuern.

Vorstandsverantwortung und AI Literacy. Die Letztverantwortung für KI-Risiken liegt nach Art. 5 DORA beim Leitungsorgan, also beim Gesamtvorstand. Das setzt nachweisbare Sachkunde voraus, um die Auswirkungen algorithmischer Entscheidungen auf das Geschäftsmodell eigenständig bewerten zu können. Verantwortlichkeiten für KI-Ergebnisse sind zwischen IT und Fachbereich lückenlos zuzuweisen.

Process Readiness und IKS-Integration. Vor der technischen Implementierung sind Geschäftsprozesse auf ihre Eignung für den Umgang mit probabilistischen, also nicht-deterministischen Ergebnissen zu validieren. Einbezogene IKT-Drittdienstleister sind einer gesonderten Risikobeurteilung zu unterziehen. Die internen Kontrollfunktionen — Risikomanagement, Compliance, Revision — müssen frühzeitig und risikoadäquat in den Lebenszyklus eingebunden werden.

Der letzte Punkt wird in der Praxis am häufigsten unterschätzt. Ein Sprachmodell antwortet probabilistisch: Dieselbe Frage kann zwei leicht unterschiedliche Formulierungen erzeugen. Ein Prozess, der auf wortgleiche Ausgaben angewiesen ist, ist für KI schlicht nicht geeignet — unabhängig davon, wie gut das Modell ist.

Entwicklung und Testen: Schatten-IT und Lieferkette

Für die Bereitstellungsphase hebt die Orientierungshilfe zwei Themen hervor.

Integrität der Lieferkette. Es gilt, die Entstehung einer unregulierten Schatten-IT in den Fachbereichen zu unterbinden; auch Low-Code-Lösungen unterliegen zwingend den DORA-Standards. Das ist für Voice AI besonders relevant, weil moderne Plattformen bewusst so einfach sind, dass eine Fachabteilung ohne IT produktiv gehen könnte. Genau das ist der Fehler. Flankierend muss die Integrität der Supply Chain gesichert werden: strikte Validierung von Trainingsdaten gegen Data Poisoning sowie rigide Prüfung von Open-Source-Bibliotheken und KI-generiertem Code auf Schwachstellen.

Sicherer Entwicklungsprozess und erweiterte Teststrategien. Um die Blackbox-Problematik zu beherrschen, muss der Entwicklungsprozess als Sicherheitsnetz fungieren: lückenlose Versionierung von Code, Trainingsdaten und Modellparametern sowie striktes Change Management für Modell-Updates inklusive getesteter Rollback-Strategien. Da herkömmliche Funktionstests bei probabilistischer KI oft versagen, sind die Testverfahren auszuweiten — Adversarial Testing simuliert gezielte Angriffe, bei generativer KI sichern qualitative Human-in-the-Loop-Prüfungen die Output-Sicherheit.

Für Voice-Agents bedeutet „Versionierung" nicht nur das Modell, sondern auch den System-Prompt und die Wissensbasis. Wer den Prompt eines produktiven Bank-Agenten ohne Freigabe und ohne Rollback-Pfad ändert, hat ein undokumentiertes Change durchgeführt — mit exakt denselben aufsichtsrechtlichen Folgen wie ein undokumentiertes Deployment im Kernbanksystem.

Laufender Betrieb und Stilllegung: die vier Handlungsfelder

Für die Betriebsphase konkretisiert die Orientierungshilfe die DORA-Vorgaben der Art. 8–11 in vier Handlungsfelder. Die folgende Tabelle übersetzt sie in Anforderungen an eine Voice-AI-Plattform:

Bemerkenswert ist, dass der Lebenszyklus erst mit der sicheren Deinstallation endet: Veraltete Modelle und Daten sind unwiederbringlich zu löschen, um Datenlecks oder Missbrauch zu verhindern. Das ist ein Punkt, den in der Praxis fast niemand vorab plant — und den Prüfer zuverlässig adressieren.

Auf Plattformseite sind das keine exotischen Anforderungen. Call History und Post-Call-Analyse liefern die Inferenz-Logs und Auswertungen, die Art. 8 und Art. 10 verlangen; über API und Webhooks lassen sich diese Daten in das bestehende SIEM oder Data Warehouse des Instituts spiegeln, statt sie in einem fremden Dashboard zu belassen.

Integration und Cloud: die eigentliche Hürde

Da leistungsfähige KI-Systeme wegen ihres Ressourcenbedarfs überwiegend nicht im eigenen Rechenzentrum, sondern über externe Cloud-Infrastrukturen bereitgestellt werden, liegt der Schwerpunkt der Orientierungshilfe auf der Beherrschung dieser Auslagerungsrisiken. Für Voice AI ist das der kritische Abschnitt — praktisch jede Plattform ist eine Auslagerung.

Erweiterte Risikobewertung und Due Diligence. Die Risikoinventur muss bereits vor Vertragsabschluss dynamische Faktoren wie Modell-Neutrainings oder Anpassungen der Modellstruktur antizipieren. Die Due Diligence darf sich nicht auf den Provider beschränken, sondern muss explizit das Risiko unautorisierter Datenabflüsse sowie die Eignung des Anbieters hinsichtlich technischer und regulatorischer Standards bewerten.

Spezifische Cyber-Sicherheit in der Cloud. Für extern gehostete Trainings- oder Inferenzumgebungen sind Angriffsvektoren wie Data Poisoning oder Adversarial Attacks zu identifizieren und abzuwehren. Werden kritische oder wichtige Funktionen ausgelagert, reicht ein „angemessenes" Sicherheitsniveau nicht aus — der Provider muss die aktuellsten und höchsten Qualitätsstandards nachweislich erfüllen.

Transparenz in der Vertragskette. Die lückenlose Kontrolle der Unterauftragsvergabe ist entscheidend, da KI-Systeme oft auf komplexe Lieferketten zurückgreifen. Das Institut muss jederzeit wissen, wo die Datenverarbeitung physisch stattfindet. SLAs müssen die spezifische Sensibilität von KI-Modellen bezüglich Latenz und Rechenkapazität verbindlich regeln und durch durchgriffskräftige Prüfrechte bis in die Tiefe der Kette abgesichert werden.

Exit-Strategie und Vendor-Lock-in. Da proprietäre Cloud-KI-Dienste einen Lock-in begünstigen, muss vertraglich gesichert sein, dass Modelle, Trainingsdaten und Metadaten in interoperablen Formaten exportiert werden können. Regelmäßige Backups auf unabhängigen Speichersystemen sowie technisch validierte Migrationsszenarien sind Pflicht.

Für die Anbieterauswahl heißt das: Eine Voice-AI-Plattform, die die Telefonnummer besitzt, das Modell nicht offenlegt und keinen Export der Gesprächsdaten erlaubt, ist unter DORA schwer darstellbar. Umgekehrt entschärft BYOC — Bring Your Own Carrier gleich zwei Punkte: Das Institut behält die Kontrolle über seine Rufnummern und den Telefonie-Vertrag, und der Wechsel des Voice-Anbieters bleibt möglich, ohne dass Kunden eine neue Nummer wählen müssen. Genau das ist eine praktisch belastbare Exit-Strategie statt einer vertraglichen Absichtserklärung. Der Auftragsverarbeitungsvertrag und die Angaben zur Datenverarbeitung liefern die Grundlage für die Due-Diligence-Dokumentation.

Implementierung Schritt für Schritt

1. Use Case zuschneiden. Starten Sie bewusst bei unterstützenden Funktionen: Öffnungszeiten, Terminvereinbarung, Weiterleitung, FAQ. Alles mit Vermögensbezug bleibt zunächst beim Menschen.
2. Kritikalität dokumentieren. Halten Sie schriftlich fest, warum der Agent keine kritische oder wichtige Funktion unterstützt. Diese Begründung ist Ihr Proportionalitäts-Nachweis nach Art. 4 DORA.
3. Ins Asset-Inventar aufnehmen. Modell, Prompt-Version, Wissensbasis, Stimme, Rufnummer, Provider und Sub-Provider — mit benanntem Verantwortlichen.
4. Auslagerung prüfen. Due Diligence des Anbieters, Verarbeitungsorte klären, Sub-Dienstleister-Kette offenlegen, Prüfrechte und SLAs zu Latenz und Verfügbarkeit vereinbaren.
5. Vor dem Go-live testen. Funktionale Tests, Lasttests mit realistischer Anrufdichte, Adversarial Testing gegen Prompt-Injection, Human-in-the-Loop-Bewertung der Antwortqualität.
6. Monitoring aufsetzen. Nicht nur Verfügbarkeit: Abbruchquote, Eskalationsrate, Antwortqualität, Latenz. Alerts bei Drift. Logs ins eigene System spiegeln.
7. BCM und Exit testen. Was passiert beim Plattformausfall? Fallback auf Weiterleitung oder Ansage. Export aller Artefakte einmal echt durchspielen — nicht nur vertraglich zusichern lassen.
8. Change Management etablieren. Jede Prompt- oder Modelländerung durchläuft Freigabe, Test und dokumentierten Rollback-Pfad.
9. Stilllegung planen. Definieren Sie schon jetzt, wie veraltete Modellversionen und Gesprächsdaten sicher gelöscht werden.

Best Practices und typische Fehler

• Fehler: Der Fachbereich startet allein. Marketing oder Filialorganisation testen einen Voice-Agent „mal kurz". Genau das ist die Schatten-IT, die die BaFin adressiert — auch bei No-Code. Binden Sie IT, Compliance und Revision ab Tag eins ein.
• Fehler: Prompt-Änderungen ohne Change-Prozess. Der Prompt ist Produktivkonfiguration, kein Textfeld. Versionieren, freigeben, Rollback vorhalten.
• Fehler: Monitoring nur auf Verfügbarkeit. Ein Agent kann zu 100 % erreichbar sein und trotzdem seit drei Wochen schlechter antworten. Art. 10 verlangt Anomalieerkennung, nicht Uptime.
• Fehler: Exit nur auf dem Papier. Eine Exit-Klausel ohne getesteten Export ist kein Exit. Spielen Sie die Migration einmal durch.
• Best Practice: Authentifizierung vor Auskunft. Alles, was über öffentlich verfügbare Informationen hinausgeht, erst nach sauberer Identifikation — idealerweise über Tastatureingabe statt gesprochener Kontonummer.
• Best Practice: Eskalation als Standard. Ein Agent, der bei Unsicherheit sauber an einen Menschen übergibt, bleibt eine unterstützende Funktion. Das ist der günstigste Compliance-Hebel überhaupt.
• Best Practice: Logs ins eigene Haus. Wer Gesprächsdaten nur im Anbieter-Dashboard hat, erfüllt Data Lineage schwer. Spiegeln Sie sie in Ihr SIEM.

Praxisbeispiel: Filialbank mit 40 Standorten

Eine regionale Bank mit 40 Filialen und rund 600 Mitarbeitern hat ein klassisches Problem: Montagvormittag zwischen 9 und 11 Uhr laufen so viele Anrufe auf, dass ein erheblicher Teil in der Warteschleife aufgibt. Die Anliegen sind überwiegend banal — Öffnungszeiten, Terminwunsch beim Berater, Frage nach benötigten Unterlagen für den Beratungstermin.

Der regulatorisch saubere Zuschnitt sieht so aus: Der Voice-Agent nimmt ab, beantwortet Öffnungszeiten und Unterlagen-Fragen aus einer gepflegten Wissensbasis, vereinbart Beratungstermine im Kalender und leitet alles andere an einen Menschen weiter. Keine Kontoauskunft, keine Kartensperre, keine Vorqualifizierung. Damit ist die Anwendung eine unterstützende Funktion — dokumentiert, begründet, im Inventar erfasst.

Die Telefonnummern bleiben über BYOC beim bestehenden Carrier des Instituts, die Gesprächsdaten fließen per Webhook in das eigene Data Warehouse, und der Fallback bei Plattformstörung ist die klassische Weiterleitung auf die Filialdurchwahl. Der Aufwand für den DORA-Nachweis bleibt damit proportional — und der Weg zur nächsten Ausbaustufe steht offen, weil Inventar, Change-Prozess und Monitoring bereits stehen.

Fazit

Mit der Orientierungshilfe transformiert die BaFin abstrakte regulatorische Anforderungen in einen operativen Handlungsrahmen. Auch ohne Rundschreiben-Charakter definiert das Papier faktisch den künftigen Goldstandard für die Prüfungspraxis. Für KI-Telefonassistenten in Banken und Versicherungen heißt das: Der Weg führt nicht über die Frage, ob man darf — sondern über Asset-Inventar, dokumentierte Kritikalitätseinstufung, echtes Monitoring, getestete Notfallpläne und eine belastbare Exit-Strategie.

Die gute Nachricht: Wer den Use Case bewusst auf unterstützende Funktionen zuschneidet und Aktionen mit Vermögensbezug an Menschen übergibt, kann proportional vorgehen und deutlich schneller produktiv werden. Famulor ist genau darauf ausgelegt — mit EU-Hosting, Auftragsverarbeitungsvertrag, BYOC für die volle Kontrolle über Rufnummern und Carrier, exportierbaren Call-Logs für Data Lineage und einem sauberen Übergabepfad an menschliche Mitarbeiter.

Der nächste Schritt: Sprechen Sie mit unserem Enterprise-Team über Ihren konkreten Use Case und die Auslagerungsdokumentation, oder sehen Sie sich an, wie Famulor Finanzdienstleister heute unterstützt. Wenn Sie zuerst den Business Case brauchen: Der ROI-Rechner zeigt in wenigen Minuten, was die Automatisierung Ihrer Anrufe einspart.

FAQ

Darf eine Bank oder Sparkasse einen KI-Telefonassistenten einsetzen?

Ja. Die BaFin verbietet KI-Telefonie nicht, sondern ordnet KI-Systeme als reguläre IKT-Assets unter DORA ein. Der Einsatz ist zulässig, wenn der Agent im Asset-Inventar erfasst, risikobasiert klassifiziert, überwacht und notfallgeplant ist.

Was ist die Kernaussage der BaFin-Orientierungshilfe zu KI unter DORA?

KI-Systeme sind „Netzwerk- und Informationssysteme" und damit reguläre IKT-Assets. Sie verlieren ihren regulatorischen Sonderstatus und müssen vollständig in den bestehenden IKT-Risikomanagementrahmen integriert werden — über den gesamten Lebenszyklus.

Wen adressiert die Orientierungshilfe?

Primär Finanzunternehmen mit vollem IKT-Risikomanagementrahmen nach Art. 5–15 DORA, insbesondere CRR-Kreditinstitute und Versicherer unter Solvency II. Institute unter dem vereinfachten Rahmen nach Art. 16 DORA sind nicht direkter Adressat.

Ist ein Voice-Agent eine kritische Funktion?

Nicht automatisch. Entscheidend ist, ob er autonome Entscheidungen mit Auswirkung auf Vermögens-, Finanz- oder Ertragslage trifft. Auskunft und Terminvereinbarung sind in der Regel unterstützende Funktionen; Kartensperre oder Kreditvorqualifizierung sind es nicht.

Was fordert die BaFin bei Auslagerung an einen Cloud-Anbieter?

Erweiterte Due Diligence inklusive Datenabfluss-Risiko, Transparenz über die gesamte Sub-Dienstleister-Kette, SLAs zu Latenz und Rechenkapazität, durchgriffskräftige Prüfrechte und eine Exit-Strategie mit Export in interoperablen Formaten.

Wer trägt die Verantwortung für KI-Risiken im Institut?

Die Letztverantwortung liegt nach Art. 5 DORA beim Leitungsorgan, also beim Gesamtvorstand. Das setzt nachweisbare Sachkunde („AI Literacy") und eine lückenlose Zuweisung der Verantwortlichkeiten zwischen IT und Fachbereich voraus.

Reicht es, den EU AI Act zu erfüllen?

Nein. Der AI Act regelt produkt- und anwendungsbezogene Pflichten nach Risikoklasse. DORA und die BaFin-Orientierungshilfe kommen mit operativen Anforderungen an Resilienz, Monitoring, Auslagerung und Notfallmanagement obendrauf.

Was bedeutet Schatten-IT im Voice-AI-Kontext?

Wenn ein Fachbereich einen Voice-Agent ohne IT, Compliance und Revision produktiv nimmt. Die BaFin stellt klar, dass auch Low-Code- und No-Code-Lösungen zwingend den DORA-Standards unterliegen.

Wie hilft BYOC bei der Exit-Strategie?

Mit Bring Your Own Carrier bleiben Rufnummern und Telefonie-Vertrag beim Institut. Ein Anbieterwechsel ist damit ohne Rufnummernwechsel möglich — eine praktisch belastbare Exit-Strategie statt einer reinen Vertragsklausel.

Wann endet der Lebenszyklus eines KI-Systems?

Erst mit der sicheren Deinstallation. Veraltete Modelle, Modellartefakte und zugehörige Daten sind unwiederbringlich zu löschen, um Datenlecks und Missbrauch zu verhindern. Das gehört bereits vor dem Go-live geplant.