Muss dieser Antrag von einem Menschen geprüft werden, oder kann er automatisch freigegeben werden? Diese Frage stellt sich bei jeder Kontoeröffnung. Im Vortrag „Vertical AI“ zeige ich, wie feste Regeln, ein kleines, im eigenen Haus trainiertes KI-Modell und der Mensch in einem BPMN-Prozess zusammenarbeiten. Und was passiert, wenn man das Modell nicht nur nach dem Ergebnis fragt, sondern nach den Gründen.

Vertical AI im KYC-Prozess: Regeln, lokale KI und Mensch im BPMN-Prozess

Das Wichtigste in Kürze

  1. Regeln sind immer effizienter als Intelligenz, ob künstlich oder natürlich. Eine DMN-Regel entscheidet in einer Millisekunde und ist in Minuten geändert. Eine Korrektur am Modell heißt: neu trainieren.
  2. Vertical AI schützt interne Daten. Das Modell läuft und lernt im eigenen Haus, auf einem einzigen Mac. Keine Kundendaten verlassen die Bank.
  3. Das Modell lernt, was in den Daten steckt, nicht das, was wir gern hätten. Ein fehlerfreier Testlauf beweist nicht, dass es das Richtige gelernt hat.
  4. Der Prozess entscheidet, wann der Mensch prüft, nicht die KI. Eine Regel kann das Modell nicht aufheben. Fällt es aus, landet der Fall beim Menschen.
  5. Spezialisierte KI ist klein, lokal trainierbar, schnell und günstig. 322 Millionen Parameter, Training in rund anderthalb Stunden, Antwort in Sekundenbruchteilen.
  6. Teilfragen zeigen, warum die KI so entscheidet, und wo sie irrt.

Der Anwendungsfall: KYC bei der Kontoeröffnung

Die Identität des Kunden ist bereits geprüft. Bewertet werden seine Angaben, das Screening und die eingereichten Unterlagen. Es gibt drei Ausgänge: automatische Freigabe, Ablehnung bei einem eindeutigen Ausschlussgrund oder manuelle Prüfung. Das Dilemma kennt jede Bank: Alles von Hand zu prüfen ist teuer, alles automatisch freizugeben ist riskant. Richtlinie und Daten der Demo sind erfunden; alle Anträge sind synthetisch.

Stufe 1: Regeln, KI und Mensch im BPMN-Prozess

Der Prozess arbeitet in drei Schritten:

  • Regeln (DMN): Eine Entscheidungstabelle prüft das Eindeutige. Ist der Kunde nicht selbst wirtschaftlich berechtigt, ist er eine politisch exponierte Person, gibt es einen ungeklärten Screening-Treffer oder einen Bezug zu den USA, muss ein Mensch prüfen. Ein bestätigter Sanktionstreffer führt sofort zur Ablehnung; das Modell wird dann gar nicht erst gefragt.
  • KI (Laya Multilingual): Auch wenn die Regeln grün sind, bewertet das Modell den Antrag. Es prüft, ob Freitexte, Nachweise und Kontozweck zusammenpassen, und beantwortet genau eine Frage: manuell prüfen, ja oder nein.
  • Mensch: Alle übrigen Fälle landen im Postkorb und werden dort entschieden.

Automatisch freigegeben wird nur, wenn die Regeln grün sind und das Modell keine Prüfung verlangt. Fällt das Modell aus, geht der Fall in die manuelle Prüfung. Die Regel zum USA-Bezug haben wir übrigens erst nachträglich ergänzt: in wenigen Minuten und ohne jedes Training.

So lernt das Modell

Grundlage sind Fälle aus der Vergangenheit, bei denen bekannt ist, ob ein Mensch prüfen musste. In der Demo sind es 6.000 synthetische Anträge mit typischen Mustern, etwa ein Privatkonto, das eigentlich geschäftlich genutzt werden soll, oder eine Ersteinzahlung aus einem Darlehen statt aus Einnahmen. Mit diesen Fällen haben wir das frei lizenzierte Basismodell Laya Multilingual lokal auf einem Mac M1 Max trainiert. Vor dem Training schickte es fast jeden Antrag in die Prüfung, danach keinen einzigen unnötig.

