Ausgefüllte FRIA als Praxisbeispiel: AML-Alert-Triage-Agent

Bindet Artikel 27 einen Betreiber von AML-Alert-Triage?¶

Beginnen Sie mit der ehrlichen Antwort auf die Frage, denn eine nachvollziehbare FRIA dokumentiert sie. Artikel 27(1) erfordert eine Bewertung der Auswirkungen auf die Grundrechte von zwei Gruppen von Implementern: öffentliche Stellen und private Unternehmen, die öffentliche Dienstleistungen erbringen, die Systeme im Anhang III mit hohem Risiko einsetzen, und jeder Implementer der Systeme im Anhang III Punkte 5(b) und 5(c): Bonität oder Bonitätsbewertung und die Preisgestaltung von Lebens- und Krankenversicherungen. Punkt 5(b) enthält auch ausdrücklich eine Ausnahme für KI, die zur Erkennung von Finanzbetrug verwendet wird.

Ein AML-Alert-Triage-Agent einer privaten Geschäftsbank passt in keine der beiden Gruppen. Die Triage von Monitoring-Alerts steht nicht auf der Liste des Anhangs III, und eine Geschäftsbank ist weder eine öffentliche Einrichtung noch nach herrschender Lesart eine private Einrichtung, die öffentliche Dienste erbringt. Die verpflichtende Frist folgt, wo sie greift, dem Anhang-III-Hochrisiko-Termin 2. Dezember 2027, festgelegt durch den Digital Omnibus zur KI (Verordnung (EU) 2026/1744, veröffentlicht im Amtsblatt am 24. Juli 2026, in Kraft seit 27. Juli 2026).

Die fiktive Bank in diesem Praxisbeispiel führt die Abschätzung dennoch durch, aus drei dokumentierten Gründen. Ihre Konzern-KI-Richtlinie wendet die Struktur des Artikels 27 Absatz 1 auf jeden Agenten-Einsatz mit hoher Auswirkung an, weil diese Struktur das vollständigste Instrument der Rechteanalyse ist, das das EU-Recht derzeit bietet. Die Bank schuldet für die Verarbeitung ohnehin eine DSFA nach Artikel 35 DSGVO, und die FRIA erweitert diese DSFA um Charta-Rechte, die eine DSFA auslässt, im Spiegel des Ergänzungsmechanismus in Artikel 27 Absatz 4. Und die Einstufung ist nicht statisch: Neue Leitlinien, eine veränderte Rolle des Agenten oder der Einsatz durch eine erfasste Konzerneinheit würden das System jeweils in den verpflichtenden Anwendungsbereich ziehen; die Bank hält das Dokument daher aktuell.

Abschnitt 1: Betreiberkontext und Zweckbestimmung (Art. 27 Abs. 1 Buchst. a)¶

Betreiber ist eine fiktive mittelgroße EU-Retail- und Geschäftsbank mit rund 1,8 Millionen Kundinnen und Kunden in drei Mitgliedstaaten. Das System ist der Alert-Triage-Agent „Triage Assist“, Version 1.4, des fiktiven Anbieters Meridian Analytics GmbH, betrieben auf der gesteuerten Agenten-Ausführungsplattform der Bank.

Die Zweckbestimmung ist eng und schriftlich fixiert: jeden Monitoring-Alert mit KYC-, Transaktionshistorie-, Screening- und Adverse-Media-Kontext anreichern; den Fall zusammenfassen; eine von drei Dispositionen vorschlagen (als unauffällig schließen, Informationen anfordern, zur Untersuchung eskalieren); und die Eskalationsbegründung für die Analystin oder den Analysten entwerfen. Der Agent arbeitet zwischen der regelbasierten Monitoring-Engine, die Alerts erzeugt, und dem Menschen, der sie entscheidet.

Die Zweckbestimmung fixiert auch, was der Agent niemals darf, und der Einsatz erzwingt diese Grenzen zur Laufzeit statt in Prosa. Der Agent hat keine Befugnis, einen Alert zu schließen, eine Verdachtsmeldung einzureichen oder zu unterdrücken oder Kundinnen und Kunden zu kontaktieren. Die Schließung eines Alerts erfordert eine Analystenentscheidung. Eskalationen und jeder kundenwirksame Schritt erfordern eine Vier-Augen-Freigabe durch eine zweite Analystin oder einen zweiten Analysten, erzwungen durch eine Laufzeit-Policy-Engine mit den vier Ergebnissen allow, warn, require_approval und block; jede Aktion wird in einen versiegelten Evidenznachweis geschrieben. Das vollständige Kontrolldesign dieses Workflows, einschließlich der Tabellen zulässiger Aktionen und Eskalationen, steht in AML-Alert-Triage-Agenten: Kontrollen und Evidenz.

Abschnitt 2: Dauer und Häufigkeit der Verwendung (Art. 27 Abs. 1 Buchst. b)¶

