Steuerung eines Agenten zur Triage von AML-Transaktionsüberwachungswarnungen
13 min · Updated 2026-06-02
Answer
Sie steuern einen Agenten zur Triage von AML-Transaktionsüberwachungswarnungen, indem Sie jede folgenschwere Handlung an einem Richtlinienkontrollpunkt abfangen, bevor sie ausgeführt wird: eine Warnung automatisch schließen, sie eskalieren, einen SAR/STR-Bericht entwerfen oder eine Fallentscheidung in das führende Fallsystem schreiben. Die beiden Ergebnisse, die eine Meldepflicht verändern — automatischer Abschluss und SAR-Bericht — werden über ein Vier-Augen-Gate an einen benannten L2/L3-Prüfer geleitet. Jede Fallentscheidung wird in einer unabhängig überprüfbaren Execution Lineage versiegelt. Die verbindlichen Anforderungen folgen aus dem AML-Recht (FATF R.20, EU AMLR Art. 69/73 und den US-BSA-SAR-Regeln) sowie der Modellrisikoaufsicht (SR 11-7). Der EU AI Act ergänzt menschliche Aufsicht und Protokollierungsdisziplin, begründet für die AML-Transaktionsüberwachung jedoch keine automatische Hochrisiko-Einstufung, weil sie nicht in Anhang III aufgeführt ist.
KLA is the independent runtime governance and assurance layer forthis Process. KLA governs the agent you already built, whether it was built in-house or on a commercial agent framework: it does not build, sell, or run the agent. The customer owns the agent; KLA owns the controls, the evidence, and the audit trail.
The Process
The job & where the agent takes high-stakes action
Ein Transaktionsüberwachungssystem (TM) erzeugt Warnungen, wenn Transaktionen vom erwarteten Profil eines Kunden abweichen — die operative Umsetzung der Pflicht aus FATF-Empfehlung 10(d), Transaktionen im Rahmen einer Geschäftsbeziehung zu überprüfen. Ein L1-Analyst bearbeitet normalerweise jede Warnung: Er liest sie, erfasst den Kontext und verwirft sie gegebenenfalls. Der Alert-Triage-Agent automatisiert diese L1-Arbeit und ergreift vier Folgeaktionen: (1) eine Warnung verwerfen oder automatisch schließen, weil keine weiteren Maßnahmen erforderlich sind; (2) die Warnung zu einer L2/L3-Untersuchung eskalieren; (3) eine SAR/STR-Erzählung entwerfen oder empfehlen; und (4) die Verfügung mit ihrer Begründung in das Fallverwaltungssystem schreiben. Zwei dieser Maßnahmen verändern stillschweigend eine gesetzliche Meldepflicht: Ein automatischer Abschluss kann einen meldepflichtigen Verdacht löschen, der nach FATF R.20 und EU AMLR Art. 69(1) unverzüglich an die FIU gemeldet werden muss; die SAR-Erzählung legt die Grundlage für das Dokument, das eine Aufsichtsbehörde später Zeile für Zeile liest. Die beiden anderen Maßnahmen — Eskalation und Schreiben in das System of Record (SoR) — dokumentieren die Gründe für die Verfügung, starten die BSA-Uhr und unterliegen dem Hinweisverbot für offenzulegende Informationen.
Stakes
Why it's high-stakes
Ein falscher automatischer Abschluss ist ein falsches Negativ, das eine Transaktion vollständig aus der menschlichen Überprüfung entfernt; kein Analyst sieht sie wieder. Ein tatsächlicher Verdacht, der nach FATF R.20 und EU AMLR Art. 69(1) unverzüglich gemeldet werden muss, wird dann nie gemeldet. Nach dem US-amerikanischen BSA gelten feste Fristen: Eine Bank muss eine SAR spätestens 30 Kalendertage nach der ersten Entdeckung von Tatsachen einreichen, die eine Grundlage für die Einreichung bilden können, und keinesfalls später als nach 60 Tagen. Ein Agent, der eine Warnung automatisch schließt, kann diese Uhr unbemerkt starten und überschreiten. Eine vom Agenten entworfene SAR-Erzählung ist ein Rechtsdokument, das die Aufsichtsbehörde wörtlich liest; eine falsche Verfügung untergräbt gerade die fortlaufende Überwachung nach R.10(d), auf die das Institut geprüft wird. Da die Erkennung von Finanzkriminalität nicht in Anhang III des EU AI Act aufgeführt ist, kann sich die Institution nicht auf eine CE-gekennzeichnete und konformitätsbewertete Hochrisiko-Pipeline stützen. Die Verantwortung liegt unmittelbar bei den AML- und Modellrisikokontrollen des Betreibers.
What goes wrong
Failure modes specific to this agent
Stiller Verdacht, Auslöschung an der Grenze zum automatischen Schließen
Der Agent schließt eine wirklich positive Warnung automatisch mit der Meldung „Keine weiteren Maßnahmen“ mit einer fließenden, plausiblen Begründung („im Einklang mit dem vorherigen Lohn- und Gehaltsabrechnungsmuster“), sodass die Transaktion niemals eskaliert und keine SAR/STR eingereicht wird. Im Gegensatz zu einer verpassten Eskalation, die irgendwann in einer menschlichen Warteschlange auftauchen würde, verlässt eine automatisch geschlossene Warnung die Arbeitswarteschlange vollständig – es gibt kein ausstehendes Element, keinen veralteten Fall und nichts, was ein Vorgesetzter bemerken könnte. Die Meldepflicht gemäß FATF R.20 / AMLR Art. 69(1) wird gelöscht, ohne dass jemals ein Mensch darüber entschieden hat.
Why it's hard to catch: Gewöhnliche Tests messen die Übereinstimmung mit historischen Analystenlabels, aber historische Labels werden selbst von Abschlüssen dominiert (die Falsch-Positiv-Raten der Branche sind extrem hoch), so dass ein Agent, der aggressiv abschließt, bei der Genauigkeit gut abschneidet und gleichzeitig die seltenen echten Positiven systematisch unterdrückt. Der Fehler ist in den Gesamtmetriken unsichtbar, erzeugt keine Ausnahme oder Warnung und taucht erst Jahre später im Rückblick der Aufsichtsbehörden auf – zu diesem Zeitpunkt sind die SAR-Fristen längst überschritten. Der Schaden ist ein Nicht-Ereignis (ein Bericht, der nie stattgefunden hat), über den kein Protokoll der ergriffenen Maßnahmen Aufschluss geben kann.
Disposition-Rationale-Entkopplung (Erzählung, die nicht zum Aufruf passt)
Der Agent schreibt eine Anordnung (z. B. Eskalation), generiert aber eine Begründung, die das Gegenteil beweist, oder fügt eine Musterbegründung bei, die sich nicht tatsächlich auf das Alarmierungsverhalten bezieht. Da es sich bei beiden Feldern um Freitext handelt, der von demselben Modell in einem Durchgang geschrieben wurde, können die Disposition und ihre Begründung auseinanderdriften, während beide Felder als kompetente Prosa gelesen werden. Nachfolgende Ermittler und spätere Prüfer verlassen sich auf die Begründung, um zu verstehen, warum der Anruf getätigt wurde. Eine entkoppelte Begründung verfälscht den Prüfpfad und den Ausgangspunkt des L2-Ermittlers.
Why it's hard to catch: Jedes Feld besteht seinen eigenen Plausibilitätsprüfung – die Disposition ist ein gültiger Enum-Wert, die Begründung ist grammatikalisch und themenbezogen – sodass die Validierung auf Feldebene und menschliche Stichproben jedes Felds isoliert bestehen. Der Fehler liegt in der Beziehung zwischen zwei Feldern, die durch Komponententests und Label-Abgleich niemals bestätigt wird. SR 11-7 nennt dies genau das, was Modellrisiko ist: nachteilige Konsequenzen aus der Verwendung der Ausgabe eines Modells, obwohl diese falsch ist, und es warnt davor, dass solche Mängel eine objektive, informierte „effektive Herausforderung“ erfordern und nicht den eigenen Selbstbericht des Modells.
Hinweislecks durch die Schreibvorgänge und Protokolle des Agenten
Der Agent schreibt einen Dispositionsbericht, eine kundenorientierte Fallnotiz oder eine ausführliche Ablaufverfolgung, die angibt oder stark impliziert, dass eine SAR/STR eingereicht wird oder eingereicht wird oder dass eine ML/TF-Analyse im Gange ist – und dass der Text an einer Stelle landet, die ein Kunde oder ein Dritter außerhalb des Perimeters sehen kann (eine CRM-Notiz, eine Beziehungsmanager-Warteschlange, eine ausgehende Nachricht, eine zu weit gefasste Protokollsenke). EU-AMLR-Art. 73 und die US BSA (31 U.S.C. § 5318(g)(2) / 31 CFR § 1020.320(e)) machen diese rechtswidrige Offenlegung geltend, und das Verbot erstreckt sich ausdrücklich auf Agenten.
Why it's hard to catch: Die Aufgabe des Agenten besteht darin, gute Erzählungen zu verfassen. Daher ist ein ausführlicher, informativer Text das Erfolgssignal – der Misserfolg ist eine Weiterleitungs-/Vertraulichkeitseigenschaft dessen, wohin der Text geht, und keine Qualitätseigenschaft des Textes selbst, was genau das ist, was bei der Bewertung der Inhaltsqualität belohnt wird. Standardtests prüfen, ob der Agent eine nützliche Erzählung produziert hat; Es wird nicht behauptet, dass kein Feld der Vertraulichkeitsstufe 2 jemals in einen vom Kunden lesbaren Kanal gelangt. Ein einzelnes falsch gebundenes Tool oder ein zu weit gefasster Protokollexporter verwandelt eine perfekte Erzählung in einen Hinweisbruch.
Disposition im veralteten Kontext (Handeln auf der Grundlage einer Momentaufnahme, an der die Welt vorbeigegangen ist)
Der Agent selektiert eine Warnung mithilfe eines Kontext-Snapshots – Sanktions-/PEP-Status, frühere SARs für den Kunden, zugehörige offene Fälle, KYC-Aktualisierungsstatus –, der beim Abruf korrekt war, zum Zeitpunkt des Schreibens der Disposition jedoch veraltet ist, oder der eine zugehörige Warnung für denselben Kunden stillschweigend auslässt. Anschließend wird es automatisch geschlossen oder eskaliert zu niedrig, da die Aktivität in der Teilansicht mit dem Profil übereinstimmt. Die Pflicht von R.10(d) besteht darin, die Übereinstimmung mit den Kenntnissen des Instituts über den Kunden zu beurteilen; Wenn man auf einen Teilschnappschuss reagiert, wird diese Pflicht stillschweigend zunichte gemacht.
Why it's hard to catch: Jede einzelne Verfügung ist intern kohärent und auf der Grundlage der vom Agenten eingesehenen Daten vertretbar, sodass bei einer Einzelfallprüfung nichts Falsches festgestellt wird. Der Fehler tritt nur dann auf, wenn Sie den gesamten Alarmverlauf des Kunden korrelieren und feststellen, dass die verknüpfte Aktivität isoliert beurteilt wurde. Testvorrichtungen präsentieren in der Regel eine Warnung mit vollständigem, eingefrorenem Kontext – der Produktionsfehlermodus ist gleichzeitiger, fragmentierter, zeitverzerrter Kontext, den Vorrichtungen selten reproduzieren.
How KLA governs it
Runtime controls, mapped to each decision point
KLA evaluates each consequential action with a policy gate that runs before the action executes: a Decision Request to POST /v1/decisions.evaluate: resolving to one of four outcomes in precedence order: allow → warn → require_approval → block (fail-closed by default). Every non-allow outcome carries reason codes and remediation.
| Decision point | Intercept (before action) | Policy checks → reason codes | Human routing (maker-checker) | Evidence captured |
|---|---|---|---|---|
| Automatisches Schließen/Ablehnen einer Warnung als „keine weiteren Maßnahmen erforderlich“. | Ein KLA SDK-Prüfpunkt umschließt den close_alert-Toolaufruf des Agenten (Govern in Place); Der Prüfpunkt sendet einen Decision Request über POST /v1/decisions.evaluate mit den Attributen der Warnung, bevor der Abschluss geschrieben wird. Bereitsteller, die das verwaltete Proxy-Gate durchlaufen, führen denselben Schritt über Executions API aus. |
| Ein require_approval-Ergebnis löst eine Decision Desk-Eskalation aus, die von der Richtlinie an einen benannten L2-Ermittler für Finanzkriminalität weitergeleitet wird (Vier-Augen-Prüfung: Der Agent ist der Ersteller, der L2-Prüfer ist der Prüfer). Der Prüfer sieht die Warnung, den vom Agenten vorgeschlagenen Abschluss und die Begründung, die auslösenden Ursachencodes und einen Link zum Lineage Record und genehmigt dann die Genehmigung, lehnt sie ab oder leitet sie an L3 weiter. |
|
| Entwurf/Empfehlung einer SAR/STR-Erzählung | Ein KLA SDK-Prüfpunkt umschließt den draft_sar_narrative-Toolaufruf; Das an POST /v1/decisions.evaluate übermittelte Decision Request enthält die Entwurfserzählung und den Fallkontext, bevor der Entwurf beibehalten oder zur Einreichung weitergeleitet wird. |
| require_approval eröffnet eine Decision Desk-Eskalation, die an einen benannten SAR-Einreichungsbeamten/MLRO-Delegierten weitergeleitet wird. Die Rolle des Agenten ist auf Entwurf/Empfehlung festgelegt; Der menschliche Prüfer ist die einzige Partei, die die Anmeldeentscheidung genehmigen und die formelle Uhr starten kann. Decision Desk zeichnet auf, wer wann genehmigt hat. |
|
| Eskalieren Sie zur L2/L3-Untersuchung ODER schreiben Sie die Anordnung und Begründung an das Fallaufzeichnungssystem | Ein KLA SDK-Prüfpunkt umschließt den Werkzeugaufruf write_disposition/escalate_case; Der Decision Request bis POST /v1/decisions.evaluate trägt sowohl die Dispositionsaufzählung als auch den Begründungstext als gepaarte Attribute, bevor der Schreibvorgang an den SoR übergeben wird. |
| Eine Hinweis- oder Begründungsinkongruenz-Blockierung sendet eine strukturierte Ablehnung an den Agenten zurück (kein SoR-Schreiben) und wird an das verantwortliche Team zur Bekämpfung von Finanzkriminalität weitergeleitet. Eine require_approval-Herabstufung öffnet eine Eskalation an einen benannten L2-Prüfer. Routing-Regeln werden in der Richtlinie festgelegt, sodass die Eskalation standardmäßig vor dem Team landet, das dieses Risiko trägt. |
|
| Querschnittsübergreifend: Sorgen Sie dafür, dass der geregelte Lauf wiederholbar und die Beweise unabhängig überprüfbar sind | Jeder oben genannte Prüfpunkt durchläuft dieselbe Evidence-by-Default-Pipeline: Jeder Decision Request, jede Richtlinienentscheidung, jeder Tool-Aufruf und jedes menschliche Urteil wird automatisch erfasst, sobald es geschieht (kein separater Protokollierungsschritt im Agentencode). |
| n/a – diese Kontrolle ist das Beweissubstrat, in dem die oben genannten menschlichen Urteile aufgezeichnet werden. |
|
Least-privilege execution & data boundaries
- Automatisches Schließen/Ablehnen einer Warnung als „keine weiteren Maßnahmen erforderlich“.: Das close_alert-Tool ist im unveränderlichen Release des Agenten an das Tool Catalog gebunden; Der Agent kann kein Werkzeug mit größerer Wirkung selbst gewähren. Data Boundaries Bewahren Sie Alarm- und Kundendaten in der genehmigten Region/im genehmigten System auf, sodass der Snapshot, den der Agent liest, der geregelte ist.
- Entwurf/Empfehlung einer SAR/STR-Erzählung: draft_sar_narrative ist schreibgeschützt/schreibgeschützt; Der Agent verfügt über kein verbindliches Tool, mit dem er eine Meldung an die FIU einreichen kann. Der Kontext des narrativen Entwurfs wird innerhalb der Datengrenze gehalten, sodass der Entwurf niemals ein nicht genehmigtes System durchläuft.
- Eskalieren Sie zur L2/L3-Untersuchung ODER schreiben Sie die Anordnung und Begründung an das Fallaufzeichnungssystem: write_disposition ist nur an den geregelten Case-SoR-Endpunkt gebunden; Der Agent ist nicht an kundenorientierte CRM-, Messaging- oder Relationship-Manager-Warteschlangen gebunden. Data Boundaries plus die Tool Catalog-Bindung verhindern mechanisch den Tipping-Off-Fehlermodus – der Agent kann physisch nicht auf eine vom Kunden lesbare Oberfläche schreiben.
- Querschnittsübergreifend: Sorgen Sie dafür, dass der geregelte Lauf wiederholbar und die Beweise unabhängig überprüfbar sind: Der Agent läuft unter einem einzigen unveränderlichen Release. Jede Änderung an Modell, Anweisungen, Parametern oder Toolbindungen führt zu einem neuen Hash-Release. Daher ist es eine beweisbare Frage, „was zum Zeitpunkt dieser Verfügung ausgeführt wurde“.
Mapped to regulation
Regulatory mapping
| Framework | Article / section | Obligation (plain language) | How a KLA runtime control satisfies it | Source |
|---|---|---|---|---|
| FATF-Empfehlungen | Empfehlung 20 – Meldung verdächtiger Transaktionen | Wenn eine Institution den Verdacht hat oder begründeten Verdacht hat, dass es sich bei den Geldern um Erträge aus Straftaten handelt oder mit der Terrorismusfinanzierung in Zusammenhang steht, muss sie laut Gesetz unverzüglich der FIU Bericht erstatten. Ein Alert-Triage-Agent beeinflusst diesen Auslöser jedes Mal, wenn er eine Einreichung ablehnt, eskaliert oder empfiehlt. | Der Prüfpunkt für das automatische Schließen (runtime_controls[0]) verhindert, dass der Agent einen meldepflichtigen Verdacht stillschweigend löscht: Schließungen mit erhöhtem Risiko und verknüpften Fällen werden blockiert oder an einen benannten L2-Menschen weitergeleitet, bevor die Warnung die Warteschlange verlässt, sodass die Entscheidung, nicht zu melden, immer von einer Person getroffen (oder ratifiziert) wird. | Source |
| FATF-Empfehlungen | Empfehlung 10(d) – Laufende CDD: Prüfung von Transaktionen | Institute müssen Transaktionen im Rahmen einer Geschäftsbeziehung fortlaufend prüfen, um sicherzustellen, dass sie mit den Kenntnissen des Instituts über den Kunden, das Geschäft, das Risikoprofil und die Finanzierungsquelle übereinstimmen. Die Transaktionsüberwachung operationalisiert diese Pflicht. | Der Linked-Case-Block im automatischer Abschluss-Checkpoint und der Disposition-Rationale-Konsistenzblock (runtime_controls[0], runtime_controls[2]) verhindern, dass der Agent eine Warnung auf einem teilweisen, isolierten Snapshot entsorgt – und bewahren so den Test „Übereinstimmung mit den Kenntnissen der Institution über den Kunden“ gegenüber dem veralteten Kontextfehlermodus. | Source |
| EU-AMLR – Verordnung (EU) 2024/1624 | Artikel 69 Absatz 1 – Meldung von Verdachtsmomenten | Verpflichtete müssen der FIU aus eigener Initiative unverzüglich Meldung erstatten, wenn sie wissen/vermuten/begründeten Verdacht haben, dass es sich bei den Geldern oder Aktivitäten (unabhängig von der Höhe) um Erträge aus Straftaten oder im Zusammenhang mit der Terrorismusfinanzierung handelt. Alle verdächtigen Transaktionen – auch versuchte Transaktionen und der Verdacht, dass die CDD nicht abgeschlossen werden kann – müssen gemeldet werden. | Die automatischer Abschluss-require_approval/Blockierungsregeln (runtime_controls[0]) stellen sicher, dass kein in den Geltungsbereich fallender Verdacht ohne menschliche Genehmigung geschlossen wird, und die SAR-narrative Regel für die menschliche Genehmigung (runtime_controls[1]) sorgt dafür, dass die Entscheidung, ob eine Meldung erfolgt oder nicht, menschlich erfolgt – so die Art. Nach Art. 69 Abs. 1 obliegt die Pflicht „auf eigene Initiative“ einer verantwortlichen Person, nicht dem Vertreter. | Source |
| EU-AMLR – Verordnung (EU) 2024/1624 | Artikel 73 – Offenlegungsverbot (Hinweis) | Verpflichtete und deren Mitarbeiter – ausdrücklich auch Erfüllungsgehilfen – dürfen gegenüber dem Kunden oder Dritten nicht offenlegen, dass eine Tätigkeit gemäß Art. 69, dass Informationen an die FIU übermittelt wurden/werden oder dass eine GW/TF-Analyse im Gange ist. | Der Tipping-off-Block und die Least-Privilege-Tool-Bindung (runtime_controls[2]) verhindern mechanisch, dass der Agent Inhalte der Vertraulichkeitsstufe 2 in ein vom Kunden lesbares oder außerhalb des Perimeters liegendes Ziel schreibt: Der Schreibvorgang wird blockiert, und der Agent verfügt überhaupt nicht über eine Tool Catalog-Bindung an eine kundenorientierte Oberfläche. | Source |
| US BSA / FinCEN – 31 CFR Kapitel X | 31 CFR § 1020.320(b)(3) – SAR-Einreichungsfrist | Eine Bank muss spätestens 30 Kalendertage nach der ersten Feststellung von Tatsachen, die als Grundlage für die Einreichung dienen können, eine Verdachtsmeldung einreichen; Die Frist kann zur Identifizierung eines Verdächtigen verlängert werden, jedoch in keinem Fall länger als 60 Kalendertage nach der ersten Entdeckung. | Durch die Erfassung der Entscheidung zum automatischen Schließen mit einem versiegelten Zeitstempel auf dem Lineage Record (runtime_controls[0], runtime_controls[3]) werden das „Datum der Ersterkennung“ und die Anordnung, die die Uhr gestartet/geschlossen hat, zu einem nachweisbaren, abfragbaren Datensatz – sodass die Institution nachweisen kann, dass die 30/60-Tage-Uhr eingehalten wurde und nicht stillschweigend von einem Agenten geschlossen wurde. | Source |
| US BSA / FinCEN – 31 CFR Kapitel X und 31 U.S.C. § 5318 | 31 CFR § 1020.320(e) und 31 U.S.C. § 5318(g)(2)(A)(i) – SAR-Vertraulichkeit/Benachrichtigung verboten | Keine Bank oder ihre Vertreter dürfen eine Verdachtsmeldung oder andere Informationen offenlegen, die ihre Existenz offenbaren würden, und ein Institut (einschließlich seiner Vertreter und Auftragnehmer) darf niemanden, der an einer Transaktion beteiligt ist, darüber informieren, dass es gemeldet wurde. | Derselbe Hinweisblock und die Least-Privilege-Bindung (runtime_controls[2]) erzwingen die US-Vertraulichkeitsgrenze: Der Agent – ein „Agent“ im Sinne von § 5318(g)(2) – wird daran gehindert, SAR-enthüllende Inhalte an ein nicht genehmigtes Ziel zu senden, und seine Schreibvorgänge sind durch Data Boundaries auf den geregelten Fall-SoR beschränkt. | Source |
| Fed/OCC SR 11-7 (Interinstitutionelle Modell-Risikoleitlinien) | SR 11-7 / OCC 2011-12 – Modelldefinition, Modellrisiko, „effektive Herausforderung“ | Ein Modell, das Eingaben in Schätzungen verarbeitet, führt unweigerlich zu Modellrisiken. Die leitende Kontrolle ist die „effektive Herausforderung“ – eine kritische Analyse durch objektive, informierte Parteien, die Einschränkungen erkennen und Veränderungen herbeiführen können. Ein LLM-Alert-Triage-Agent ist selbst ein Modell, das validiert, hinterfragt und überwacht werden muss. | Die Vier-Augen-Prüfung Decision Desk-Eskalation (runtime_controls[0], runtime_controls[1]) institutionalisiert die „effektive Herausforderung“ bei Dispositionen mit den höchsten Einsätzen – ein benannter, kompetenter Mensch überprüft unabhängig den Anruf des Agenten – und der Disposition-Rationale-Konsistenzblock (runtime_controls[2]) fängt die fehlerhafte, aber fließende Ausgabe des Modells ab Ein Selbstbericht würde niemals etwas verraten. | Source |
| EU AI Act – Verordnung (EU) 2024/1689 | Anhang III – Umfang der Hochrisikoklassifizierung (und die Ausnahme zur Betrugserkennung bei der Bonitätsbewertung) | Anhang III zählt acht Hochrisikogebiete auf; Der Eintrag „Finanzdienstleistungen“ umfasst die Kreditwürdigkeit/Bonitätsbewertung „mit Ausnahme von KI-Systemen, die zur Aufdeckung von Finanzbetrug eingesetzt werden“. Die Überwachung von AML-Transaktionen und die Aufdeckung von Finanzkriminalität sind in Anhang III nirgendwo aufgeführt, sodass es sich nicht automatisch um ein KI-System mit hohem Risiko handelt. | Hierbei handelt es sich um eine Scoping-Zuordnung, nicht um eine Kontrollzuordnung: Sie teilt dem Betreiber mit, dass das Hochrisiko-Konformitätsregime hier nicht die tragende Verpflichtung darstellt. Die Laufzeitkontrollen sind daher so konzipiert, dass sie zunächst die AML- und Modellrisikobestimmungen erfüllen, während sie freiwillig die menschlichen Überwachungs- und Protokollierungsdisziplinen von EU AI Act (unten) als bewährte Praxis und für den Fall übernehmen, dass ein Bereitsteller anderweitig im Geltungsbereich liegt. | Source |
| EU AI Act – Verordnung (EU) 2024/1689 | Artikel 14 Absatz 4 Buchstaben b, d und e – Menschliche Aufsicht | Aufsichtspersonen müssen sich der Automatisierungsverzerrung (übermäßiges Vertrauen in die Ausgabe des Systems) bewusst sein, in der Lage sein, zu entscheiden, die Ausgabe nicht zu verwenden, zu ignorieren, zu überschreiben oder umzukehren, und in der Lage sein, das System durch einen „Stopp“ in einen sicheren Zustand zu unterbrechen. | require_approval Pause + Decision Desk Override und Re-Route (runtime_controls[0], runtime_controls[1]) sind das direkte mechanische Analogon von Ignorieren/Override/Reverse; Block (runtime_controls[2]) ist der „Stopp in einen sicheren Zustand“ – die Aktion des Agenten wird durch eine strukturierte Ablehnung angehalten. Der Rezensent sieht in Begründungscodes genau den Zweck, Automatisierungsverzerrungen entgegenzuwirken, anstatt den Agenten abzunicken. | Source |
| EU AI Act – Verordnung (EU) 2024/1689 | Artikel 26 (2) und 26 (6) – Pflichten des Betreibers | Betreiber müssen natürliche Personen mit der erforderlichen Kompetenz, Schulung und Autorität mit der menschlichen Aufsicht betrauen und automatisch generierte Protokolle mindestens sechs Monate lang unter ihrer Kontrolle halten. | Decision Desk leitet Eskalationen an benannte, kompetente L2/L3/MLRO-delegierte Prüfer (runtime_controls[0–2]) weiter – was die Anforderungen an Kompetenz und Autorität erfüllt – und die Evidence-by-Default-Pipeline behält automatisch generierte Lineage Records weit über die Sechsmonatsuntergrenze hinaus (runtime_controls[3]). | Source |
| EU AI Act – Verordnung (EU) 2024/1689 | Artikel 12 Absatz 1 – Aufzeichnungen (automatische Protokollierung) | KI-Systeme mit hohem Risiko müssen technisch eine automatische Aufzeichnung von Ereignissen (Protokolle) über die Systemlebensdauer ermöglichen, um eine dem Verwendungszweck entsprechende Rückverfolgbarkeit zu ermöglichen. | Evidence-by-Default erfasst alle Decision Request, Richtlinienentscheidungen, Toolaufrufe und menschlichen Urteile automatisch (runtime_controls[3]) und versiegelt sie jeweils in einem nur anhängbaren, Merkle-sicheren Lineage Record – wodurch die Anforderungen an die automatische Protokollierung und Rückverfolgbarkeit als integrierte Eigenschaft und nicht als Ergänzung erfüllt werden, auch wenn Art. 12 ist nur dann strikt bindend, wenn sich das System in einem Hochrisikobereich befindet. | Source |
Prove the control held
Audit-evidence checklist
- Für jeden automatischen Abschluss: der Decision Request, das Richtlinienergebnis + reasonCodes und – bei erhöhtem Risiko – das Urteil und der Zeitstempel des genannten L2-Genehmigers, versiegelt auf dem Lineage Record (beweist, dass kein in den Geltungsbereich fallender Verdacht ohne menschliche Genehmigung geschlossen wurde; FATF R.20 / AMLR Art. 69).
- Für jede SAR/STR-Erzählung: der genaue Text des Agentenentwurfs, der require_approval-Datensatz und die Autorisierung des benannten SAR-Einreichungsbeamten – was die menschliche Urheberschaft der Einreichungsentscheidung beweist und dass der Agent nur den Entwurf verfasst hat (SR 11-7 wirksame Anfechtung; AMLR Art. 69(1) „auf eigene Initiative“).
- Für jeden Dispositionsschreibvorgang: die gepaarte Disposition + Begründung wie eingereicht, plus das Zieltool und seine Tool Catalog-Bindung, die beweisen, dass der Schreibvorgang nur den genehmigten Fall-SoR und niemals eine vom Kunden lesbare Oberfläche erreicht hat (Hinweis: AMLR Art. 73 / 31 CFR § 1020.320(e) / 31 U.S.C. § 5318(g)(2)).
- Ein versiegelter Zeitstempel der Ersterkennung auf jeder Alarmdisposition, damit die 30/60-Tage-BSA-SAR-Uhr nachweisbar und nicht rekonstruierbar ist (31 CFR § 1020.320(b)(3)).
- Der aktive Release-Hash (Modell + Anweisungen + Parameter + Toolbindungen), der auf jedem Lineage Record eingeprägt ist und antwortet: „Welche Konfiguration hat genau diese Disposition erzeugt?“.
- Unabhängige Überprüfung: Jeder Lineage Record ist über GET /v1/lineage/{id}/verify überprüfbar, indem die Merkle-Wurzel mit der veröffentlichten ImmuDB-Ledger-Wurzel neu berechnet wird – kein Vertrauen in KLA erforderlich.
- Aufbewahrung automatisch generierter Protokolle für mindestens sechs Monate (EU AI Act Art. 26(6)), exportierbar als Sealed Evidence Bundle oder als EU AI Act Annex IV Control Pack für einen Prüfer.
- Ein regelmäßiges „effektives Challenge“-Paket: eine Stichprobe automatisch geschlossener Warnungen, die von einer unabhängigen Partei erneut überprüft und deren Urteile erfasst wurden – ein Beweis dafür, dass die von SR 11-7 geforderte Modellrisikoüberwachung tatsächlich durchgeführt wurde.
A concrete intercept
Reference scenario: Ein Agent versucht, eine Warnung zu einem PEP mit einer fließenden Begründung automatisch zu schließen – und ein benannter L2-Ermittler erhält das Veto
- 1
Der Alert-Triage-Agent liest den Alarm ALRT-77214 (schnelle Überweisungen mit runden Zahlen auf und von einem Geschäftskonto) und beschließt, ihn automatisch zu schließen, da keine weiteren Maßnahmen erforderlich sind. Dabei wird die Begründung „Muster im Einklang mit früheren Lieferantenzahlungen“ generiert.
- 2
Bevor der Abschluss geschrieben wird, sendet der KLA SDK-Prüfpunkt, der close_alert umschließt, einen Decision Request an POST /v1/decisions.evaluate mit folgenden Attributen: customer_pep=true, jurisdiction_risk=high, linked_open_alerts=1.
- 3
Die Richtlinie stimmt mit zwei Regeln überein: AML_AUTOCLOSE_ELEVATED_RISK (PEP + Gerichtsbarkeit mit hohem Risiko) gibt require_approval zurück und AML_AUTOCLOSE_LINKED_CASE_OPEN (eine zugehörige offene Warnung ist vorhanden) gibt Block zurück. Durch Vorrang gewinnt der einzelne Block – der Abschluss findet nicht statt; Der Agent erhält eine strukturierte Ablehnung mit Ursachencodes und Abhilfemaßnahmen.
- 4
Da ein entsprechender Fall offen ist, leitet die Richtlinie auch eine Decision Desk-Eskalation an den benannten L2-Ermittler für Finanzkriminalität weiter, der für den Fall dieses Kunden zuständig ist. Der Prüfer sieht die Warnung, den vom Agenten vorgeschlagenen Abschluss und seine Begründung, beide Ursachencodes und einen Link zum Lineage Record.
- 5
Der Ermittler ignoriert den Abschluss des Agenten (die Außerkraftsetzung von Art. 14(4)(d)), verknüpft die beiden Warnungen und eskaliert zu L3 – der Vier-Augen-Prüfung-Kontrolle und SR 11-7 „effektive Herausforderung“ in Aktion.
- 6
Jeder Schritt – der Decision Request, die Block- + require_approval-Ergebnisse, die Ursachencodes, die Identität und das Urteil des Prüfers sowie der aktive Release-Hash – wird in einem Nur-Anhänge-Lineage Record mit einem Merkle-Beweis versiegelt, der später über GET /v1/lineage/{id}/verify überprüft und in einen EU AI Act Annex IV Control Pack ohne Vertrauen exportiert werden kann KLA erforderlich.
What most teams get wrong
The non-obvious insight
Ein AML-Transaktionsüberwachungsagent ist mit ziemlicher Sicherheit KEIN „Hochrisiko-KI-System“ im Sinne von EU AI Act Anhang III – und genau deshalb bedarf es einer bewussteren Steuerung, nicht weniger. Der Eintrag „Finanzdienstleistungen“ in Anhang III deckt die Bonitätsbewertung ab, streicht jedoch „KI-Systeme zur Aufdeckung von Finanzbetrug“ heraus, und die Aufdeckung von Finanzkriminalität erscheint an keiner anderen Stelle in der Liste. Der Betreiber erhält also keine CE-Kennzeichnung, keine Konformitätsbewertung des Anbieters, ihm werden keine technischen Unterlagen nach Anhang IV ausgehändigt – nichts von den hochriskanten Gerüsten, die diese Entscheidungen abstützen. Die verbindliche Kraft ergibt sich stattdessen aus dem AML-Gesetz (FATF R.20, AMLR Art. 69/73, die BSA SAR-Regeln) und aus SR 11-7 Modellrisikoaufsicht, wo der Agent eindeutig ein „Modell“ ist, das einer Validierung und einer „wirksamen Anfechtung“ unterliegt.
Why it matters: Teams argumentieren routinemäßig rückwärts: „Der EU AI Act ist das strenge Regime. Wenn unser Agent also kein hohes Risiko darstellt, können wir ihn leichtfertig regeln.“ Für die AML-Triage ist diese Schlussfolgerung genau umgekehrt. Das Fehlen einer Anhang-III-Konformitätshülle bedeutet, dass die eigenen Laufzeitkontrollen des Betreibers – menschliche Freigabe der Melde-/Nichtmelde-Entscheidung, Eindämmung des Hinweisgebers, versiegelter Nachweis der Uhr – das Einzige sind, was zwischen einer automatisch geschlossenen Warnung und einem Jahre später behördlichen Rückblick steht. Der EU AI Act wird hier am besten freiwillig als menschliche Aufsichts- und Protokollierungsdisziplin genutzt (Art. 12/14/26), während die tragenden Verpflichtungen AML- und Modellrisiko sind. Eine Fehleinstufung des Regimes führt direkt dazu, dass die einzige Entscheidung – die stille automatische Schließung – nicht ausreichend kontrolliert wird, bei der kein Mensch auf dem Laufenden ist und es keine Ausnahme gibt, die sie abfangen kann.
Die US-amerikanische BSA gibt einer Bank eine feste Obergrenze von 60 Kalendertagen ab der ersten Entdeckung vor, um eine SAR einzureichen (30 Tage, verlängerbar um 30, um einen Verdächtigen zu identifizieren) – was bedeutet, dass ein Alarm-Triage-Agent, der eine wirklich positive Warnung automatisch schließt, nicht nur einen Fehler macht, sondern stillschweigend startet und dann eine gesetzliche Uhr sprengt, die niemand beobachtet, weil eine geschlossene Warnung die Arbeitswarteschlange verlässt und keine Alterungsausnahme generiert. (source)
Q&A
Frequently asked questions
Ist ein AML-Transaktionsüberwachungsagent ein Hochrisiko-KI-System gemäß EU AI Act?
Höchstwahrscheinlich nicht. EU AI Act Anhang III zählt acht Hochrisikogebiete auf; Der Eintrag zu Finanzdienstleistungen deckt Kreditwürdigkeit und Bonitätsbewertung ab, schließt jedoch ausdrücklich „KI-Systeme zur Aufdeckung von Finanzbetrug“ aus, und die Aufdeckung von Geldwäsche und Finanzkriminalität erscheint an keiner anderen Stelle in Anhang III. Daher ist ein AML-Triage-Agent im Allgemeinen nicht automatisch ein hohes Risiko. Die Governance-Verpflichtungen ergeben sich in erster Linie aus dem AML-Recht (FATF R.20, EU AMLR Art. 69/73, die US BSA SAR-Regeln) und der Modellrisikoaufsicht (SR 11-7); Der EU AI Act gilt als bewährte Praxis für menschliche Aufsicht und Aufzeichnungen (Art. 12/14/26) und wenn der Betreiber anderweitig in den Geltungsbereich fällt. Bestätigen Sie die Einstufung anhand Ihres eigenen Einsatzes und suchen Sie Rat – gehen Sie nicht davon aus, dass „kein hohes Risiko“ gleichbedeutend ist mit „geringer Governance“.
Welche Agentenentscheidungen müssen von einem Menschen genehmigt werden und welche können automatisch ablaufen?
Die beiden Entscheidungen, die eine gesetzliche Meldepflicht verschieben, bekommen ein menschliches Tor. Eine SAR/STR-Erzählung ist immer require_approval – der Agent entwirft, ein benannter SAR-Einreichungsbeamter genehmigt die Einreichungsentscheidung. Eine automatische Schließung wird auf require_approval beschränkt (oder blockiert), wenn die Warnung erhöhte Risikoattribute aufweist (PEP, Gerichtsbarkeit mit hohem Risiko, frühere SAR) oder ein verwandter Fall offen ist und an einen benannten L2-Ermittler weitergeleitet wird. Routinemäßige Schließungen mit geringem Risiko und normale Dispositionsschreibvorgänge können als „Zulassen“ oder „Warnen“ ausgeführt werden, aber jeder zeichnet immer noch einen Ursachencode auf seinem Lineage Record auf, sodass die Entscheidung rekonstruierbar ist.
Wie verhindert die Führung des Agenten einen Hinweisverstoß?
Zwei Schichten. Erstens blockiert eine Inhaltsprüfung alle Dispositionsberichte oder Fallnotizen, die besagen oder andeuten, dass eine SAR eingereicht wird (oder dass eine ML/TF-Analyse im Gange ist), wenn ihr Ziel ein vom Kunden lesbares oder außerhalb des Umfangs liegendes Feld ist (Ursachencode AML_TIPPING_OFF_RISK). Zweitens – und noch grundlegender – bedeutet die Bindung mit den geringsten Rechten Tool Catalog plus Data Boundaries, dass der Agent über kein Tool verfügt, das überhaupt in eine kundenorientierte CRM-, Nachrichten- oder Relationship-Manager-Warteschlange schreiben kann. EU-AMLR-Art. 73 und die US BSA (31 U.S.C. § 5318(g)(2), 31 CFR § 1020.320(e)) dehnen die Tipping-off-Bar ausdrücklich auf Agenten aus, sodass die Beschränkung der Schreibvorgänge des Agenten auf den geregelten Fall SoR der Kontrollmechanismus ist.
Wie beweisen Sie einem Prüfer, dass der Bevollmächtigte eine Einreichung nicht stillschweigend übersehen hat?
Jede Disposition – einschließlich jeder automatischen Schließung – wird automatisch als nur anhängendes Lineage Record erfasst, das das Decision Request, das Richtlinienergebnis und die Ursachencodes, jedes menschliche Urteil, den aktiven Release-Hash und einen versiegelten Zeitstempel für die Ersterkennung enthält. Da die Datensätze in einem Merkle-sicheren ImmuDB-Ledger verankert sind, kann ein Prüfer sie über GET /v1/lineage/{id}/verify überprüfen, ohne KLA zu vertrauen, und Sie können den relevanten Abschnitt als Sealed Evidence Bundle oder EU AI Act Annex IV Control Pack exportieren. Auch die geschlossenen Warnungen sind Beweise und kein blinder Fleck: Sie können nachweisen, welche durch die zulässige Richtlinie geschlossen und welche von einer namentlich genannten Person ratifiziert wurden.
Die Genauigkeit des Agenten im Vergleich zu historischen Analystenbewertungen ist hoch – reicht das nicht als Bestätigung aus?
Nein, und sich darauf zu verlassen ist die klassische Falle. Historische Etiketten werden von Abschlüssen dominiert, da die Falsch-Positiv-Raten bei Warnmeldungen sehr hoch sind. Daher punktet ein Agent, der aggressiv abschließt, bei der Etikettenübereinstimmung gut und unterdrückt gleichzeitig systematisch das seltene echte Positive – den genauen Fall, der gemeldet werden muss. SR 11-7 weist darauf hin: Das Modellrisiko besteht in nachteiligen Folgen falscher, aber verwendeter Ausgabe, und die vorgeschriebene Kontrolle ist eine „wirksame Anfechtung“ durch objektive, informierte Parteien, nicht die selbstberichtete Genauigkeit des Modells. Governance fügt diese Herausforderung strukturell hinzu: Vier-Augen-Prüfung Überprüfung hochriskanter Abschlüsse und eine regelmäßige unabhängige erneute Überprüfung automatisch geschlossener Warnungen, die beide als Beweis dafür erfasst werden, dass die Überwachung tatsächlich durchgeführt wurde.
Erstellt oder führt KLA den AML-Agenten aus?
Nein. Der Kunde erstellt und besitzt den AML-Triage-Agenten (LangGraph, CrewAI, Agentforce, Microsoft Copilot oder intern). KLA ist die unabhängige Laufzeit-Governance- und Sicherungsschicht, die den Agenten vor Ort steuert: Sie fängt jede Folgeaktion ab, bevor sie ausgeführt wird, erzwingt Richtlinien als Code mit den vier Ergebnissen (Zulassen/Warnen/require_approval/Blockieren), leitet Entscheidungen mit hohem Risiko an benannte menschliche Genehmiger in Decision Desk weiter und versiegelt die signierte Execution Lineage, die der Regulierung zugeordnet ist. KLA reicht niemals eine SAR ein, schließt niemals eine Warnung und tätigt niemals den Anruf – Menschen haben das Veto gegen require_approval und die Richtlinie hat die Autorität darüber, ob eine Aktion ausgeführt wird.
Related blueprints & guides
- Steuerung eines Agenten zur Beurteilung von Sanktions-Screening-Treffern
- Steuerung eines FNOL-/Schadensaufnahme-Triage-Agenten (NAIC AI Bulletin + EU AI Act)
- Steuerung eines Pharmakovigilanz-Agenten für die Aufnahme unerwünschter Ereignisse und die Fallbearbeitung
- Solution: Financial services & financial crime
- Blaupausen für geregelte Arbeitsabläufe bei Finanzkriminalität (Hub)
- Leitung eines Agenten zur Überprüfung von Treffern und Urteilen gegen Geldwäsche-Sanktionen
- Richtliniengesteuerte Ausführung (Kernkonzept)
- Menschliches Genehmigungsgate hinzufügen (Vier-Augen-Prüfung)
- Decision Desk (Eskalationen und Weiterleitung an Genehmiger)
- Evidence Room (Sealed Evidence Bundle / Control Pack)
Primary sources
- FATF Recommendations — Recommendation 20: Reporting of suspicious transactions: FATF (via ICNL library mirror of the FATF Recommendations)
- Regulation (EU) 2024/1624 (AMLR) — Article 69: Reporting of suspicions: EUR-Lex (Official Journal text, via amlr.eu consolidated reproduction)
- Regulation (EU) 2024/1624 (AMLR) — Article 73: Prohibition of disclosure (tipping-off): EUR-Lex (Official Journal text, via amlr.eu consolidated reproduction)
- 31 CFR § 1020.320(b)(3) — Reports by banks of suspicious transactions: SAR filing deadline: US e-CFR / Treasury–FinCEN (via Cornell Legal Information Institute)
- 31 U.S.C. § 5318(g)(2)(A) — Notification prohibited (statutory tipping-off bar): US House Office of the Law Revision Counsel (US Code, via govinfo.gov)
- SR 11-7 / OCC 2011-12 — Supervisory Guidance on Model Risk Management (definition of model, model risk, effective challenge): Board of Governors of the Federal Reserve & OCC (interagency guidance, reissued by FDIC as FIL-22-2017)
- Regulation (EU) 2024/1689 (EU AI Act) — Article 14: Human oversight: artificialintelligenceact.eu (mirror of Regulation (EU) 2024/1689)
- Regulation (EU) 2024/1689 (EU AI Act) — Article 26: Obligations of deployers of high-risk AI systems: artificialintelligenceact.eu (mirror of Regulation (EU) 2024/1689)
- Regulation (EU) 2024/1689 (EU AI Act) — Article 12: Record-keeping (automatic logging): artificialintelligenceact.eu (mirror of Regulation (EU) 2024/1689)
- Regulation (EU) 2024/1689 (EU AI Act) — Annex III: High-risk AI systems enumeration (and credit-scoring fraud-detection exception): artificialintelligenceact.eu (mirror of Regulation (EU) 2024/1689)
- KLA Control Plane Docs — Policy-Gated Execution: KLA Digital
- KLA Control Plane Docs — Decision Desk: KLA Digital
- KLA Control Plane Docs — Evidence-by-Default: KLA Digital
- KLA Control Plane Docs — Evidence Room (Sealed Evidence Bundle / Control Pack): KLA Digital
- KLA Control Plane Docs — Agents & Registry (Releases, Tool Catalog, least-privilege): KLA Digital
- KLA Control Plane Docs — Add a Human Approval Gate (SDK checkpoint / maker-checker): KLA Digital
- KLA Control Plane Docs — Govern an Agent End-to-End: KLA Digital
- KLA Control Plane Docs — API Reference (decisions.evaluate, lineage verify): KLA Digital
Govern this Process without re-platforming the agent
KLA wraps the agent you already run, gates each high-stakes action, routes the hard calls to a named human, and seals independently verifiable evidence mapped to regulation.