Das Training dauerte für 5.000 Anträge gut anderthalb Stunden. Hochgerechnet sind 20.000 Anträge in etwa sechs, 50.000 in etwa fünfzehn Stunden trainiert, also über Nacht. Erst bei rund einer Million Fällen lohnt sich ein GPU-Server. Wichtiger als die Dauer ist, dass sich das Training jederzeit wiederholen lässt: Daten ergänzen, neu trainieren, mit Testdaten und Gegenproben prüfen, Modell tauschen. Prozess und Regeln bleiben dabei unverändert.

Warum kein großes Sprachmodell aus der Cloud?

  • Datenschutz: Die Kundendaten würden an einen externen Dienst gehen.
  • Kosten und Tempo: Sekunden und Gebühren pro Antrag statt Sekundenbruchteilen auf eigener Hardware.
  • Kontrolle: Ein Cloud-Modell lässt sich nicht im eigenen Haus auf die eigene Richtlinie trainieren, und die Modellversionen wechselt der Anbieter.
  • Prüfbarkeit: Freier Text statt einer festen Entscheidung mit Wahrscheinlichkeit.

Fairerweise: Ein großes Sprachmodell könnte Begründungen formulieren. Das kann Laya nicht. Und genau hier setzt die zweite Stufe an.

Die erste Erkenntnis: Ein guter Test reicht nicht

Auf den Testdaten entschied das Modell fehlerfrei. Gegenproben, bei denen wir jeweils nur ein einziges Merkmal eines Antrags verändert haben, zeigten trotzdem eine Abkürzung: Bei der Wohnadresse an der Reeperbahn reagierte das Modell auf einen Dokumenttyp im Antrag statt auf die Adresse selbst. Mit 1.000 zusätzlichen Beispielen und knapp zwei Stunden Training war der Fehler behoben.

Ein Fall blieb trotzdem falsch: K10, eine Schenkung ohne Nachweis. Das Modell gab den Antrag automatisch frei, mit angezeigter Sicherheit von 100 Prozent. Und weil Laya nur „ja“ oder „nein“ sagt, sieht man der Entscheidung nicht an, worauf das Modell geachtet hat.

Stufe 2: Teilfragen statt einer Frage

Statt nur „Muss geprüft werden?“ zu fragen, stellt der Prozess dem Modell zusätzlich sechs Teilfragen, abgeleitet aus der Richtlinie:

  • Ist die Herkunft der Mittel erklärt und belegt?
  • Ist der Vermögensaufbau stimmig?
  • Passen Beschäftigung und Arbeitgeber zusammen?
  • Passt die geplante Kontonutzung zum Kontotyp?
  • Ist die Wohnadresse klärungsbedürftig?
  • Sind US-Status und Auslandswohnsitz widerspruchsfrei?

Jede Teilfrage beantwortet das Modell mit „unauffällig“, „prüfen“ oder „unklar“. Dafür braucht es kein zweites Modell: Bei Laya gehören Frage und Antwortmöglichkeiten zur Eingabe, dasselbe Modell beantwortet also beliebige Fragen. Gut kann es das allerdings erst nach einem weiteren Training. Dafür haben wir aus den vorhandenen Fällen abgeleitet, welcher Aspekt jeweils auffällig war, 920 Fälle mit zwei gleichzeitigen Auffälligkeiten ergänzt und das Modell aus Stufe 1 rund 5,7 Stunden auf dem Mac weitertrainiert.

