Ticket-Triage im Schweizer Fintech: Cloud-LLM versus On-Premise-Modell

Zwei Ansätze für die Ticket-Triage im Schweizer Fintech

Ein Schweizer Fintech mit 120 Mitarbeitenden steht vor zwei Optionen, um die Ticket-Triage im Back-Office zu automatisieren: ein Cloud-LLM wie GPT-4o oder Claude 3.5 Sonnet über die API des Anbieters, oder ein Open-Weight-Modell wie Llama 3 70B oder Mistral Large, das auf eigener Hardware im Rechenzentrum läuft. Beide Ansätze lösen dasselbe Problem: Support-Tickets aus dem Zahlungsverkehr, der Compliance und dem Back-Office werden automatisch klassifiziert, priorisiert und an die richtige Fachabteilung geroutet. Der entscheidende Unterschied liegt nicht in der Modellqualität, sondern in der Datenhoheit, den Betriebskosten und der Skalierbarkeit über mehrere Abteilungen hinweg. Für ein Unternehmen, das ISO 27001 zertifiziert ist und Kundendaten nicht an Dritte übermitteln darf, fällt die Entscheidung zugunsten des On-Premise-Ansatzes aus, auch wenn dieser höhere Initialkosten und mehr Betriebskomplexität mit sich bringt.

Acht Kriterien für die Entscheidung

Die Bewertung stützt sich auf acht Kriterien, die für den konkreten Use Case relevant sind: Latenz pro Ticket, Betriebskosten pro 1 000 Tickets, Vendor-Lock-in, ISO 27001-Konformität, Skalierbarkeit über Abteilungen, Integrationsaufwand in bestehende Helpdesk-Systeme, Fehlerquote bei der Klassifikation und Verfügbarkeit des Modells bei Ausfällen. Die Latenz misst die Zeit von der Ticket-Eingabe bis zur Rückgabe der Klassifikation. Die Betriebskosten umfassen API-Gebühren oder Strom, Kühlung und Wartung der Hardware. Der Vendor-Lock-in beschreibt, wie stark das Unternehmen an einen bestimmten Anbieter gebunden ist. Die ISO 27001-Konformität prüft, ob die Datenverarbeitung den Anforderungen der Norm entspricht, insbesondere bei der Verarbeitung von Kundendaten im Zahlungsverkehr. Die Skalierbarkeit bewertet, wie aufwendig es ist, das System von einem Fachbereich auf drei oder vier Abteilungen auszuweiten.

Vergleichstabelle: Cloud-LLM versus On-Premise

Die Zahlen basieren auf typischen Werten aus Pilotprojekten im Schweizer Fintech-Umfeld. Die Latenz des On-Premise-Ansatzes ist höher, weil die Inferenz auf eigener Hardware erfolgt und keine optimierten Cloud-Cluster genutzt werden. Die Betriebskosten sinken nach der Amortisation der Hardware deutlich, da keine pro Token abgerechneten Gebühren anfallen. Die Fehlerquote ist beim On-Premise-Modell leicht höher, weil die Modelle in der Regel kleiner sind als die proprietären Cloud-Modelle und weniger Fine-Tuning-Daten erhalten haben.

Wann Cloud-LLMs die bessere Wahl sind

Der Cloud-Ansatz gewinnt, wenn das Unternehmen keine strengen Datenschutzanforderungen hat, die Latenz unter 1 000 ms kritisch ist und der Betrieb schnell starten soll, ohne eigene Hardware zu beschaffen. Für ein Fintech, das nur allgemeine Support-Tickets ohne Kundendaten verarbeitet, ist GPT-4o über die API eine pragmatische Wahl: Die Integration dauert zwei bis drei Wochen, die Fehlerquote liegt bei 4 bis 7 Prozent, und die Kosten sind pro Ticket kalkulierbar. Der On-Premise-Ansatz gewinnt, wenn Kundendaten, Transaktionshistorien oder Compliance-Dokumente verarbeitet werden müssen, die das Gebäude nicht verlassen dürfen. In diesem Fall ist die höhere Latenz von 1 500 bis 2 500 ms akzeptabel, weil die Triage nicht in Echtzeit erfolgen muss, sondern innerhalb von 30 bis 60 Sekunden. Die höhere Fehlerquote von 6 bis 9 Prozent lässt sich durch eine mehrstufige Pipeline mit menschlicher Freigabe für kritische Tickets kompensieren.

Skalierung über Abteilungen und Integrationsaufwand

Die Skalierung über Abteilungen ist der entscheidende Faktor für Unternehmen mit 51 bis 200 Mitarbeitenden, die in drei bis vier Monaten von einem Piloten auf den Regelbetrieb übergehen wollen. Der Cloud-Ansatz skaliert linear: Jede zusätzliche Abteilung erhöht das API-Volumen und damit die Kosten, aber die Infrastruktur bleibt unverändert. Der On-Premise-Ansatz erfordert eine Hardware-Erweiterung, wenn die Ticket-Volumen über die Kapazität der bestehenden GPU-Instanz hinauswachsen. In der Praxis bedeutet das: Für zwei Abteilungen genügt eine NVIDIA A100 80GB, für vier Abteilungen sind zwei Instanzen oder eine A100 40GB mit optimierter Batch-Verarbeitung nötig. Die Kosten für die zusätzliche Hardware liegen bei 20 000 bis 40 000 CHF, was in der Regel innerhalb von sechs bis neun Monaten durch die eingesparten API-Gebühren amortisiert ist. Die Integration in bestehende Helpdesk-Systeme erfolgt in beiden Fällen über REST-APIs und Webhooks, der Aufwand ist beim On-Premise-Ansatz um zwei bis drei Wochen höher, weil die lokale Vektordatenbank für die RAG-Komponente eingerichtet und die API-Endpunkte im internen Netzwerk abgesichert werden müssen.

Empfehlung für den konkreten Use Case

Für ein Schweizer Fintech mit ISO 27001-Zertifizierung, 120 Mitarbeitenden und dem Ziel, die Fehlerquote im Back-Office innerhalb von drei Monaten zu senken, ist der On-Premise-Ansatz die richtige Wahl. Die Begründung ist dreifach: Erstens, die Datenhoheit. Kundendaten aus dem Zahlungsverkehr dürfen nicht an Cloud-Anbieter in den USA oder der EU übermittelt werden, was die ISO 27001-Konformität gefährdet. Zweitens, die Skalierbarkeit. Die Ausweitung von einem Piloten auf drei Abteilungen (Zahlungsverkehr, Compliance, Back-Office) ist mit einer einmaligen Hardware-Erweiterung um 20 000 bis 40 000 CHF möglich, während der Cloud-Ansatz die Kosten pro Ticket dauerhaft erhöht. Drittens, die Kostenstruktur. Nach der Amortisation der Initialinvestition von 40 000 bis 80 000 CHF sinken die Betriebskosten pro 1 000 Tickets auf 5 bis 12 CHF, was bei einem Volumen von 5 000 bis 10 000 Tickets pro Monat eine jährliche Ersparnis von 30 000 bis 60 000 CHF gegenüber dem Cloud-Ansatz bedeutet. Die höhere Latenz und die leicht höhere Fehlerquote sind akzeptabel, weil die Triage nicht in Echtzeit erfolgen muss und eine menschliche Freigabe für kritische Tickets die verbleibenden Fehler abfängt.