KI zur Erkennung von Betrug und Anomalien im Unternehmen

Ein Unternehmen entdeckt eine Unregelmäßigkeit in der Finanzaufstellung zwei Monate, nachdem sie aufgetreten ist. Acht Wochen lang sahen die Transaktionen in den wöchentlichen Berichten normal aus, da der Bericht Monat für Monat vergleicht und keine Verhaltensmuster in Echtzeit verfolgt. Dies ist ein Szenario, das sich in Finanzabteilungen, Einkaufsprozessen und Zahlungssystemen wiederholt: Die Anomalie existiert in den Daten, aber keine Schwellenwertregel erfasst sie.

KI zur Betrugserkennung funktioniert anders als eine Liste von Regeln. Sie lernt das Muster der Normalität und meldet Abweichungen, bevor sie einen Schwellenwert überschreitet, den ein Mensch hätte einstellen können. Im Folgenden beschreibe ich die Architektur eines solchen Systems, welche Metriken gemessen werden sollten, wo die Grenzen der Automatisierung liegen und was das Recht vorschreibt.

Ein ausgereiftes System zur Betrugserkennung arbeitet in mehreren Schichten, von denen jede eine andere Art von Abweichung erfasst.

Die regelbasierte Schicht ist nach wie vor die erste Linie. Typische Regeln: Betrag überschreitet die Autorisierungsgrenze, Transaktion aus einem Land außerhalb der Whitelist, Kontonummer von der Sperrliste. Regeln sind deterministisch, schnell und auditierbar. Problem: Angreifer, die die Regeln kennen, passen ihre Aktivitäten genau unterhalb der Schwellenwerte an.

Die statistische Schicht berechnet die Abweichung vom durchschnittlichen Transaktionswert für ein bestimmtes Konto, die Häufigkeit von Aktivitäten in einem Zeitfenster und die Abweichung von der typischen stündlichen Aktivitätsverteilung. Sie erkennt die Streuung vieler kleiner Transaktionen, die absichtlich so gestaltet sind, dass sie keine Schwellenwertregel auslösen.

Die Modellschicht ist ein Klassifikator, der auf der Historie von als legitim oder betrügerisch markierten Transaktionen trainiert wurde. Eingabe: ein Merkmalsvektor der Transaktion (Betrag, Zeit, Kategorie, Kontrahentendaten, Kontenhistorie). Ausgabe: Betrugswahrscheinlichkeit (0-1) und Risikokategorie. Gradient-Boosting-Modelle (XGBoost, LightGBM) und tabellarische neuronale Netze bieten hier das beste Verhältnis von Effektivität zu Interpretierbarkeit.

Die Schicht für sequenzielles Verhalten analysiert eine Folge von Ereignissen, nicht ein einzelnes Ereignis. Ein Nutzer, der sich innerhalb von 20 Minuten von einem neuen Gerät aus anmeldet, Kontaktdaten ändert, ein neues Konto hinzufügt und eine Überweisung initiiert, erzeugt ein Hochrisikomuster, selbst wenn jeder dieser Schritte für sich genommen unterhalb der Alarmschwelle liegt. LSTM- oder Transformer-Modelle für Ereignissequenzen sind das richtige Werkzeug.

Der Agent koordiniert die Signale aus allen Schichten, führt zusätzliche Überprüfungen durch (Abfrage des Registers, Lookup der Lieferantenhistorie) und erzeugt einen einheitlichen Alarm mit Kontext, den der Analyst auf dem Dashboard sieht.

Das zentrale Entwurfsmuster für ein Betrugserkennungssystem ist die Trennung von reversiblen und irreversiblen Aktionen.

Automatische Aktion (ohne Human-Gate): Markierung einer Transaktion im System als verdächtig, Senkung des Tageslimits, erzwungene zusätzliche Autorisierung beim nächsten Login. Reversibel innerhalb weniger Sekunden durch den Analysten oder den Nutzer selbst.

Aktion, die ein Human-Gate erfordert: Sperrung des Kontos, Ablehnung einer Überweisung, Meldung an die Aufsichtsbehörde, Weiterleitung des Falls an die Compliance-Abteilung. Irreversibel oder kostspielig rückgängig zu machen. Hier muss immer ein Mensch die Entscheidung genehmigen.

