Souveräne KI beginnt bei den Schwellwerten und nicht beim Anbieter

Eine Kreditpipeline läuft heute zu über 85 Prozent durch und das schneller, kontrollierbarer und freigabefähig. Nicht, weil ein Foundation Model alles löst, sondern weil wir aufgehört haben, hohe Schwellwerte mit Sicherheit zu verwechseln. Ein Bericht aus dem Maschinenraum.

von Maximilian Dassler, Se­ni­or Pro­duct Ma­na­ger bei DFKP

Als Deutsche Firmenkredit Partner (DFKP) ermöglichen wir kleinen und mittleren Unternehmen einen hausbankunabhängigen Zugang zur passenden Finanzierung. Dafür verarbeiten wir rund 200 Dokumentenklassen wie Jahresabschlüsse, BWAs, Kontoauszüge, Steuerunterlagen, Gesellschaftsverträge. Herausfordernd ist nicht nur die Anzahl, sondern die massive Variation innerhalb einer Klasse: Format, Struktur und Umfang ändern sich je nach Quelle. Früher lief das durch Sichtkontrolle und manuelle Übertragung.

Eine Skalierung war demzufolge nur über mehr Personal möglich.“

Heute geht der Großteil dieser Dokumente ohne menschlichen Eingriff durch. Nicht über ein Modell, sondern über eine Architektur, die wir bewusst nicht monolithisch gebaut haben. Die Frage war übrigens nie, ob wir das selbst bauen können. Die Frage war, ob wir es in wenigen Monaten produktiv stabil betreiben können. Die Antwort lag in Buildsimple, einer Cloud-Plattform aus Deutschland für die automatische Klassifikation, Analyse und Extraktion von Dokumenten, die im produktionsnahen PoC mit echten, schwierigen Dokumenten aus dem Tagesgeschäft zurecht kam – nicht mit synthetischen Mustern.

Architektur: Kombination, nicht Monolith

Im ersten Schritt übernimmt ein Foundation Model die Klassifikation und Extraktion für die zehn bis 15 Kernklassen, die den Großteil unseres Volumens tragen. Pro Klasse sind eigene Konfidenzschwellen definiert; ein Dokument läuft nur dann automatisch durch, wenn es seine Schwelle überschreitet. Unterschreitet es sie, übernimmt ein Large Language Model – und das Routing entscheidet nicht nur nach Klasse, sondern nach Ausprägung innerhalb der Klasse: Ein Jahresabschluss aus Datev ist ein anderes Dokument als einer aus Lexware, auch wenn er gleich heißt.

Regelbasierte Validierung sitzt an Stellen, wo deterministische Logik gilt, dort braucht es kein Modell, sondern Präzision.“

Extraktionsergebnisse gehen als JSON in Salesforce Custom Objects und von dort in eine Finance Engine, die gegen die Kriterien von über 200 Finanzierungspartnern prescort. Schwellwerte werden anhand realer Produktionsdaten kontinuierlich nachkalibriert. Korrekturen aus dem Quality Review fließen automatisiert per API in das Modelltraining zurück und verbessern die Klassifikation für die nächste Iteration. Die Steuerungslogik liegt vollständig bei uns, einschließlich des LLM-Pfads: welche Daten in welches Modell wandern, wie sie protokolliert werden, wann ein Fallback greift. Im regulierten Umfeld ist das Voraussetzung: Wer Modellauswahl, Routing und Schwellwerte nicht selbst kontrolliert, kann auch keinen Audit-Nachweis führen.

Das einfachste Dokument ist das schwierigste

Kontoauszüge wirken oft standardisiert. Sind sie allerdings nicht. Jede Bank strukturiert sie anders. Zeiträume stehen mal explizit im Header, mal müssen sie aus Transaktionsdaten abgeleitet werden. Unser erstes klassisches ML-Modell kam mit der Heterogenität nicht zurecht – die Genauigkeit war für ein Volumen-Dokument unbrauchbar. Die Lösung war kein Strategiewechsel, sondern Notwehr: ein spezialisiertes ML-Modell für die volumenstarken Banken mit einheitlicher Struktur, ein vorgeschalteter Klassifikator, der die übrigen Auszüge an ein LLM weiterleitet.

Erst diese Hybrid-Architektur brachte die nötige Genauigkeit – und sie ist heute die mit Abstand größte Verbesserung unserer Dunkelverarbeitungsquote (STP-Rate).“

BWA, SuSa, G&V und Jahresabschluss sind häufig Teile voneinander, mal einzeln eingereicht, mal kombiniert in einer Datei. Zwei Probleme traten gleichzeitig auf: Erstens erkennt das Modell ab einer gewissen Seitenzahl die hinteren Dokumentteile nicht mehr zuverlässig. Zweitens sind sich die Dokumenttypen so ähnlich, dass eine eingebettete G&V im Jahresabschluss fälschlich als Standalone klassifiziert wird. Die Lösung erforderte dediziertes Training pro Dokumenttyp und präzise Schwellwert-Kalibrierung, iterativ, mit Produktionsdaten, deutlich aufwändiger als geplant.

Die Vertrauensfalle: Wo Vorsicht in Stillstand kippt

Die heikelste Lehre war nicht technisch, sondern operativ. Initial haben wir die Konfidenzschwellen hoch angesetzt – aus Vorsicht. Das Ergebnis: Ein Großteil der Dokumente lief technisch automatisiert, wurde aber trotzdem manuell nachkontrolliert. Die Key-User hatten kein Vertrauen in die Quote, also prüften sie alles. Der Automatisierungsvorteil verbrannte.

Hohe Schwellwerte sehen nach Sicherheit aus, sind aber Stillstand.“

Sie verschieben die manuelle Arbeit nur einen Schritt nach hinten. Der Balanceakt seither: Training so optimieren, dass die Dunkelverarbeitungsquote steigt, ohne dass die Key-User aussteigen. Das ist ein laufender Prozess, besonders bei jedem neuen Dokumenttyp oder jeder Erweiterung der Extraktionsfelder.

Was die Architektur heute leistet

Über 85 Prozent Dunkelverarbeitung, rund 70 Prozent Zeitersparnis, rund 60 Prozent weniger Korrekturen, dreifacher Durchsatz mit gleichem Personalstand. Die Bearbeitungszeit pro Dokument hat sich im Median von ca. 30 auf 2 Minuten verkürzt. Rund die Hälfte der Teamkapazität ist heute frei für komplexe Fälle statt für Routine.

Auf 100 Prozent zielen wir gar nicht erst ab, denn die letzten Prozentpunkte bei den heterogensten Klassen kosten unverhältnismäßig viel.“

Und wo der Kunde unvollständige Dokumente liefert, kann auch das beste Modell nichts extrahieren. Das ist der Skalierungsgewinn, nicht die Quote Was die Architektur­entscheidungen für IT-Verantwortliche im regulierten Umfeld bedeutet, lässt sich auf zwei Sätze bringen:

Foundation Models sind ein Werkzeug, kein Plan. Und 100 Prozent Automatisierung sind ein KPI, kein Ziel.“

Maximilian Dassler, DFKP