Ohne dieses Fundament scheitert jedes KI-Projekt in der Compliance 

14/09/2026

Sie führen ein neues KI-Modell für die Alert-Bearbeitung ein. Die ersten Wochen laufen gut, die Zahlen sehen vielversprechend aus. Drei Monate später fällt jemandem auf, dass das Modell nicht auf Basis des dokumentierten Prozesses arbeitet, sondern systematisch Abkürzungen und Inkonsistenzen übernommen hat, die sich in den gelebten Prozess über Jahre eingeschlichen haben.  

Solche Fehler bleiben oft lange unbemerkt, weil ein Modell kein Gespür für Lücken hat. Bekommt ein erfahrener Analyst einen unvollständigen Datensatz vorgelegt, merkt er es hoffentlich und fragt nach. Ein KI-Modell, das mit demselben unvollständigen Datensatz arbeitet, merkt es nicht, trifft aber trotzdem eine Entscheidung, und zwar schnell und äußerst selbstbewusst. 

Woran liegt das? Selten am Modell selbst, sondern meistens daran, dass vor dem Start niemand genau genug hingeschaut hat: Läuft der Prozess wirklich so, wie alle glauben? Sind die Daten, mit denen das Modell arbeitet, verlässlich? Und schaut überhaupt jemand hin, wenn später etwas aus dem Ruder läuft? Diese drei Fragen zu Prozessen, Daten und Governance werden vor dem Start eines KI-Projekts oft zu schnell abgehakt oder sogar ganz ausgelassen. 

Prozesse: Der Unterschied zwischen dem, was dokumentiert ist, und dem, was passiert 

Viele Institute haben für die Bearbeitung von Alerts einen dokumentierten Prozess. Und dann gibt es den erfahrenen Mitarbeiter, der das seit Jahren anders macht – schneller, pragmatischer, mit Kniffen, die nirgends stehen. Beide Prozesse existieren parallel: der geschriebene und der gelebte. 

Wird jetzt ein KI-System auf Basis historischer Daten trainiert, lernt es den gelebten Prozess – also das, was tatsächlich passiert ist, nicht das, was in der Doku steht. Auf den ersten Blick ist das gut: Das System spiegelt die Realität. Auf den zweiten Blick weniger, denn es übernimmt auch die Abkürzungen, die Inkonsistenzen und die Fehler, die sich in diesen gelebten Prozess über Jahre eingeschlichen haben, oft ohne, dass sie jemals kontrolliert wurden. 

Als naheliegende Reaktion darauf aktualisieren viele Institute ihre Prozessdokumentation: Projekt aufsetzen, Workshops mit den Fachbereichen, am Ende ein neues Dokument. Das dauert, und bis die neue Doku fertig ist, hat sich die Realität längst wieder verändert – sei es durch neue Mitarbeiter, neue Zuständigkeiten, neue regulatorische Vorgaben oder ein neues Tool. Im AML-Kontext ist das noch kritischer als in anderen Bereichen, denn der Prüfer sieht am Ende ein Dokument, das möglicherweise nicht mehr beschreibt, was in Ihrem Haus tatsächlich passiert. 

Ein Lösungsansatz, den wir in der Praxis oft umsetzen, ist Process Mining.

Dabei wird anhand von Systemlogs rekonstruiert, wie ein Prozess wirklich läuft, statt sich blind auf die Doku zu verlassen. Für KI-Projekte im AML-Umfeld sollte das der erste Schritt sein, noch bevor über passende Modelle gesprochen wird. 

Eine Einschränkung gibt es allerdings: Process Mining funktioniert nur, wenn Prozess und Daten in Systemen laufen, die Logs erzeugen. Das ist längst nicht überall der Fall. In vielen Häusern laufen Teile der KYC- oder KYB-Prozesse noch über Excel-Listen, oder Dokumente werden ausgedruckt, unterschrieben, wieder eingescannt und in einem dritten System abgelegt. Dadurch gibt es keine durchgängigen Logs und der Prozess lebt teilweise außerhalb des Systems, nämlich in Mitarbeiterköpfen, Mails oder lokalen Dateien. 

Hier kann GenAI eine Hilfe sein, indem sie diese analogen Informationen – gescannte Dokumente, Excel-Listen mit Freitextspalten – liest und strukturiert. KI muss also nicht das Ende eines Digitalisierungsprojekts sein, sondern auch der erste Schritt, zum Beispiel im Process Mining, um Licht ins analoge Dunkle zu bringen. 

Daten: Drei Systeme, drei Wahrheiten 

Neben unsauber dokumentierten Prozessen gibt es in vielen Instituten eine weitere Baustelle: die Daten, mit denen das KI-Modell arbeiten soll. Sie müssen vollständig, konsistent und nachvollziehbar sein. Ein Beispiel aus der Praxis, das viele kennen dürften: Im Customer Onboarding einer Bank wurde vor drei Jahren eine Adresse im CRM-System erfasst. Der Kunde ist seitdem umgezogen, aber die neue Adresse wurde nur im Kontoführungssystem eingetragen. Im AML-Monitoring existiert eine dritte Version des Kundendatensatzes, weil die letzte Synchronisation acht Monate zurückliegt. 

Wenn Sie jetzt ein Modell bauen wollen, das Änderungen im Datensatz in Kombination mit Transaktionsmustern erkennen soll (typisch bei Identitätsbetrug), haben Sie ein Problem. Das Modell braucht verlässliche Nachvollziehbarkeit: Wann hat sich was geändert, und woher stammt diese Information?  

