Die meisten KI-Projekte im Bankwesen scheitern aus einem Grund, der nichts mit der Modellqualität zu tun hat. Führungsteams verbringen Monate damit, Parameteranzahlen und Benchmark-Ergebnisse zu vergleichen, während eine leisere Bedrohung alles untergräbt, was sie aufbauen. Sie betrachten die Modellgröße als den Siegfaktor. Das ist sie nicht. In den regulierten, mehrstufigen Workflows, die den Finanzsektor dominieren, multipliziert sich Genauigkeit nicht. Sie zerfällt. Wer sich auf den Einzelschritt-Score fixiert, wird vom systemweiten Versagen unvorbereitet getroffen.

Das eigentliche Problem ist nicht die Modellgröße

Hier ist die Rechnung, die Risikomanager nachts wachhält. Stellen Sie sich eine Pipeline mit sechs verschiedenen Phasen vor – Datenextraktion, Validierung, Risikobewertung, Compliance-Prüfung, Dokumentenerstellung und finale Genehmigung. Jede Phase funktioniert isoliert betrachtet hervorragend und erreicht eine Genauigkeit von 97 Prozent. Der Instinkt ist, dies zu feiern. Aber die Wahrscheinlichkeit folgt nicht der Intuition. Verknüpft man diese Schritte, sinkt die End-to-End-Zuverlässigkeit auf etwa 83 Prozent.

Diese Lücke zwischen lokaler Perfektion und globalem Scheitern ist die KI-Koordinationslücke (AI Coordination Gap). Es ist der Reibungsverlust, der bei den Übergaben zwischen Agenten, Softwaretools und menschlichen Prüfern entsteht. Regulierungsbehörden suchen bereits genau nach dieser Schwachstelle. Sie werden sie entdecken, noch bevor Ihr Engineering-Team seine Post-Mortem-Analyse abgeschlossen hat.

Bis 2026 hat sich die Diskussion verschoben. Es geht nicht mehr darum, welches Modell ein Forschungs-Leaderboard anführt. Es geht um Budgetdisziplin, Datensouveränität und die Kontrolle über Updates. Sie entscheiden sich entweder für ein maßgeschneidertes Small Language Model, das Sie innerhalb Ihrer eigenen Infrastruktur kontrollieren können, oder für ein standardisiertes Large Language Model, das Sie pro Token mieten.

SLM vs. LLM: Was sich 2026 tatsächlich ändert

Standardisierte Frontier-Modelle – GPT-4o, Claude und ihre Kollegen – bleiben unerreicht bei offenem Reasoning und analytischen Aufgaben mit geringem Volumen. Sie lesen zwischen den Zeilen. Sie verstehen Nuancen. Aber dieser Komfort hat seinen Preis. Sie besitzen die Gewichte nicht. Sie kontrollieren den Release-Plan nicht. Ein stilles Wochenend-Update des Anbieters kann die Art und Weise verändern, wie Ihre Anwendung Schwellenwerte für das Schulden-Einkommens-Verhältnis interpretiert oder verdächtige Transaktionen markiert, und Sie haben möglicherweise keinen Nachweis darüber, was genau geändert wurde. In einer Branche, in der jede Entscheidung einen Audit-Trail erfordert, ist diese Undurchsichtigkeit teuer.

Maßgeschneiderte SLMs, die auf Open Weights wie Llama oder Mistral basieren, kehren die Gleichung um. Sie sind für harte, volumenintensive Aufgaben gebaut: das Extrahieren von Feldern aus Hypotheken-PDFs, das Klassifizieren von KYC-Dokumenten oder das Parsen von Transaktionsvermerken. Da Sie sie selbst hosten, können Sie eine Version einfrieren, Differenztests durchführen und einem Auditor beweisen, dass das Modell im März identisch mit dem Modell im Juni ist. Sie sind zudem extrem kostengünstig und kosten pro Token etwa zehn- bis dreißigmal weniger als ihre Cloud-basierten Verwandten. Der Kompromiss ist eine geringere Leistungsfähigkeit. Ein SLM wird nicht über Markttrends philosophieren. Es wird jedoch zehntausend Rechnungen pro Stunde stempeln, ohne proprietäre Daten außerhalb Ihrer Firewall zu versenden.

Heterogenes Routing: Der 80/20-Split

