RAG-Assistent für Vertragsprüfung: 4-Wochen-Pilot im Schweizer Fintech

Der Engpass: Vertragsprüfung im Schweizer Fintech-Backoffice

In Schweizer Fintechs mit 11 bis 50 Mitarbeitern hängen Vertragsprüfungen an drei Engpässen: Der Controller prüft Klauseln manuell gegen das interne Standardwerk, der Anwalt korrigiert Abweichungen per E-Mail, und der Vertrieb wartet auf Freigabe. Die First-Response-Time liegt bei 4 bis 8 Stunden pro Vertrag, die Fehlerquote bei 12 bis 18 Prozent, weil müde Mitarbeiter Klauseln übersehen. Das System: SAP oder Microsoft Dynamics ERP speichert Vertragsdaten, das CRM hält Kundenhistorie, aber die Prüfung selbst läuft in Word-Dokumenten und E-Mail-Threads. Kein System greift ineinander, keine Automatisierung existiert. Der Schmerz: Jede verzögerte Vertragsfreigabe kostet Auftragsvolumen, und jeder Fehler in einer Haftungsklausel kann zu Regressforderungen führen. Betroffen sind Controller, Anwälte und Vertriebsleiter – alle drei warten aufeinander, ohne dass ein System den Prozess orchestriert.

Warum Standardlösungen nicht greifen

Die meisten Schweizer Fintechs probieren drei Ansätze, die alle scheitern. Erstens: Generative KI als Chatbot. Mitarbeiter fragen Claude oder GPT-4 nach Klauselbegründungen, aber das Modell halluziniert Paragraphen und kennt nicht das interne Standardwerk. Zweitens: RAG ohne Human-in-the-Loop. Ein Vektor-Datenbank-System schlägt Redaktionen vor, aber niemand prüft sie, bevor sie in den Vertrag gehen. Bei 11 bis 50 Mitarbeitern fehlt die Kapazität für systematische Freigaben. Drittens: Vollständige ERP-Ersetzung. Man will SAP durch eine KI-native Plattform ersetzen, aber die Migration dauert 12 bis 18 Monate und kostet 200.000 bis 500.000 CHF. Alle drei Ansätze ignorieren die Realität: Schweizer Fintechs brauchen keine neue IT-Landschaft, sondern einen Layer über der bestehenden, der die Prüfung beschleunigt, ohne die Compliance zu gefährden. Die DSGVO und das nDSG erlauben keine Blackbox-Entscheidungen bei Vertragsänderungen.

Der Ansatz: RAG-Assistent mit Human-in-the-Loop

Der funktionierende Ansatz: Ein Retrieval-Augmented Knowledge Assistant, der über die bestehende ERP- und CRM-Landschaft läuft. Die Architektur: Verträge aus SAP/Dynamics werden in Vektor-Datenbanken (z. B. Pinecone oder Weaviate) eingelesen, chunked und mit Embeddings (Claude 3 Haiku oder OpenAI text-embedding-3-small) versehen. Die Claude API (Sonnet oder Opus) liest neue Verträge, vergleicht Klauseln mit dem internen Standardwerk und markiert Abweichungen. Der Mitarbeiter sieht eine diff-Ansicht: „Klausel 7.2 weicht ab: Haftungsbegrenzung 100.000 CHF statt 50.000 CHF“. Er akzeptiert, ändert oder lehnt ab. Die Entscheidung wird im ERP protokolliert. Human-in-the-Loop ist Pflicht: Jede Änderung, die Geld, Gesundheit oder Verträge betrifft, wird von einem Menschen freigegeben. Die Architektur ist model-agnostic: Claude API für Qualität, Open-Weight-Modelle (Llama 3 70B) auf eigener Hardware, wenn Daten die Schweiz nicht verlassen dürfen.

Vier Schritte zum Piloten in 4 Wochen

Woche 1: Prozess-Audit. Identifiziere den Workflow mit dem höchsten Volumen (z. B. 50 Verträge/Monat) und sammle die Datenbasis: Vertragsarchiv aus SAP, CRM-Historie, internes Standardwerk. Woche 2: RAG-Pipeline. Setze Vektor-Datenbank auf, chunk die Verträge, trainiere die Embeddings, integriere die Claude API. Woche 3: UI-Prototyp und Human-in-the-Loop. Baue eine einfache Web-UI, die Abweichungen anzeigt, und teste mit 5 echten Verträgen. Woche 4: Messung und Übergabe. Erstelle ein Vorher/Nachher-Baseline: First-Response-Time, Fehlerquote, Durchlaufzeit. Dokumentiere den Workflow und übergib an Managed Operations. Für 11 bis 50 Mitarbeiter: Ein einziger approvierender Mitarbeiter pro Tag reicht, da die Vorarbeit den manuellen Aufwand um 60 bis 70 Prozent reduziert. Die 4-Wochen-Frist ist realistisch für einen Piloten auf einem einzigen Workflow, nicht für eine vollständige ERP-Integration.

Stolperfallen und Compliance-Hürden

Stolperfall 1: Datenresidenz. Die Claude API verarbeitet Daten in den USA. Für Schweizer Fintechs mit strengen nDSG-Anforderungen: Open-Weight-Modelle auf eigener Hardware in Zürich oder Genf. Die Architektur bleibt model-agnostic – ein Wechsel erfordert nur einen API-Adapter. Stolperfall 2: Fehlende Freigabe-Struktur. Ohne klar definierten approvierenden Mitarbeiter pro Tag kollabiert der Human-in-the-Loop-Prozess. Definiere: Wer prüft, wie lange dauert die Freigabe, was passiert bei Ablehnung? Stolperfall 3: Skalierung ohne Messung. Wenn der Pilot läuft, aber keine Baseline existiert, kann man nicht beweisen, dass die First-Response-Time gesunken ist. Erstelle das Vorher/Nachher-Protokoll in Woche 1, nicht in Woche 4. Stolperfall 4: Compliance-Blindheit. Die DSGVO (Art. 6, 9) und das nDSG erfordern Logging aller Abfragen, RBAC-Zugriffskontrolle und eine Datenflussanalyse. Ohne diese drei Elemente: Kein Go-Live.