Genau dafür eignet sich Data Lineage, durch die sich für jeden Datenpunkt nachvollziehen lässt, woher er kommt, wann er zuletzt verändert wurde und durch welchen Prozess oder welches System. Ohne diese Informationen können Sie erstens kein verlässliches Modell trainieren, und zweitens gegenüber einem Prüfer nicht erklären, warum ein Modell zu einem bestimmten Zeitpunkt eine bestimmte Entscheidung getroffen hat, weil Sie im Zweifel selbst nicht wissen, welche Datenversion das Modell zu diesem Zeitpunkt gesehen hat. 

Eine funktionierende Lösung setzt zwei Dinge voraus

Das sind einmal technische Lineage-Tools, die automatisch nachverfolgen, wie Daten durch Ihre Systeme fließen und wo sie transformiert werden und organisatorische Klarheit darüber, wer für welche Daten verantwortlich ist. Bevor Sie in Tooling investieren, lohnt sich deshalb die Frage: Welche Datenpunkte sind in Ihrem Haus überhaupt so kritisch, dass Sie ihre Herkunft kennen müssen – und wer im Unternehmen weiß das eigentlich? 

Governance: Wer merkt es, wenn die KI falsch liegt? 

Wer ist bei Ihnen im Alltag eigentlich dafür verantwortlich, dass ein KI-System gut funktioniert? Wer schaut regelmäßig nach und wer wird informiert, wenn die Qualität nachlässt?  

Ein Beispiel: Die IT-Abteilung sagt, das Modell läuft technisch einwandfrei, aber Compliance bemängelt die Ergebnisse. Was passiert in einem solchen Fall in Ihrem Haus? Ein anderes Beispiel: Ein Analyst bemerkt, dass eine bestimmte Art von Alert seit Wochen deutlich häufiger auftritt als vorher. Liegt ein neues Betrugsmuster vor, oder liegt es am Modell? Oder umgekehrt: Bei Kunden aus einem bestimmten Land gibt es plötzlich auffällig wenige Treffer – handelt es sich wirklich um weniger Betrug, oder doch eher um einen Modellfehler? 

In allen diesen Fällen braucht es einen definierten Eskalationsweg: Wer hört sich diese Beobachtungen an? Wer hat die Befugnis zu sagen, das prüfen wir jetzt? Wer kann am System etwas ändern, und wer dokumentiert, dass diese Frage überhaupt gestellt und beantwortet wurde? Jemand muss die Befugnis und die Fähigkeit haben, solche Fragen zu stellen und zu beantworten – nicht nur beim Go-Live, sondern dauerhaft. 

Der Weg zum Ziel: Use Case statt Grundsatzreform 

Prozesse sauber dokumentieren, Datenbasis nachvollziehbar aufstellen, Governance klären bzw. aufbauen: Das klingt nach einem Großprojekt, das Monate, wenn nicht sogar Jahre dauern kann. So lange möchte zu Recht niemand warten, bevor er mit KI überhaupt anfängt. 

Zeitlich kommt Druck von außen hinzu: Die neue EU-Geldwäscheverordnung (AML-VO) gilt ab dem 10. Juli 2027 und verlangt nachvollziehbare Daten und belastbare Prozesse. Wer erst dann mit den Grundlagen anfängt, baut sie unter Zeitdruck, und das wird gerne teuer.  

Der praktikablere Weg: Sie müssen das Fundament nicht für das gesamte Unternehmen auf einmal schaffen. Es reicht, wenn Sie bei dem einen konkreten Anwendungsfall ansetzen, mit dem Sie starten wollen, und dafür drei Fragen sauber beantworten. 

• Welcher Teil des Prozesses ist für diesen Anwendungsfall überhaupt relevant, und läuft er wirklich so, wie Sie es sich vorstellen?  

• Von welchen fünf bis zehn Datenfeldern hängt dieser Anwendungsfall ab, und sind die für Ihre Testfälle gut genug?  

• Wer schaut sich in den ersten Wochen an, ob das, was dabei herauskommt, plausibel ist? 

Das dauert Wochen, keine Monate oder Jahre. Und Sie lernen dabei genau, wo in Ihrem Unternehmen die größten Herausforderungen liegen – wichtiges Wissen, sobald es später um Skalierung geht. 

Sichtbare Kosten sind niedriger als versteckte Kosten 

Wer immer noch zögert, weil ein sauberes Fundament für KI-Projekte aufwendig und teuer erscheint, sollte die Frage umdrehen: Was kostet es eigentlich, kein Fundament zu haben? Jedes Pilotprojekt, das nie in Produktion geht, jede Vendor-Konfiguration, deren Voreinstellungen nie hinterfragt wurden, und jede Stunde, die ein Analyst in einem System verbringt, dessen Ergebnissen er nicht traut, verursachen vermutlich schon heute immense Kosten – nicht als Posten in einem Projektbudget, aber als versteckte Kosten mit Blick auf Ineffizienz und Risiko.  

Sie möchten wissen, wie tragfähig Ihr eigenes Fundament für KI-Projekte ist? Sprechen Sie uns gerne an, per Mail oder auf LinkedIn.

Hinweis: Dieser Beitrag ersetzt keine rechtliche oder regulatorische Beratung.