AI Agents operationalisieren: Roadmap, Governance und KPIs für Finanzdienstleister

Autor: acceleraid Redaktion

Teil fünf der Serie „AI Agents im Customer Lifecycle“ übersetzt den strategischen Anspruch in einen kontrollierbaren Start. Nach den Grundlagen, der Daten- und Entscheidungsschicht, den Lifecycle-Kampagnen und den Branchen-Playbooks geht es nun um die Umsetzung: kein Big Bang, sondern ein erster produktiver Trigger mit überprüfbarer Governance.

Das Ziel ist ein belastbarer erster Trigger – nicht die perfekte Zielarchitektur

AI Agents werden im Finanzdienstleistungsumfeld selten daran scheitern, dass ein Modell keine Empfehlung erzeugen kann. Die kritische Frage lautet vielmehr: Ist für jede Empfehlung klar, welche Daten verwendet wurden, welcher Zweck erlaubt ist, wer die Entscheidung verantwortet und wie ein Ergebnis später nachvollzogen wird? Genau deshalb sollte die Einführung nicht als Software-Roll-out, sondern als kontrollierter Betriebsaufbau geführt werden.

Das Whitepaper setzt dafür einen klaren Zielpunkt: Vom Anschluss der Daten bis zum ersten Live-Kampagnen-Trigger liegen sechs bis neun Wochen. Dieser Zeitraum ist kein ROI-Versprechen und auch kein Freibrief für eine unvollständige Prüfung. Er beschreibt einen begrenzten, messbaren Start: ein definierter Anwendungsfall, ein kontrollierter Datenfluss, ein dokumentiertes Entscheidungsschema und aktives Monitoring.

Für das Steuerungsteam folgt daraus eine nützliche Umkehrung. Nicht zuerst alle Kanäle, Datenquellen und Use Cases planen. Zuerst den kleinsten Anwendungsfall wählen, der drei Eigenschaften erfüllt: Er hat einen klaren Geschäftszweck, eine prüfbare Entscheidungslogik und eine rückverfolgbare Ergebnismessung. Ein Reaktivierungsimpuls oder eine Onboarding-Erinnerung kann dafür geeigneter sein als ein komplexes, kundennahes Angebot mit vielen Ausnahmen.

Die Roadmap: vier Phasen, vier Freigaben

Die Roadmap strukturiert den Start in Connect, Score, Orchestrate und Go Live. Entscheidend ist nicht die Reihenfolge allein, sondern das Governance-Gate am Ende jeder Phase. Ein Gate ist eine formale Entscheidung: Das Team prüft Evidenz, benennt offene Risiken und entscheidet ausdrücklich, ob der nächste Schritt freigegeben wird.

Connect: Woche eins bis zwei

In Woche eins bis zwei geht es nicht darum, möglichst viele Daten anzubinden. Das Team legt fest, welche Quelle für den ersten Anwendungsfall wirklich erforderlich ist und welche Felder dafür nicht benötigt werden. Daraus entstehen ein Datenflussbild, eine Zweckbeschreibung und eine Rollenmatrix. Fachbereich, Datenschutz, Informationssicherheit und Betrieb sollten diese Unterlagen gemeinsam abnehmen; nachträgliche Zustimmung ist kein Ersatz für eine sauber definierte Datennutzung.

Das erste Gate lautet deshalb: Darf dieser Datenfluss für diesen Zweck betrieben werden? Erst wenn Consent-Status, Zweckbindung, Zugriffsrechte, Aufbewahrung und die verantwortliche Stelle dokumentiert sind, sollte die Scoring-Phase beginnen. PII-Schutz gehört dabei in den Datenfluss vor Modell und Prompt, nicht in eine nachgelagerte Kampagnenprüfung.

Score: Woche drei bis fünf

In Woche drei bis fünf wird aus dem priorisierten Signal ein begrenztes Entscheidungsmodell. Vor der fachlichen Diskussion über Modellgüte braucht es eine Baseline: Welches Verhalten soll der Score unterstützen, welche Gruppe dient dem Vergleich und welcher Schwellenwert löst überhaupt eine Aktion aus? Ein Score ist keine Handlung; er ist ein dokumentierter Input für eine spätere Entscheidung.