Praktische Implementierung des Human-Gate-Musters: Ein Alarm mit einem Risikowert über 0,75 gelangt in die Warteschlange des Analysten mit vollem Kontext (warum das System das Risiko so hoch bewertet hat, welche Merkmale entscheidend waren, Kontenhistorie der letzten 30 Tage, ähnliche vorherige Fälle). Der Analyst genehmigt oder lehnt im Interface ab, mit einem Pflichtkommentar zur Begründung. Dieser Kommentar wird im Audit-Log gespeichert.

Die folgende Tabelle vergleicht die Schichten und ihre Eigenschaften:

Der einzige faire Ausgangspunkt: Ein ML-Modell zur Betrugserkennung benötigt historische Daten mit Markierungen. Wenn die Organisation zuvor kein Tracking-System hatte, woher kommen dann die positiven Daten (verifizierte Betrugsfälle)?

Vier Ansätze, die wir in der Praxis anwenden:

Regeln als Label-Generator. Sie führen das alte regelbasierte System auf historischen Daten aus und behandeln dessen Ergebnisse als schwache Labels. Das Modell lernt die Muster, die die Regeln bereits erfasst haben, sowie Anomalien in der Nähe dieser Muster.

Externe Datensätze. Für den Finanzsektor gibt es gebündelte Datensätze zu Transaktionen mit markierten Betrugsfällen (z. B. IEEE-CIS Fraud Detection, PaySim). Ein guter Ausgangspunkt für das erste Modell, das später auf eigenen Daten feinabgestimmt werden muss.

Synthetische Daten. Ein Generator für synthetische Daten (CTGAN oder ein dedizierter Simulator für Geschäftsprozesse) erzeugt Beispiele für betrügerisches Verhalten basierend auf Expertenwissen über Betrugsmuster. Diesen Themenbereich beschreibt der Artikel synthetische Daten für KI detailliert.

Active Learning mit Analysten. Die ersten Wochen des Systembetriebs laufen im Shadow-Modus: Das System generiert Alarme, blockiert aber nicht. Analysten überprüfen die Alarme und labeln sie. Innerhalb von 4-6 Wochen sammeln Sie einige hundert Markierungen, die das Training des ersten echten Modells ermöglichen.

Genauigkeit (Accuracy) ist eine falsche Metrik für die Betrugserkennung. Bei 0,5 % Betrugsfällen in einem Datensatz hat ein Modell, das immer „kein Betrug“ antwortet, eine Genauigkeit von 99,5 % und ist nutzlos.

Die richtigen Metriken:

Precision (Präzision): Wie viele der vom System als Betrug markierten Transaktionen tatsächlich Betrug sind. Geringe Präzision = viele falsche Alarme = Analysten verschwenden Zeit mit der Überprüfung sauberer Transaktionen, und das System verliert an Glaubwürdigkeit.

Recall (Sensitivität): Wie viele tatsächliche Betrugsfälle das System erkennt. Geringe Sensitivität = Betrug passiert unbemerkt. Für die Betrugserkennung ist Recall in der Regel wichtiger als Precision, aber beide Metriken müssen Mindestwerte erreichen.

F1-Score und ROC-AUC als aggregierte Indikatoren. Ein ROC-AUC über 0,95 im Testdatensatz ist ein guter Ausgangspunkt für die Produktion.

Kosten des Fehlers sind die ultimative Geschäftsmetrik. Ein falsch positiver Befund (Sperrung einer legitimen Transaktion) kostet: verlorene Transaktion, Bearbeitung von Beschwerden, Schädigung der Kundenbeziehung. Ein falsch negativer Befund (nicht erkannter Betrug) kostet: finanzieller Verlust, Kosten für das Verfahren, Reputationsrisiko. Definieren Sie diese Kosten numerisch und passen Sie die Klassifikatorschwelle an, um die Gesamtkosten zu minimieren, nicht um den F1-Score zu maximieren.