Die Banken, die die Nase vorn haben, betrachten dies nicht mehr als eine Entweder-oder-Wette. Ihre Architektur ist heterogen. Ein günstiges, feingetuntes SLM übernimmt die erste Durchlaufprüfung bei vorhersehbaren, strukturierten Aufgaben – Dokumentenextraktion, Entity Tagging oder routinemäßige Eignungsprüfungen – und bewältigt damit etwa achtzig Prozent des Gesamtvolumens. Die verbleibenden zwanzig Prozent – die Grenzfälle, die analogisches Denken oder komplexe Richtlinieninterpretationen erfordern – werden an ein Frontier-LLM eskaliert.

Das ist nicht theoretisch. Ein Hypothekenverwalter könnte ein SLM Einkommenszahlen aus Gehaltsabrechnungen extrahieren lassen und dann nur die unklaren Anträge an ein größeres Modell weiterleiten, das verschiedene Beschäftigungsverhältnisse mit den sich ändernden bundesstaatlichen Richtlinien abgleicht. So senken Sie die Cloud-Ausgaben, ohne die Leistungsfähigkeit zu reduzieren.

Ein Fünf-Schichten-Framework, um die Lücke zu schließen

Das Schließen der Koordinationslücke erfordert mehr als nur intelligentes Routing. Es benötigt einen expliziten Stack. Hier ist ein Fünf-Schichten-Framework, das Teams ab sofort einsetzen können.

  1. Modellauswahl. Behandeln Sie die Inferenz wie eine Triage-Pflegekraft. Leiten Sie Aufgaben basierend auf Volumen und Sensibilität weiter. Hochfrequente, risikoarme Operationen gehen an Ihr SLM. Fälle, die Urteilsvermögen, Mehrdeutigkeit oder die Lösung von Kundenbeschwerden erfordern, gehen an das LLM. Schreiben Sie die Routing-Regeln in Code, nicht in einen Prompt.

  2. Grounding. Jede Antwort, die einen Kunden betrifft, muss auf ein Quelldokument verweisen. Nutzen Sie Retrieval-Augmented Generation, um Ausgaben in Ihren tatsächlichen Richtlinienhandbüchern, Zinssätzen und regulatorischen Bekanntmachungen zu verankern. Vertrauen Sie niemals dem parametrischen Gedächtnis eines Modells für aktuelle Zinssätze oder Gebührenordnungen. Gedächtnis driftet. Ein PDF mit einer Versionsnummer nicht.

  3. Orchestrierung. Erstellen Sie Workflows, bei denen der Pfad sichtbar ist. Tools wie LangGraph ermöglichen es Ihnen, explizite, prüfbare Zustandsautomaten zu definieren. Eine Entscheidung sollte definierte Phasen durchlaufen: Extrahieren, Verifizieren, Entscheidung, Protokollieren. Lassen Sie Agenten sich nicht durch einen offenen Gesprächszyklus („Chat“) zu einem Ergebnis vorarbeiten. Wenn Sie das Flussdiagramm nicht zeichnen können, können Sie es auch einem Regulator nicht erklären.

  4. Tool-Zugriff. Agenten müssen Kernbanksysteme aufrufen können, aber jede Integration ist ein potenzieller Fehlerpunkt. Nutzen Sie das Model Context Protocol, um zu standardisieren, wie Agenten Ihre Hauptbücher, CRM-Datensätze und Compliance-Datenbanken authentifizieren und abfragen. Einheitliche Schnittstellen verringern die Gefahr unbemerkter Funktionsausfälle.

  5. Verifizierung. Reservieren Sie eine feste Spur für menschliches Urteilsvermögen. Leiten Sie Hochrisiko-Entscheidungen – große Überweisungen, Überschreitungen von Kreditlimits, Verdachtsmeldungen (SAR filings) – an einen menschlichen Prüfer oder an einen zweiten Verifizierungs-Agenten weiter, der auf einem isolierten Modell läuft. Redundanz an der Peripherie schützt das Zentrum.

Das Richtige messen

Hören Sie auf, Teams für die Genauigkeit pro Einzelschritt zu belohnen. Eine Pipeline, bei der jedes Modul eine Genauigkeit von 99 Prozent auf einem Testdatensatz beansprucht, kann dennoch bei jedem fünften echten Kunden scheitern, wenn die Schritte interagieren. Beginnen Sie damit, die End-to-End-Zuverlässigkeit zu messen. Speisen Sie synthetische Fehlerfälle ein. Testen Sie Übergaben so, wie Angreifer die Nahtstellen testen.

Die Banken, die im Jahr 2026 mit KI tatsächlich gewinnen, sind nicht diejenigen, die die größten Modelle mieten. Es sind diejenigen, die die klarsten Systeme zusammenfügen. Sie wissen, dass ein kleines Modell, das man prüfen kann, ein großes Modell schlägt, das man nicht erklären kann, und dass