Das Modell-Gate verlangt daher mehr als einen plausiblen Kennwert. Es umfasst Datenqualität, Modellversion, angenommene Grenzen, Testfälle und eine fachliche Abnahme. Die neunte MaRisk-Novelle fasst diese Anforderungen in AT 4.3.4 „Verwendung von Modellen“: Institute müssen Annahmen nachvollziehbar begründen, Eignung vor dem Einsatz bewerten, Datenqualität absichern, Modelle regelmäßig validieren und bei KI-Modellen auf hinreichende Erklärbarkeit achten. Eine Kennzahl ohne Version, Gültigkeitsbereich und Verantwortliche ist damit kein steuerbarer Score.

Orchestrate: Woche sechs bis sieben

In Woche sechs bis sieben wird festgelegt, wie ein freigegebener Score in eine konkrete Journey mündet. Dazu gehören Kanal, Zeitfenster, Kontaktfrequenz, Ausnahmen, Eskalation und der Punkt, an dem ein Mensch eingreift. Die Regel „nicht senden“ ist dabei genauso wichtig wie die Regel „senden“.

Dieses Gate trennt Determinismus und Optimierung. Consent, Opt-out, Sperrlisten und Frequenzgrenzen werden verbindlich durchgesetzt. Timing, Reihenfolge oder Textvarianten dürfen innerhalb dieser Leitplanken getestet werden. Für ein begrenztes Pilot-Szenario sollte jede Entscheidung auf Signal, Score-Version, Regel und ausgelöste Aktion zurückgeführt werden können. So entsteht kein Black Box Journey Builder, sondern ein auditable Prozess.

Go Live: Woche acht bis neun

Woche acht bis neun bedeutet einen kontrollierten Start, nicht die breite Automatisierung sämtlicher Journeys. Die Betriebsfreigabe sollte eine begrenzte Zielgruppe, einen verantwortlichen Owner, ein Stop-Kriterium, ein Incident-Verfahren und einen festen Rhythmus für die Ergebnisprüfung festhalten. Monitoring beginnt vor dem Versand: Es prüft Datenfluss, Consent, Ausspielung, Auffälligkeiten und die Fähigkeit, eine einzelne Entscheidung rasch zu rekonstruieren.

Der wichtigste Effekt dieser Reihenfolge ist organisatorisch. Fachteam und Kontrolle arbeiten nicht nacheinander, sondern am gleichen Entscheidungsobjekt. Das reduziert Übergaben und verhindert, dass Compliance erst nach dem Produktivstart nach einer Erklärung fragen muss.

Compliance als Entwurfsprinzip

Die Roadmap ersetzt keine rechtliche Einzelfallprüfung. Sie macht jedoch sichtbar, wo diese Prüfung stattfinden muss. Bei einer ausschließlich automatisierten Entscheidung mit rechtlicher oder ähnlich erheblicher Wirkung schützt Art. 22 DSGVO insbesondere das Recht auf menschliches Eingreifen, auf Darlegung des eigenen Standpunkts und auf Anfechtung der Entscheidung. Daraus folgt kein pauschales Recht auf Offenlegung eines Algorithmus. Die Informationspflichten nach Art. 13 bis 15 verlangen vielmehr aussagekräftige Informationen über die involvierte Logik; eine vollständige technische Offenlegung ist nicht erforderlich, wie die EDSA-Leitlinie WP251rev.01 erläutert. Der Prüfpunkt gehört in Connect und Score, nicht an das Ende der Journey.

Der EU AI Act verlangt eine zweite, getrennte Betrachtung. Systeme zur Bewertung der Kreditwürdigkeit natürlicher Personen sowie zur Risikoabschätzung und Preisbildung in der Lebens- und Krankenversicherung fallen in die Hochrisiko-Kategorien des Anhangs III. Für diese Anhang-III-Systeme greifen die einschlägigen Kapitel-III-Pflichten nach der Verordnung (EU) 2026/1744 ab dem zweiten Dezember 2027. Der allgemeine Geltungsbeginn des AI Act und die Transparenzpflichten bleiben davon unberührt.

