Steuerung eines Agenten zur Beurteilung von Sanktions-Screening-Treffern
13 min · Updated 2026-06-02
Answer
Sie steuern einen Agenten zur Beurteilung von Sanktions-Screening-Treffern, indem Sie seine drei folgenreichen Handlungen an einem Richtlinienkontrollpunkt abfangen, bevor sie ausgeführt werden: einen Treffer als falsch positiv freigeben, eine echte Übereinstimmung bestätigen und damit blockieren oder einfrieren oder eine mehrdeutige unscharfe Übereinstimmung eskalieren. Der Kontrollpunkt arbeitet bei Freigaben im Fail-Closed-Modus. Eine Freigabe ist die unumkehrbare Handlung mit verschuldensunabhängiger Haftung: Eine irrtümliche Freigabe an eine gesperrte Partei verletzt IEEPA unabhängig von Treu und Glauben. Deshalb bleibt jede Freigabe standardmäßig angehalten und wird über ein Vier-Augen-Gate an einen benannten Sanktionsbeauftragten geleitet; der Blockierungs- und Einfrierpfad bleibt schnell. Die verbindlichen Anforderungen folgen aus dem Sanktionsrecht – der 50-Prozent-Regel des OFAC, der verschuldensunabhängigen IEEPA-Haftung, der Vermögenssperre nach EU-Verordnung 269/2014 und dem UN/FATF-Standard zum unverzüglichen Einfrieren. Der EU AI Act ergänzt menschliche Aufsicht und Protokollierungsdisziplin, begründet hier jedoch keine automatische Hochrisiko-Einstufung nach Anhang III.
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 Namens- und Zahlungsabgleich vergleicht Gegenparteien, Zahlungsabsender und Begünstigte (FinCEN-Reisegeldaten für Überweisungen von 3.000 US-Dollar oder mehr) mit der OFAC-SDN-/konsolidierten Liste und der EU-konsolidierten Finanzsanktionsliste und erzeugt einen Treffer, wenn eine genaue oder unscharfe Übereinstimmung den Schwellenwert überschreitet. Ein Sanktionsanalyst beurteilt gewöhnlich jeden Treffer: Er prüft den übereinstimmenden Namen, die zugrunde liegenden Daten der Gegenpartei und den Listeneintrag und verwirft falsche Positive. Der Agent automatisiert diese Arbeit und ergreift drei Folgemaßnahmen: (1) einen Treffer als falsch positiv verwerfen, wodurch eine zurückgehaltene Zahlung freigegeben oder ein Onboarding abgeschlossen und damit Gelder oder Dienstleistungen der Gegenpartei zur Verfügung gestellt werden; (2) eine echte Übereinstimmung bestätigen, wodurch die Zahlung blockiert oder abgelehnt und das Guthaben oder Konto eingefroren wird; und (3) eine mehrdeutige unscharfe Übereinstimmung an einen benannten Sanktionsbeauftragten eskalieren. Die Asymmetrie dieser Handlungen bestimmt das Kontrollmodell: Ein Verwerfen stellt Gelder zur Verfügung (EU-Verordnung 269/2014 Art. 2(2) und der UN/FATF-Standard zum Einfrieren von Vermögenswerten verbieten dies für eine gelistete Partei), während ein block den Status quo erhält. Entscheidend ist, dass das Fehlen eines Listentreffers keine Freigabe rechtfertigt: Nach der 50-Prozent-Regel des OFAC ist ein Unternehmen, das insgesamt zu 50 % oder mehr direkt oder indirekt im Besitz blockierter Personen ist, selbst blockiert, auch wenn es nie auf der SDN-Liste erscheint. Ein reiner Namensabgleich erfasst diese Fälle daher strukturell nicht ausreichend.
Stakes
Why it's high-stakes
Sanktionshaftung ist verschuldensunabhängig. Nach IEEPA (50 U.S.C. § 1705) kann eine zivilrechtliche Strafe gegen jede Person verhängt werden, die eine rechtswidrige Handlung begeht, ohne dass Wissen oder Vorsatz vorliegen muss; scienter ("vorsätzlich") erscheint nur im strafrechtlichen Unterabschnitt. Gibt der Agent einen Treffer frei, der tatsächlich eine Übereinstimmung war, und wird die zurückgehaltene Zahlung an eine gesperrte Partei freigegeben, liegt der Verstoß unabhängig vom guten Glauben des Agenten oder von der Plausibilität seiner Begründung vor. Der inflationsbereinigte gesetzliche Höchstbetrag beträgt je Verstoß 377.700 US-Dollar oder das Doppelte des Werts der zugrunde liegenden Transaktion, je nachdem, welcher Betrag höher ist; eine Zahlungsdatei kann Tausende von Transaktionen enthalten. Ebenso eindeutig ist das EU-Recht: Die Verordnung (EU) 269/2014 Art. 2 verlangt das Einfrieren aller Gelder und wirtschaftlichen Ressourcen, die gelisteten Personen gehören, von ihnen gehalten oder kontrolliert werden, und verbietet, ihnen direkt oder indirekt Gelder oder wirtschaftliche Ressourcen zur Verfügung zu stellen. Auch der umgekehrte Fehler hat Folgen: Die fälschliche Bestätigung eines falschen Positivs blockiert eine legitime Zahlung, friert einen legitimen Kunden ein und kann in großem Umfang zum Ausschluss ganzer Nationalitäten oder Regionen aus Risikogründen führen. Das ist ein Schaden für beaufsichtigtes Verhalten und Fairness, aber kein Fall verschuldensunabhängiger Haftung. Da die Sanktionsprüfung 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 bei den eigenen Sanktions- und Modellrisikokontrollen des Bereitstellers.
What goes wrong
Failure modes specific to this agent
Freigabe bei „kein SDN-Treffer“, wenn es sich bei der Gegenpartei um ein durch Derivate blockiertes Unternehmen handelt (blinder Fleck der 50-Prozent-Regel)
Der Agent entscheidet über einen Treffer (oder einen Screening-Fehler), indem er den Namen der Gegenpartei mit der veröffentlichten SDN/konsolidierten Liste vergleicht, keinen genauen Listeneintrag findet und ihn löscht – wodurch die Zahlung freigegeben wird. Aber die 50-Prozent-Regel des OFAC führt dazu, dass jedes Unternehmen, das zu insgesamt 50 % oder mehr direkt oder indirekt einer oder mehreren blockierten Personen gehört, selbst blockiert wird, auch wenn es nicht auf der SDN-Liste aufgeführt ist. Der Agent argumentiert mit der Liste, mit der er einen Abgleich durchführen kann. Es löst standardmäßig nicht die Kette des wirtschaftlichen Eigentums auf. Eine Zahlung eines designierten Oligarchen an eine Scheinfirma, die über zwei zwischengeschaltete Unternehmen zu 60 % beteiligt ist, gilt also als klares „kein Treffer“ und der Agent gibt sie frei – ein Verstoß gegen die verschuldensunabhängige Haftung.
Why it's hard to catch: Die Logik des Agenten ist lokal korrekt („Name nicht auf der Liste → keine Übereinstimmung“), sodass jeder Komponententest, der ein Listenabgleichsverhalten bestätigt, bestanden wird und die Begründung, die er schreibt („Gegenpartei nicht auf OFAC-SDN oder konsolidierter EU-Liste ab <Version> vorhanden“), wahr und prüfungssicher ist. Der Fehler ist eine Abwesenheit – eine Überprüfung, die der Agent nie durchgeführt hat – und nicht eine falsche Antwort, die er gegeben hat. Es erscheint nur, wenn Eigentumsdaten überlagert werden, die in Testgeräten (ein einzelner Name oder eine Liste) fast nie enthalten sind. Die aggregierte Genauigkeit sieht gerade deshalb hervorragend aus, weil der Sinn der Regel darin besteht, dass diese Entitäten für die Namensprüfung unsichtbar sind.
Übermäßige Freigabe unscharfer Übereinstimmungen führt zu einer Risikominderung einer Kohorte
Um die sehr hohe Falsch-Positiv-Rate bei der Namensprüfung zu unterdrücken, ist der Agent darauf eingestellt (oder lernt), unscharfe Übereinstimmungen – Transliterationsvarianten, gebräuchliche Nachnamen, teilweise DOB-Matches – aggressiv zu löschen. Für sich genommen sieht jedes Freigabe vernünftig aus. Aber die gleiche Optimierung, die harmlose slawische oder arabische Namensvarianten löscht, erhöht auch die Rate, mit der echte Übereinstimmungen mit denselben Namenskonventionen gelöscht werden, und der Spiegelfehler (übermäßige Bestätigung, um sicher zu sein) blockiert und friert stillschweigend legitime Kunden ein, die sich auf bestimmte Nationalitäten oder Korridore konzentrieren. Am Ende lässt die Institution entweder echte Übereinstimmungen durch eine Kohorte durchsickern oder verringert das Risiko einer ganzen Kohorte aus der Bank – beides Fehler bei der Beurteilungsqualität, die in der Pro-Treffer-Ansicht nicht sichtbar sind.
Why it's hard to catch: Die Überprüfung pro Treffer ergibt nichts: Jeder ist klar und jeder Block ist anhand seiner eigenen Fakten vertretbar. Der Schaden ist eine Verteilungseigenschaft – eine unterschiedliche Klar-/Bestätigungsrate über Kohorten hinweg (Nationalität, Transliterationsfamilie, Zahlungskorridor) – die nur dann auftritt, wenn die Ergebnisse aggregiert und gruppenübergreifend verglichen werden, was bei der Qualitätssicherung von Fall zu Fall und der Prüfung der Label-Übereinstimmung nie der Fall ist. Da sich die vorherrschende Kennzahl (Falsch-Positiv-Reduktion) verbessert, je mehr der Agent mehr Freigabe durchführt, sehen sowohl die Risikominderung als auch das Risiko einer durchgesickerten echte Übereinstimmung auf dem Dashboard wie „Effizienzgewinne“ aus.
Freigabe der Zahlung, während über den Treffer noch entschieden wird (Verstoß gegen „unverzügliche Verzögerung“)
Der Agent (oder die umgebende Orchestrierung) behandelt die Entscheidung als beratend und lässt die Zahlung weiter abwickeln oder gibt die Sperre frei, sobald eine vorläufige „wahrscheinlich falsch positive“ Einschätzung vorliegt, bevor eine menschliche oder endgültige politische Entscheidung getroffen wird. Der UN/FATF-Standard, den die Länder umsetzen, erfordert das „unverzügliche“ Einfrieren und die Sicherstellung, dass nichts zugunsten einer bestimmten Partei bereitgestellt wird; Eine Zahlung, die während der gerichtlichen Entscheidung beglichen wird, macht das Einfrieren zunichte, selbst wenn der Agent später zu dem Schluss kommt, dass es sich um eine echte Übereinstimmung handelte. Die gefährliche Vorgabe lautet hier: „Lassen Sie es fließen, es sei denn, Sie sagen, es soll aufhören“ – das genaue Gegenteil dessen, was das Sanktionsrecht vorschreibt.
Why it's hard to catch: Funktionell „funktioniert“ der Agent: Über Treffer wird entschieden, Zahlungen erhalten meist die richtige Disposition, und beim Testen greift das Timing nur selten, weil Testzahlungen nicht tatsächlich umgesetzt werden. Der Fehler ist eine zeitliche/ordnungsmäßige Eigenschaft – die Freigabe wird ausgeführt, bevor die Entscheidung endgültig ist –, die sich nur bei Parallelität und Latenz in der Produktion manifestiert und einen korrekt aussehenden Prüfpfad erzeugt (der Agent hat entschieden; er hat erst entschieden, nachdem das Geld übrig war). Standardmäßige Funktionstests bestätigen die Entscheidung, nicht aber, dass sich während der Entscheidungsphase kein Wert bewegt hat.
Veraltete Listenversion: Entscheidung gegen die gestrige konsolidierte Liste
Der Agent klärt oder bestätigt einen Treffer, indem er gegen einen Snapshot der Sanktionsliste argumentiert, der korrekt aussieht, aber veraltet ist – eine Bezeichnung, die an diesem Morgen zur konsolidierten EU-Liste oder zum OFAC-SDN hinzugefügt wurde, ist nicht in der Version, mit der der Agent abgeglichen hat, sodass eine neu benannte Partei freigegeben und die Zahlung freigegeben wird. Die konsolidierte EU-Liste „spiegelt die im Amtsblatt veröffentlichten offiziell angenommenen Texte wider“ und wird bei Bedarf aktualisiert; OFAC aktualisiert die SDN-Liste kontinuierlich. Gegen eine veraltete Version zu urteilen, ist ein klarer Beweis dafür, dass sie im Vergleich zur falschen Referenz „richtig“ war.
Why it's hard to catch: Der Agent erstellt eine saubere, in der Liste zitierte Begründung („nicht auf der konsolidierten Liste vorhanden“), und das Einzige, was falsch ist, ist die in diesem Bildschirm eingebettete Listenversion, die bei keiner Qualitätsprüfung pro Entscheidung überprüft wird – die Begründung ist intern konsistent und die zitierte Liste ist eine echte Liste, nur eine alte. Die Wiederholung der Entscheidung anhand der aktuellen Liste würde es auffangen, aber die meisten Tests wiederholen die Entscheidung anhand einer eingefrorenen Spielplanliste, so dass die Veraltenheit genau dort aus dem Test heraus entwickelt wird, wo sie in der Produktion schmerzt. Das Schadensfenster ist eng (zwischen einer Bezeichnung und der nächsten Listensynchronisierung) und kann beim Sampling leicht übersehen werden.
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 |
|---|---|---|---|---|
| Löschen Sie einen Treffer als falsch positiv (gibt eine zurückgehaltene Zahlung frei / schließt ein Onboarding ab – stellt Gelder oder Dienstleistungen zur Verfügung) | Ein KLA SDK-Prüfpunkt umschließt den clear_hit/release_payment-Toolaufruf des Agenten (Govern in Place); Der Kontrollpunkt übermittelt ein Decision Request über POST /v1/decisions.evaluate mit der übereinstimmenden Partei, dem/den Listeneintragskandidaten, der Übereinstimmungsbewertung, den geklärten Feststellungen zum wirtschaftlichen Eigentum und der Listenversion, BEVOR die Freigabe geschrieben wird. Bereitsteller, die das verwaltete Proxy-Gate durchlaufen, führen denselben Schritt über Executions API aus. Dies ist die Aktion, bei der das Gate fehlschlägt: Wenn die Richtlinie nicht ausgewertet werden kann, wird die Löschung nicht fortgesetzt und die Zahlung bleibt zurückgehalten. |
| Ein require_approval-Ergebnis löst eine Decision Desk-Eskalation aus, die von der Richtlinie an einen benannten Sanktionsbeauftragten/OFAC-EU-Compliance-Prüfer weitergeleitet wird (Vier-Augen-Prüfung: Der Agent ist der Hersteller, der Beamte ist der Prüfer). Der Beamte sieht die übereinstimmende Partei, die Einträge und Bewertungen der Kandidatenliste, die Eigentumsfeststellungen, die Listenversion, die vom Agenten vorgeschlagene klare + Begründung, die auslösenden Ursachencodes und einen Link zum Lineage Record, genehmigt dann die Freigabe, lehnt sie ab oder leitet sie an einen hochrangigen MLRO-/Sanktionsleiter weiter. Die Freigabe wird nur bei einer Genehmigung ausgeführt. |
|
| Bestätigen Sie eine echte Übereinstimmung (blockieren/lehnen Sie die Zahlung ab und frieren Sie das Guthaben oder das Konto ein) | Ein KLA SDK-Prüfpunkt umschließt den confirm_match/Einfrieren-Tool-Aufruf des Agenten; Der Decision Request bis POST /v1/decisions.evaluate trägt die übereinstimmende Partei, den Listeneintrag, die Punktzahl und die vorgeschlagene Einfrieraktion, bevor der Block/Einfrier-Commit erfolgt. Da ein Einfrieren die ausfallsichere Richtung für das Sanktionsrecht ist, kann dieser Weg schnell voranschreiten – aber er wird dennoch aufgezeichnet und nur durch Überprüfung rückgängig gemacht, sodass eine übermäßige Blockierung eher beobachtbar als stillschweigend ist. |
| Eine Bestätigung/Einfrierung wird fortgesetzt und löst standardmäßig keine blockierende Eskalation aus, aber eine Bestätigung mit niedriger Punktzahl löst einen von Assurance weitergeleiteten Überprüfungspunkt an einen benannten Sanktionsbeauftragten aus, sodass eine unrechtmäßige Einfrierung umgehend korrigiert wird. Jede Freigabe wird als Eskalation der Freigabeklasse an einen benannten Beamten weitergeleitet. Überbestätigungsraten auf Kohortenebene werden als Assurance Alerts angezeigt (siehe Querschnittskontrolle). |
|
| Eskalieren Sie einen mehrdeutigen unscharfe Übereinstimmung an einen Sanktionsbeauftragten | Ein KLA SDK-Prüfpunkt umschließt den escalate_hit-Toolaufruf des Agenten; Das Decision Request bis POST /v1/decisions.evaluate trägt den Übereinstimmungswert, die fehlenden/schlechteren Daten (z. B. unvollständige Reiseregel-Urheber-/Begünstigtenfelder) und die Kandidatenlisteneinträge vor den Eskalationsrouten. Die sichere Standardeinstellung des Agenten, wenn er einen Treffer nicht lösen kann, ist die Eskalation und nicht die Klärung. |
| Ein require_approval-Ergebnis löst eine Decision Desk-Eskalation aus, die mit dem vollständigen Kontextpaket (Punktzahl, Kandidateneinträge, Datenlücken, Listenversion) an einen benannten Sanktionsbeauftragten weitergeleitet wird. Der Beamte löscht, bestätigt oder fordert weitere Daten an; die Verfügung und die Identität werden erfasst. Die Zurückbehaltung der zugrunde liegenden Zahlung bleibt für die Dauer des Urteils bestehen („unverzüglich“ / fail-closed bei Freigabe). |
|
| Übergreifend: Sorgen Sie dafür, dass der Lauf wiederholbar ist, achten Sie auf Risikominimierung und sorgen Sie dafür, dass Beweise unabhängig überprüfbar sind | Jeder oben genannte Prüfpunkt durchläuft die gleiche Evidence-by-Default-Pipeline (jeder Decision Request, jede Richtlinienentscheidung, jeder Tool-Aufruf und jedes menschliche Urteil werden automatisch erfasst, wenn sie stattfinden, kein separater Protokollierungsschritt im Agentencode) und das Löschen/Bestätigen der Ergebnisse speist die Kohortenüberwachung des Assurance Center ein. |
| n/a für das Beweissubstrat; Assurance Alerts werden mit einem Link zum Lineage Explorer an das zuständige Sanktions-/Finanzkriminalitätskontrollteam weitergeleitet, um die Läufe hinter einer Disparität zu untersuchen. |
|
Least-privilege execution & data boundaries
- Löschen Sie einen Treffer als falsch positiv (gibt eine zurückgehaltene Zahlung frei / schließt ein Onboarding ab – stellt Gelder oder Dienstleistungen zur Verfügung): clear_hit / release_payment ist im unveränderlichen Release des Agenten an den Tool Catalog gebunden; Der Agent kann kein Vergleichs- oder Onboarding-Abschlusstool selbst gewähren, mit dem er nicht freigegeben wurde. Data Boundaries Behalten Sie die sanktionierten Partei-, Zahlungs- und Eigentumsdaten in der genehmigten Region/im genehmigten System und heften Sie den Bildschirm an ein versioniertes, zeitgestempeltes Listenartefakt, sodass die Referenz, anhand derer der Agent abgerechnet hat, die geregelte ist.
- Bestätigen Sie eine echte Übereinstimmung (blockieren/lehnen Sie die Zahlung ab und frieren Sie das Guthaben oder das Konto ein): confirm_match / freeze ist ausschließlich an den geregelten Endpunkt zum Blockieren von Zahlungen bzw. Einfrieren von Konten gebunden. Der Agent ist weder an einen kundenorientierten Kanal gebunden, der den Sperrgrund offenlegen könnte (Sanktionsvertraulichkeit), noch an ein Tool zur einseitigen Aufhebung einer Sperre; diese Route führt immer über das Freigabe-Gate.
- Eskalieren Sie einen mehrdeutigen unscharfe Übereinstimmung an einen Sanktionsbeauftragten: escalate_hit ist schreibgeschützt/weiterleitungsgebunden; es kann sich nicht selbst lösen oder einfrieren. Das Kontextbündel wird innerhalb der Datengrenze zusammengestellt, sodass Kandidaten-Match- und Parteidaten niemals ein nicht genehmigtes System passieren.
- Übergreifend: Sorgen Sie dafür, dass der Lauf wiederholbar ist, achten Sie auf Risikominimierung und sorgen Sie dafür, dass 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 Löschung mit welcher Listenversion ausgeführt wurde.
Mapped to regulation
Regulatory mapping
| Framework | Article / section | Obligation (plain language) | How a KLA runtime control satisfies it | Source |
|---|---|---|---|---|
| US OFAC – 50-Prozent-Regel | Überarbeitete Leitlinien zu Unternehmen, die im Besitz gesperrter Personen sind (13. August 2014) und FAQ 401 | Ein Unternehmen, das insgesamt zu 50 % oder mehr direkt oder indirekt im Besitz einer oder mehrerer gesperrter Personen ist, ist selbst gesperrt, auch wenn es NICHT auf der SDN-Liste aufgeführt ist; „Indirekt“ umfasst das Eigentum über zwischengeschaltete Unternehmen mit einer Beteiligung von über 50 %. Ein Nur-Namen-Bildschirm, der „Kein Listentreffer“ zurückgibt, beweist daher allein nicht, dass eine Gegenpartei eindeutig ist. | Die Freigabe-Sperre, wenn keine Auflösung des wirtschaftlichen Eigentums/der 50 %-Regel angehängt ist (runtime_controls[0], SANC_CLEAR_NO_OWNERSHIP_RESOLUTION), verhindert, dass der Agent eine Zahlung bei einem bloßen „Kein SDN-Treffer“ freigibt; Der Clearingvorgang kann erst fortgesetzt werden, wenn eine Eigentumsüberprüfung beigefügt ist und ein benannter Sanktionsbeauftragter ihn über dem Punktestand bestätigt. | Source |
| US IEEPA – verschuldensunabhängige zivilrechtliche Haftung | 50 U.S.C. § 1705(a)-(c); 31 CFR Part 501 App. A (gesetzliche zivilrechtliche Höchststrafe) | Eine zivilrechtliche Strafe „kann gegen jede Person verhängt werden, die eine rechtswidrige Handlung begeht“, ohne Wissen oder Vorsatz (Wissenschaftler – „vorsätzlich“ – erscheint nur im Unterabschnitt „Strafrecht“). Der inflationsbereinigte gesetzliche Höchstbetrag beträgt je Verstoß 377.700 US-Dollar oder das Doppelte des zugrunde liegenden Transaktionswerts, je nachdem, welcher Betrag höher ist. Eine irrtümliche Freigabe an eine gesperrte Partei stellt unabhängig vom Treu und Glauben einen vollständigen Verstoß dar. | Da die Haftung für eine falsche Freigabe strikt ist, schließt sich das Gate bei der Freigabe-/Freigabeaktion (runtime_controls[0], runtime_controls[3]): Jede Freigabe innerhalb des Gültigkeitsbereichs wird standardmäßig zurückgehalten und an einen benannten Beamten weitergeleitet, sodass keine Freigabe von Werten an eine potenziell blockierte Partei allein auf das Wort des Agenten hin erfolgt. Die Asymmetrie ist in der politischen Richtung kodiert – Freigabepausen, Einfrieren der Erlöse. | Source |
| Restriktive Maßnahmen der EU – Verordnung. (EU) 269/2014 | Artikel 2 Absätze 1 bis 2 – Einfrieren von Vermögenswerten und das Verbot der Bereitstellung | Alle Gelder und wirtschaftlichen Ressourcen, die den gelisteten Personen gehören, von ihnen gehalten oder kontrolliert werden, müssen eingefroren werden. Es dürfen weder direkt noch indirekt Gelder oder wirtschaftliche Ressourcen an die gelisteten Personen oder zugunsten dieser Personen weitergegeben werden. „Kontrolliert“ und „indirekt“ machen die Verpflichtung umfassender als eine wörtliche Namensübereinstimmung. | Das Freigabe-Gate (runtime_controls[0]) behandelt eine Freigabe-Aktion als „Zurverfügungstellen“-Akt und hält sie bis zur Eigentumsentscheidung und der Freigabe durch den Beamten zurück; Der Bestätigungs-/Einfrierpfad (runtime_controls[1]) führt das Einfrieren in der ausfallsicheren Richtung aus. Zusammen verhindern sie, dass der Agent Gelder einer kontrollierten/indirekten Partei zur Verfügung stellt, während echte Einfrierungen stattfinden. | Source |
| Restriktive Maßnahmen der EU – Konsolidierte Liste (GD FISMA) | Konsolidierte EU-Sanktionsliste (spiegelt die Texte des Amtsblatts wider und wird bei Bedarf aktualisiert) | Die konsolidierte EU-Finanzsanktionsliste ist die operative Referenz für die Überprüfung und spiegelt die offiziell angenommenen Texte im Amtsblatt wider. es wird bei Bedarf aktualisiert. Die Entscheidung muss anhand der aktuellen Listenversion erfolgen. | Der Block „stale-list-version“ (runtime_controls[0], SANC_CLEAR_STALE_LIST_VERSION) lehnt einen Freigabe ab, dessen Bildschirm mit einer Liste ausgeführt wurde, die älter als die aktuell veröffentlichte Version ist, und die Beweiserfassung heftet das genaue versionierte Listenartefakt an den Lineage Record (runtime_controls[0], runtime_controls[3]), sodass „auf welche Listenversion sich dieser Freigabe stützte“ lautet beweisbar. | Source |
| FATF R.6 (über den Standard zum Einfrieren von Vermögenswerten des UN-Sicherheitsrats) | UN-Sicherheitsrat „Einfrieren von Vermögenswerten: Erläuterung der Begriffe“ – „Unverzügliches Einfrieren“ | Die Gelder und Vermögenswerte benannter Personen – einschließlich derer, die sich direkt oder indirekt im Besitz oder unter der Kontrolle befinden – müssen OHNE VERZÖGERUNG eingefroren werden, und es darf nichts zu ihren Gunsten zur Verfügung gestellt werden. „Ohne Verzögerung“ ist eine zeitliche Kontrolle darüber, wann sich der Wert bewegen darf. | Die Standardeinstellung „fail-closed bei Freigabe“ plus der Block „Unapproved-Release-Path“ (runtime_controls[0], SANC_RELEASE_PATH_UNAPPROVED) und die dauerhafte Sperrung während der Eskalation (runtime_controls[2]) stellen sicher, dass die Zahlung für die Dauer der Entscheidung eingefroren bleibt – kein Wert bewegt sich, während ein Treffer aussteht, was „ohne Verzögerung“ bedeutet. | Source |
| FATF R.16 (über die FinCEN-Reiseregel) | 31 CFR § 1010.410(e) – „Reiseregel“ für Gelder (über 3.000 USD) | Bei Überweisungen im Wert von 3.000 US-Dollar oder mehr müssen die Angaben zum Absender (Übermittler) und Begünstigten/Empfänger-Institution mit der Zahlung übermittelt und aufbewahrt werden. Dies sind die Daten, über die der Agent entscheidet; Fehlende oder minderwertige Travel-Rule-Daten führen zu unauflösbaren unscharfe Übereinstimmungen. | Die Eskalationsregel „Unzureichende Reiseregeldaten“ (runtime_controls[2], SANC_INSUFFICIENT_TRAVEL_RULE_DATA) leitet einen Treffer mit fehlenden/minderwertigen Absender-Begünstigten-Daten an einen benannten Beamten weiter, anstatt den Agenten eine Klärung einer dünnen Zahlungsaufzeichnung zu überlassen – wodurch eine strukturelle Datenlücke in eine Eskalation und nicht in eine stille Klärung umgewandelt wird. | Source |
| EU AI Act – Verordnung (EU) 2024/1689 | Anwendungsbereich von Anhang III (Klassifizierungshinweis: Sanktionsüberprüfung wird nicht aufgeführt) | Anhang III listet die Hochrisikogebiete auf; Sanktionsüberprüfung/Entscheidung über das Einfrieren von Vermögenswerten ist nicht aufgeführt, sodass ein Agent für die Entscheidung über Sanktionstreffer nicht automatisch ein Hochrisiko-KI-System ist. Das Gesetz über verschuldensunabhängige Sanktionen ist das vorherrschende Regime; Der EU AI Act gilt als Aufsichts-/Protokollierungsdisziplin und dort, wo der Bereitsteller ansonsten in den Geltungsbereich fällt. | Hierbei handelt es sich um eine Scoping-Zuordnung, nicht um eine Kontrollzuordnung: Sie teilt dem Bereitsteller mit, dass das Hochrisiko-Konformitätsregime hier nicht die lasttragende Verpflichtung ist, sodass die Laufzeitkontrollen zuerst das Sanktionsgesetz und die Asymmetrie (fail-closed bei der Veröffentlichung) erfüllen und die folgenden EU AI Act-Artikel zur Aufsicht/Protokollierung freiwillig übernehmen. | 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 bewusst sein, in der Lage sein, zu entscheiden, die Ausgabe des Systems nicht zu verwenden, zu ignorieren, zu überschreiben oder umzukehren, und in der Lage sein, einzugreifen oder das System in einen sicheren Zustand zu unterbrechen. | Die require_approval-Pause bei einer Freigabe + Decision Desk-Überschreibung/Umleitung (runtime_controls[0], runtime_controls[2]) ist das direkte Analogon von Ignorieren/Überschreiben/Umkehren; Die Blockergebnisse (No-Ownership, Stale-List, Unapproved-Release-Pfad) sind die „Unterbrechung in einen sicheren Zustand“ – der sichere Zustand für Sanktionen ist die zurückgehaltene Zahlung. Dem Beamten vorgelegte Ursachencodes wirken einer Voreingenommenheit der Automatisierung entgegen, die zwar plausibel, aber falsch ist. | Source |
| EU AI Act – Verordnung (EU) 2024/1689 | Artikel 12 Absätze 1 bis 2 – Aufzeichnungen (automatische Protokollierung) | KI-Systeme mit hohem Risiko müssen technisch eine automatische Aufzeichnung von Ereignissen (Protokolle) über die Systemlebensdauer hinweg ermöglichen, mit einer dem Verwendungszweck angemessenen Rückverfolgbarkeit. | Evidence-by-Default erfasst alle Decision Request, Richtlinienentscheidungen, Toolaufrufe und menschlichen Urteile automatisch (runtime_controls[3]) und versiegelt sie alle – einschließlich der genauen Listenversion, gegen die der Bildschirm lief – in einem nur anhängbaren, Merkle-sicheren Lineage Record, der die Anforderungen an die automatische Protokollierung und Rückverfolgbarkeit als integrierte Eigenschaft erfüllt, selbst wenn Art. 12 bindet strikt nur im Hochrisikobereich. | Source |
| EU AI Act – Verordnung (EU) 2024/1689 | Artikel 26(6) – Aufbewahrung von Bereitstellungsprotokollen | Bereitsteller müssen die automatisch generierten Protokolle mindestens sechs Monate lang unter ihrer Kontrolle halten (es sei denn, andere Unions-/nationale Rechtsvorschriften legen einen längeren Zeitraum fest). | Die Evidence-by-Default-Pipeline speichert automatisch generierte Lineage Records weit über die Sechs-Monats-Untergrenze (runtime_controls[3] hinaus) und kann als Sealed Evidence Bundle oder als Sanktionsprogramm Control Pack exportiert werden – und Sanktions-/AML-Aufzeichnungsregeln erfordern typischerweise eine weitaus längere Aufbewahrung, was das gleiche Ledger unterstützt. | Source |
Prove the control held
Audit-evidence checklist
- Für jede Freigabe/Freigabe: der Decision Request, die beigefügte Auflösung des wirtschaftlichen Eigentums / der 50 %-Regel, das Ergebnis der Police + reasonCodes sowie das Genehmigungsurteil und der Zeitstempel des benannten Sanktionsbeauftragten, versiegelt auf dem Lineage Record – ein Beweis dafür, dass keine Wertfreigabe allein aufgrund des Wortes des Agenten erfolgte (IEEPA verschuldensunabhängige Haftung; OFAC 50 Prozent-Regel; EU-Reg. 269/2014 Art. 2(2)).
- Das genaue versionierte, zeitgestempelte Sanktionslisten-Artefakt, anhand dessen jedes Urteil überprüft wurde, ist an Lineage Record angeheftet – also „auf welche konsolidierte OFAC-SDN-/EU-Version der konsolidierten Liste stützte sich dieser eindeutige Beweis?“ ist nachweisbar und nicht rekonstruierbar (konsolidierte EU-Liste; Block veralteter Versionen).
- Für jede Bestätigung/Einfrierung: der Decision Request, die Übereinstimmungspunktzahl, die Einfrierungsaktion und ihr geregelter Zielendpunkt sowie jede Überprüfungsmarkierung mit niedriger Punktzahl – es wird festgestellt, dass die Einfrierung zuordenbar war und dass unrechtmäßige Einfrierungen zur sofortigen Überprüfung markiert wurden (UN/FATF „Einfrieren ohne Verzögerung“; Risikominderungskontrolle).
- Beweisen Sie, dass die zugrunde liegende Zahlung für die gesamte Dauer einer Eskalation/Entscheidung zurückgehalten wurde (kein Wert wurde verschoben, während ein Treffer ausstand) – die „unverzügliche“ zeitliche Kontrolle.
- Jede Freigabe/Umkehr wird als Eskalation der Freigabeklasse mit der Genehmigung des benannten Beamten erfasst, da die Aufhebung einer Sperre selbst eine „Zurverfügungstellen“-Aktion ist und das Freigabe-Gate mit Vier-Augen-Prüfung erbt.
- Aufschlüsselung der Kohorten-Freigaberate und Bestätigungs-/Einfrierungsrate des Assurance Center (nach Nationalität, Transliterationsfamilie, Zahlungskorridor, Region) und alle Assurance Alerts, die bei Ungleichheiten ausgelöst werden – ständige Beweise dafür, dass übermäßiges Freigabe (durchgesickerte echte Übereinstimmungen) und übermäßiges Blockieren (Risikominderung/finanzieller Ausschluss) aktiv überwacht werden.
- Der aktive Release-Hash (Modell + Anweisungen + Parameter + Toolbindungen) ist auf jedem Lineage Record eingeprägt und antwortet: „Welche Konfiguration hat genau zu dieser Entscheidung geführt?“
- Unabhängige Verifizierung: 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; exportierbar als Sealed Evidence Bundle oder als Sanktionsprogramm Control Pack, wobei die Protokolle über den EU AI Act Art. hinaus aufbewahrt werden. 26(6) Sechsmonatsuntergrenze.
A concrete intercept
Reference scenario: Ein Agent versucht, eine Zahlung ohne SDN-Hit an eine Tarnfirma abzuwickeln – und ein benannter Sanktionsbeamter hält die Freigabe zurück
- 1
Der Agent zur Trefferbeurteilung überprüft die Zahlung PAY-55218 (eine Überweisung von 480.000 US-Dollar an „Meridian Trade Holdings Ltd“), nachdem die Abgleich-Engine einen unscharfen Treffer mit niedriger Punktzahl gemeldet hat, vergleicht den Namen mit den konsolidierten OFAC-SDN- und EU-Listen, findet keinen genauen Eintrag und bereitet sich darauf vor, den Treffer als falsch positiv zu löschen – was die zurückgehaltene Zahlung freigeben würde – mit der Begründung „Kontrahent nicht auf der OFAC-SDN- oder konsolidierten EU-Liste vorhanden“.
- 2
Bevor die Veröffentlichung geschrieben wird, sendet der KLA SDK-Prüfpunkt, der clear_hit / release_payment umschließt, einen Decision Request an POST /v1/decisions.evaluate mit: match_score=0,61, list_version=OFAC-SDN-2026-06-01, beneficial_ownership_resolution=abwesend, release_path=settlement-prod.
- 3
Die Richtlinie stimmt mit zwei Regeln überein: SANC_CLEAR_NO_OWNERSHIP_RESOLUTION (keine 50 %-Regel/Eigentumsprüfung ist beigefügt) gibt Block zurück, und SANC_CLEAR_HUMAN_SIGNOFF (ein Treffer auf der Sanktionsliste wird gelöscht) gibt require_approval zurück. Aufgrund des Vorrangs gewinnt der einzelne Block – der Freigabe geht nicht weiter; die Zahlung bleibt zurückgehalten; Der Agent erhält eine strukturierte Ablehnung mit Begründungscodes und Abhilfemaßnahmen („Beschluss über wirtschaftliches Eigentum beifügen; Route zum Sanktionsbeauftragten“).
- 4
Die Richtlinie leitet eine Decision Desk-Eskalation an den genannten Sanktionsbeauftragten weiter, dem dieser Korridor gehört. Der Beamte sieht die Partei, die Kandidatenlisteneinträge, match_score, den Beschluss über fehlende Eigentumsverhältnisse, die Listenversion, die vom Agenten vorgeschlagene Klarstellung + Begründung, beide Ursachencodes und einen Link zum Lineage Record.
- 5
Der Beamte untersucht die Eigentumskette und stellt fest, dass Meridian indirekt über zwei Vermittler zu 60 % im Besitz einer bestimmten Person ist – einer Derivate-gesperrten Einheit gemäß der 50-Prozent-Regel des OFAC, die niemals auf der SDN-Liste erscheint. Der Beamte verweigert die Freigabe und bestätigt die Übereinstimmung; Das Einfrieren geht weiter. Die Kunst. Die Außerkraftsetzung gemäß Artikel 14(4)(d) und die Vier-Augen-Prüfung-Kontrolle werden auf die eine Handlung ausgeübt, die eine verschuldensunabhängige Haftung mit sich bringt.
- 6
Jeder Schritt – der Decision Request, die Block- + require_approval-Ergebnisse, die Ursachencodes, das angeheftete Listenversionsartefakt, die Identität und das Urteil des Beamten 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 ein Sanktionsprogramm Control Pack mit Nr. exportiert werden kann Vertrauen in KLA erforderlich.
What most teams get wrong
The non-obvious insight
Für einen Sanktionstreffer-Entscheidungsagenten muss das Policy-Gate fail-closed auf der CLEAR-Aktion (Freigabe) basieren, nicht auf dem Block – das Gegenteil davon, wie die meisten Genehmigungs-Gates verkabelt sind. Die beiden Fehler sind nicht symmetrisch: Durch die Freigabe einer echten Übereinstimmung wird Wert an eine gesperrte Partei freigegeben, was nach IEEPA (50 U.S.C. § 1705) einen Verstoß gegen die strenge Haftung ohne Treu und Glauben darstellt (der inflationsbereinigte Höchstbetrag ist der höhere Betrag von 377.700 US-Dollar oder das Doppelte des Transaktionswerts pro Verstoß), wohingegen die fälschliche Bestätigung eines falschen Positivs lediglich eine legitime Zahlung darstellt – erstattungsfähig – und einen Schaden ohne verschuldensunabhängige Haftung darstellt. Der gefährliche, unumkehrbare Schritt ist also die Veröffentlichung, und ein „Kein SDN-Treffer“ reicht nicht einmal aus, um dies zu rechtfertigen: Die 50-Prozent-Regel des OFAC bewirkt, dass eine Entität, die sich zu mehr als 50 % (direkt oder indirekt) im Besitz blockierter Personen befindet, selbst blockiert wird, ohne jedoch auf der Liste zu erscheinen. Das Gate hält daher standardmäßig alle im Geltungsbereich befindlichen Daten frei und ermöglicht ein schnelles Einfrieren.
Why it matters: Die meisten Teams entwerfen Genehmigungstore für fail-closed, indem sie die Aktion verweigern – sinnvoll, wenn das Riskante darin besteht, etwas zu tun. Hier besteht die riskante Sache in der Freigabe, und ein naives „Beratungsurteil, lassen Sie die Zahlung fließen, es sei denn, Sie werden aufgefordert, damit aufzuhören“-Design scheitert – offen genau bei der verschuldensunabhängigen Haftungsklage, und macht dann den Standard „Einfrieren ohne Verzögerung“ zunichte, indem es den Wert bewegen lässt, während ein Treffer ansteht. Schlimmer noch: Dieselbe übermäßige Freigabe-Optimierung, die Fehlalarme unterdrückt, verringert auf der Spiegelseite stillschweigend das Risiko ganzer Nationalitäten oder Korridore aus der Bank – ein Fairness-Schaden, der pro Treffer unsichtbar und nur in Freigabe/Confirm-Raten auf Kohortenebene sichtbar ist. Die fail-closed-Richtung richtig zu machen (Release pausiert, Einfrieren geht weiter, Aufhebung der Sperre erbt das Freigabe-Gate erneut) und die Kohortenverteilung zu beobachten, ist das gesamte Steuerungsdesign und das Gegenteil der Standardeinstellung.
Eine falsche Sanktionsklarheit ist einzigartig unversöhnlich: Gemäß IEEPA (50 U.S.C. § 1705) gilt die zivilrechtliche Haftung für „jede Person, die eine rechtswidrige Handlung begeht“, ohne Wissen oder Vorsatz. Daher ist die Freigabe einer zurückgehaltenen Zahlung an eine gesperrte Partei ein vollständiger Verstoß, selbst wenn der Agent in vollkommenem guten Glauben gehandelt hat, und unterliegt einem gesetzlichen Höchstbetrag von 377.700 US-Dollar oder dem Doppelten des Transaktionswerts pro Verstoß, je nachdem, welcher Betrag höher ist. Aus diesem Grund muss die eindeutige Aktion eines Agent zur Beurteilung und nicht seine Blockadeaktion hinter einem benannten Menschen stehen fail-closed. (source)
Q&A
Frequently asked questions
Ist ein Sanktionsüberprüfungs-Trefferentscheidungsagent ein KI-System mit hohem Risiko im Sinne von EU AI Act?
Höchstwahrscheinlich nicht auf der Grundlage von Anhang III. Die Sanktionsüberprüfung/Entscheidung über das Einfrieren von Vermögenswerten ist in EU AI Act Anhang III nicht aufgeführt, sodass der Agent nicht automatisch ein Hochrisiko-KI-System ist. Die vorherrschende Regelung ist das Sanktionsgesetz mit verschuldensunabhängiger Haftung – die 50-Prozent-Regel des OFAC und IEEPA (50 U.S.C. § 1705), EU-Verordnung. 269/2014, das Verbot des Einfrierens und Bereitstellens von Vermögenswerten sowie der UN/FATF-Standard „Unverzügliches Einfrieren“. Der EU AI Act gilt weiterhin sinnvoll als menschliche Aufsicht und Protokollierungsdisziplin (Art. 12, 14, 26) und wenn der Betreiber ansonsten in den Geltungsbereich fällt. Bestätigen Sie die Einstufung anhand Ihres eigenen Einsatzes und suchen Sie Rat – „kein hohes Risiko gemäß Anhang III“ bedeutet nicht „geringes Governance-Risiko“, da die Sanktionshaftung streng ist.
Warum bleibt das Tor fail-closed bei einem Freigabe, lässt aber ein Einfrieren zu?
Weil die beiden Fehler nicht symmetrisch sind. Durch die Freigabe einer echten Übereinstimmung wird Wert für eine gesperrte Partei freigegeben, was gemäß IEEPA einen Verstoß gegen strenge Haftung ohne Treu und Glauben und einen gesetzlichen Höchstbetrag von 377.700 US-Dollar oder dem Doppelten des Transaktionswerts pro Verstoß darstellt – je nachdem, welcher Betrag höher ist – ein irreversibler, kostspieliger Schritt. Die fälschliche Bestätigung eines falschen Positivs führt lediglich zu einer rechtmäßigen Zahlung, die erstattungsfähig ist. Die gefährliche Aktion ist also die Freigabe: Jede Freigabe innerhalb des Geltungsbereichs wird standardmäßig zurückgehalten und an einen benannten Sanktionsbeauftragten weitergeleitet (require_approval), während das Einfrieren in die ausfallsichere Richtung erfolgt und aufgezeichnet wird. Ein Aufhebung der Sperre erbt das Freigabe-Gate erneut, da das Aufheben eines Sperren selbst ein „Verfügbarkeits“-Akt ist.
Wenn die Gegenpartei nicht auf der SDN-Liste steht, warum kann der Agent sie dann nicht einfach löschen?
Denn „kein Listentreffer“ ist nicht dasselbe wie „klar“. Die 50-Prozent-Regel des OFAC blockiert jedes Unternehmen, das insgesamt zu 50 % oder mehr direkt oder indirekt einer oder mehreren blockierten Personen gehört, selbst, obwohl es nie auf der SDN-Liste erscheint, und deckt „indirekt“ das Eigentum über zwischengeschaltete Unternehmen ab, die zu 50 % oder mehr im Eigentum stehen. Bei einem Nur-Namen-Bildschirm fehlen diese abgeleiteten blockierten Entitäten strukturell. Das Freigabe-Gate blockiert daher alle Clears, denen keine wirtschaftliche Eigentümerschaft/50 %-Regel-Entscheidung beigefügt ist (SANC_CLEAR_NO_OWNERSHIP_RESOLUTION) – der Agent muss die Eigentumskette auflösen, und oberhalb des Punktebereichs muss ein benannter Beamter bestätigen, bevor eine Freigabe erfolgt.
Wie verhindert die Verwaltung des Agenten, dass das Risiko ganzer Länder oder Korridore verringert wird?
Bei der Überprüfung pro Treffer kann keine Risikominderung festgestellt werden – jeder gelöschte Block und jeder Block sieht für sich genommen vertretbar aus. Der Schaden ist verteilt, daher verfolgt das Assurance Center von KLA die Freigaberate und die Bestätigungs-/Einfrierungsrate des Agenten über definierte Kohorten hinweg (Nationalität, Transliterationsfamilie, Zahlungskorridor, Region). Wenn eine Kohorte mit einer wesentlich anderen Rate bestätigt/eingefroren – oder gelöscht – wird, wird diese Diskrepanz zu einer Assurance Alert mit angehängter Kohortenaufschlüsselung und einem Link zum Lineage Explorer. Dadurch wird übermäßiges Blockieren (finanzieller Ausschluss) und übermäßiges Löschen (durchgesickerte echte Übereinstimmungen) von der unsichtbaren „Effizienz“ des Dashboards in einen stichhaltigen, überprüfbaren Fairness-Beweis umgewandelt, während die Kennzeichnung „Bewertung bei niedriger Punktzahl bestätigen“ einzelne unrechtmäßige Einfrierungen sofort auffängt.
Wie stellen Sie sicher, dass eine Zahlung nicht beglichen wird, während über einen Treffer noch entschieden wird?
Der Fail-Closed-Standard für die Freigabe ist der Mechanismus: Eine Freigabe, die nicht vollständig ausgewertet werden kann, wird nicht fortgesetzt, sodass die Zahlung zurückgehalten bleibt. Der Blockierung des Freigabepfads (SANC_RELEASE_PATH_UNAPPROVED) verhindert, dass der Agent den Wert über einen anderen Pfad als den genehmigten, die Sperre beibehaltenden Abrechnungsendpunkt weiterleitet, und während einer Eskalation bleibt die Sperre für die gesamte Dauer der Entscheidung bestehen. Jedes Lineage Record trägt den Nachweis, dass die Zahlung durchgehend zurückgehalten wurde – die operative Form des UN/FATF-Standards „Unverzüglich einfrieren“, den ein naives „Lassen Sie es fließen, es sei denn, Sie werden aufgefordert, es zu stoppen“-Design zunichte machen würde.
Erstellt, führt oder betreibt KLA den Sanktionsprüfungsagenten?
Nein. Der Kunde erstellt und besitzt den Sanktionstreffer-Entscheidungsagenten (LangGraph, CrewAI, Agentforce, Microsoft Copilot oder intern) und der Kunde ist Eigentümer des Sanktionsprogramms. KLA ist die unabhängige Laufzeit-Governance- und Sicherungsschicht, die den Agenten vor Ort regelt: Er fängt jede Folgeaktion ab, bevor sie ausgeführt wird, erzwingt Richtlinien als Code mit den vier Ergebnissen (Zulassen/Warnen/require_approval/Blockieren) und einer freigabeseitigen fail-closed-Richtung, leitet hochriskante Freigaben und Freigaben an benannte menschliche Genehmiger in Decision Desk weiter und Siegel, unterzeichnete Hinrichtungslinie, die dem Sanktionsgesetz zugeordnet ist. KLA löscht nie einen Treffer, gibt nie eine Zahlung frei und tätigt nie den Anruf – Menschen haben das Veto gegen require_approval.
Related blueprints & guides
- Steuerung eines Agenten zur Triage von AML-Transaktionsüberwachungswarnungen
- 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)
- Steuerung eines AML-Transaktionsüberwachungs-Alarm-Triage-Agenten
- Richtliniengesteuerte Ausführung (Kernkonzept)
- Menschliches Genehmigungsgate hinzufügen (Vier-Augen-Prüfung)
- Decision Desk (Eskalationen und Weiterleitung an Genehmiger)
- Assurance Center (Kohorten-/Risikominderungsüberwachung)
- Evidence Room (Sealed Evidence Bundle / Control Pack)
Primary sources
- Revised Guidance on Entities Owned by Persons Whose Property and Interests in Property Are Blocked (the '50 Percent Rule'): US Department of the Treasury, Office of Foreign Assets Control (OFAC)
- OFAC FAQ 401 — Entities Owned by Blocked Persons (50 Percent Rule) / indirect ownership: US Department of the Treasury, Office of Foreign Assets Control (OFAC)
- 50 U.S.C. § 1705 — Penalties under the International Emergency Economic Powers Act (IEEPA): United States Code (via Cornell Legal Information Institute)
- 31 CFR Part 501, Appendix A — Economic Sanctions Enforcement Guidelines: US Department of the Treasury / OFAC (Code of Federal Regulations, via Cornell Legal Information Institute)
- Council Regulation (EU) No 269/2014, Article 2 — Freezing of funds and economic resources: EUR-Lex (Official Journal of the European Union)
- Financial sanctions: Consolidated list of persons, groups and entities subject to EU financial sanctions: European Commission, DG FISMA
- Assets Freeze: Explanation of Terms (UN Security Council sanctions assets-freeze measure): United Nations Security Council
- 31 CFR § 1010.410 — Records to be made and retained by financial institutions (the 'Travel Rule', transmittals of funds of $3,000 or more): FinCEN / US Department of the Treasury (Code of Federal Regulations, via Cornell Legal Information Institute)
- Regulation (EU) 2024/1689 (EU AI Act), Article 14 — Human oversight: EUR-Lex (mirrored at artificialintelligenceact.eu)
- Regulation (EU) 2024/1689 (EU AI Act), Article 12 — Record-keeping (logging): EUR-Lex (mirrored at artificialintelligenceact.eu)
- Regulation (EU) 2024/1689 (EU AI Act), Article 26 — Obligations of deployers of high-risk AI systems: EUR-Lex (mirrored at artificialintelligenceact.eu)
- KLA Control Plane — Policy-Gated Execution (core concept): KLA Digital
- KLA Control Plane — Evidence-by-Default (core concept): KLA Digital
- KLA Control Plane — Decision Desk (product module): KLA Digital
- KLA Control Plane — Policy Builder (product module): KLA Digital
- KLA Control Plane — Agents & Registry (product module): KLA Digital
- KLA Control Plane — Evidence Room (product module): KLA Digital
- KLA Control Plane — Assurance Center (product module): KLA Digital
- KLA Control Plane — Govern an Agent End-to-End (guide): KLA Digital
- KLA Control Plane — Add a Human Approval Gate (guide): KLA Digital
- KLA Control Plane — 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.