Reaktionszeit auf Alarme ist eine operative Metrik: Wie viel Zeit vergeht vom Generieren des Alarms bis zur Entscheidung des Analysten. Eine Alarmwarteschlange, die langsamer wächst, als sie abgearbeitet wird, ist ein Signal für Probleme mit der Personalbesetzung oder Priorisierung.

Betrugserkennungssysteme verarbeiten Daten, die fast immer personenbezogene Daten sind: Kontonummern, Transaktionshistorie, Standort, Geräte-IDs. Jede dieser Kategorien unterliegt der DSGVO.

Wichtige praktische Anforderungen:

Rechtliche Grundlage der Verarbeitung. Für die Verarbeitung von Daten zum Zweck der Betrugserkennung ist die rechtliche Grundlage das berechtigte Interesse des Verantwortlichen (Art. 6 Abs. 1 lit. f DSGVO) oder eine gesetzliche Verpflichtung aus AML-Vorschriften (Geldwäschegesetz). Die Grundlage muss im Verzeichnis der Verarbeitungstätigkeiten dokumentiert sein.

Datenminimierung. Das Modell benötigt keinen Namen und Vornamen des Kunden, um das Risiko einer Transaktion zu bewerten. Arbeiten Sie mit pseudonymisierten internen Identifikatoren, wo immer eine vollständige Identifizierung in der jeweiligen Phase nicht erforderlich ist. Identifizierende Daten werden erst bei einem bestätigten Alarm, der eine Handlung erfordert, hinzugefügt.

Aufbewahrungsfristen. Trainingsdaten, Alarmprotokolle und Entscheidungen der Analysten haben unterschiedliche Aufbewahrungsfristen. Trainingsdaten ohne PII können lange gespeichert werden. Protokolle mit vollständigen Transaktionsdaten unterliegen einer TTL gemäß der DSGVO-Politik und sektorspezifischen Vorschriften.

DPIA. Für Systeme mit automatisierter Profilbildung von Transaktionen zum Zweck der Risikobewertung ist eine DPIA gemäß Art. 35 DSGVO erforderlich. Die DPIA muss eine Beschreibung der Risikoprofile, eine Bewertung der Auswirkungen auf die betroffenen Personen und Maßnahmen zur Risikominimierung umfassen.

Self-Hosting vs. Cloud. ML-Modelle und Trainingsdaten für die Betrugserkennung enthalten die vollständige Transaktionshistorie einer Organisation. In vielen Sektoren (Bankwesen, Versicherungen) verlangen Regulierungsbehörden, dass die Daten die kontrollierte Umgebung nicht verlassen. Self-Hosting von Modell und Infrastruktur bietet volle Kontrolle über Data Residency.

KI-Systeme zur Betrugserkennung im Finanz- und Kreditsektor sind in Anhang III des AI Act ausdrücklich als Hochrisikosysteme aufgeführt (Punkt 5b: KI-Systeme, die zur Bewertung der Kreditwürdigkeit und Bonität natürlicher Personen eingesetzt werden). Dies gilt sowohl für fertige Lösungen als auch für Systeme, die für den Eigenbedarf entwickelt werden, wenn die Organisation die Rolle des Deployers oder Providers einnimmt.

Pflichten, die sich aus der Klassifizierung als Hochrisikosystem ergeben:

Technische Dokumentation umfasst eine Beschreibung des Modells, Trainingsdaten (Quellen, Umfang, Anonymisierungsverfahren), Qualitätsmetriken auf dem Testdatensatz, Einschränkungen und bekannte Fehler. Sie muss bei jeder wesentlichen Änderung des Modells aktualisiert werden.

Transparenz der Entscheidungen. Das System muss erklären können, warum eine Transaktion als riskant eingestuft wurde. SHAP-Werte oder LIME für Gradient-Boosting-Modelle, Attention für sequenzielle Modelle. Der Analyst muss verstehen, welche Merkmale entscheidend waren. Die Erklärbarkeit behandelt der Artikel Das Problem der Blackbox.

Human-Oversight als Pflicht, nicht als Option. Für Entscheidungen mit negativen Auswirkungen auf eine natürliche Person (Kontosperrung, Transaktionsablehnung, Eskalation an Strafverfolgungsbehörden) verlangt das Recht die Möglichkeit, die Entscheidung durch einen Menschen anzufechten und überprüfen zu lassen. Das System muss dies technisch ermöglichen, nicht nur prozedural.