Für Deployers solcher Hochrisikosysteme konkretisiert Art. 26 die operative Seite: menschliche Aufsicht muss kompetenten Personen zugewiesen werden, Eingabedaten müssen zweckbezogen relevant und hinreichend repräsentativ sein, und Logs sind mindestens sechs Monate aufzubewahren. Diese Anforderungen lassen sich als Gate-Evidenz führen: Benennung der Aufsicht, Datenprüfung, Log-Konzept und Betroffeneninformation. Damit wird Governance prüfbar, statt nur als Prinzip dokumentiert zu werden.

Ein KPI-System, das Lernen und Kontrolle verbindet

Kampagnenkennzahlen bleiben wichtig, reichen aber für Agenten nicht aus. Je Lifecycle-Phase braucht das Team eine Primärkennzahl und wenige Diagnosen: Akquise beobachtet Conversion und Kosten pro Akquisition; Aktivierung betrachtet Aktivierungsrate, Zeit bis zur ersten Nutzung und Annahme; Retention verfolgt Abwanderungs- und Bindungsrate sowie Reaktivierungsreaktionen. Die Kennzahl wird jeweils gegen eine vorab definierte Baseline oder Kontrollgruppe gelesen, nicht isoliert als Erfolgsmeldung.

Darüber liegt ein Programm-Scorecard mit vier Perspektiven. Erstens Wirkung: Verbesserung gegenüber Baseline. Zweitens Effizienz: Kontakte pro gewünschtem Ergebnis und Durchlaufzeit. Drittens Modellqualität: Stabilität, Drift und Lift gegenüber dem bisherigen Verfahren. Viertens Governance: Anteil nachvollziehbarer Entscheidungen, Zeit bis zur Audit-Antwort, offene Ausnahmen und abgebrochene Journeys. Diese Perspektive verhindert, dass eine kurzfristig bessere Conversion eine schwächere Kontrollfähigkeit verdeckt.

Als Referenz für die Messdisziplin kann ein belegter Reaktivierungsfall dienen: 175.000 kontaktierte Kundinnen und Kunden und ein Uplift von 30,3 % gegenüber der Kontrollgruppe. Dieser Wert ist kein Planwert für andere Programme. Er zeigt jedoch, warum eine Vergleichsgruppe, ein klarer Trigger und eine eindeutige Ergebnisdefinition zur Implementierung gehören.

Die operative Leitfrage

Ein guter Start beantwortet nicht „Wie viele Agents können wir ausrollen?“, sondern „Können wir diesen einen Trigger verantworten, erklären, überwachen und bei Bedarf stoppen?“ Wer jede Phase mit einem belastbaren Gate abschließt, gewinnt Geschwindigkeit ohne Kontrollverlust. Der nächste Use Case baut dann nicht auf Folien, sondern auf einem nachweislich funktionierenden Betriebsmodell auf.

Die Serie im Überblick

• Vom Kampagnenkalender zum AI Agent: So wird CLM zum geschlossenen Kreislauf

• Die Intelligence Layer: Warum CDP, Predictions und AI Agents zusammengehören

• AI Agents im Customer Lifecycle: fünfzehn Kampagnen von Akquise bis Win-back

• Ein Framework, drei Branchen: AI Agents für Banken, Karten und Versicherungen

• AI Agents operationalisieren: Roadmap, Governance und KPIs für Finanzdienstleister (aktueller Beitrag: /blog/ai-agents-financial-services-implementation-kpis)

Illustration: KI-generiert. KI-gestützte Inhalte: Bei der Erstellung unserer Beiträge setzen wir KI-Technologien und automatisierte Agenten ein, unter anderem von Microsoft, Google, OpenAI, Anthropic und weiteren Anbietern. Themen, fachliche Ausrichtung und finale Freigabe liegen bei unserem Team.