Il s'agit de la carte de référence pour gouverner un agent AML ou IA de paiement. Si vous êtes responsable de la criminalité financière dans une banque, une société de paiement ou une fintech, vous n'avez pas besoin d'un autre essai pour savoir si l'IA agentique est « à haut risque ». Vous devez savoir, action par action, exactement où se situe la porte de contrôle, qui signe et quelles preuves doivent être scellées lorsque l'agent agit. C'est ce qu'est cette page : une seule Carte de contrôle et de preuves qui prend chaque chose qu'un agent AML fait réellement (triage des alertes, autorisation des sanctions, rédaction SAR/STR, contrôle des paiements, intégration et KYC, surveillance des transactions) et la mappe à (a) la porte de contrôle qui doit s'exécuter au moment de l'action, (b) la personne responsable qui signe la signature, et (c) l'enregistrement scellé et inviolable qui prouve que cela s'est produit, avec des références croisées à DORA, l'AMLR et les Principes de Wolfsberg.\n\nLa thèse derrière la carte est simple et elle ne change pas de ligne en ligne : gouverné par l'exécution, pas par la paperasse. À la vitesse de la machine, un contrôle qui se trouve dans un PDF de politique n'est pas un contrôle. La porte doit passer à l'intérieur du chemin d'exécution de l'agent, l'humain responsable doit être une personne nommée dans une file d'attente d'approbation et non une signature recueillie le trimestre suivant, et les preuves doivent être scellées au moment de la décision, et non reconstruites le matin où un examinateur le demande. Pour connaître l’argumentation réglementaire complète derrière cette carte, lisez l’article complémentaire, Governing AML et payment agents. Cette page est la plaque tournante : ajoutez-la à vos favoris et utilisez les outils par action liés tout au long pour opérationnaliser chaque ligne.
Comment lire la carte : porte, humain, preuve
Trois colonnes dans la carte font le vrai travail, et chacune correspond à une primitive d'exécution concrète. Obtenez ces trois définitions correctement et le reste de la page est une table de recherche.
La porte de contrôle est un point de contrôle à l'intérieur du chemin d'exécution de l'agent, exprimé sous forme de politique en tant que code, qui décide de ce que l'agent peut faire au moment où il essaie d'agir. Il se résout en l'une des quatre décisions, par ordre de priorité : autoriser (l'action se déroule de manière autonome), avertir (elle se poursuit mais est marquée pour un examen ultérieur), require_approval (elle s'arrête et se dirige vers un humain nommé avant que quoi que ce soit ne s'exécute) et bloquer (elle est complètement arrêtée). Toute la discipline de gouvernance d'un agent consiste à choisir la bonne décision pour chaque action et chaque tranche de risque : une alerte de routine de faible valeur peut être autoriser, une sanction au-dessus d'un seuil de confiance doit être require_approval ou bloquer. Ce sont les mêmes quatre décisions que vous prenez dans une porte Policy Builder.
L'humain responsable n'est pas une abstraction. Lorsqu'une porte aboutit à require_approval, l'action entre dans un examen par deux personnes, créateur-vérificateur : l'agent (ou un analyste de première ligne) est le créateur, et un humain nommé et dûment autorisé est le vérificateur qui doit approuver avant l'exécution. Il s'agit d'une fonction Decision Desk : une personne réelle dans une vraie file d'attente, avec le pouvoir d'approuver, de rejeter ou de renvoyer, et dont l'identité est capturée. Wolfsberg est explicite sur le fait que cette responsabilité incombe à l'entreprise, que le système soit construit en interne ou acheté auprès d'un fournisseur ; il n'est pas transféré au fournisseur de modèles.
Les preuves scellées sont le dossier produit au moment de la décision et verrouillé afin qu'il ne puisse pas être modifié en silence par la suite. Il capture les entrées vues par l'agent, la politique appliquée, la décision prise et l'humain qui l'a approuvée, comme une unité contemporaine et inviolable : un enregistrement Evidence Room. C'est la propriété qu'un tableau de bord et un fichier journal n'ont pas, et c'est précisément ce qu'une CRF en vertu de l'article AMLR 69, un superviseur DORA ou un examinateur AMLA doit voir.
La carte des contrôles et des preuves
C'est le centre de la page. Chaque ligne correspond à une chose qu'un agent AML ou de paiement fait. Lisez ce qui se passe si le système n'est pas géré, la porte de contrôle qui doit se déclencher (mappée sur allow / warn / require_approval / block), l'humain responsable qui signe au Decision Desk, l'enregistrement scellé Evidence Room et la réglementation qui ancre l'obligation.
Aucune ligne ne repose sur une métrique fabriquée ou un cas inventé. Chaque ancre réglementaire est un véritable instrument public : la AMLR (Règlement (UE) 2024/1624), AMLD6 (Directive (UE) 2024/1640), DORA (Règlement (UE) 2022/2554), les Principes de Wolfsberg et, le cas échéant, la Loi de l'UE sur l'IA (Règlement (UE) 2024/1689, article 14 on surveillance humaine).
| Action de l'agent | Risque en cas de non-gouvernance | Porte de contrôle (autoriser/avertir/exiger_approbation/bloquer) | Humain responsable (Decision Desk) | Preuve scellée (Evidence Room) | Ancre Reg |
|---|---|---|---|---|---|
| Triage des alertes de surveillance des transactions/fermeture automatique | La fausse fermeture automatique d'une véritable alerte enterre toute activité suspecte ; un modèle non révisé définit silencieusement l'appétit pour le risque de l'entreprise | autoriser des types d'alertes à faible risque définis dans le seuil ; avertir pour les scores limites ; require_approval / block pour les typologies de valeur élevée ou à haut risque, l'agent ne peut pas fermer automatiquement | Enquêteur de première ligne en tant que vérificateur des alertes escaladées ; la politique de clôture automatique elle-même détenue par le MLRO / Head de Financial Crime | Entrées et raisonnements capturés pour chaque clôture automatique, ainsi que la version de la politique appliquée : le processus auditable rendu réel et reconstructible sur demande | AMLR Art. 69 (reconstruction de la CRF, 5 working jours) ; DORAArt. 3(22) résilience des fonctions critiques |
| Sanctions/autorisation de coup sûr PEP | Une fausse effacement automatique d'un vrai coup est une violation des sanctions ; un faux blocage automatique gèle un paiement légitime : ni l'un ni l'autre n'est réversible par un tableau de bord du lendemain matin | autoriser uniquement en dessous d'un seuil de confiance étroitement défini ; require_approval au-dessus ; bloquer les correspondances exactes de la liste désignée en attente d'examen | Nommé l'examinateur des sanctions comme vérificateur avant l'exécution de toute effacement ou blocage | Chaque décision d'effacement/blocage est scellée avec l'identité de l'examinateur, le seuil appliqué et la preuve de correspondance sous-jacente | Sanctions AMLR/obligations CDD ; Responsabilité de l'entreprise Wolfsberg ; Loi de l’UE sur l’IA Art. 14 oversight (selon le champ d'application) |
| Rédaction et dépôt SAR / STR | Un récit déposé de manière autonome devient un document juridique sans qu'aucun être humain ne soit responsable de son contenu ou de son exactitude | Rédiger de manière autonome (autoriser) ; *le dépôt est toujours require_approval*** : une porte obligatoire de fabricant-vérificateur avec approbation humaine | MLRO ou un agent nommé délégué en tant que vérificateur ; l'agent (ou l'analyste) en tant que créateur | Le récit déposé ainsi que ses preuves sources scellées pour la CRF et un examinateur AMLA, avec l'humain approbateur enregistré au moment du dépôt | obligations de déclaration AMLR / AMLD6 ; Responsabilité de l'entreprise Wolfsberg (en interne ou auprès d'un fournisseur) |
| Contrôle/libération/blocage des paiements | Un paiement débloqué ne peut pas être annulé par une entrée de journal ultérieure ; la décision s'exécute en temps réel et est définitive | Autorité d'approbation en ligne au point d'action : autoriser dans le cadre de la politique, exiger_une approbation au-dessus des seuils de valeur/risque, bloquer lors du filtrage des exceptions, jamais de surveillance en aval uniquement | Approbateur des opérations de paiement avec autorité de libération pour vérifier les transactions signalées | Enregistrement de décision en temps réel : qui ou quoi a autorisé la libération/le blocage, contre quelle version de politique, avec quelles entrées, scellées au fur et à mesure | Résilience opérationnelle de DORA (Art. 3(22)) ; obligations de paiement et de sanctions |
| Intégration du client / acceptation KYC et KYB | Un agent qui accepte un client à haut risque sans examen crée un échec CDD qui n'apparaît qu'à l'examen suivant | autoriser les acceptations à faible risque dans le cadre de la politique ; require_approval en cas d'acceptation au-dessus des seuils de risque définis ; bloquer sur les catégories interdites | Agent d'intégration/acceptation de première ligne en tant que vérificateur au-dessus du seuil | Lignée de ce que l'agent a vérifié (données CDD, sélection, notation des risques), ce qu'il a conclu et la décision d'acceptation humaine au-dessus du seuil | Diligence raisonnable client AMLR (à partir de 10 juillet 2027) ; Explicabilité de Wolfsberg |
| Enquête sur la propriété effective (UBO) | Une mauvaise détermination d'UBO sous-estime le risque et se propage dans chaque décision en aval concernant la relation | permet des chaînes de propriété simples ; require_approval lorsque la propriété est opaque, superposée ou traverse des juridictions à haut risque | Analyste de diligence raisonnable renforcée en tant que vérificateur des structures complexes | Dossier scellé de la structure de propriété que l'agent a reconstruite, les sources utilisées et la détermination humaine où un examen était nécessaire | AMLR transparence en matière de propriété effective ; Dates d'enregistrement AMLD6 (décalées, de 10 juillet 2027) |
Mappage de la carte aux primitives d'exécution
La carte est délibérément neutre en termes de produit dans ses colonnes, mais elle est conçue pour être opérationnalisée par trois primitives d'exécution qui doivent agir ensemble. Si l’un des trois manque, la ligne n’est pas gouvernée : elle est documentée, ce qui n’est pas la même chose.
Policy Builder gates transforment la troisième colonne en code en cours d'exécution. Les décisions dans la carte (allow, warn, require_approval, block) ne sont pas des adjectifs ; ce sont les résultats littéraux qu’une porte politique émet lorsque l’agent atteint un point de contrôle. Vous créez le seuil (« au-dessus de 0.85 sanctions-matchconfidence, require_approval »), la porte l'applique en ligne et l'agent ne peut pas le contourner. C'est la différence entre un contrôle qui s'exécute et un contrôle décrit dans un classeur.
Le Decision Desk transforme la quatrième colonne en une réalité nommée à deux personnes. Chaque résultat require_approval est acheminé vers une file d'attente de création-vérification où un humain réel et autorisé approuve, rejette ou renvoie l'action avant qu'elle ne s'exécute. C'est ce qui satisfait à l'exigence de Wolfsberg selon laquelle l'entreprise (et non le vendeur, pas le modèle) reste responsable, et ce qui donne à l'examinateur un nom à opposer à toute décision consécutive.
Le Evidence Room transforme la cinquième colonne en un artefact scellé. Au moment où chaque porte est résolue, les entrées, la version politique, la décision et l'humain approbateur sont écrits dans un seul enregistrement contemporain et inviolable. Parce qu'il est scellé au point d'action, il répond au test de construction de l'article 69 recon de l'AMLR et aux attentes de résilience DORA sans aucune difficulté médico-légale. Consultez un exemple d'exportation de lignée d'exécution pour savoir ce que contient l'un de ces enregistrements.
Pourquoi un tableau de bord échoue sur cette carte
La manière la plus courante dont les déploiements AML agentiques échouent à leur premier examen sérieux est de confondre observabilité et preuves. Un tableau de bord vous montre le présent ; un fichier journal vous montre ce qu'un système a choisi d'enregistrer sur lui-même. Ni l’une ni l’autre ne satisfait une seule ligne de cette carte, car les preuves au sens réglementaire possèdent trois propriétés qui manquent à un tableau de bord.
Elle est contemporaine, produite au moment de la décision et disponible avant l'arrivée de la demande de la CRF. Il est complet, capturant les entrées, la politique appliquée, la décision et l'humain approbateur comme une unité scellée qui rassemble les enregistrements dont un analyste a besoin dans les délais. Et c'est inviolable : un examinateur peut vérifier qu'il n'a pas été modifié après coup, sans vous croire sur parole. Une horloge de cinq jours ouvrables de la CRF en vertu de l'article AMLR 69, compressible à moins de 24 hours en cas d'urgence, n'est pas une fonctionnalité de reporting que vous utiliserez plus tard ; c'est un test pour savoir si la lignée dans la cinquième colonne était scellée au moment où cela s'est produit.
C'est également là que l'auto-attestation du fournisseur est en avance sur ce qu'elle peut prouver. Une plateforme centrale de lutte contre la criminalité financière peut décrire la trace de son agent comme « traçable et vérifiable », mais cette trace est auto-certifiée au sein de la propre plateforme du vendeur : un auditeur est invité à faire confiance au dossier de l'agent du vendeur. Une véritable institution gère un fournisseur principal, un fournisseur de points de contrôle distinct et des agents internes ailleurs ; trois parcours auto-certifiés dans trois formats ne constituent pas une stratégie de preuves. La carte suppose une couche unique et neutre de contrôle et de preuves pour chacun d’eux.
Opérationnalisation de chaque ligne : le cluster d'outils AML
Chaque ligne de la carte dispose d'un outil correspondant pour vous aider à la rendre opérationnelle. Utilisez-les pour transformer la carte de référence en un programme en direct, action par action.
Dépôt SAR/STR (ligne 3). La porte maker-checker sur les rapports d'activités suspectes est le cas le plus propre de require_approval de toute la carte. Notre générateur de créateur-vérificateur SAR/STR rédige le récit et l'achemine vers une approbation obligatoire par deux personnes, de sorte que l'agent ne dépose jamais sans qu'une personne nommée soit enregistrée.
Triage de surveillance des transactions (ligne 1). Décider quelles typologies d'alerte un agent peut autoriser la fermeture ou doit escalader commence par connaître vos signaux d'alarme à froid. La bibliothèque red-flags de surveillance des transactions est la référence de typologie qui doit se trouver derrière votre politique de fermeture automatique, si un modèle est dans la bibliothèque, la porte ne doit pas laisser l'agent la fermer silencieusement.
Intégration, UBO et CDD (lignes 5 et 6). Les seuils qui déterminent require_approval lors de l'acceptation et de l'examen de la propriété découlent de l'image des risques à l'échelle de votre entreprise. L'outil AML Enterprise-wide Risk Assessment vous aide à définir ces bandes de risque délibérément plutôt que par défaut.
Préparation du programme sur toutes les lignes. Étant donné que la date limite contraignante est la date de 10 juillet 2027 application de l'AMLR et non une date mobile de la loi sur l'IA, l'outil AMLR 2027 readiness vérifie la gouvernance de votre agent par rapport au livre de règles unique auquel la carte entière est ancrée. Exécutez-le pour voir quelles lignes vous pouvez déjà prouver et lesquelles sont encore de la paperasse.
Les trois régimes derrière chaque ancre
La dernière colonne de la carte cite trois régimes qui convergent déjà vers la même exigence opérationnelle, et un seul d'entre eux est la loi européenne sur l'IA. Savoir quel régime détermine quelle obligation vous indique pourquoi la porte est là où elle se trouve.
DORA : en vigueur actuellement et en vigueur. Règlement (UE) 2022/2554 has appliqué depuis 17 January 2025. Un système de LBC, de sanctions ou de paiement peut être considéré comme une fonction critique ou importante en vertu de l'article 3(22) lorsqu'une évaluation documentée et spécifique à l'entité montre que sa perturbation nuirait sensiblement à la performance financière de l'entreprise, à la solidité de ses services ou à son respect continu de l'autorisation. C'est pourquoi les lignes de contrôle des paiements et de triage comportent aujourd'hui des obligations de résilience et de reconstruction, avant la date du 2027 application de l'AMLR.
L'AMLR : contraignant à partir du 10 juillet 2027 et le fond. Règlement (UE) 2024/1624 is le règlement unique directement applicable en matière de diligence raisonnable à l'égard de la clientèle, de PPE et de transparence de la propriété effective. Son délai de réponse de cinq jours ouvrables selon l'article 69(1), compressible à moins de 24 hours, est le test de reconstruction pour lequel la colonne Evidence Room est conçue pour réussir. AMLA à Francfort est en activité depuis le 1 July 2025 et commence la supervision directe d'une première vague d'entreprises sélectionnées du 2028.
La loi européenne sur l'IA : la nuance, pas la panique. Pour la plupart des surveillances AML autonomes, la classification comme à haut risque n'est ni établie ni décisive, et la date d'application de l'annexe III est le 2 décembre 2027, déplacée du 2 août 2026 by l'Omnibus numérique sur l'IA. Lorsqu'un système est dans le champ d'application, l'article 14 requiresonne une surveillance humaine significative, y compris la capacité d'intervenir et de passer outre, ce qui est exactement la discipline require_approval et block que la carte encode déjà. Construisez sur la carte et l’obligation de la loi sur l’IA, là où elle atterrit, est déjà satisfaite. L'argument de classification complet se trouve dans l'article complémentaire.
Foire aux questions
Qu'est-ce que la carte de contrôle et de preuves des agents AML ?
Il s'agit d'un tableau de référence qui mappe chaque action d'un agent AML ou d'IA de paiement (triage des alertes, autorisation des sanctions, rédaction SAR/STR, contrôle des paiements, intégration et KYC, enquête sur la propriété effective) à trois choses : la porte de contrôle qui doit s'exécuter lorsque l'agent agit (en décidant d'autoriser, d'avertir, d'exiger_l'approbation ou de bloquer), l'humain responsable qui signe dans un Decision Desk à deux personnes examen et le dossier scellé et inviolable Evidence Room produit au moment de la décision. Chaque ligne est ancrée à une véritable régulation publique : DORA, l’AMLR, l’AMLD6, les principes de Wolfsberg, ou encore l’EU AI Act.
Comment les portes de contrôle sont-elles mappées pour autoriser, avertir, require_approval et bloquer ?
Chaque porte se résout en l'une des quatre décisions par ordre de priorité. Autoriser permet à une action de routine à faible risque de se dérouler de manière autonome. Warn le laisse continuer mais le signale pour un examen ultérieur. Require_approval met l'action en pause et l'achemine vers un humain nommé avant que quoi que ce soit ne s'exécute : il s'agit de la porte de vérification du créateur pour les sanctions dépassant un seuil de confiance, le dépôt SAR et l'intégration à haut risque. Block arrête complètement l’action. Choisir la bonne décision pour chaque action et chaque tranche de risque est la discipline fondamentale de la gouvernance de l'agent.
Qui est la personne responsable de chaque action de l'agent ?
Lorsqu'une porte nécessite une approbation, une personne nommée et dûment autorisée devient le vérificateur dans un examen Decision Desk à deux personnes : un examinateur des sanctions pour l'autorisation des hits, le MLRO ou un agent désigné délégué pour le dépôt SAR, un approbateur des opérations de paiement pour la libération des paiements, un agent d'acceptation pour l'intégration. Les principes de Wolfsberg précisent explicitement que cette responsabilité incombe à l'entreprise, que l'agent soit constitué en interne ou qu'il s'approvisionne auprès d'un fournisseur ; il n'est pas transféré au fournisseur de modèles.
Qu'est-ce qui compte comme preuve scellée et pourquoi un fichier journal ne suffit-il pas ?
Les preuves scellées sont un enregistrement produit au moment de la décision et verrouillé afin qu'il ne puisse pas être modifié en silence, capturant les entrées, la version politique, la décision et l'humain qui l'approuve comme une seule unité. Un fichier journal ou un tableau de bord ne possède pas trois propriétés dont un examinateur a besoin : il doit être contemporain (créé sur le moment, non reconstruit après une demande), complet (une unité scellée, et non quatre systèmes assemblés ensemble) et inviolable (vérifiable sans vous croire sur parole). L'horloge de la CRF de l'article AMLR 69 five jours ouvrables, compressible à moins de 24 hours, est un test direct pour savoir si la lignée a été scellée au moment où cela s'est produit.
Quelles réglementations ancrent la carte et lesquelles s'appliquent désormais ?
Trois régimes convergent. DORA (Règlement (UE) 2022/2554) s'applique puisque 17 January 2025 et peut faire d'un système AML ou de paiement une fonction critique ou importante en vertu de l'article 3(22). L'AMLR (règlement (UE) 2024/1624) s'applique à partir du 10 juillet 2027 et fixe les obligations de diligence raisonnable à l'égard des clients, de propriété effective et de réponse de la CRF. La loi de l’UE sur l’IA (règlement (UE) 2024/1689) s’applique au cas par cas ; là où il atterrit, l'article 14 requirespose une surveillance humaine avec la capacité d'intervenir et de passer outre. Les principes de Wolfsberg (1 December 2022) fixent aujourd'hui la référence en matière de responsabilité des entreprises.
Un agent d'IA peut-il déposer un SAR ou annuler une sanction par lui-même ?
Il peut rédiger un SAR de manière autonome, mais le dépôt doit toujours être une porte de vérification par le créateur et l'approbation avec une approbation humaine obligatoire, avec l'agent approbateur enregistré. Pour les sanctions, l'agent ne peut s'auto-effacer qu'en dessous d'un seuil de confiance étroitement défini ; au-dessus, l'autorisation doit être acheminée vers un réviseur nommé, et les correspondances exactes sur les listes désignées doivent bloquer l'examen en attente. Dans les deux cas, une fausse décision autonome est en réalité irréversible (un récit déposé est un dossier juridique, une correspondance erronée est une violation des sanctions), c’est pourquoi la porte se situe avant l’action, et non dans un tableau de bord après.
Points clés à retenir
Traitez cette page comme la carte de référence à laquelle vous revenez chaque fois que vous vous lèvez, achetez ou prolongez une AML ou un agent de paiement. La discipline ne change jamais : pour chaque action entreprise par l'agent, décidez de la porte de contrôle (allow, warn, require_approval, block), nommez l'humain qui signe au Decision Desk et scellez la preuve dans le Evidence Room au moment de la décision. Ancrez chacun d’eux à la réglementation qui vous lie réellement (DORA depuis le 2025 janvier, l’AMLR du 2027 juillet, Wolfsberg aujourd’hui) et non à une date limite mouvante de la loi européenne sur l’IA. Les entreprises qui remporteront le prochain débat sur la surveillance ne seront pas celles qui disposent du cahier de politique le plus épais ; ce seront eux dont les preuves ont été scellées à la vitesse de la machine, dans le parcours d'exécution, une rangée à la fois. Régissez par l'exécution, pas par la paperasse, et utilisez les outils de cette page pour rendre chaque ligne de la carte réelle avant qu'un examinateur ne le demande.