Überwachung nach der Implementierung. Der AI Act verlangt eine aktive Überwachung der Systemleistung in Produktionsdaten. Dies bedeutet regelmäßige Qualitätsprüfungen, Dokumentation von Leistungsabfällen und ein Verfahren zur Reaktion auf festgestellte Verschlechterungen.

Ein Betrugserkennungssystem ohne Monitoring verschlechtert sich leise. Das Verhalten von Betrügern entwickelt sich weiter: Ein Modell, das mit Daten von vor einem Jahr trainiert wurde, erkennt möglicherweise keine neuen Muster. Minimale Produktionsmetriken:

Alarmrate (Prozentsatz der Transaktionen, die einen Alarm auslösen) täglich überwacht. Ein plötzlicher Anstieg ist ein Signal für einen Angriff oder einen Systemfehler. Ein plötzlicher Rückgang deutet darauf hin, dass das Modell ein neues Muster nicht mehr erkennt.

Precision bei bestätigten Alarmen (Analysten markieren Alarme als echten Betrug oder Fehlalarm). Ein Rückgang der Präzision über zwei aufeinanderfolgende Wochen ist ein Signal für Modelldrift, der ein Retraining erfordert.

Zeit von der Transaktion zum Alarm (Latenz). Ein Anstieg der Latenz kann auf eine Überlastung der Infrastruktur oder eine erhöhte Rechenkomplexität bei einer wachsenden Anzahl von Merkmalen hindeuten.

Eskalationsrate zum Human-Gate. Wenn sie steigt, sind die Analysten überlastet oder die Schwellenwerte für automatische Aktionen sind zu konservativ. Wenn sie bei stabiler Alarmrate sinkt, könnte ein Problem mit der Kalibrierung der Schwellenwerte vorliegen.

Eine vollständige Architektur für das Monitoring von Agenten beschreibt der Artikel Monitoring der Qualität von KI-Agenten.

Die Implementierung eines Betrugserkennungssystems beginnt nicht mit dem ML-Modell. Sie beginnt mit der Inventarisierung von Daten und Prozessen.

Woche 1-2: Inventarisierung. Welche Quellsysteme enthalten Transaktionsdaten? Wie sind sie strukturiert? Gibt es historische Markierungen für Betrug (z. B. Kundenbeschwerden, Entscheidungen der Compliance-Abteilung)? Wo liegt das Human-Gate im aktuellen Prozess?

Woche 3-4: Shadow-Modus mit Regeln. Starten Sie ein vereinfachtes regelbasiertes System im Shadow-Modus (protokolliert Alarme, blockiert nicht). Sie sammeln Daten über die Verteilung der Transaktionen, kalibrieren Schwellenwerte und überprüfen, ob Alarme überhaupt die richtigen Personen erreichen.

Monat 2: Erstes statistisches Modell. Trainieren Sie es mit den gesammelten historischen Daten. Führen Sie es im Shadow-Modus neben den Regeln aus. Vergleichen Sie die Alarme der Regeln mit denen des Modells. Analysten labeln Abweichungen.

Monat 3: Start mit Human-Gate. Das Modell generiert Alarme, Regeln können automatisch blockieren, alles über einem festgelegten Risikoschwellenwert gelangt in die Warteschlange des Analysten. Sie messen die Metriken wöchentlich.

Monat 4+: Verbesserungszyklus. Retrainieren Sie das Modell mit den gesammelten Labels. Fügen Sie sequenzielle Schichten hinzu, sobald Sie ausreichend Historie gesammelt haben. Erweitern Sie die Automatisierung nur für reversible Aktionen.

Einen vollständigen Implementierungsplan beschreibt der Artikel Schritt-für-Schritt-Plan zur KI-Implementierung. Das Tool Agenten-Blueprint hilft bei der Gestaltung der Alarmflussarchitektur.

Beschreiben Sie Ihr Szenario für Betrugserkennung oder Anomalien, und das Modell zeigt Ihnen, welche Architektur Sie verwenden sollten, welche Metriken Sie überwachen müssen und was RODO und AI Act in Ihrem Fall vorschreiben (Playground: PII maskiert, keine Speicherung):

