Gouverner un agent de triage d'alertes de surveillance des transactions AML
13 min · Updated 2026-06-02
Answer
Vous gouvernez un agent de triage d'alertes AML en interceptant chacune de ses actions à conséquence — clôturer automatiquement une alerte, l'escalader, rédiger un récit de SAR/STR ou écrire une décision de traitement dans le système de référence des dossiers — par un point de contrôle de politique exécuté avant l'action. Les deux issues qui modifient une obligation de déclaration, la clôture automatique et le récit de SAR, sont routées vers un humain L2/L3 nommément désigné dans un contrôle maker-checker, et chaque décision de traitement est scellée dans une traçabilité vérifiable de manière indépendante. Les obligations contraignantes viennent du droit LCB-FT (R.20 du GAFI, art. 69/73 de l'AMLR de l'UE et règles SAR du BSA américain) et de la supervision du risque de modèle (SR 11-7) ; le règlement européen sur l'IA apporte une discipline de contrôle humain et d'enregistrement plutôt qu'une classification automatique à haut risque, car la surveillance des transactions AML ne figure pas à 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 système de surveillance des transactions (TM) génère des alertes lorsque des transactions s'écartent du profil attendu d'un client — la forme opérationnelle de l'obligation de la Recommandation 10(d) du GAFI d'examiner attentivement les transactions sur l'ensemble d'une relation d'affaires. Un analyste L1 trie normalement chaque alerte : la lire, rassembler le contexte et la qualifier. L'agent de triage d'alertes automatise ce travail de L1 et prend quatre actions à conséquence : (1) rejeter / clôturer automatiquement une alerte sans suite ; (2) escalader l'alerte vers une investigation L2/L3 ; (3) rédiger ou recommander un récit de SAR/STR (déclaration de soupçon) ; et (4) écrire la décision de traitement et sa justification dans le système de gestion des dossiers de référence. Deux de ces actions déplacent silencieusement une obligation légale de déclaration : une clôture automatique peut éteindre un soupçon déclarable que la R.20 du GAFI et l'art. 69(1) de l'AMLR de l'UE imposent de déclarer rapidement à la CRF (cellule de renseignement financier), et l'action de récit de SAR amorce le document qu'un régulateur lira plus tard ligne par ligne. Les deux autres — escalader et écrire dans le SoR — fixent la justification de la décision, déclenchent le chronomètre du BSA et sont liées par l'interdiction de divulgation (tipping-off) quant à ce qui peut être révélé.
Stakes
Why it's high-stakes
Une clôture automatique erronée est un faux négatif qui retire entièrement une transaction de la revue humaine — aucun analyste ne la reverra jamais — de sorte qu'un soupçon réel que la R.20 du GAFI et l'art. 69(1) de l'AMLR de l'UE imposent de déclarer rapidement n'est jamais déclaré. Sous le BSA américain, le chronomètre est strict et chiffré : une banque doit déposer un SAR au plus tard 30 jours calendaires après la détection initiale de faits pouvant constituer un fondement de dépôt, et en aucun cas plus de 60 jours ; un agent qui clôture automatiquement une alerte peut déclencher (et dépasser) silencieusement ce délai. Un récit de SAR rédigé par l'agent est un document juridique qu'un régulateur lit littéralement, et une qualification erronée érode précisément le contrôle de vigilance constante de la R.10(d) sur lequel l'institution est examinée. Comme la détection de la criminalité financière ne figure pas à l'annexe III du règlement européen sur l'IA, l'institution ne peut pas s'appuyer sur un pipeline à haut risque marqué CE et évalué en conformité pour rattraper ces défaillances — la charge de gouvernance repose entièrement sur les propres contrôles LCB-FT et de risque de modèle du déployeur.
What goes wrong
Failure modes specific to this agent
Extinction silencieuse du soupçon à la frontière de la clôture automatique
L'agent clôture automatiquement une alerte véritablement positive comme sans suite avec une justification fluide et plausible (« cohérent avec le schéma de paie antérieur »), de sorte que la transaction n'est jamais escaladée et qu'aucun SAR/STR n'est jamais déposé. Contrairement à une escalade manquée qu'une file humaine finirait par faire ressortir, une alerte clôturée automatiquement quitte entièrement la file de travail — aucun élément en attente, aucun dossier vieillissant, rien qu'un superviseur puisse remarquer. L'obligation de déclaration au titre de la R.20 du GAFI / art. 69(1) de l'AMLR est éteinte sans qu'aucun humain n'ait jamais décidé qu'elle devait l'être.
Why it's hard to catch: Les tests ordinaires mesurent l'accord avec les étiquettes historiques des analystes, mais ces étiquettes sont elles-mêmes dominées par des clôtures (les taux de faux positifs des alertes dans le secteur sont extrêmement élevés), de sorte qu'un agent qui clôture agressivement obtient un bon score de précision tout en supprimant systématiquement le rare vrai positif. L'erreur est invisible dans les métriques agrégées, ne produit ni exception ni alerte, et ne ressort que des années plus tard lors d'une revue rétrospective du régulateur — moment où les délais de SAR sont dépassés depuis longtemps. Le préjudice est un non-événement (une déclaration qui n'a jamais eu lieu), qu'aucun journal des actions effectuées ne peut révéler.
Découplage décision–justification (un récit qui ne correspond pas à la décision)
L'agent écrit une décision de traitement (p. ex. escalader) mais génère une justification qui plaide pour l'inverse, ou y joint un raisonnement passe-partout qui ne fait pas réellement référence au comportement à l'origine de l'alerte. Comme les deux champs sont du texte libre écrit par le même modèle en une seule passe, la décision et sa justification peuvent diverger tout en se lisant chacune comme une prose compétente. Les enquêteurs en aval, et plus tard les examinateurs, s'appuient sur la justification pour comprendre pourquoi la décision a été prise ; une justification découplée corrompt la piste d'audit et le point de départ de l'enquêteur L2.
Why it's hard to catch: Chaque champ passe son propre test de vraisemblance — la décision est une valeur d'énumération valide, la justification est grammaticale et pertinente — de sorte que la validation au niveau du champ et les contrôles humains ponctuels de l'un ou l'autre champ pris isolément réussissent. Le défaut réside dans la relation entre deux champs, que ni les tests unitaires ni la comparaison d'étiquettes ne vérifient jamais. SR 11-7 appelle cela exactement ce qu'est le risque de modèle : des conséquences défavorables liées à l'utilisation de la sortie d'un modèle alors qu'elle est incorrecte, et il avertit que de tels défauts exigent une « remise en question effective » (effective challenge) objective et informée plutôt que l'auto-évaluation du modèle.
Fuite de tipping-off via les écritures et les journaux de l'agent
L'agent écrit un récit de décision, une note de dossier visible par le client ou une trace verbeuse qui indique ou implique fortement qu'un SAR/STR est ou sera déposé, ou qu'une analyse BC/FT est en cours — et ce texte atterrit quelque part où un client ou un tiers hors périmètre peut le voir (une note CRM, une file de chargé de relation, un message sortant, un collecteur de journaux trop large). L'art. 73 de l'AMLR de l'UE et le BSA américain (31 U.S.C. § 5318(g)(2) / 31 CFR § 1020.320(e)) en font une divulgation illicite, et l'interdiction s'étend explicitement aux agents.
Why it's hard to catch: Le travail de l'agent est d'écrire de bons récits, de sorte qu'un texte verbeux et informatif est le signal de succès — la défaillance est une propriété de routage/confidentialité concernant la destination de ce texte, non une propriété de qualité du texte lui-même, qui est exactement ce que récompensent les évaluations de qualité de contenu. Les tests standard vérifient que l'agent a produit un récit utile ; ils ne vérifient pas qu'aucun champ de confidentialité de niveau 2 ne franchit jamais un canal lisible par le client. Un seul outil mal lié ou un exportateur de journaux trop large transforme un récit parfait en violation de tipping-off.
Décision sur contexte périmé (agir sur un instantané que le monde a déjà dépassé)
L'agent trie une alerte à partir d'un instantané de contexte — statut sanctions/PPE, SAR antérieurs sur le client, dossiers ouverts liés, état d'actualisation KYC — qui était correct au moment de la récupération mais périmé au moment où la décision est écrite, ou qui omet silencieusement une alerte liée sur le même client. Il clôture alors automatiquement ou sous-escalade parce que, sur sa vue partielle, l'activité paraît cohérente avec le profil. L'obligation de la R.10(d) est d'évaluer la cohérence avec la connaissance que l'institution a du client ; agir sur un instantané partiel contourne discrètement cette obligation.
Why it's hard to catch: Chaque décision individuelle est cohérente en interne et défendable sur les données que l'agent a vues, de sorte que la revue au cas par cas ne trouve rien d'anormal ; le défaut n'apparaît que lorsqu'on corrèle l'historique complet des alertes du client et qu'on remarque qu'une activité liée a été triée isolément. Les jeux de test présentent généralement une seule alerte avec un contexte complet et figé — le mode de défaillance en production est un contexte concurrent, fragmenté et désynchronisé dans le temps, que les jeux de test reproduisent rarement.
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 |
|---|---|---|---|---|
| Clôturer automatiquement / rejeter une alerte sans suite | Un point de contrôle du SDK KLA enveloppe l'appel d'outil close_alert de l'agent (Govern in Place) ; le point de contrôle soumet une Decision Request via POST /v1/decisions.evaluate avec les attributs de l'alerte avant que la clôture ne soit écrite. Les déployeurs passant par le proxy géré contrôlent la même étape via l'Executions API. |
| Une issue require_approval ouvre une Escalation dans Decision Desk, routée par la politique vers un enquêteur L2 criminalité financière nommément désigné (maker-checker : l'agent est le maker, le relecteur L2 est le checker). Le relecteur voit l'alerte, la clôture proposée par l'agent + sa justification, les codes de motif déclencheurs et un lien vers le Lineage Record, puis approuve, refuse ou re-route vers L3. |
|
| Rédiger / recommander un récit de SAR/STR | Un point de contrôle du SDK KLA enveloppe l'appel d'outil draft_sar_narrative ; la Decision Request soumise à POST /v1/decisions.evaluate porte le projet de récit et le contexte du dossier avant que le projet ne soit persisté ou routé vers le dépôt. |
| require_approval ouvre une Escalation dans Decision Desk, routée vers un responsable du dépôt des SAR / délégué MLRO nommément désigné. Le rôle de l'agent est fixé à rédiger/recommander ; le relecteur humain est la seule partie qui peut autoriser la décision de dépôt et déclencher le chronomètre formel. Decision Desk enregistre qui a approuvé et quand. |
|
| Escalader vers une investigation L2/L3 OU écrire la décision de traitement + justification dans le système de référence des dossiers | Un point de contrôle du SDK KLA enveloppe l'appel d'outil write_disposition / escalate_case ; la Decision Request vers POST /v1/decisions.evaluate porte à la fois l'énumération de décision et le texte de justification comme attributs appariés avant que l'écriture ne soit validée dans le SoR. |
| Un block pour tipping-off ou incohérence de justification renvoie un refus structuré à l'agent (aucune écriture dans le SoR) et remonte à l'équipe de contrôle criminalité financière propriétaire ; une rétrogradation require_approval ouvre une Escalation vers un relecteur L2 nommément désigné. Les règles de routage sont déclarées dans la politique afin que l'Escalation arrive par défaut devant l'équipe propriétaire de ce risque. |
|
| Transversal : garder l'exécution gouvernée rejouable et les preuves vérifiables de manière 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 (aucune étape de journalisation séparée dans le code de l'agent). |
| s.o. — ce contrôle est le substrat de preuve dans lequel les verdicts humains ci-dessus sont enregistrés. |
|
Least-privilege execution & data boundaries
- Clôturer automatiquement / rejeter une alerte sans suite: L'outil close_alert est lié dans la Release immuable de l'agent par rapport au Tool Catalog ; l'agent ne peut pas s'octroyer un outil à plus fort impact. Les Data Boundaries maintiennent les données d'alerte et de client dans la région/le système approuvés afin que l'instantané lu par l'agent soit celui qui est gouverné.
- Rédiger / recommander un récit de SAR/STR: draft_sar_narrative est lié en lecture/rédaction seule ; l'agent n'a aucune liaison d'outil capable de soumettre un dépôt à la CRF. Le contexte de rédaction du récit est conservé à l'intérieur de la Data Boundary afin que le projet ne transite jamais par un système non approuvé.
- Escalader vers une investigation L2/L3 OU écrire la décision de traitement + justification dans le système de référence des dossiers: write_disposition est lié uniquement au point de terminaison gouverné du SoR de dossiers ; l'agent n'a aucune liaison vers le CRM orienté client, la messagerie ou les files de chargés de relation. Les Data Boundaries ainsi que la liaison au Tool Catalog sont ce qui empêche mécaniquement le mode de défaillance de tipping-off — l'agent ne peut physiquement pas écrire sur une surface lisible par le client.
- Transversal : garder l'exécution gouvernée rejouable et les preuves vérifiables de manière indépendante: l'agent s'exécute sous une seule Release immuable ; tout changement de modèle, d'instructions, de paramètres ou de liaisons d'outils produit une nouvelle Release hachée, de sorte que « qu'est-ce qui tournait à la date de cette décision » est une question prouvable.
Mapped to regulation
Regulatory mapping
| Framework | Article / section | Obligation (plain language) | How a KLA runtime control satisfies it | Source |
|---|---|---|---|---|
| Recommandations du GAFI | Recommandation 20 — Déclaration des opérations suspectes | Si une institution soupçonne ou a des motifs raisonnables de soupçonner que des fonds sont le produit d'une activité criminelle ou sont liés au financement du terrorisme, elle doit, en vertu de la loi, faire rapidement une déclaration à la CRF. Un agent de triage d'alertes influence ce déclencheur chaque fois qu'il rejette, escalade ou recommande un dépôt. | Le point de contrôle de clôture automatique (runtime_controls[0]) empêche l'agent d'éteindre silencieusement un soupçon déclarable : les clôtures à risque élevé et à dossier lié sont bloquées ou routées vers un humain L2 nommément désigné avant que l'alerte ne quitte la file, de sorte que la décision de ne pas déclarer est toujours prise (ou ratifiée) par une personne. | Source |
| Recommandations du GAFI | Recommandation 10(d) — Vigilance constante : examen attentif des transactions | Les institutions doivent exercer un examen attentif et continu des transactions sur l'ensemble d'une relation d'affaires afin de s'assurer qu'elles sont cohérentes avec la connaissance qu'a l'institution du client, de son activité, de son profil de risque et de l'origine des fonds. La surveillance des transactions opérationnalise cette obligation. | Le block pour dossier lié dans le point de contrôle de clôture automatique et le block de cohérence décision–justification (runtime_controls[0], runtime_controls[2]) empêchent l'agent de qualifier une alerte sur un instantané partiel et isolé — préservant le test de « cohérence avec la connaissance qu'a l'institution du client » face au mode de défaillance de contexte périmé. | Source |
| AMLR de l'UE — Règlement (UE) 2024/1624 | Article 69(1) — Déclaration des soupçons | Les entités assujetties doivent déclarer rapidement à la CRF, de leur propre initiative, lorsqu'elles savent/soupçonnent/ont des motifs raisonnables de soupçonner que des fonds ou des activités (quel que soit le montant) sont le produit d'une activité criminelle ou liés au financement du terrorisme. Toutes les transactions suspectes — y compris les tentatives et les soupçons nés de l'impossibilité de mener à bien la vigilance à l'égard de la clientèle — doivent être déclarées. | Les règles require_approval/block de clôture automatique (runtime_controls[0]) garantissent qu'aucun soupçon dans le périmètre n'est clôturé sans signature humaine, et la règle de signature humaine du récit de SAR (runtime_controls[1]) maintient la décision de déclarer ou non comme une décision humaine — de sorte que l'obligation « de leur propre initiative » de l'art. 69(1) repose sur une personne responsable et non sur l'agent. | Source |
| AMLR de l'UE — Règlement (UE) 2024/1624 | Article 73 — Interdiction de divulgation (tipping-off) | Les entités assujetties et leur personnel — y compris explicitement les agents — ne doivent pas révéler au client ni à des tiers qu'une activité est en cours d'évaluation au titre de l'art. 69, que des informations ont été/seront transmises à la CRF, ou qu'une analyse BC/FT est en cours. | Le block de tipping-off associé à la liaison d'outil à moindre privilège (runtime_controls[2]) empêche mécaniquement l'agent d'écrire du contenu de confidentialité de niveau 2 vers toute destination lisible par le client ou hors périmètre : l'écriture est bloquée, et l'agent n'a de toute façon aucune liaison dans le Tool Catalog vers une surface orientée client. | Source |
| BSA américain / FinCEN — 31 CFR Chapter X | 31 CFR § 1020.320(b)(3) — Délai de dépôt du SAR | Une banque doit déposer un SAR au plus tard 30 jours calendaires après la détection initiale de faits pouvant constituer un fondement de dépôt ; le délai peut être prolongé pour identifier un suspect, mais en aucun cas au-delà de 60 jours calendaires après la détection initiale. | Capturer la décision de clôture automatique avec un horodatage scellé sur le Lineage Record (runtime_controls[0], runtime_controls[3]) fait de la « date de détection initiale » et de la décision qui a déclenché/arrêté le chronomètre un enregistrement prouvable et interrogeable — de sorte que l'institution peut démontrer que le délai de 30/60 jours a été respecté plutôt que silencieusement dépassé par une clôture de l'agent. | Source |
| BSA américain / FinCEN — 31 CFR Chapter X et 31 U.S.C. § 5318 | 31 CFR § 1020.320(e) et 31 U.S.C. § 5318(g)(2)(A)(i) — Confidentialité du SAR / notification interdite | Aucune banque ni aucun de ses agents ne peut divulguer un SAR ou toute information qui en révélerait l'existence, et une institution (y compris ses agents et sous-traitants) ne peut notifier à aucune personne impliquée dans une transaction que celle-ci a été déclarée. | Le même block de tipping-off et la même liaison à moindre privilège (runtime_controls[2]) appliquent la barrière de confidentialité américaine : l'agent — un « agent » au sens du § 5318(g)(2) — est empêché d'émettre du contenu révélant un SAR vers toute destination non approuvée, et ses écritures sont confinées par les Data Boundaries au SoR de dossiers gouverné. | Source |
| Fed/OCC SR 11-7 (guide interagences sur le risque de modèle) | SR 11-7 / OCC 2011-12 — définition du modèle, risque de modèle, « effective challenge » | Un modèle qui transforme des entrées en estimations crée invariablement un risque de modèle ; le contrôle directeur est la « remise en question effective » (effective challenge) — une analyse critique par des parties objectives et informées capables d'identifier les limites et de produire des changements. Un agent LLM de triage d'alertes est lui-même un modèle qui doit être validé, remis en question et surveillé. | L'Escalation maker-checker dans Decision Desk (runtime_controls[0], runtime_controls[1]) institutionnalise l'« effective challenge » sur les décisions aux enjeux les plus élevés — un humain compétent et nommément désigné examine indépendamment la décision de l'agent — et le block de cohérence décision–justification (runtime_controls[2]) détecte la sortie incorrecte mais fluide du modèle que l'auto-évaluation ne révélerait jamais. | Source |
| Règlement européen sur l'IA — Règlement (UE) 2024/1689 | Annexe III — périmètre de la classification à haut risque (et l'exception de détection de fraude pour l'évaluation de crédit) | L'annexe III énumère huit domaines à haut risque ; l'entrée relative aux services financiers couvre l'évaluation de la solvabilité/notation de crédit « à l'exception des systèmes d'IA utilisés à des fins de détection de fraude financière ». La surveillance des transactions AML / la détection de la criminalité financière n'est énumérée nulle part dans l'annexe III, de sorte qu'elle n'est pas automatiquement un système d'IA à haut risque. | Il s'agit d'une correspondance de périmètre et non d'une correspondance de contrôle : elle indique au déployeur que le régime de conformité à haut risque n'est pas l'obligation porteuse ici. Les contrôles d'exécution sont donc conçus pour satisfaire d'abord les régimes LCB-FT et de risque de modèle, tout en adoptant volontairement les disciplines de contrôle humain et de journalisation du règlement européen sur l'IA (ci-dessous) comme bonne pratique et pour le cas où un déployeur serait par ailleurs dans le périmètre. | 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 (dépendance excessive à la sortie du système), être en mesure de décider de ne pas utiliser / d'ignorer / d'outrepasser / d'inverser la sortie, et être en mesure d'interrompre le système via un « arrêt » vers un état sûr. | La pause require_approval + l'outrepassement et le re-routage dans Decision Desk (runtime_controls[0], runtime_controls[1]) sont l'analogue mécanique direct d'ignorer/outrepasser/inverser ; block (runtime_controls[2]) est l'« arrêt vers un état sûr » — l'action de l'agent est stoppée par un refus structuré. Le relecteur voit les codes de motif précisément pour contrer le biais d'automatisation plutôt que d'entériner l'agent sans examen. | Source |
| Règlement européen sur l'IA — Règlement (UE) 2024/1689 | Article 26(2) et 26(6) — Obligations des déployeurs | Les déployeurs doivent confier le contrôle humain à des personnes physiques disposant des compétences, de la formation et de l'autorité nécessaires, et conserver sous leur contrôle les journaux générés automatiquement pendant au moins six mois. | Decision Desk route les Escalations vers des relecteurs L2/L3/délégués MLRO compétents et nommément désignés (runtime_controls[0–2]) — satisfaisant l'exigence de compétence et d'autorité — et 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]). | Source |
| Règlement européen sur l'IA — Règlement (UE) 2024/1689 | Article 12(1) — 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 afin d'assurer 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 dans un Lineage Record en ajout seul avec preuve de Merkle — satisfaisant l'exigence de journalisation automatique et de traçabilité comme propriété intégrée plutôt qu'ajoutée après coup, même si l'art. 12 ne s'impose strictement que lorsque le système est dans le périmètre à haut risque. | Source |
Prove the control held
Audit-evidence checklist
- Pour chaque clôture automatique : la Decision Request, l'issue de la politique + reasonCodes, et — en cas de risque élevé — le verdict et l'horodatage de l'approbateur L2 nommément désigné, scellés sur le Lineage Record (prouve qu'aucun soupçon dans le périmètre n'a été clôturé sans signature humaine ; R.20 du GAFI / art. 69 de l'AMLR).
- Pour chaque récit de SAR/STR : le texte exact du projet de l'agent, l'enregistrement require_approval et l'autorisation du responsable du dépôt des SAR nommément désigné — établissant la paternité humaine de la décision de dépôt et le fait que l'agent n'a fait que rédiger (effective challenge de SR 11-7 ; « de leur propre initiative » de l'art. 69(1) de l'AMLR).
- Pour chaque écriture de décision de traitement : la décision + justification appariées telles que soumises, ainsi que l'outil de destination et sa liaison au Tool Catalog prouvant que l'écriture n'a atteint que le SoR de dossiers approuvé et jamais une surface lisible par le client (tipping-off : art. 73 de l'AMLR / 31 CFR § 1020.320(e) / 31 U.S.C. § 5318(g)(2)).
- Un horodatage de détection initiale scellé sur chaque décision d'alerte afin que le chronomètre SAR de 30/60 jours du BSA soit prouvable plutôt que reconstitué (31 CFR § 1020.320(b)(3)).
- Le hash de la Release active (modèle + instructions + paramètres + liaisons d'outils) apposé sur chaque Lineage Record, répondant à « quelle configuration exacte a produit cette décision ».
- Vérification indépendante : chaque Lineage Record vérifiable via GET /v1/lineage/{id}/verify en recalculant la racine de Merkle par rapport à la racine publiée du registre ImmuDB — aucune confiance en KLA requise.
- Conservation des journaux générés automatiquement pendant au moins le minimum de six mois (art. 26(6) du règlement européen sur l'IA), exportables sous forme de Sealed Evidence Bundle ou de Control Pack annexe IV du règlement européen sur l'IA pour un examinateur.
- Un dossier périodique d'« effective challenge » : un échantillon d'alertes clôturées automatiquement réexaminé par une partie indépendante, avec capture de ses verdicts — preuve que la surveillance du risque de modèle exigée par SR 11-7 a réellement eu lieu.
A concrete intercept
Reference scenario: Un agent tente de clôturer automatiquement une alerte sur une PPE avec une justification fluide — et un enquêteur L2 nommément désigné obtient le veto
- 1
L'agent de triage d'alertes lit l'alerte ALRT-77214 (virements rapides à montants ronds entrant et sortant d'un compte professionnel) et décide de la clôturer automatiquement sans suite, en générant la justification « schéma cohérent avec les paiements fournisseurs antérieurs ».
- 2
Avant que la clôture ne soit écrite, le point de contrôle du SDK KLA enveloppant close_alert soumet une Decision Request à POST /v1/decisions.evaluate, portant les attributs : customer_pep=true, jurisdiction_risk=high, linked_open_alerts=1.
- 3
La politique fait correspondre deux règles : AML_AUTOCLOSE_ELEVATED_RISK (PPE + juridiction à haut risque) renvoie require_approval, et AML_AUTOCLOSE_LINKED_CASE_OPEN (une alerte ouverte liée existe) renvoie block. Par précédence, le seul block l'emporte — la clôture n'est pas exécutée ; l'agent reçoit un refus structuré avec codes de motif et remédiation.
- 4
Comme un dossier lié est ouvert, la politique route également une Escalation dans Decision Desk vers l'enquêteur L2 criminalité financière nommément désigné qui est propriétaire du dossier de ce client. Le relecteur voit l'alerte, la clôture proposée par l'agent et sa justification, les deux codes de motif et un lien vers le Lineage Record.
- 5
L'enquêteur ignore la clôture de l'agent (l'outrepassement de l'art. 14(4)(d)), relie les deux alertes et escalade vers L3 — le contrôle maker-checker et l'« effective challenge » de SR 11-7 en action.
- 6
Chaque étape — la Decision Request, les issues block + require_approval, les codes de motif, l'identité et le verdict du relecteur, et 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 annexe IV du règlement européen sur l'IA sans aucune confiance en KLA requise.
What most teams get wrong
The non-obvious insight
Un agent de surveillance des transactions AML n'est presque certainement PAS un « système d'IA à haut risque » au sens de l'annexe III du règlement européen sur l'IA — et c'est précisément pour cela qu'il a besoin d'une gouvernance plus délibérée, et non moindre. L'entrée services financiers de l'annexe III couvre la notation de crédit mais exclut « les systèmes d'IA utilisés à des fins de détection de fraude financière », et la détection de la criminalité financière n'apparaît nulle part ailleurs dans la liste. Le déployeur n'obtient donc ni marquage CE, ni évaluation de la conformité du fournisseur, ni documentation technique de l'annexe IV qui lui serait remise — aucun des échafaudages du haut risque ne vient rattraper ces décisions. La force contraignante vient au contraire du droit LCB-FT (R.20 du GAFI, art. 69/73 de l'AMLR, règles SAR du BSA) et de la supervision du risque de modèle SR 11-7, où l'agent est sans ambiguïté un « modèle » soumis à validation et à « effective challenge ».
Why it matters: Les équipes raisonnent couramment à l'envers : « le règlement européen sur l'IA est le régime strict, donc si notre agent n'est pas à haut risque, nous pouvons le gouverner légèrement ». Pour le triage AML, cette inférence est exactement inversée. L'absence d'enveloppe de conformité de l'annexe III signifie que les propres contrôles d'exécution du déployeur — signature humaine sur la décision de déclarer ou non, confinement du tipping-off, preuve scellée du chronomètre — sont la seule chose qui sépare une alerte clôturée automatiquement d'une revue rétrospective réglementaire des années plus tard. Le règlement européen sur l'IA est ici mieux utilisé volontairement comme discipline de contrôle humain et de journalisation (art. 12/14/26), tandis que les obligations porteuses sont celles de la LCB-FT et du risque de modèle. Mal classer le régime conduit tout droit à sous-contrôler la seule décision — la clôture automatique silencieuse — qui n'a aucun humain dans la boucle et aucune exception pour la rattraper.
Le BSA américain donne à une banque un plafond strict de 60 jours calendaires à compter de la détection initiale pour déposer un SAR (30 jours, prolongeables de 30 pour identifier un suspect) — ce qui signifie qu'un agent de triage d'alertes qui clôture automatiquement une alerte véritablement positive ne commet pas simplement une erreur : il déclenche puis dépasse silencieusement un chronomètre légal que personne ne surveille, car une alerte clôturée quitte la file de travail et ne génère aucune exception de vieillissement. (source)
Q&A
Frequently asked questions
Un agent de surveillance des transactions AML est-il un système d'IA à haut risque au sens du règlement européen sur l'IA ?
Très probablement non. L'annexe III du règlement européen sur l'IA énumère huit domaines à haut risque ; son entrée services financiers couvre l'évaluation de la solvabilité et la notation de crédit mais exclut expressément « les systèmes d'IA utilisés à des fins de détection de fraude financière », et la détection AML/criminalité financière n'apparaît nulle part ailleurs dans l'annexe III. Un agent de triage AML n'est donc généralement pas automatiquement à haut risque. Les obligations de gouvernance découlent principalement du droit LCB-FT (R.20 du GAFI, art. 69/73 de l'AMLR de l'UE, règles SAR du BSA américain) et de la supervision du risque de modèle (SR 11-7) ; le règlement européen sur l'IA s'applique comme bonne pratique de contrôle humain et d'enregistrement (art. 12/14/26) et lorsque le déployeur est par ailleurs dans le périmètre. Confirmez la classification au regard de votre propre déploiement et consultez un conseil juridique — ne supposez pas que « pas à haut risque » signifie « gouvernance légère ».
Quelles décisions de l'agent doivent être signées par un humain, et lesquelles peuvent s'exécuter automatiquement ?
Les deux décisions qui déplacent une obligation légale de déclaration reçoivent une porte humaine. Un récit de SAR/STR est toujours en require_approval — l'agent rédige, un responsable du dépôt des SAR nommément désigné autorise la décision de dépôt. Une clôture automatique est placée en require_approval (ou bloquée) chaque fois que l'alerte porte des attributs de risque élevé (PPE, juridiction à haut risque, SAR antérieur) ou qu'un dossier lié est ouvert, avec routage vers un enquêteur L2 nommément désigné. Les clôtures de routine à faible risque et les écritures ordinaires de décision de traitement peuvent se poursuivre en allow ou warn, mais chacune enregistre tout de même un code de motif sur son Lineage Record afin que la décision soit reconstituable.
Comment la gouvernance de l'agent empêche-t-elle une violation de tipping-off ?
Deux couches. Premièrement, un contrôle de contenu bloque tout récit de décision ou note de dossier qui indique ou implique qu'un SAR est en cours de dépôt (ou qu'une analyse BC/FT est en cours) lorsque sa destination est un champ lisible par le client ou hors périmètre (reasonCode AML_TIPPING_OFF_RISK). Deuxièmement — et plus fondamentalement — la liaison à moindre privilège dans le Tool Catalog associée aux Data Boundaries signifie que l'agent ne dispose d'aucun outil capable d'écrire vers un CRM orienté client, un message ou une file de chargé de relation. L'art. 73 de l'AMLR de l'UE et le BSA américain (31 U.S.C. § 5318(g)(2), 31 CFR § 1020.320(e)) étendent explicitement l'interdiction de tipping-off aux agents, de sorte que confiner les écritures de l'agent au SoR de dossiers gouverné est le mécanisme déterminant.
Comment prouver à un examinateur que l'agent n'a pas silencieusement manqué un dépôt ?
Chaque décision de traitement — y compris chaque clôture automatique — est capturée automatiquement sous forme de Lineage Record en ajout seul portant la Decision Request, l'issue de la politique et les codes de motif, tout verdict humain, le hash de la Release active et un horodatage de détection initiale scellé. Comme les enregistrements sont ancrés à un registre ImmuDB avec preuve de Merkle, un examinateur peut les vérifier via GET /v1/lineage/{id}/verify sans faire confiance à KLA, et vous pouvez exporter la tranche pertinente sous forme de Sealed Evidence Bundle ou de Control Pack annexe IV du règlement européen sur l'IA. Les alertes clôturées sont elles aussi des preuves, et non un angle mort : vous pouvez démontrer lesquelles ont été clôturées comme autorisées par la politique et lesquelles ont été ratifiées par un humain nommément désigné.
La précision de l'agent par rapport aux étiquettes historiques des analystes est élevée — n'est-ce pas une validation suffisante ?
Non, et s'y fier est le piège classique. Les étiquettes historiques sont dominées par des clôtures parce que les taux de faux positifs des alertes sont très élevés, de sorte qu'un agent qui clôture agressivement obtient un bon score d'accord avec les étiquettes tout en supprimant systématiquement le rare vrai positif — le cas précis qui doit être déclaré. SR 11-7 le souligne : le risque de modèle est constitué des conséquences défavorables d'une sortie incorrecte mais utilisée, et le contrôle prescrit est l'« effective challenge » par des parties objectives et informées, et non la précision auto-déclarée du modèle. La gouvernance ajoute cette remise en question de façon structurelle : revue maker-checker sur les clôtures à enjeux élevés et réexamen périodique indépendant des alertes clôturées automatiquement, tous deux capturés comme preuves que la surveillance a réellement eu lieu.
KLA construit-il ou exécute-t-il l'agent AML ?
Non. Le client construit et possède l'agent de triage AML (LangGraph, CrewAI, Agentforce, Microsoft Copilot ou développé en interne). KLA est la couche indépendante de gouvernance d'exécution et d'assurance qui gouverne l'agent en place : elle intercepte chaque action à conséquence avant son exécution, applique la politique sous forme de code avec les quatre issues (allow / warn / require_approval / block), route les décisions à enjeux élevés vers des approbateurs humains nommément désignés dans Decision Desk, et scelle un traçabilité d'exécution signé mis en correspondance avec la réglementation. KLA ne dépose jamais de SAR, ne clôture jamais d'alerte et ne prend jamais la décision — les humains détiennent le veto sur require_approval, et la politique détient l'autorité sur l'exécution ou non d'une action.
Related blueprints & guides
- Gouverner un agent d'adjudication des alertes de filtrage des sanctions
- 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 d'adjudication des correspondances de filtrage des sanctions AML
- Exécution conditionnée par la politique (concept central)
- Ajouter une porte d'approbation humaine (maker-checker)
- Decision Desk (Escalations et routage des approbateurs)
- Evidence Room (Sealed Evidence Bundle / Control Pack)
Primary sources
- FATF Recommendations — Recommendation 20: Reporting of suspicious transactions: FATF (via ICNL library mirror of the FATF Recommendations)
- Regulation (EU) 2024/1624 (AMLR) — Article 69: Reporting of suspicions: EUR-Lex (Official Journal text, via amlr.eu consolidated reproduction)
- Regulation (EU) 2024/1624 (AMLR) — Article 73: Prohibition of disclosure (tipping-off): EUR-Lex (Official Journal text, via amlr.eu consolidated reproduction)
- 31 CFR § 1020.320(b)(3) — Reports by banks of suspicious transactions: SAR filing deadline: US e-CFR / Treasury–FinCEN (via Cornell Legal Information Institute)
- 31 U.S.C. § 5318(g)(2)(A) — Notification prohibited (statutory tipping-off bar): US House Office of the Law Revision Counsel (US Code, via govinfo.gov)
- SR 11-7 / OCC 2011-12 — Supervisory Guidance on Model Risk Management (definition of model, model risk, effective challenge): Board of Governors of the Federal Reserve & OCC (interagency guidance, reissued by FDIC as FIL-22-2017)
- Regulation (EU) 2024/1689 (EU AI Act) — Article 14: Human oversight: artificialintelligenceact.eu (mirror of Regulation (EU) 2024/1689)
- Regulation (EU) 2024/1689 (EU AI Act) — Article 26: Obligations of deployers of high-risk AI systems: artificialintelligenceact.eu (mirror of Regulation (EU) 2024/1689)
- Regulation (EU) 2024/1689 (EU AI Act) — Article 12: Record-keeping (automatic logging): artificialintelligenceact.eu (mirror of Regulation (EU) 2024/1689)
- Regulation (EU) 2024/1689 (EU AI Act) — Annex III: High-risk AI systems enumeration (and credit-scoring fraud-detection exception): artificialintelligenceact.eu (mirror of Regulation (EU) 2024/1689)
- KLA Control Plane Docs — Policy-Gated Execution: KLA Digital
- KLA Control Plane Docs — Decision Desk: KLA Digital
- KLA Control Plane Docs — Evidence-by-Default: KLA Digital
- KLA Control Plane Docs — Evidence Room (Sealed Evidence Bundle / Control Pack): KLA Digital
- KLA Control Plane Docs — Agents & Registry (Releases, Tool Catalog, least-privilege): KLA Digital
- KLA Control Plane Docs — Add a Human Approval Gate (SDK checkpoint / maker-checker): KLA Digital
- KLA Control Plane Docs — Govern an Agent End-to-End: KLA Digital
- KLA Control Plane Docs — API Reference (decisions.evaluate, lineage verify): KLA Digital
Govern this Process without re-platforming the agent
KLA wraps the agent you already run, gates each high-stakes action, routes the hard calls to a named human, and seals independently verifiable evidence mapped to regulation.