AI Automation Audit: 15-Punkte-Checkliste für Fintech in der Schweiz

Warum ein Audit vor dem Piloten steht

Ein AI Automation Audit ist kein Beratungsauftrag, sondern ein technisches Due-Diligence-Projekt. Es endet mit einem dokumentierten Plan, der festlegt, welcher Workflow als Pilot dient, welche APIs angebunden werden und welche Compliance-Hürden bestehen. Für eine Fintech-Firma mit 51 bis 200 Mitarbeitern in der Schweiz bedeutet das: Der Audit muss innerhalb von 2 Wochen abgeschlossen sein, um den Cashflow nicht zu belasten. Die Checkliste unten ist so aufgebaut, dass jeder Punkt innerhalb von 1 bis 2 Tagen abgearbeitet werden kann. Sie ersetzt keine Strategie, aber sie verhindert, dass der Pilot an technischen oder regulatorischen Details scheitert, die im Vorfeld hätten erkannt werden können.

Prozessanalyse und Datenqualität

Bevor ein einziger Code geschrieben wird, muss der Ist-Zustand der Ticket-Verarbeitung dokumentiert sein. Das Helpdesk-System (z. B. Zendesk, Jira Service Management oder ein eigenes Tool) liefert die Rohdaten. Die Frage ist nicht, wie viele Tickets pro Woche ankommen, sondern wie sie strukturiert sind. Ein Ticket mit dem Betreff ‘Zahlung nicht angekommen’ und dem Körper ‘Kunde X sagt, das Geld ist weg’ ist für ein LLM schwer zu klassifizieren. Ein Ticket mit den Feldern ‘Kunden-ID’, ‘Transaktions-ID’, ‘Fehlercode’ und ‘Beschreibung’ ist es nicht. Der Audit muss also die Datenqualität der Eingaben messen. Wenn weniger als 70 % der Tickets die benötigten Metadaten enthalten, ist der erste Schritt nicht die KI, sondern die Anpassung des Ticket-Formulars. Das kostet 2 Tage Entwicklung, spart aber 4 Wochen Fehlklassifikation im Piloten.

Compliance und Datenfluss

PCI DSS v4.0 ist in der Schweiz kein optionales Framework, sondern eine Voraussetzung für die Zusammenarbeit mit Payment-Providern. Abschnitt 3.3 verlangt, dass PANs (Primary Account Numbers) bei Speicherung maskiert werden. In einem RAG-System bedeutet das: Vor dem Einbetten in pgvector muss die PAN aus dem Dokument entfernt oder durch einen Token ersetzt werden. Der Token wird in einem getrennten, verschlüsselten Key-Value-Store abgelegt, der nur dem Entschlüsselungs-Service zugänglich ist. Das Embedding enthält somit keine sensiblen Zahlungsdaten. Zusätzlich muss der Audit prüfen, ob das Helpdesk-System Webhooks für neue Tickets und REST-Endpunkte für das Setzen von Metadaten bietet. Wenn nicht, ist der Pilot auf ein anderes System umzuleiten oder die API muss erst ausgebaut werden.

Technische Architektur und Integration

Die Architektur des Piloten ist bewusst model-agnostic. Für die Ticket-Triage wird ein Open-Weight-Modell (z. B. Llama 3 70B oder Mistral 8x7B) auf der eigenen Hardware des Kunden betrieben, da die Tickets PCI DSS-relevante Daten enthalten können. Das Modell wird über eine Custom REST API angesprochen, die die Eingaben validiert und die Ausgaben in das Helpdesk-System zurückspielt. pgvector dient als Vektordatenbank für die Retrieval-Augmented Generation: Die Support-Dokumentation, die FAQ und die letzten 100 gelösten Tickets werden in Vektoren umgewandelt und in pgvector gespeichert. Die Suche erfolgt über einen HNSW-Index, der bei 100.000 Vektoren eine Latenz von unter 50 ms liefert. Die Webhooks des Helpdesk-Systems triggern den Agenten bei jedem neuen Ticket. Der Agent erstellt einen Draft und tragt ihn als Kommentar in das Ticket ein. Der Support-Mitarbeiter prüft und sendet.

KPIs und Messbarkeit

Der Pilot ist kein ‘Try and Error’, sondern ein gemessener Vergleich. Vor dem Start wird der Baseline-Wert erfasst: Wie lange dauert es im Durchschnitt, bis ein Ticket klassifiziert und weitergeleitet wird? Wie hoch ist die Fehlerquote bei der manuellen Zuordnung? Diese Zahlen werden in einem Dashboard festgehalten. Nach 4 Wochen Pilotbetrieb wird derselbe Messwert erhoben. Die Zielgröße ist eine Reduktion der Cycle Time um mindestens 40 % und eine Fehlerquote von unter 2 %. Wenn die Zahlen nicht erreicht werden, wird der Pilot nicht fortgesetzt, sondern die Ursache analysiert. Häufige Stolpersteine sind: unklare Ticket-Beschreibungen, fehlende Metadaten, oder ein Modell, das für die deutsche Sprache nicht ausreichend trainiert ist. Die Checkliste unten hilft, diese Punkte im Vorfeld zu identifizieren.

Pflege und Weiterentwicklung der Checkliste

Eine Checkliste ist kein statisches Dokument. Nach dem Piloten muss sie aktualisiert werden, um die neuen Erkenntnisse einzuarbeiten. Wenn der Pilot gezeigt hat, dass die Ticket-Beschreibungen zu vage sind, wird ein neuer Punkt ‘Ticket-Formular anpassen’ ergänzt. Wenn das Modell bei bestimmten Ticket-Typen fehlerhaft klassifiziert, wird ein Punkt ‘Modell-Finetuning für Typ X’ hinzugefügt. Die Checkliste wird alle 3 Monate von einem technischen Lead und einem Compliance-Beauftragten gemeinsam durchgegangen. Änderungen werden versioniert und dokumentiert. So bleibt das Dokument ein lebendes Werkzeug, das mit der Reifegrad-Entwicklung der KI-Automatisierung mitwächst.