Im BPMN-Prozess laufen die sieben Fragen parallel, jede als eigener Service-Task. Danach entscheidet ein Gateway „Befund?“: Freigegeben wird nur, wenn die Regeln grün sind und alle sieben Antworten unauffällig. Jede andere Antwort, auch ein technischer Fehler, führt zum Menschen. Und die Prüferin erfährt nicht mehr nur, dass geprüft werden soll, sondern warum. Beim Antrag von Tim zum Beispiel nennen die Teilfragen zwei Gründe: die Wohnadresse an der Reeperbahn und die Angabe „selbstständig“, obwohl Gehalt und Arbeitgeberbestätigung vorliegen.

Zwei Dinge fragen wir bewusst nicht: die Regeln, denn die entscheidet die Entscheidungstabelle eindeutig. Und Nationalität oder Abstammung, denn ein Modell, das wegen der Herkunft eines Menschen prüft, wäre ein Diskriminierungsrisiko. „Herkunft“ heißt hier nur Herkunft des Geldes.

Die Teilfragen entlarven die Abkürzung

Wo das Modell richtig entscheidet, nennt es jetzt auch den Grund. Auf den synthetischen Testdaten beantwortet es alle sieben Fragen fehlerfrei, auch alle 93 Testfälle mit zwei Auffälligkeiten. Das sagt allerdings wenig, denn die Texte stammen aus denselben Vorlagen wie die Trainingsdaten. Der eine Fehler ist derselbe wie in Stufe 1: K10 wird auch mit Teilfragen freigegeben.

Jetzt aber lässt sich herausfinden, warum. Wir haben in K10 jeweils genau einen Freitext gegen die Formulierung aus den Trainingsvorlagen ausgetauscht. Beim Text zur Mittelherkunft ändert das nichts, obwohl dort ausdrücklich steht, dass es keinen Nachweis gibt. Erst der Vermögenstext mit dem Satz „möchte ich nicht weiter erläutern“ kippt die Antworten auf „unklar“. Der Grund: In den Trainingsdaten haben alle 175 Schenkungen ohne Nachweis genau diese Formulierung.

Das Modell hat den Satz gelernt, nicht das fehlende Dokument. Ohne Teilfragen wüssten wir nur: K10 ist falsch entschieden. Mit Teilfragen sehen wir, an welcher Stelle das Modell falsch hinschaut.

Daraus folgt die nächste Datenrunde: Schenkungen ohne Nachweis mit anderen Formulierungen aufnehmen und nachtrainieren. Bis dahin gilt die vierte Kernaussage. Eine Regel „Schenkung ohne Unterlage heißt manuelle Prüfung“ ist in DMN in wenigen Minuten ergänzt.

Die BPMN-Engine: Kogito und CIB flow

Die Demo läuft auf Kogito als schlanker Microservice. Prozess und Regeln werden beim Bauen zu Java-Code, jeder Prozess bekommt automatisch eine REST-Schnittstelle, der Dienst startet in Sekunden. Das passt, wenn ein Prozess als eigener Dienst in eine Microservice-Landschaft gehört. Für die Aufgaben der Menschen bringt Kogito allerdings nur eine Schnittstelle mit; Postkorb, Prüfmaske und Dashboard der Demo haben wir selbst gebaut.

Für den Einsatz im Unternehmen mit vielen Sachbearbeitern empfehlen wir CIB flow, die Low-Code-BPM-Plattform der CIB software GmbH. Sie bringt Aufgabenliste, Formulare, Rechte und Rollen, Dokumentenansicht und Konnektoren mit, im eigenen Haus oder als SaaS. Darunter arbeitet CIB seven, ein Fork von Camunda 7. Regeln und Modell lassen sich dort genauso über einen Service-Task anbinden.

Fazit

Regeln entscheiden, was eindeutig ist. Die KI prüft, ob die Angaben zusammenpassen. Teilfragen zeigen, warum sie so entscheidet, und decken auf, wo sie Abkürzungen gelernt hat. Im Zweifel entscheidet der Mensch, und wann dieser Zweifel besteht, legt der Prozess fest, nicht das Modell.

Code, Daten und Modell der Demo stehen auf GitHub:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert