Leitstück 09 · Audit · FinCrime-Architektur 2026

Die Agentic Audit Pipeline

Agenten können Fälle vorbereiten — aber nur in einer Pipeline aus Retrieval-Quality-Gates, adversarialer Prüfung, Review Queue und menschlicher Verantwortung wird aus Maschinenarbeit belastbare Evidenz statt überzeugender Erfindung.

Ein KI-Agent, der eine Fallzusammenfassung schreibt, ist eine verführerische Sache: Er liest hundert Dokumente, verknüpft Transaktionen, formuliert eine plausible Geschichte — in Sekunden, was einen Analysten Stunden kostet. Genau hier liegt die Gefahr. Generative Modelle sind darauf trainiert, überzeugend zu klingen, nicht belegt zu sein. Eine flüssige, kohärente Fallzusammenfassung kann vollständig erfunden sein und trotzdem jeden ersten Leseeindruck bestehen. In der Geldwäschebekämpfung ist das kein Stilproblem — es ist die Differenz zwischen einer haltbaren Verdachtsmeldung und einer, die vor Gericht zerfällt.

Die Antwort ist nicht, auf Agenten zu verzichten, sondern sie in eine Pipeline einzuhängen, die ihre Ausgaben nicht glaubt, sondern prüft. Ein hypothetisches FinRegAgents v2.4 macht das Muster greifbar: zwischen dem Agenten und der menschlichen Freigabe liegen Quality-Gates für das Retrieval, ein adversarialer Gegen-Durchlauf, eine Review Queue und am Ende ein Mensch, der verantwortet. Jede dieser Stufen existiert aus einem Grund: weil die Stufe davor lügen kann.

Warum die flüssige Zusammenfassung das Problem ist

Die klassische Schwäche von KI im FinCrime-Kontext ist nicht, dass sie zu wenig sagt, sondern dass sie zu überzeugend sagt, bevor genug bewiesen ist. Ein Sprachmodell füllt Lücken mit Plausiblem; es nennt eine Quelle, die es nicht gelesen hat; es leitet eine Schlussfolgerung ab, die sich gut anfügt, aber durch nichts gedeckt ist. Bei einem Marketingtext fällt das nicht weiter ins Gewicht. Bei einem Dokument, das einen Menschen einer Straftat verdächtigt, ist es eine Katastrophe — und eine, die durch ihre eigene Überzeugungskraft schwer zu entdecken ist.

Der gefährlichste Output eines Agenten ist nicht der offensichtlich falsche, sondern der flüssig formulierte, der eine Lücke mit Plausiblem füllt und dabei aussieht wie ein Beleg.

Die Pipeline begegnet dem mit einer einfachen Haltung: Kein Output des Agenten ist Evidenz, bis er eine Kette von Prüfungen passiert hat. Was den Agenten verlässt, ist ein Vorschlag — eine Hypothese mit angehängten Belegen, die anschließend gegen ihre eigenen Belege getestet wird.

Stufe 1 — Retrieval-Quality-Gates

Die meisten Fehler agentischer Fallarbeit entstehen nicht beim Formulieren, sondern beim Beschaffen. Holt der Agent die falschen, veralteten oder irrelevanten Dokumente, ist alles Folgende vergiftet — „garbage in, confident garbage out“. Das erste Gate prüft deshalb nicht die Antwort, sondern das Retrieval: Stammen die herangezogenen Belege aus zugelassenen Quellen? Sind sie aktuell genug? Decken sie die Behauptung überhaupt ab, oder ist die Ähnlichkeit nur oberflächlich? Belegt jede Aussage im Entwurf mindestens ein abgerufenes Dokument, oder hängt sie in der Luft?

Erst wenn das Retrieval diese Gates besteht, darf der Agent überhaupt eine Hypothese formulieren. Eine Behauptung ohne deckenden Beleg wird nicht „mit niedriger Confidence“ weitergereicht, sondern verworfen — sie ist im Sinne von Leitstück 02 ein Claim ohne Provenienz und damit gar kein Claim.

Stufe 2 — Der adversariale Durchlauf

Ein einzelner Agent, der seine eigene Arbeit prüft, ist ein schlechter Prüfer — er teilt seine blinden Flecken. Deshalb tritt ein zweiter, gegnerisch instruierter Durchlauf an: Seine Aufgabe ist nicht, die Hypothese zu bestätigen, sondern sie zu zerlegen. Er sucht die schwächste Kante (Leitstück 06), die nicht gedeckte Aussage, die alternative Erklärung, die entlastende Lesart. Findet er einen Riss, geht der Fall zurück oder mit ausgewiesener Schwäche weiter. Dieser Pass ist die maschinelle Form des Vier-Augen-Prinzips — und er ist billig genug, um auf jeden Fall angewendet zu werden, nicht nur auf die auffälligen.

Stufe 3 — Die Review Queue: menschliche Zeit dorthin, wo sie zählt

Selbst eine gut geprüfte Pipeline produziert mehr Vorschläge, als Menschen sorgfältig prüfen können. Die Review Queue ist deshalb kein simpler Eingangskorb, sondern eine Priorisierung: Sie sortiert nach Unsicherheit und Tragweite, nicht nach Eingangszeit. Ein Grenzfall mit knapper adversarialer Entscheidung und hohem Schaden gehört nach oben; ein klarer, mehrfach gedeckter Fall mit geringer Tragweite kann mit leichterem Blick durch. So fließt die knappste Ressource — menschliche Aufmerksamkeit — dorthin, wo sie den größten Unterschied macht.

Wichtig ist, was die Queue dem Menschen vorlegt: nicht die glatte Zusammenfassung, sondern den Vorschlag mit seinen Rissen. Der Analyst sieht, welche Aussage der adversariale Pass angezweifelt hat, welche Kante die schwächste ist, welcher Beleg fehlt. Die Pipeline verkauft ihm keine fertige Wahrheit, sondern legt ihm eine begründete Hypothese samt ihrer Schwachstellen auf den Tisch.

Stufe 4 — Der Mensch verantwortet

Am Ende steht die Invariante, die dieses Dossier von Anfang an trägt (Leitstück 02): Die abschließende Entscheidung hat ein Gesicht. Der Agent bereitet vor, prüft, schlägt vor — aber die meldepflichtige Verdachtsentscheidung im Sinne des § 43 GwG trifft ein Mensch, mit Namen, Begründung und Zeitpunkt. Nicht, weil der Mensch unfehlbar wäre, sondern weil Verantwortung zurechenbar sein muss. Eine Pipeline, die diesen letzten Schritt automatisiert, hat keine schnellere Compliance gebaut, sondern eine ohne Verantwortlichen.

Python · Die Pipeline als Kette von Gates mit Ledger-Spurfrom dataclasses import dataclass, field
from datetime import datetime, timezone

class GateError(Exception): ...

@dataclass
class Proposal:
    summary: str
    claims: list            # jede Aussage mit Beleg (vgl. Leitstück 02)
    weakest_link: str | None = None
    confidence: float = 0.0

class AuditPipeline:
    def __init__(self, ledger): self._ledger = ledger

    def run(self, p: Proposal):
        self._gate_retrieval(p)        # Stufe 1
        self._adversarial(p)            # Stufe 2
        self._enqueue_for_review(p)     # Stufe 3 — kein Auto-Approve
        return p                        # Stufe 4: Mensch entscheidet separat

    def _gate_retrieval(self, p):
        for c in p.claims:
            if not c.get("provenance"):           # keine Aussage ohne Beleg
                self._log("RetrievalGateFailed", claim=c["statement"])
                raise GateError("Aussage ohne deckenden Beleg")
        self._log("RetrievalGatePassed", n=len(p.claims))

    def _adversarial(self, p):
        weak = challenge(p)             # zweiter, gegnerischer Durchlauf
        p.weakest_link = weak
        self._log("AdversarialPass", weakest_link=weak)

    def _enqueue_for_review(self, p):
        priority = (1.0 - p.confidence)        # unsicher + schwer = oben
        self._log("Enqueued", priority=round(priority, 2))

    def _log(self, name, **d):
        self._ledger.append({"stage": name, "at": datetime.now(timezone.utc), **d})

Man beachte, was die run-Methode nicht tut: Sie gibt nichts frei. Sie endet bei der Einreihung in die Review Queue; die Freigabe ist ein separater, menschlicher Akt. Und jede Stufe schreibt ihren Ausgang ins Event Ledger aus Leitstück 03 — bestanden wie durchgefallen. So entsteht nicht nur ein geprüfter Fall, sondern eine prüfbare Prüfung: Die Aufsicht kann nachvollziehen, wie sorgfältig die Maschine gearbeitet hat, bevor ein Mensch sie übernahm.

Was die Pipeline für die Aufsicht leistet

Die AMLA fragt nach Wirksamkeit und Erklärbarkeit (Leitstück 02). Eine agentische Fallarbeit ohne Pipeline kann beides nicht liefern: Sie produziert plausible Texte ohne nachvollziehbare Herkunft. Die Audit Pipeline dreht das um. Jeder Befund trägt seine Belege (Quality-Gate), seine Gegenprobe (adversarialer Pass), seine Priorisierung (Queue) und seine menschliche Freigabe — alles im Ledger. Die Frage „Wie sind Sie zu diesem Verdacht gekommen, und wie haben Sie geprüft, dass die KI sich nicht geirrt hat?“ hat damit eine Antwort, die nicht aus Vertrauen, sondern aus Spur besteht.

Ein durchgespielter Fall

Ein Agent bearbeitet einen Structuring-Verdacht und legt einen sauber formulierten Entwurf vor: sechs verbundene Einzahlungen, eine gemeinsame Gegenstelle, eine plausible Geschichte. Das Retrieval-Gate prüft die angehängten Belege — und stolpert: Eine der sechs „Einzahlungen“ ist im Entwurf behauptet, aber durch kein abgerufenes Dokument gedeckt; das Modell hatte die Lücke mit einer plausiblen Zahl gefüllt. Das Gate verwirft den Entwurf und schickt ihn zurück. Der Agent zieht die ungedeckte Aussage zurück und legt erneut vor, diesmal mit fünf belegten Transaktionen.

Jetzt greift der adversariale Pass. Er akzeptiert die fünf Belege, findet aber die schwächste Kante: Die Verbindung zur Gegenstelle stammt aus einer KI-Inferenz über Namensähnlichkeit (Leitstück 06), nicht aus einem bestätigten Register. Er markiert sie als weakest_link. Der Fall landet damit nicht als „klarer Treffer“ in der Queue, sondern als Grenzfall mit hoher Tragweite — und wird nach oben priorisiert. Die Analystin sieht beim Öffnen nicht die glatte Geschichte, sondern genau diese Schwachstelle markiert.

Sie prüft die Gegenstelle manuell, bestätigt sie über eine zweite Quelle und gibt frei — mit Namen, Begründung und dem Vermerk, dass die ursprünglich schwächste Kante nun gestützt ist. Was in das EvidencePackage (Leitstück 02) eingeht, ist nicht der erste, halb erfundene Entwurf, sondern ein geprüfter Befund mit dokumentierter Prüfgeschichte. Hätte die Pipeline gefehlt, wäre die erfundene sechste Transaktion in eine Verdachtsmeldung gewandert — und genau daran wäre sie später zerbrochen.

Kernsätze

Die Pipeline macht agentische Fallarbeit prüfbar — über alle Domänen hinweg. Eine davon ist besonders unbarmherzig, weil sie tief in Beteiligungsketten und Graphen führt: die Ermittlung der wirtschaftlich Berechtigten. Wie aus Ownership-Strukturen eine Graph-Traversierung mit Zustandsmaschine wird, schließt das Dossier ab — Leitstück 10: Komplexe Ownership-Strukturen und die UBO-Verifikationslücke.

Markiert: Agentic AI · RegTech Architecture · AML Observability · KI in Compliance · Audit · Architektur