KI-Assistenten im Banking: mehr als das nächste Chatbot-Projekt

KI-Assistenten im Banking: mehr als das nächste Chatbot-Projekt

Wer heute noch über "Chatbots" spricht, verpasst den eigentlichen Wandel. KI-Assistenten im Banking sind keine Dialogfenster mehr, die FAQ-Antworten ausspielen, sondern Systeme, die auf Basis von Transaktionsdaten, Vertragsdaten und Verhaltenssignalen in Echtzeit Entscheidungen treffen und Handlungen auslösen. Der Unterschied ist nicht graduell, sondern strukturell – und er entscheidet darüber, ob ein Projekt nach zwölf Monaten noch genutzt wird oder in der Ablage verschwindet.

Warum klassische Chatbot-Projekte scheitern

Die meisten Chatbot-Initiativen der letzten Jahre wurden als Kostensenkungsprojekt im Kundenservice aufgesetzt: Intents definieren, Antworten hinterlegen, Ticketvolumen senken. Das Problem ist der fehlende Datenzugriff. Ein Chatbot, der nicht weiß, dass ein Kunde vor drei Tagen eine Rückbuchung erhalten hat oder sein Dispolimit zu 95 Prozent ausgeschöpft ist, kann nur generische Antworten liefern. Banken berichten in solchen Setups typischerweise von Lösungsraten zwischen 20 und 35 Prozent bei einfachen Anfragen – bei allem, was Kontext erfordert, eskaliert das System sofort an einen Mitarbeiter.

Ein KI-Assistent, der direkt an eine vertikale Customer Data Platform angebunden ist, kehrt diese Logik um. Er sieht nicht nur die Anfrage, sondern die letzten Transaktionen, den Produktbestand, offene Vorgänge und einen aktuellen Risiko- oder Next-Best-Action-Score. Damit steigen Lösungsraten in der Praxis auf 55 bis 70 Prozent für Anfragen, die vorher zwingend an einen Sachbearbeiter gingen.

Von reaktiv zu proaktiv: der eigentliche Hebel

Der größte Wertunterschied liegt nicht im Servicekanal, sondern im Auslöser. Klassische Chatbots warten auf eine Nutzeranfrage. KI-Assistenten, die auf Transaktionsdatenströme reagieren, erkennen Muster, bevor der Kunde überhaupt aktiv wird: eine ungewöhnliche Häufung von Kleinbetragsabbuchungen, ein plötzlicher Gehaltseingang von einem neuen Arbeitgeber, eine erste Kreditkartenzahlung im Ausland nach Jahren ohne Auslandsumsätze. Jedes dieser Ereignisse ist ein Trigger, der einen automatisierten, aber personalisierten Dialog anstoßen kann – etwa eine Reisekrankenversicherung anbieten, eine Betrugsprüfung einleiten oder ein Cross-Sell für ein Tagesgeldkonto ausspielen, wenn sich hohe Liquidität auf dem Girokonto ansammelt.

In der Praxis verschieben Banken mit einem solchen Setup 15 bis 25 Prozent ihrer Service-Interaktionen von reaktiv zu proaktiv, mit messbar höherer Annahmequote bei Angeboten, weil der Zeitpunkt und der Kontext stimmen statt einer pauschalen Kampagne.

Technische Voraussetzungen, die oft unterschätzt werden

Ein leistungsfähiger KI-Assistent braucht drei Dinge, die viele Institute unterschätzen. Erstens einen Echtzeit-Datenzugriff auf Transaktions- und Kontobewegungen, nicht nur auf einen nächtlichen Batch-Export aus dem Data Warehouse. Zweitens ein Scoring-Modell, das kontinuierlich mit frischen Daten nachtrainiert wird, damit Next-Best-Action-Empfehlungen nicht nach wenigen Wochen veralten. Drittens eine Orchestrierungsschicht, die entscheidet, welcher Kanal – App-Push, E-Mail, Filiale, Call-Center – für welches Segment und welche Uhrzeit die höchste Wirkung erzielt.

