Gouverner un agent d'adjudication des alertes de filtrage des sanctions
13 min · Updated 2026-06-02
Answer
Vous gouvernez un agent d'adjudication des alertes de sanctions en interceptant ses trois actions à conséquences — lever une alerte comme faux positif (ce qui libère un paiement ou une entrée en relation en attente), confirmer une correspondance réelle (ce qui bloque et gèle) et escalader une correspondance approximative ambiguë — au moyen d'un point de contrôle de politique exécuté avant que l'action ne s'exécute, et en rendant la barrière fermée par défaut (fail-closed) sur l'action de libération plutôt que sur le blocage. Une levée est le geste irréversible et porteur de responsabilité objective (une libération erronée au profit d'une partie bloquée constitue une violation de l'IEEPA indépendamment de la bonne foi) ; chaque levée est donc retenue par défaut et acheminée vers un responsable sanctions nommément désigné dans une barrière maker-checker, tandis que le chemin de blocage/gel reste rapide ; la force contraignante provient du droit des sanctions (la règle des 50 % de l'OFAC et la responsabilité objective au titre de l'IEEPA, le gel des avoirs du règlement (UE) 269/2014, la norme ONU/GAFI de « gel sans délai »), le règlement européen sur l'IA apportant une discipline de supervision humaine et de journalisation plutôt qu'une classification automatique à haut risque au titre de l'annexe 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
Un moteur de filtrage des noms et des paiements compare les contreparties, les donneurs d'ordre et les bénéficiaires des paiements (données de la Travel Rule de FinCEN pour les transmissions de 3 000 $ ou plus) avec la liste SDN/consolidée de l'OFAC et la liste consolidée des sanctions financières de l'UE, et déclenche une « alerte » dès qu'une correspondance approximative ou exacte franchit le seuil. Un analyste sanctions adjudique normalement chaque alerte : examiner le nom apparié, les données sous-jacentes de la partie et l'entrée de la liste, puis statuer. L'agent d'adjudication des alertes automatise ce travail et prend trois actions à conséquences : (1) lever une alerte comme faux positif — ce qui libère un paiement en attente ou finalise une entrée en relation, mettant des fonds ou des services entre les mains de la contrepartie ; (2) confirmer une correspondance réelle — ce qui bloque/rejette le paiement et gèle les fonds ou le compte ; et (3) escalader une correspondance approximative ambiguë vers un responsable sanctions nommément désigné. L'asymétrie entre ces actions est tout l'enjeu : une levée met des fonds à disposition (l'acte que l'art. 2(2) du règlement (UE) 269/2014 et la norme ONU/GAFI de gel des avoirs interdisent à l'égard d'une partie inscrite), tandis qu'un blocage maintient le statu quo. Point essentiel : une « absence de correspondance sur la liste » n'équivaut pas à une « levée » : la règle des 50 % de l'OFAC signifie qu'une entité détenue à 50 % ou plus au total, directement ou indirectement, par des personnes bloquées est elle-même bloquée alors qu'elle n'apparaît jamais sur la liste SDN ; le filtrage par le seul nom sous-détecte donc structurellement.
Stakes
Why it's high-stakes
La responsabilité en matière de sanctions est objective, et non fondée sur la négligence. En vertu de l'IEEPA (50 U.S.C. § 1705), une sanction civile « peut être infligée à toute personne qui commet un acte illicite », sans élément de connaissance ni d'intention — l'élément intentionnel (« willfully ») n'apparaît que dans la sous-section pénale. Ainsi, si l'agent lève une alerte qui était une correspondance réelle et que le paiement en attente est libéré au profit d'une partie bloquée, il s'agit d'une violation consommée, quelle que soit la bonne foi de l'agent ou la plausibilité de sa justification. Le maximum légal ajusté de l'inflation est le plus élevé de 377 700 $ ou du double de la valeur de la transaction sous-jacente, par violation — et un fichier de paiements peut contenir des milliers de transactions. Le volet européen est tout aussi catégorique : l'art. 2 du règlement (UE) 269/2014 exige que tous les fonds et ressources économiques contrôlés par les personnes inscrites soient gelés et qu'aucun fonds ni aucune ressource économique ne soit mis, directement ou indirectement, à leur disposition ou à leur profit. L'erreur inverse n'est pas gratuite non plus : confirmer à tort un faux positif bloque un paiement légitime, gèle un client légitime et, à grande échelle, produit du de-risking et l'exclusion financière de nationalités ou de régions entières — un préjudice de conduite et d'équité sous surveillance prudentielle, simplement sans responsabilité objective. Le filtrage des sanctions n'étant pas énuméré à l'annexe III du règlement européen sur l'IA, l'institution ne dispose d'aucune filière à haut risque marquée CE et soumise à évaluation de la conformité pour sécuriser ces décisions ; la charge de gouvernance repose sur les propres contrôles sanctions et risque de modèle du déployeur.
What goes wrong
Failure modes specific to this agent
Lever une alerte sur « absence de correspondance SDN » alors que la contrepartie est une entité bloquée par dérivation (angle mort de la règle des 50 %)
L'agent adjudique une alerte (ou une absence de détection) en vérifiant le nom de la contrepartie dans la liste SDN/consolidée publiée, ne trouve aucune entrée exacte et lève l'alerte — libérant le paiement. Or la règle des 50 % de l'OFAC rend bloquée toute entité détenue à 50 % ou plus au total, directement ou indirectement, par une ou plusieurs personnes bloquées, alors même qu'elle n'est pas nommée sur la liste SDN. L'agent raisonne sur la liste avec laquelle il peut effectuer l'appariement ; il ne résout pas, par défaut, la chaîne de propriété effective. Ainsi, un paiement vers une société écran détenue à 60 %, via deux entités intermédiaires, par un oligarque désigné apparaît comme une « absence de correspondance » propre et l'agent le libère — une infraction à responsabilité objective.
Why it's hard to catch: La logique de l'agent est localement correcte (« nom absent de la liste → pas de correspondance »), de sorte que chaque test unitaire qui vérifie le comportement d'appariement avec la liste passe, et la justification qu'il rédige (« contrepartie absente de la liste SDN de l'OFAC et de la liste consolidée de l'UE en date de <version> ») est vraie et irréprochable à l'audit. Le défaut est une absence — un contrôle que l'agent n'a jamais effectué — et non une réponse erronée qu'il aurait donnée. Il n'apparaît que lorsque les données de propriété sont superposées, ce que les jeux de test (un nom unique comparé à une liste) n'incluent presque jamais. La précision globale paraît excellente précisément parce que toute la raison d'être de la règle est que ces entités sont invisibles au filtrage par nom.
Sur-levée des correspondances approximatives qui s'accumule en de-risking d'une cohorte
Pour réduire le taux très élevé de faux positifs du filtrage par nom, l'agent est réglé (ou apprend) à lever agressivement les correspondances approximatives — variantes de translittération, noms de famille courants, correspondances partielles de date de naissance. Prise isolément, chaque levée paraît raisonnable. Mais le même réglage qui lève les variantes bénignes de noms slaves ou arabes augmente aussi le taux auquel les correspondances réelles impliquant ces mêmes conventions de dénomination sont levées, et l'échec miroir (sur-confirmer par prudence) bloque et gèle silencieusement des clients légitimes concentrés dans certaines nationalités ou certains corridors. L'institution finit soit par laisser passer des correspondances réelles dans une cohorte, soit par exclure une cohorte entière de la banque par de-risking — deux défaillances de qualité d'adjudication invisibles dans la vue par alerte.
Why it's hard to catch: La revue par alerte ne trouve rien : chaque levée et chaque blocage est défendable sur ses propres faits. Le préjudice est une propriété distributionnelle — un taux différentiel de levée/confirmation entre cohortes (nationalité, famille de translittération, corridor de paiement) — qui n'apparaît que lorsque les résultats sont agrégés et comparés entre groupes, ce que l'assurance qualité au cas par cas et les tests d'accord d'étiquetage ne font jamais. Comme la métrique dominante (réduction des faux positifs) s'améliore à mesure que l'agent lève davantage, le de-risking et le risque de correspondance réelle laissée passer ressemblent tous deux à des « gains d'efficacité » sur le tableau de bord.
Libération du paiement alors que l'alerte est encore en cours de qualification (la violation du « sans délai »)
L'agent (ou l'orchestration qui l'entoure) traite la qualification comme un simple avis et laisse le paiement poursuivre son règlement, ou lève le blocage dès qu'il se forge une opinion provisoire de type « probable faux positif », avant qu'un humain ou une décision de politique définitive n'existe. La norme ONU/GAFI que les pays transposent exige de geler « sans délai » et de veiller à ce que rien ne soit mis à disposition au profit d'une partie désignée ; un paiement qui se règle pendant la qualification fait échec au gel, même si l'agent conclut plus tard qu'il s'agissait d'une véritable correspondance. Le défaut dangereux ici est « laisser passer sauf ordre d'arrêt » — l'exact inverse de ce qu'exige le droit des sanctions.
Why it's hard to catch: Fonctionnellement, l'agent « marche » : les alertes sont qualifiées, les paiements reçoivent la plupart du temps la bonne issue, et en test le problème de timing se manifeste rarement parce que les paiements de test ne bougent pas réellement. La défaillance est une propriété temporelle/d'ordonnancement — la libération s'exécute avant que la qualification ne soit définitive — qui ne se manifeste qu'avec la concurrence et la latence de la production, et qui produit une piste d'audit d'apparence correcte (l'agent a bien qualifié l'alerte ; simplement, il l'a fait après que l'argent est parti). Les tests fonctionnels standard vérifient la décision, et non l'absence de tout mouvement de valeur pendant que la décision était en attente.
Version de liste périmée : qualifier les alertes au regard de la liste consolidée de la veille
L'agent lève ou confirme une alerte en raisonnant sur un instantané de liste de sanctions d'apparence correcte mais obsolète — une désignation ajoutée le matin même à la liste consolidée de l'UE ou à la liste SDN de l'OFAC ne figure pas dans la version utilisée par l'agent pour le rapprochement, de sorte que l'alerte sur une partie nouvellement désignée est levée et le paiement libéré. La liste consolidée de l'UE « reflète les textes officiellement adoptés et publiés au Journal officiel » et est mise à jour chaque fois que nécessaire ; l'OFAC met à jour la liste SDN en continu. Qualifier au regard d'une version périmée, c'est une levée qui était « correcte » par rapport à la mauvaise référence.
Why it's hard to catch: L'agent produit une justification propre, citant la liste (« absent de la liste consolidée »), et la seule chose erronée est la version de liste intégrée à ce criblage, qu'aucun contrôle qualité par décision n'inspecte — la justification est cohérente en interne et la liste citée est une vraie liste, simplement ancienne. Rejouer la décision contre la liste actuelle le détecterait, mais la plupart des tests rejouent contre une liste de fixture figée, de sorte que l'obsolescence est évacuée du test précisément là où elle frappe en production. La fenêtre de préjudice est étroite (entre une désignation et la synchronisation de liste suivante) et facile à manquer par échantillonnage.
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 |
|---|---|---|---|---|
| Lever une alerte en faux positif (libère un paiement bloqué / finalise une entrée en relation — met des fonds ou des services à disposition) | Un point de contrôle du KLA SDK enveloppe l'appel d'outil clear_hit / release_payment de l'agent (Govern in Place) ; le point de contrôle soumet une Decision Request via POST /v1/decisions.evaluate portant la partie rapprochée, la ou les entrées de liste candidates, le score de correspondance, les conclusions résolues sur les bénéficiaires effectifs et la version de liste AVANT que la libération ne soit écrite. Les déployeurs qui passent par le proxy managé soumettent la même étape au même contrôle via l'Executions API. C'est l'action sur laquelle la porte de contrôle se ferme en cas d'échec (fail-closed) : si la politique ne peut pas être évaluée, la levée n'a pas lieu et le paiement reste bloqué. |
| Un résultat require_approval ouvre une Decision Desk Escalation acheminée par la politique vers un responsable sanctions nommé / un réviseur conformité OFAC-EU (maker-checker : l'agent est le maker, le responsable est le checker). Le responsable voit la partie rapprochée, les entrées de liste candidates et leurs scores, les conclusions sur les bénéficiaires effectifs, la version de liste, la levée proposée par l'agent + sa justification, les codes de motif déclencheurs et un lien vers le Lineage Record, puis approuve la libération, la refuse ou la réachemine vers un MLRO senior / responsable sanctions. La libération ne s'exécute que sur une approbation. |
|
| Confirmer une correspondance avérée (bloque/rejette le paiement et gèle les fonds ou le compte) | Un point de contrôle du KLA SDK encapsule l'appel d'outil confirm_match / freeze de l'agent ; la Decision Request envoyée à POST /v1/decisions.evaluate porte la partie correspondante, l'entrée de liste, le score et l'action de gel proposée avant que le blocage/gel ne soit validé. Le gel étant la direction de sécurité intrinsèque (fail-safe) en droit des sanctions, ce parcours est autorisé à se dérouler rapidement — mais il reste enregistré et n'est réversible que par révision, de sorte qu'un sur-blocage soit observable plutôt que silencieux. |
| Une confirmation/un gel se poursuit et n'ouvre par défaut aucune Escalation bloquante, mais une confirmation à faible score génère un élément de révision routé via Assurance vers un officier sanctions nommé, afin qu'un gel injustifié soit corrigé rapidement. Tout dégel est routé vers un officier nommé en tant qu'Escalation de classe libération. Les taux de sur-confirmation au niveau d'une cohorte remontent sous forme d'Assurance Alerts (voir le contrôle transversal). |
|
| Escalader une correspondance approximative ambiguë vers un responsable sanctions | Un checkpoint du KLA SDK encadre l’appel d’outil escalate_hit de l’agent ; la Decision Request vers POST /v1/decisions.evaluate transporte le score de correspondance, les données manquantes ou de faible qualité (p. ex. champs donneur d’ordre/bénéficiaire de la Travel Rule incomplets) et les entrées de liste candidates avant que l’escalade ne soit routée. Lorsqu’il ne peut pas résoudre une alerte, le comportement sûr par défaut de l’agent est d’escalader plutôt que de lever l’alerte. |
| Un résultat require_approval ouvre une Escalation Decision Desk routée vers un responsable sanctions désigné avec l’ensemble complet du contexte (score, entrées candidates, lacunes de données, version de la liste). Le responsable lève l’alerte, la confirme ou demande des données supplémentaires ; la décision prise et l’identité sont enregistrées. La mise en attente du paiement sous-jacent persiste pendant toute la durée de l’adjudication (« sans délai » / fail-closed à la libération). |
|
| Transversal : garder l'exécution rejouable, surveiller le de-risking et conserver des preuves vérifiables de façon indépendante | Chaque point de contrôle ci-dessus passe par le même pipeline Evidence-by-Default (chaque Decision Request, décision de politique, appel d'outil et verdict humain est capturé automatiquement au moment où il se produit, sans étape de journalisation distincte dans le code de l'agent), et les résultats clear/confirm alimentent la surveillance par cohortes de l'Assurance Center. |
| s.o. pour le substrat de preuve ; les Assurance Alerts sont acheminées vers l'équipe de contrôle sanctions/criminalité financière responsable, avec un lien vers Lineage Explorer pour inspecter les exécutions à l'origine d'une disparité. |
|
Least-privilege execution & data boundaries
- Lever une alerte en faux positif (libère un paiement bloqué / finalise une entrée en relation — met des fonds ou des services à disposition): clear_hit / release_payment est lié dans la Release immuable de l'agent au regard du Tool Catalog ; l'agent ne peut pas s'octroyer lui-même un outil de règlement ou de finalisation d'onboarding avec lequel il n'a pas été mis en Release. Les Data Boundaries maintiennent les données de parties sanctionnées, de paiement et de propriété dans la région/le système approuvé, et épinglent le criblage à un artefact de liste versionné et horodaté, afin que la référence au regard de laquelle l'agent a levé l'alerte soit bien la référence gouvernée.
- Confirmer une correspondance avérée (bloque/rejette le paiement et gèle les fonds ou le compte): confirm_match / freeze est lié uniquement au point de terminaison gouverné de blocage de paiement / gel de compte ; l'agent n'a aucune liaison vers un canal orienté client qui pourrait divulguer le motif du gel (confidentialité des sanctions), ni aucune liaison vers un outil de dégel unilatéral — les dégels passent par le contrôle de libération.
- Escalader une correspondance approximative ambiguë vers un responsable sanctions: escalate_hit est lié en lecture/routage seul ; il ne peut lui-même ni libérer ni geler. L’ensemble de contexte est assemblé à l’intérieur de la Data Boundary afin que les données de correspondance candidate et de partie ne transitent jamais par un système non approuvé.
- Transversal : garder l'exécution rejouable, surveiller le de-risking et conserver des preuves vérifiables de façon indépendante: l'agent s'exécute sous une Release unique et immuable ; toute modification du modèle, des instructions, des paramètres ou des liaisons d'outils produit une nouvelle Release hachée, de sorte que « qu'est-ce qui tournait, contre quelle version de liste, à la date de ce clear » est une question dont la réponse est prouvable.
Mapped to regulation
Regulatory mapping
| Framework | Article / section | Obligation (plain language) | How a KLA runtime control satisfies it | Source |
|---|---|---|---|---|
| OFAC (États-Unis) — règle des 50 % (50 Percent Rule) | Revised Guidance on Entities Owned by Blocked Persons (13 Aug 2014) et FAQ 401 | Une entité détenue à 50 % ou plus au total, directement ou indirectement, par une ou plusieurs personnes bloquées est elle-même bloquée même si elle n'est PAS nommée sur la liste SDN ; « indirectement » couvre la détention par l'intermédiaire d'entités intermédiaires détenues à 50 % ou plus. Un filtrage portant uniquement sur le nom qui renvoie « aucune correspondance sur la liste » n'établit donc pas, à lui seul, qu'une contrepartie peut être dégagée. | Le blocage côté dégagement lorsqu'aucune résolution de bénéficiaire effectif / règle des 50 % n'est jointe (runtime_controls[0], SANC_CLEAR_NO_OWNERSHIP_RESOLUTION) empêche l'agent de libérer un paiement sur la seule base d'un « aucune correspondance SDN » ; le dégagement ne peut pas se poursuivre tant qu'un filtrage de l'actionnariat n'est pas joint et, au-dessus de la bande de score, tant qu'un responsable sanctions nommément désigné ne l'a pas ratifié. | Source |
| IEEPA (États-Unis) — responsabilité civile objective | 50 U.S.C. § 1705(a)-(c) ; 31 CFR Part 501 App. A (sanction civile maximale prévue par la loi) | Une sanction civile « peut être infligée à toute personne qui commet un acte illicite », sans élément de connaissance ni d'intention (l'élément intentionnel — scienter, « willfully » — n'apparaît que dans la sous-section pénale). Le maximum légal, ajusté de l'inflation, est le montant le plus élevé entre $377,700 et le double de la valeur de la transaction sous-jacente, par violation. Une libération erronée au profit d'une partie bloquée constitue une violation consommée, indépendamment de la bonne foi. | Parce que la responsabilité en cas de dégagement erroné est objective, le gate se ferme par défaut (fail-closed) sur l'action de dégagement/libération (runtime_controls[0], runtime_controls[3]) : chaque dégagement dans le périmètre est retenu par défaut et acheminé vers un responsable nommément désigné, de sorte qu'aucune libération de valeur au profit d'une partie potentiellement bloquée ne se produit sur la seule parole de l'agent. L'asymétrie est encodée dans le sens de la politique — la libération est mise en pause, le gel se poursuit. | Source |
| Mesures restrictives de l'UE — Règlement (UE) 269/2014 | Article 2(1)-(2) — gel des avoirs et interdiction de « mise à disposition » | Tous les fonds et ressources économiques appartenant aux personnes inscrites sur la liste, ou détenus ou contrôlés par elles, doivent être gelés, ET aucun fonds ni aucune ressource économique ne peut être mis à disposition, directement ou indirectement, de ces personnes ou à leur profit. « Contrôlés » et « indirectement » rendent l'obligation plus large qu'une simple correspondance littérale de nom. | Le gate de dégagement (runtime_controls[0]) traite un dégagement comme un acte de « mise à disposition » et le retient dans l'attente de la résolution de l'actionnariat et de la validation du responsable ; le chemin de confirmation/gel (runtime_controls[1]) exécute le gel dans le sens de sécurité (fail-safe). Ensemble, ils empêchent l'agent de mettre des fonds à la disposition d'une partie contrôlée ou détenue indirectement tout en laissant les gels légitimes se poursuivre. | Source |
| Mesures restrictives de l'UE — Liste consolidée (DG FISMA) | Liste consolidée des sanctions de l'UE (reflète les textes du Journal officiel, mise à jour chaque fois que nécessaire) | La liste consolidée des sanctions financières de l'UE est la référence de filtrage opérationnelle et reflète les textes officiellement adoptés au Journal officiel ; elle est mise à jour chaque fois que nécessaire. L'adjudication doit filtrer par rapport à la version en vigueur de la liste. | Le blocage pour version de liste périmée (runtime_controls[0], SANC_CLEAR_STALE_LIST_VERSION) refuse toute levée d'alerte dont le filtrage a été exécuté sur une liste plus ancienne que la version publiée en vigueur, et la capture de preuves épingle l'artefact de liste versionné exact au Lineage Record (runtime_controls[0], runtime_controls[3]), de sorte que « sur quelle version de la liste cette levée s'est-elle appuyée » soit prouvable. | Source |
| GAFI R.6 (via la norme de gel des avoirs du Conseil de sécurité de l'ONU) | CSNU « Gel des avoirs : explication des termes » — « geler sans délai » | Les fonds et avoirs des personnes désignées — y compris ceux qu'elles possèdent ou contrôlent directement ou indirectement — doivent être gelés SANS DÉLAI, et rien ne peut être mis à disposition à leur profit. « Sans délai » est un contrôle temporel sur le moment où la valeur peut circuler. | Le réglage par défaut fail-closed à la libération, associé au blocage des voies de libération non approuvées (runtime_controls[0], SANC_RELEASE_PATH_UNAPPROVED) et au maintien persistant de la retenue pendant l'escalade (runtime_controls[2]), garantit que le paiement reste gelé pendant toute la durée de l'adjudication — aucune valeur ne circule tant qu'une alerte est en attente, ce qui satisfait l'exigence « sans délai ». | Source |
| GAFI R.16 (via la Travel Rule du FinCEN) | 31 CFR § 1010.410(e) — « Travel Rule » relative aux fonds (3 000 $ et plus) | Pour les transmissions de fonds de 3 000 $ ou plus, les informations relatives au donneur d'ordre (« transmittor ») et au bénéficiaire/à l'établissement destinataire doivent accompagner le paiement et être conservées. Ce sont les données sur lesquelles l'agent fonde son adjudication ; des données Travel Rule manquantes ou de mauvaise qualité produisent des correspondances approximatives impossibles à résoudre. | La règle d'escalade pour données Travel Rule insuffisantes (runtime_controls[2], SANC_INSUFFICIENT_TRAVEL_RULE_DATA) achemine une alerte dont les données donneur d'ordre-bénéficiaire sont manquantes ou de mauvaise qualité vers un responsable nommément désigné plutôt que de laisser l'agent lever l'alerte sur un enregistrement de paiement lacunaire — une lacune structurelle de données devient ainsi une escalade et non une levée silencieuse. | Source |
| Règlement européen sur l'IA (EU AI Act) — Règlement (UE) 2024/1689 | Champ d'application de l'annexe III (note de classification : le filtrage des sanctions n'y est pas énuméré) | L'annexe III énumère les domaines à haut risque ; le filtrage des sanctions / l'adjudication de gel des avoirs n'y figure pas, de sorte qu'un agent d'adjudication des alertes de sanctions n'est pas automatiquement un système d'IA à haut risque. Le droit des sanctions, à responsabilité objective, est le régime dominant ; l'EU AI Act s'applique en tant que discipline de supervision et de journalisation, et lorsque le déployeur relève par ailleurs de son champ d'application. | Il s'agit d'une cartographie de périmètre et non d'une cartographie de contrôles : elle indique au déployeur que le régime de conformité des systèmes à haut risque n'est pas ici l'obligation structurante, de sorte que les contrôles d'exécution satisfont d'abord au droit des sanctions et à l'asymétrie (blocage par défaut à la libération), en adoptant volontairement les articles du règlement européen sur l'IA relatifs au contrôle humain et à la journalisation ci-dessous. | Source |
| Règlement européen sur l'IA — Règlement (UE) 2024/1689 | Article 14(4)(b),(d),(e) — Contrôle humain | Les personnes chargées du contrôle doivent rester conscientes du biais d'automatisation, pouvoir décider de ne pas utiliser / d'ignorer / de passer outre / d'inverser la sortie du système, et pouvoir intervenir ou interrompre le système pour l'amener dans un état sûr. | La pause require_approval sur un résultat « clear » + le passage outre / réacheminement via le Decision Desk (runtime_controls[0], runtime_controls[2]) constitue l'analogue direct de « ignorer / passer outre / inverser » ; les résultats block (no-ownership, stale-list, unapproved-release-path) correspondent à l'« interruption vers un état sûr » — l'état sûr, en matière de sanctions, étant le paiement retenu. Les codes motifs présentés au responsable sanctions contrent le biais d'automatisation face à un « clear » plausible mais erroné. | Source |
| Règlement européen sur l'IA — Règlement (UE) 2024/1689 | Article 12(1)-(2) — Enregistrement (journalisation automatique) | Les systèmes d'IA à haut risque doivent permettre techniquement l'enregistrement automatique des événements (journaux) tout au long de la durée de vie du système, avec une traçabilité adaptée à la destination prévue. | Evidence-by-Default capture automatiquement chaque Decision Request, décision de politique, appel d'outil et verdict humain (runtime_controls[3]) et scelle chacun d'eux — y compris la version exacte de la liste utilisée pour le criblage — dans un Lineage Record en ajout seul et doté de preuves de Merkle, satisfaisant l'exigence de journalisation automatique et de traçabilité comme propriété intégrée, même là où l'Art. 12 ne s'impose strictement que dans le périmètre à haut risque. | Source |
| Règlement européen sur l'IA — Règlement (UE) 2024/1689 | Article 26(6) — Conservation des journaux par le déployeur | Les déployeurs doivent conserver les journaux générés automatiquement qui se trouvent sous leur contrôle pendant au moins six mois (sauf si un autre droit de l'Union ou un droit national prévoit une durée plus longue). | Le pipeline Evidence-by-Default conserve les Lineage Records générés automatiquement bien au-delà du plancher de six mois (runtime_controls[3]), exportables sous forme de Sealed Evidence Bundle ou de Control Pack de programme sanctions — et les règles de conservation en matière de sanctions et de LCB-FT exigent généralement des durées bien plus longues, que le même registre prend en charge. | Source |
Prove the control held
Audit-evidence checklist
- Pour chaque clear/libération : la Decision Request, la résolution jointe de bénéficiaire effectif / règle des 50 %, le résultat de politique + reasonCodes, ainsi que le verdict approve du responsable sanctions désigné et son horodatage, scellés sur le Lineage Record — prouvant qu'aucune libération de valeur n'est intervenue sur la seule parole de l'agent (responsabilité sans faute au titre de l'IEEPA ; OFAC 50 Percent Rule ; Règl. (UE) 269/2014, art. 2(2)).
- L'artefact exact de liste de sanctions, versionné et horodaté, contre lequel chaque adjudication a été filtrée, épinglé au Lineage Record — de sorte que la question « sur quelle version de la liste OFAC SDN / de la liste consolidée de l'UE cette levée s'est-elle appuyée » soit prouvable, et non reconstruite (liste consolidée de l'UE ; blocage en cas de version obsolète).
- Pour chaque confirmation/gel : la Decision Request, le score de correspondance, l'action de gel et son endpoint de destination gouverné, ainsi que tout signalement de revue pour score faible — établissant que le gel était attribuable et que les gels injustifiés ont été signalés pour une revue rapide (« gel sans délai » ONU/GAFI ; contrôle du de-risking).
- La preuve que le paiement sous-jacent est resté bloqué pendant toute la durée de toute escalade/adjudication (aucune valeur n'a circulé tant qu'un hit était en attente) — le contrôle temporel du « sans délai ».
- Tout dégel/annulation capturé comme une Escalation de classe libération avec l'autorisation de l'officier nommé — car annuler un gel est en soi un acte de « mise à disposition » et hérite du contrôle maker-checker du côté levée.
- Les ventilations de cohorte de l'Assurance Center des taux de levée et des taux de confirmation/gel (par nationalité, famille de translittération, corridor de paiement, région) et toute Assurance Alert déclenchée sur des disparités — preuve permanente que la sur-levée (vraies correspondances échappées) et le sur-blocage (de-risking / exclusion financière) sont activement surveillés.
- Le hash de la Release active (modèle + instructions + paramètres + liaisons d'outils) apposé sur chaque Lineage Record, répondant à la question « quelle configuration exacte a produit cette adjudication ».
- Vérification indépendante : chaque Lineage Record est vérifiable via GET /v1/lineage/{id}/verify en recalculant la racine de Merkle par rapport à la racine publiée du registre ImmuDB — sans aucune confiance requise envers KLA ; exportable sous forme de Sealed Evidence Bundle ou de Control Pack de programme de sanctions, avec des journaux conservés au-delà du plancher de six mois de l'Art. 26(6) de l'EU AI Act.
A concrete intercept
Reference scenario: Un agent tente de lever un paiement « sans hit SDN » vers une société écran — et un officier sanctions nommé retient la libération
- 1
L'agent d'adjudication des hits examine le paiement PAY-55218 (un virement de 480 000 $ vers « Meridian Trade Holdings Ltd ») après que le moteur de filtrage a déclenché un hit approximatif à score faible, vérifie le nom par rapport aux listes OFAC SDN et consolidée de l'UE, ne trouve aucune entrée exacte et s'apprête à lever le hit comme faux positif — ce qui libérerait le paiement bloqué — avec la justification « contrepartie absente de la liste OFAC SDN et de la liste consolidée de l'UE ».
- 2
Avant que la libération ne soit écrite, le checkpoint du KLA SDK qui encapsule clear_hit / release_payment soumet une Decision Request à POST /v1/decisions.evaluate, portant : match_score=0.61, list_version=OFAC-SDN-2026-06-01, beneficial_ownership_resolution=absent, release_path=settlement-prod.
- 3
La politique fait correspondre deux règles : SANC_CLEAR_NO_OWNERSHIP_RESOLUTION (aucun filtrage au titre de la règle des 50 % / de la propriété n'est joint) renvoie block, et SANC_CLEAR_HUMAN_SIGNOFF (un hit de liste de sanctions en cours de levée) renvoie require_approval. Par précédence, le seul block l'emporte — la levée n'a pas lieu ; le paiement reste bloqué ; l'agent reçoit un refus structuré avec codes de motif et remédiation (« joindre la résolution de propriété effective ; router vers l'officier sanctions »).
- 4
La politique route une Escalation du Decision Desk vers l'officier sanctions nommé qui est responsable de ce corridor. L'officier voit la partie, les entrées candidates de la liste, match_score, la résolution de propriété absente, la version de la liste, la levée proposée par l'agent + sa justification, les deux codes de motif et un lien vers le Lineage Record.
- 5
L'officier parcourt la chaîne de propriété et découvre que Meridian est détenue à 60 %, indirectement via deux intermédiaires, par une personne désignée — une entité bloquée par dérivation au titre de la règle des 50 % de l'OFAC qui n'apparaît jamais sur la liste SDN. L'officier refuse la libération et confirme la correspondance ; le gel a lieu. Le droit de passer outre prévu à l'Art. 14(4)(d) et le contrôle maker-checker sont exercés sur la seule action qui engage une responsabilité objective.
- 6
Chaque étape — la Decision Request, les résultats block + require_approval, les codes de motif, l'artefact de version de liste épinglé, l'identité et le verdict de l'officier, ainsi que le hash de la Release active — est scellée dans un Lineage Record en ajout seul avec une preuve de Merkle, vérifiable ultérieurement via GET /v1/lineage/{id}/verify et exportable dans un Control Pack de programme de sanctions sans aucune confiance requise envers KLA.
What most teams get wrong
The non-obvious insight
Pour un agent d'adjudication des correspondances de sanctions, la barrière de politique doit fermer par défaut (fail-closed) sur l'action CLEAR (libération), et non sur le blocage — l'inverse du câblage de la plupart des barrières d'approbation. Les deux erreurs ne sont pas symétriques : lever une correspondance réelle libère de la valeur au profit d'une partie bloquée, ce qui constitue, en vertu de l'IEEPA (50 U.S.C. § 1705), une violation à responsabilité objective sans défense de bonne foi (le maximum ajusté à l'inflation est le plus élevé de 377 700 $ ou du double de la valeur de la transaction, par violation), alors que confirmer à tort un faux positif ne fait que retenir un paiement légitime — un préjudice récupérable et hors responsabilité objective. Le geste dangereux et irréversible est donc la libération, et une « absence de correspondance SDN » ne suffit même pas à la justifier : la règle des 50 % de l'OFAC rend elle-même bloquée toute entité détenue à 50 % ou plus (directement ou indirectement) par des personnes bloquées, alors qu'elle n'apparaît jamais sur la liste. La barrière retient donc par défaut toute levée dans le périmètre et laisse le gel se poursuivre rapidement.
Why it matters: La plupart des équipes conçoivent des barrières d'approbation qui ferment par défaut en refusant l'action — ce qui est sensé lorsque le risque consiste à faire quelque chose. Ici, le risque consiste à libérer, et une conception naïve du type « adjudication consultative, laisser passer le paiement sauf ordre d'arrêt » s'ouvre par défaut (fail-open) précisément sur l'action à responsabilité objective, puis met en échec la norme du « gel sans délai » en laissant la valeur circuler pendant qu'une correspondance est en attente. Pire, le même réglage de sur-levée qui supprime les faux positifs exclut discrètement de la banque, en miroir et par de-risking, des nationalités ou des corridors entiers — un préjudice d'équité invisible correspondance par correspondance et visible seulement dans les taux de levée/confirmation au niveau des cohortes. Fixer correctement le sens du fail-closed (la libération s'arrête, le gel se poursuit, le dégel hérite à nouveau de la barrière de libération) et surveiller la distribution par cohorte constitue l'intégralité de la conception du contrôle, et c'est l'inverse du comportement par défaut.
Une levée de sanctions erronée est singulièrement impitoyable : en vertu de l'IEEPA (50 U.S.C. § 1705), la responsabilité civile s'applique à « toute personne qui commet un acte illicite » sans élément de connaissance ni d'intention — si bien que libérer un paiement retenu au profit d'une partie bloquée constitue une violation consommée même si l'agent a agi en parfaite bonne foi, exposée à un maximum légal égal au plus élevé de 377 700 $ ou du double de la valeur de la transaction par violation. C'est pourquoi c'est l'action de levée d'un agent d'adjudication, et non son action de blocage, qui doit être retenue en fail-closed derrière un humain nommément désigné. (source)
Q&A
Frequently asked questions
Un agent d'adjudication des correspondances de filtrage des sanctions est-il un système d'IA à haut risque au sens de l'AI Act européen ?
Très probablement pas sur le fondement de l'annexe III. Le filtrage des sanctions / l'adjudication des gels d'avoirs ne figure pas à l'annexe III de l'AI Act européen, l'agent n'est donc pas automatiquement un système d'IA à haut risque. Le régime dominant est le droit des sanctions à responsabilité objective — la règle des 50 % de l'OFAC et l'IEEPA (50 U.S.C. § 1705), le gel des avoirs et l'interdiction de « mise à disposition » du règlement (UE) 269/2014, et la norme ONU/GAFI du « gel sans délai ». L'AI Act européen s'applique néanmoins utilement comme discipline de contrôle humain et de journalisation (art. 12, 14, 26) et lorsque le déployeur entre par ailleurs dans son champ d'application. Confirmez la classification au regard de votre propre déploiement et consultez un conseil juridique — « pas à haut risque au titre de l'annexe III » ne signifie pas « faible gouvernance », car la responsabilité en matière de sanctions est objective.
Pourquoi la barrière ferme-t-elle par défaut sur une levée tout en laissant un gel se poursuivre ?
Parce que les deux erreurs ne sont pas symétriques. Lever une correspondance réelle libère de la valeur au profit d'une partie bloquée, ce qui constitue, en vertu de l'IEEPA, une violation à responsabilité objective sans défense de bonne foi, assortie d'un maximum légal égal au plus élevé de 377 700 $ ou du double de la valeur de la transaction par violation — un geste irréversible et coûteux. Confirmer à tort un faux positif ne fait que retenir un paiement légitime, ce qui est récupérable. L'action dangereuse est donc la libération : toute levée dans le périmètre est retenue par défaut et routée vers un responsable sanctions nommément désigné (require_approval), tandis que le gel se poursuit dans le sens de sécurité (fail-safe) et est enregistré. Un dégel hérite à nouveau de la barrière côté levée, car annuler un gel est en soi un acte de « mise à disposition ».
Si la contrepartie ne figure pas sur la liste SDN, pourquoi l'agent ne peut-il pas simplement lever l'alerte ?
Parce qu'« aucune correspondance sur la liste » n'équivaut pas à « levée ». La règle des 50 % (50 Percent Rule) de l'OFAC rend elle-même bloquée toute entité détenue à 50 % ou plus, au total, directement ou indirectement, par une ou plusieurs personnes bloquées, même si elle n'apparaît jamais sur la liste SDN, et « indirectement » couvre la détention par l'intermédiaire d'entités elles-mêmes détenues à 50 % ou plus. Un filtrage sur le seul nom manque structurellement ces entités bloquées par dérivation. Le contrôle de levée bloque donc toute levée à laquelle n'est attachée aucune résolution de propriété effective / de la règle des 50 % (SANC_CLEAR_NO_OWNERSHIP_RESOLUTION) — l'agent doit résoudre la chaîne de propriété et, au-delà de la bande de score, un responsable nommément désigné doit ratifier, avant qu'une libération ne soit exécutée.
Comment la gouvernance de l'agent l'empêche-t-elle de pratiquer le de-risking sur des nationalités ou des corridors entiers ?
La revue alerte par alerte ne voit pas le de-risking — chaque levée et chaque blocage paraît défendable isolément. Le préjudice est distributionnel ; l'Assurance Center de KLA suit donc le taux de levée et le taux de confirmation/gel de l'agent sur des cohortes définies (nationalité, famille de translittération, corridor de paiement, région). Si une cohorte est confirmée/gelée — ou levée — à un taux sensiblement différent, cette disparité devient une Assurance Alert accompagnée de la ventilation par cohorte et d'un lien vers Lineage Explorer. Le sur-blocage (exclusion financière) et la sur-levée (vraies correspondances laissées passer) cessent ainsi d'être une « efficacité » invisible dans un tableau de bord pour devenir des preuves d'équité permanentes et révisables, tandis que le marqueur de revue des confirmations à faible score détecte rapidement les gels individuels injustifiés.
Comment garantir qu'un paiement ne soit pas réglé tant qu'une alerte est encore en cours de qualification ?
Le mécanisme est la valeur par défaut fail-closed sur la libération : une levée/libération qui ne peut pas être entièrement évaluée n'est pas exécutée, et le paiement reste donc retenu. Le blocage du chemin de libération (SANC_RELEASE_PATH_UNAPPROVED) empêche l'agent de pousser de la valeur par un chemin autre que le point de règlement approuvé qui préserve la retenue, et pendant une escalade la retenue persiste pendant toute la durée de la qualification. Chaque Lineage Record porte la preuve que le paiement est resté retenu tout du long — la forme opérationnelle de la norme ONU/GAFI de « gel sans délai », qu'une conception naïve du type « laisser passer sauf ordre d'arrêt » mettrait en échec.
KLA construit-elle, exécute-t-elle ou exploite-t-elle l'agent de filtrage des sanctions ?
Non. Le client construit et possède l'agent de qualification des alertes de sanctions (LangGraph, CrewAI, Agentforce, Microsoft Copilot ou développement interne), et le client est propriétaire du programme de sanctions. KLA est la couche indépendante de gouvernance et d'assurance à l'exécution qui gouverne l'agent là où il s'exécute : elle intercepte chaque action à conséquences avant son exécution, applique des politiques policy-as-code avec les quatre issues (allow / warn / require_approval / block) et une orientation fail-closed côté libération, achemine les levées et dégels à fort enjeu vers des approbateurs humains nommément désignés dans Decision Desk, et scelle une lignée d'exécution signée mise en correspondance avec le droit des sanctions. KLA ne lève jamais une alerte, ne libère jamais un paiement et ne prend jamais la décision — les humains détiennent le veto sur require_approval.
Related blueprints & guides
- Gouverner un agent de triage d'alertes de surveillance des transactions AML
- Gouverner un agent de triage FNOL / réception des sinistres (bulletin IA de la NAIC + AI Act européen)
- Gouverner un agent de réception des événements indésirables et de traitement des cas en pharmacovigilance
- Solution: Financial services & financial crime
- Blueprints de workflows gouvernés pour la criminalité financière (hub)
- Gouverner un agent de triage des alertes de surveillance des transactions LCB-FT
- Exécution conditionnée par la politique (concept central)
- Ajouter une barrière d'approbation humaine (maker-checker)
- Decision Desk (escalades et routage des approbateurs)
- Assurance Center (surveillance des cohortes / du de-risking)
- 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.