Ticket-Triage im Fintech: RAG-Assistent mit OpenAI API und PCI-DSS

Problem: Manuelle Ticket-Triage im Fintech-Support

Fintech-Unternehmen in Österreich mit 500 bis 2000 Mitarbeitern kämpfen mit einem wachsenden Ticket-Volumen im Customer Support. Manuelle Klassifikation und Zuordnung binden wertvolle Arbeitszeit und führen zu einer Fehlerquote von 15-25% bei der Routing-Entscheidung. Das Ergebnis: längere Durchlaufzeiten, unzufriedene Kunden und überlastete Support-Teams. Ein Retrieval-Augmented Knowledge Assistant (RAG) kann diese manuelle Arbeit automatisieren, indem er Tickets semantisch klassifiziert und die passende Antwort oder den zuständigen Mitarbeiter vorschlägt. Die Herausforderung liegt nicht in der Technologie, sondern in der Integration in bestehende Prozesse und die Einhaltung von PCI-DSS-Anforderungen. Ein Fixed-Scope-Pilot bietet die Möglichkeit, den Nutzen messbar zu validieren, bevor eine breite Skalierung erfolgt. Der Fokus liegt auf einer Reduktion der Fehlerquote und einer Verkürzung der Dokument-Durchlaufzeit im Back Office.

Architektur: RAG-Assistent mit OpenAI API und lokaler Option

Der Pilot startet mit einem Prozess-Audit der bestehenden Support-Workflows. Ziel ist es, die drei häufigsten Ticket-Kategorien zu identifizieren, die zusammen 60-70% des Volumens ausmachen. Diese Kategorien werden für die Automatisierung ausgewählt. Die Architektur nutzt die OpenAI API für die semantische Klassifikation und Antwortgenerierung, da sie aktuell die höchste Qualität bei der natürlichen Sprachverarbeitung bietet. Für PCI-DSS-kritische Daten, die den Server nicht verlassen dürfen, wird ein Open-Weight-Modell wie Llama 3 auf eigener Hardware betrieben. Die Integration erfolgt über die offiziellen APIs von Slack oder Microsoft Teams. Der Assistent wird als Bot eingerichtet, der in spezifischen Kanälen aktiv ist. Er liest eingehende Tickets, klassifiziert sie und postet eine vorgeschlagene Antwort oder Routing-Empfehlung. Die Endanwender interagieren weiterhin über ihre gewohnten Kanäle, ohne neue Software installieren zu müssen. Diese model-agnostische Architektur ermöglicht es, je nach Datenklasse den richtigen Provider zu wählen.

Zeitplan: 6 Monate vom Audit zum Rollout

Die Implementierung dauert typischerweise 6 Monate. Monat 1-2: Prozess-Audit und Datenbereinigung. Die historischen Tickets werden auf Qualität und Vollständigkeit geprüft. Fehlende Metadaten werden ergänzt, unklare Kategorien werden neu definiert. Monat 3-4: Pilot-Entwicklung und Integration in Slack/Teams. Der RAG-Assistent wird trainiert und in die bestehenden Workflows eingebunden. Monat 5: Validierung und Human-in-the-Loop-Training. Die Support-Mitarbeiter lernen, die Vorschläge des Assistenten zu prüfen und zu korrigieren. Monat 6: Rollout und Übergabe an den Betrieb. Der Pilot wird auf weitere Ticket-Kategorien ausgeweitet. Die Human-in-the-Loop-Struktur ist Standard: Der Assistent klassifiziert das Ticket und schlägt eine Antwort vor. Ein Mensch prüft den Vorschlag und bestätigt oder korrigiert ihn. Bei Tickets, die Geld, Gesundheitsdaten oder Verträge betreffen, ist die menschliche Freigabe obligatorisch. Diese Struktur ist nicht optional, um Compliance und Qualität sicherzustellen.

Compliance: PCI-DSS-Anforderungen und Datenhaltung

PCI-DSS-konforme Implementierung erfordert eine klare Trennung der Datenklassen. Kreditkartendaten (PAN) dürfen im Klartext nicht an externe APIs gesendet werden. Die Triage-Klassifikation erfolgt auf Basis von Metadaten und anonymisierten Texten. Bei sensiblen Daten wird das Modell lokal gehostet. Die Architektur muss so gestaltet sein, dass PCI-DSS-Scopes klar getrennt sind und keine sensiblen Daten in der OpenAI-API landen. Zusätzlich werden Logging-Mechanismen implementiert, die alle Aktionen des Assistenten protokollieren. Diese Logs sind für Audits und Compliance-Prüfungen erforderlich. Die menschliche Freigabe bei sensiblen Tickets dient als zusätzliche Sicherheitsmaßnahme. Regelmäßige Penetrationstests und Code-Reviews sind Teil des Betriebs. Die Compliance-Strategie wird im Prozess-Audit definiert und im Pilot validiert.

Messung: Vorher-Nachher-Baseline und ROI

Der Pilot liefert einen messbaren Vorher-Nachher-Vergleich zu drei Kernmetriken: Durchlaufzeit, Fehlerquote und manuelle Nachbearbeitungszeit. Die Durchlaufzeit wird von der Ticket-Eingangszeit bis zur Zuordnung gemessen. Ziel ist eine Verkürzung um 40%. Die Fehlerquote bei der Klassifikation wird durch Stichproben von 100 Tickets pro Woche gemessen. Ziel ist eine Reduktion um mindestens 30%. Die manuelle Nachbearbeitungszeit wird durch die Support-Mitarbeiter erfasst. Ziel ist eine Reduktion um 50%. Diese Metriken werden im Pilot-Report dokumentiert und als Basis für die Skalierungsentscheidung genutzt. Der ROI wird durch die eingesparte manuelle Arbeitszeit und die reduzierte Fehlerquote berechnet. Bei einem Unternehmen mit 500-2000 Mitarbeitern liegt der typische ROI bei 200-300% innerhalb des ersten Jahres nach Rollout.

Stolperfallen und Gegenmaßnahmen

Die häufigsten Stolperfallen sind: unzureichende Datenqualität in den historischen Tickets, fehlende klare Eskalationsregeln und Widerstand der Support-Teams. Gegenmaßnahmen: Vor dem Pilot eine Datenbereinigung durchführen, klare SLAs für die menschliche Freigabe definieren und die Support-Mitarbeiter früh in den Design-Prozess einbinden. Ein weiterer häufiger Fehler ist die Annahme, dass der Assistent 100% der Tickets korrekt klassifiziert. In der Praxis liegt die Genauigkeit bei 85-95%, je nach Ticket-Kategorie. Die menschliche Freigabe ist daher nicht optional, sondern ein integraler Bestandteil der Architektur. Bei der Skalierung auf weitere Kategorien muss die Datenqualität erneut geprüft werden. Neue Kategorien erfordern oft zusätzliche Trainingsdaten und Anpassungen der Klassifikationslogik. Die model-agnostische Architektur ermöglicht es, bei Bedarf auf ein anderes Modell umzustellen, ohne die Integrationsschicht zu ändern.