Ohne diese drei Bausteine bleibt der "KI-Assistent" letztlich ein Sprachmodell über einer statischen Wissensdatenbank – nützlich, aber ohne den strukturellen Vorteil gegenüber klassischen Chatbots.

Regulatorik als Designparameter, nicht als Bremse

Für Banken, Versicherer und Kartenemittenten in Europa ist die Einbindung von GDPR-, BaFin- und DORA-Anforderungen kein nachträglicher Compliance-Check, sondern ein Architekturprinzip. Ein KI-Assistent, der Transaktionsdaten für Empfehlungen nutzt, muss Einwilligungen granular respektieren, Erklärbarkeit für jede automatisierte Entscheidung liefern können und im Zweifel in einer privaten Cloud- oder On-Premise-Umgebung betrieben werden, um Datenhoheit zu sichern. Institute, die diese Anforderungen von Anfang an in die Systemarchitektur einbauen, vermeiden spätere Nachrüstungen, die Projekte um sechs bis zwölf Monate verzögern können.

Was das für die Priorisierung bedeutet

Für Entscheider heißt das: Der Ausgangspunkt für ein KI-Assistenten-Projekt sollte nicht die Frage "Welche Fragen soll der Bot beantworten?" sein, sondern "Welche Transaktionsereignisse lösen heute keine Reaktion aus, obwohl sie sollten?". Diese Umkehrung der Fragestellung verändert Budget, Teamzusammensetzung und Erfolgsmetriken – weg von Ticketreduktion, hin zu Konversionsraten, Cross-Sell-Erfolg und Kundenbindung. Institute, die diesen Wechsel vollziehen, berichten nach zwölf bis achtzehn Monaten von signifikant höherem Produkt-pro-Kunde-Verhältnis und einer messbaren Reduktion der Abwanderungsquote in den adressierten Segmenten.

Der Chatbot war ein Kanal-Upgrade. Der transaktionsdatengetriebene KI-Assistent ist eine neue Schicht im Kernbankgeschäft – und sollte entsprechend behandelt werden.

Organisatorische Verantwortung neu denken

Ein weiterer, oft unterschätzter Aspekt ist die organisatorische Verankerung. Klassische Chatbot-Projekte lagen meist vollständig im Kundenservice, mit klar abgegrenztem Budget und Erfolgsmessung über Ticketvolumen. Ein transaktionsdatengetriebener KI-Assistent berührt dagegen Marketing, Risikomanagement, Compliance und den Vertrieb gleichzeitig, weil er Empfehlungen ausspricht, die potenziell verkaufsrelevant, aber auch regulatorisch sensibel sind. Institute, die für ein solches Projekt weiterhin nur den Kundenservice als Owner definieren, laufen Gefahr, dass Vertriebs- und Risikoabteilungen erst nachträglich Einspruch erheben – mit entsprechenden Verzögerungen. Ein interdisziplinäres Steering-Committee, das von Beginn an Kundenservice, Vertrieb, Risiko und Compliance zusammenbringt, verkürzt Entscheidungswege deutlich und verhindert, dass ein technisch fertiges System an internen Freigabeprozessen scheitert.

Der Vergleich mit reinen Sprachmodell-Ansätzen

Es lohnt sich, den Unterschied zwischen einem reinen Large-Language-Model-Layer und einem transaktionsdatenintegrierten Assistenten noch einmal konkret zu machen. Ein Sprachmodell allein kann Anfragen verstehen und flüssig formulieren, aber es kennt weder den aktuellen Kontostand noch die letzte Transaktion, wenn es nicht explizit angebunden ist. In der Praxis führt das dazu, dass viele LLM-basierte Pilotprojekte im Banking zunächst beeindrucken, dann aber an genau den Fällen scheitern, die für Kunden am relevantesten sind – individuelle, kontextabhängige Anliegen. Erst die Kombination aus Sprachverständnis und Echtzeitzugriff auf Transaktions- und Kundendaten macht aus einem Demo-fähigen Prototyp ein produktionsreifes System, das im Tagesgeschäft tatsächlich Arbeitslast von Mitarbeitenden übernimmt.