Ein regelbasiertes und statistisches System funktioniert vom ersten Tag an ohne Trainingsdaten. Ein ML-Modell benötigt eine Transaktionshistorie mit mindestens einigen hundert bestätigten Betrugsfällen oder Fehlalarmen. Wenn solche Daten nicht vorhanden sind, laufen die ersten 4-6 Wochen im Shadow-Modus: Das System protokolliert Alarme, Analysten labeln sie, und erst danach wird das Modell trainiert. Synthetische Daten können diesen Start beschleunigen, erfordern jedoch eine Validierung mit realen Daten vor der Produktionsfreigabe. Detaillierte Ansätze für Startdaten beschreibt der Artikel Wie man Unternehmensdaten für KI vorbereitet.

KI-Systeme, die zur Profilbildung oder Bewertung des finanziellen Risikos natürlicher Personen eingesetzt werden, sind in Anhang III des AI Act als Hochrisikosysteme aufgeführt. Die Konsequenz: Technische Dokumentation ist erforderlich, eine DPIA (Datenschutz-Folgenabschätzung) ist Pflicht, die Erklärbarkeit von Entscheidungen muss gewährleistet sein, und es ist eine aktive Überwachung nach der Implementierung erforderlich. Die Organisation, die ein solches System einsetzt, muss auch die Möglichkeit bieten, Entscheidungen durch einen Menschen anzufechten. Das ist keine Theorie: Die AI-Act-Compliance-Prüfungen im Finanzsektor haben in Polen 2026 begonnen. Die Pflichten aus AI Act und DSGVO für Unternehmen behandelt der Artikel AI Act und DSGVO 2026.

Ein Modell, das auf historischen Entscheidungen trainiert wird, kann diskriminierende Muster verfestigen, wenn die historischen Entscheidungen voreingenommen waren (z. B. ein höherer Anteil an Kontrollen für bestimmte demografische Gruppen). Minimale Schutzmaßnahmen: Bias-Audit am Testdatensatz (unterscheidet sich die False-Positive-Rate signifikant zwischen Gruppen), Entfernung rechtlich geschützter Attribute (Geschlecht, Alter, Nationalität) aus den Modellmerkmalen, regelmäßige Tests auf Gleichheit der Effektivität. Der AI Act verlangt für Hochrisikosysteme die Dokumentation von Bias-Minderungsmaßnahmen als Teil der technischen Dokumentation. Mehr über algorithmische Voreingenommenheit beschreibt der Artikel Algorithmische Voreingenommenheit in der Forschung.

Betrugserkennung geht davon aus, dass eine bekannte Zielklasse existiert (Betrug als Label in den Trainingsdaten) und verwendet überwachte Klassifikatoren. Anomalieerkennung benötigt keine Labels: Sie lernt die Verteilung der Normalität und signalisiert alles, was davon abweicht. In der Praxis werden beide Ansätze kombiniert. Ein überwachter Klassifikator erkennt bekannte Betrugsmuster. Unüberwachte Anomalieerkennung (Autoencoder, Isolation Forest, DBSCAN auf Embeddings) erkennt unbekannte Muster, einschließlich völlig neuer Angriffstypen. Die Koordinations-Agentenschicht kombiniert Signale aus beiden Quellen. Die Architektur mehrstufiger Agenten beschreibt der Artikel Mehrstufiger KI-Agent.

Die Kosten hängen vom Umfang ab: ob eine Integration mit bestehenden Transaktionssystemen (ERP, Zahlungsplattform) erforderlich ist, wie viele Datenquellen einbezogen werden, ob Self-Hosting aufgrund von Regularien notwendig ist und welche Latenz für Alarme erwartet wird. Ein Pilotumfang (Shadow-Modus, ein Transaktionsstrom, regelbasiert-statistisches System) hat andere Kosten als eine vollständige mehrschichtige Architektur mit sequenziellem Modell und Analysten-Dashboard. Den für Ihre Organisation sinnvollen Umfang können Sie mit dem ROI-Rechner berechnen oder über das Kontaktformular mit uns besprechen.