Die Bewertungsergebnisse enthalten die Produktionsnutzung vom 1. Oktober 2026 nach einem 12-wöchigen überwachten Pilotversuch, für eine unbegrenzte Dauer unter Berücksichtigung der Überprüfungskontinuität im letzten Abschnitt. Die Nutzung ist kontinuierlich: Der Agent verarbeitet jede Warnung bei ihrer Ankunft, etwa 4.200 Warnungen pro Woche und etwa 220.000 pro Jahr, auf den drei EU-Marktplätzen der Bank, wobei alle Verarbeitung innerhalb der EU-Datengrenze der Bank erfolgt.

Das Volumen ist eine grundrechtsrelevante Tatsache und gehört in diesen Abschnitt. Bei 220.000 Alerts im Jahr trifft eine Verzerrung, die die Eskalationsquote um einen einzigen Prozentpunkt verschiebt, Tausende von Kundinnen und Kunden; deshalb bewertet das Risikoregister in Abschnitt 4 Diskriminierungsschäden auch nach ihrer Größenordnung.

Abschnitt 3: Kategorien betroffener Personen (Art. 27 Abs. 1 Buchst. c)¶

Die primär betroffene Gruppe sind die Alert-Subjekte: Privat- und KMU-Kunden, deren Transaktionen die Monitoring-Engine auslösen. Eine zweite Gruppe bilden in Transaktionsdaten genannte Gegenparteien, darunter Personen, die keine Kundinnen oder Kunden der Bank sind.

Besondere Aufmerksamkeit gilt Kundinnen und Kunden, deren gewöhnliche Transaktionsmuster aus strukturellen Gründen von den Modellnormen abweichen: kürzlich Zugewanderte und Grenzgänger mit regelmäßigen Überweisungen an Angehörige, Geflüchtete, Personen in bargeldintensiven Berufen, Kundinnen und Kunden mit Transaktionen in einkommensschwächere Korridorländer sowie politisch exponierte Personen und ihre Familienangehörigen. Auf diesen Gruppen lastet der De-Risking-Druck der Geldwäschebekämpfung historisch am stärksten; sie sind daher die Gruppen, die ein Triage-Agent am ehesten über-eskaliert.

Zwei weitere Gruppen vervollständigen den Abschnitt. Triage-Analystinnen und -Analysten sind ebenfalls betroffene Personen: Der Agent formt ihre Arbeit und erzeugt Kennzahlen darüber, weshalb Automatisierungs-Bias, Kompetenzverlust und Arbeitsüberwachung bewertet werden. Mitinhaber gemeinsamer Konten und unterhaltsberechtigte Angehörige sind mittelbar betroffen, wenn ein Konto nach einer Eskalation eingeschränkt oder gekündigt wird.

Abschnitt 4: Das Risikoregister, Recht für Recht (Art. 27 Abs. 1 Buchst. d)¶

Abschnitt 4 trägt das Gewicht der Abschätzung. Jede Zeile benennt das betroffene Grundrecht, ein konkretes Schadensszenario, eine Einstufung von Wahrscheinlichkeit und Schwere aus einer konsistenten Matrix, die Abhilfemaßnahme und das Restrisiko nach der Maßnahme. Die Rechte werden einzeln bewertet; ein Nutzen für ein Recht gleicht einen Schaden an einem anderen niemals aus. Die Werte unten sind die Beispielbewertung der fiktiven Bank: Sie zeigen eine vertretbare Methode, und keine Aufsichtsbehörde schreibt die konkreten Werte vor.

Bewertung des Registers: Wahrscheinlichkeit × Schwere¶

Die Risikostufen stammen aus derselben Wahrscheinlichkeit-Schwere-Matrix wie in der FRIA-Vorlage, konsistent auf das gesamte Dokument angewendet. Halten Sie die Matrix und die Begründung jeder Einstufung fest; die Methode zählt für eine prüfende Stelle ebenso viel wie die Ergebnisse.

Abschnitt 5: Menschliche Aufsicht durch Laufzeitkontrollen (Art. 27 Abs. 1 Buchst. e)¶

Der Aufsichtsabschnitt benennt seine Verantwortlichen: die Leitung Financial Crime Operations, vertreten durch zwei Senior-AML-Beauftragte. Glaubwürdig wird der Abschnitt dadurch, dass jedem Aufsichtsversprechen eine Kontrolle entspricht, die im Moment der Agentenaktion ausgeführt wird.

Vier-Augen-Freigabe. Jede Eskalation, jedes Auskunftsersuchen und jeder Einschränkungsvorschlag erfordert die Freigabe einer zweiten qualifizierten Analystin oder eines zweiten qualifizierten Analysten. Die Laufzeit-Policy-Engine liefert für diese Aktionen die Entscheidung require_approval, und der Evidenznachweis hält Freigebende, Zeitstempel und Begründung fest. Eine FRIA, die die Vier-Augen-Freigabe als Abhilfemaßnahme nennt, ist mit einer einzigen Abfrage gegen diese Nachweise überprüfbar.

Eskalationsschwellen. Alerts über der Hochrisiko-Schwelle oder mit Bezug zu politisch exponierten Personen, früheren Verdachtsmeldungen oder Hochrisiko-Korridoren sind von jedem Schließungsvorschlag ausgeschlossen und gehen in die Senior-Prüfung. Die Schwellenwerte liegen in einem versionierten Policy-Paket, sodass die FRIA die exakt geltende Regel zitieren kann.

Eingriff und Kill-Switch. Analystinnen und Analysten können jeden Vorschlag überstimmen. Die Aufsichtsverantwortliche kann den Agenten sofort suspendieren; der Prozess fällt dann auf das manuelle Verfahren vor Einführung des Agenten zurück. Vor dem Zugang absolvieren Analystinnen und Analysten eine Schulung zu Fähigkeiten, Fehlermodi und Automatisierungs-Bias des Agenten, jährlich aufgefrischt.

Aufsicht über die Aufsicht. Override-Quoten, Zustimmungsquoten und Zeit pro Alert werden monatlich geprüft, um Durchwinken und Arbeitsdruck zu erkennen, die beiden leisen Wege, auf denen menschliche Aufsicht zerfällt.

Abschnitt 6: Maßnahmen bei Eintritt der Risiken (Art. 27 Abs. 1 Buchst. f)¶

Ein Verstoß im Disparate-Impact-Test oder ein Befund der verblindeten Nachprüfung eröffnet einen Modellrisiko-Vorfall; das Financial-Crime-Gremium entscheidet zwischen Schwellenanpassung, Merkmalsentfernung, Neutraining und Suspendierung. Kundenbeschwerden mit Bezug zu triagierten Alerts werden dem DSB und der Aufsichtsverantwortlichen gemeldet, und der versiegelte Evidenznachweis des Falls wird zur Prüfung herangezogen.

Rollback ist konkret, weil alles versioniert ist: Agentenversion, Prompts und Policy-Paket. Unter einer fehlerhaften Version triagierte Alerts sind aus den Evidenznachweisen identifizierbar und werden nachgeprüft. Zu Unrecht verhängte Einschränkungen werden mit dokumentierter Wiedereinsetzung aufgehoben; Gebühren und nachweisbare unmittelbare Schäden werden nach der bestehenden Entschädigungsrichtlinie der Bank erstattet.

Zur Meldung: Ein erfasster Betreiber muss die Ergebnisse der FRIA nach Artikel 27 Absatz 3 der Marktüberwachungsbehörde mitteilen. Die fiktive Bank liegt außerhalb dieser Pflicht; sie meldet wesentliche Vorfälle über ihre bestehenden Aufsichtskanäle und hält die FRIA für die Aufsicht auf Anfrage bereit.

Abschnitt 7: Überprüfungsrhythmus und Aktualisierungsauslöser¶

Artikel 27(2) erfordert, dass ein im Rahmen stehender Deployer die Bewertung aktualisiert, wenn jedes bewertete Element sich ändert oder nicht mehr aktuell ist und die fiktive Bank die gleiche Disziplin annimmt. Die geplante Überprüfung findet alle 12 Monate und bei jeder jährlichen Modellvalidierung des Überwachungsengines statt.

Ereignisauslöser erzwingen eine frühere Überprüfung: eine neue Agentenversion oder ein neues Policy-Paket, eine Änderung des Alert-Volumens um mehr als 25 %, der Eintritt in einen neuen Markt oder ein neues Segment, ein Verstoß im Disparate-Impact-Test, ein Aufsichtsbefund, Einstufungsleitlinien mit AML-Bezug und die Veröffentlichung der offiziellen Vorlage des AI Office nach Artikel 27 Absatz 5, worauf die Abschätzung auf dieser Vorlage neu gefasst wird. Jede Überprüfung wird an das Dokument angefügt; abgelöste Fassungen werden nach dem Aufbewahrungsplan der Bank vorgehalten.

Ausgefülltes Beispiel herunterladen und eigene Abschätzung erstellen¶

Das ausgefüllte Beispiel ist ein einzelnes Markdown-Dokument mit allem Obigen in voller Länge: der Anwendbarkeitsanalyse in Abschnitt 0, allen sechs Abschnitten in der Struktur des Artikels 27 Absatz 1, dem ungekürzten Risikoregister und einem fiktiven Freigabeblock. Es gehört zur leeren FRIA-Vorlage aus dem Vorlagen-Leitfaden.

Für eine Abschätzung Ihres eigenen Einsatzes füllt der kostenlose FRIA-Generator dieselbe Struktur im Browser aus und exportiert Markdown oder JSON. Betreiber in Frankreich lesen ihn zusammen mit dem Leitfaden zur CNIL-Praxis; Betreiber von Kreditscoring und Versicherungstarifierung, die die verpflichtende Artikel-27-Pflicht trifft, finden eigene Praxisbeispiele in der Kreditscoring-FRIA und der Versicherungs-FRIA.

Überprüfbar liest sich diese FRIA, weil ihr Aufsichtsabschnitt Kontrollen beschreibt, die zur Ausführungszeit laufen: Policy-Entscheidungen mit vier Ergebnissen, Vier-Augen-Freigaben und versiegelte Evidenznachweise. Diese Laufzeitschicht stellt KLA bereit, und der Leitfaden zu AML-Alert-Triage-Kontrollen dokumentiert sie von Ende zu Ende.