Questa è la carta di riferimento per governare un agente AML o AI pagamenti. Se gestisci un crimine finanziario presso una banca, una società di pagamenti o una fintech, non hai bisogno di un altro saggio per stabilire se l’intelligenza artificiale degli agenti sia “ad alto rischio”. È necessario sapere, azione dopo azione, esattamente dove si trova il cancello di controllo, chi firma e quali prove devono essere sigillate quando l'agente agisce. Questo è ciò che è questa pagina: una singola Mappa di controllo e prove che prende ogni cosa che un agente antiriciclaggio fa effettivamente (triage di allerta, autorizzazione alle sanzioni, redazione di SAR/STR, screening dei pagamenti, onboarding e KYC, monitoraggio delle transazioni) e la mappa su (a) il gate di controllo che deve essere eseguito al momento dell'azione, (b) l'essere umano responsabile che firma e (c) il record sigillato e a prova di manomissione che dimostra che è avvenuto, con riferimenti incrociati a DORA, AMLR e Principi Wolfsberg.\n\nLa tesi alla base della mappa è semplice e non cambia riga dopo riga: governare in base all'esecuzione, non alla documentazione. Alla velocità della macchina, un controllo che si trova in un PDF di policy non è un controllo. Il cancello deve correre all'interno del percorso di esecuzione dell'agente, la persona responsabile deve essere una persona nominata in coda per l'approvazione e non una firma raccolta nel trimestre successivo, e le prove devono essere sigillate al momento della decisione, non ricostruite la mattina in cui un esaminatore chiede. Per l'argomentazione normativa completa alla base di questa mappa, leggi il pezzo complementare, Governing AML and payment agents. Questa pagina è l'hub: aggiungila ai segnalibri e utilizza gli strumenti per azione collegati per rendere operativa ogni riga.
Come leggere la mappa: cancello, umano, prova
Tre colonne nella mappa svolgono il lavoro vero e ciascuna si mappa su una primitiva di runtime concreta. Se inserisci correttamente queste tre definizioni, il resto della pagina sarà una tabella di ricerca.
Il gate di controllo è un checkpoint all'interno del percorso di esecuzione dell'agente, espresso come policy-as-code, che decide cosa può fare l'agente nel momento in cui tenta di agire. Si risolve in una delle quattro decisioni, in ordine di precedenza: allow (l'azione procede in modo autonomo), warn (procede ma viene contrassegnata per una revisione successiva), require_approval (si ferma e viene indirizzata a un essere umano con nome prima che venga eseguita qualsiasi cosa) e block (viene interrotta completamente). L'intera disciplina nel governare un agente consiste nel scegliere la decisione giusta per ciascuna azione e ciascuna fascia di rischio: un avviso di routine di basso valore può essere consentito, una sanzione superata una soglia di confidenza deve essere richiesta_approvazione o blocca. Queste sono le stesse quattro decisioni che scrivi in un gate di Policy Builder.
L’essere umano responsabile non è un’astrazione. Laddove un gate si risolve in require_approval, l'azione entra in una revisione tra due persone, maker-checker: l'agente (o un analista di prima linea) è il maker e un essere umano nominato e opportunamente autorizzato è il checker che deve approvare prima dell'esecuzione. Questa è una funzione del Decision Desk: una persona reale in una coda reale, con l'autorità di approvare, rifiutare o rimandare e la cui identità viene catturata. Wolfsberg è esplicito nel dire che questa responsabilità spetta all'azienda sia che il sistema sia costruito internamente sia che venga acquistato da un fornitore; non viene trasferito al fornitore del modello.
La prova sigillata è la documentazione prodotta al momento della decisione e bloccata in modo che non possa essere successivamente modificata silenziosamente. Cattura gli input visualizzati dall'agente, la policy applicata, la decisione raggiunta e l'essere umano che l'ha approvata, come un'unità contemporanea a prova di manomissione: un record Evidence Room. Questa è la proprietà che un dashboard e un file di registro non hanno, ed è esattamente ciò che una FIU ai sensi dell'articolo 69, della LRD, un supervisore DORA o un esaminatore della LRD devono vedere.
La mappa dei controlli e delle prove
Questo è il centro della pagina. Ogni riga è una cosa che fa un agente antiriciclaggio o di pagamento. Leggi tutto: cosa va storto se funziona senza controllo, il cancello di controllo che deve attivarsi (mappato su consentire/avvisare/richiedere_approvazione/bloccare), l'essere umano responsabile che firma al Decision Desk, il record sigillato dell'Evidence Room e il regolamento che fissa l'obbligo.
Nessuna riga si basa su una metrica fabbricata o su un caso inventato. Ogni ancoraggio normativo è un vero e proprio strumento pubblico: la RDC (il regolamento (UE) 2024/1624), AMLD6 (la direttiva (UE) 2024/1640), DORA (il regolamento (UE) 2022/2554),, i principi di Wolfsberg e, laddove interviene caso per caso, la legge UE sull'IA (regolamento (UE) 2024/1689, Articolo 14 sul controllo umano).
| Azione dell'agente | Rischio se non governato | Cancello di controllo (consenti / avvisa / richiede_approvazione / blocca) | Umano responsabile (Decision Desk) | Prove sigillate (Stanza delle prove) | Ancoraggio regolare |
|---|---|---|---|---|---|
| Triage di avviso/chiusura automatica per il monitoraggio delle transazioni | La falsa chiusura automatica di un vero avviso nasconde attività sospette; un modello non rivisto definisce silenziosamente la propensione al rischio dell'impresa | consentire tipi di avvisi a basso rischio definiti entro la soglia; avvertire per punteggi limite; richiesta_approvazione / blocca per tipologie ad alto valore o ad alto rischio l'agente potrebbe non chiudersi automaticamente | Investigatore di prima linea come controllore sugli allarmi intensificati; la stessa polizza di chiusura automatica di proprietà dell'MLRO/Responsabile della criminalità finanziaria | Input e ragionamenti acquisiti per ogni chiusura automatica, oltre alla versione della policy applicata: il processo verificabile reso reale e ricostruibile su richiesta | LRD art. 69 (ricostruzione FIU, 5 giorni lavorativi); DORAArt. 3(22) resilienza delle funzioni critiche |
| Sanzioni/Autorizzazione dei colpi PEP | Una falsa eliminazione automatica di un vero successo costituisce una violazione delle sanzioni; un falso blocco automatico congela un pagamento legittimo: nessuno dei due è reversibile da una dashboard del mattino successivo | consentire solo al di sotto di una soglia di confidenza ben fissata; richiede_approvazione sopra; blocca le corrispondenze esatte dell'elenco designato in attesa di revisione | Nominato revisore delle sanzioni come controllore prima dell'esecuzione di qualsiasi cancellazione o blocco | Ogni decisione di cancellazione/blocco è sigillata con l'identità del revisore, la soglia applicata e la prova di corrispondenza sottostante | Sanzioni antiriciclaggio/obblighi CDD; Responsabilità dell'azienda Wolfsberg; Legge UE sull’AI art. Supervisione 14 (dove previsto) |
| Stesura e deposito SAR/STR | Una narrazione archiviata autonomamente diventa un documento legale senza che alcun essere umano sia responsabile del suo contenuto o della sua accuratezza | Redigere in autonomia (consenti); *l'archiviazione è sempre richiesta_approvazione***: un cancello obbligatorio per il controllo del produttore con l'approvazione umana | MLRO o funzionario delegato nominato come controllore; l'agente (o l'analista) come creatore | Il resoconto depositato e la relativa prova originale sigillati per la FIU e un esaminatore AMLA, con la persona che ha approvato registrato al momento del deposito | Obblighi di segnalazione AMLR/AMLD6; Responsabilità dell'azienda Wolfsberg (interna o di provenienza) |
| Controllo/rilascio/blocco dei pagamenti | Un pagamento rilasciato non può essere annullato da una successiva registrazione nel registro; la decisione ha esecuzione in tempo reale ed è definitiva | Autorità di approvazione in linea al momento dell'azione: consentire all'interno della policy, richiedere_approvazione al di sopra delle soglie di valore/rischio, bloccare le eccezioni di screening, mai monitoraggio solo a valle | Approvatore delle operazioni di pagamento con autorità di rilascio come controllore sulle transazioni contrassegnate | Registrazione delle decisioni in tempo reale: chi o cosa ha autorizzato il rilascio/blocco, rispetto a quale versione della policy, con quali input, sigillati mentre avviene | Resilienza operativa DORA (Art. 3(22)); obblighi di pagamenti e sanzioni |
| Onboarding del cliente/KYC e accettazione KYB | Un agente che accetta un cliente ad alto rischio senza revisione crea un errore CDD che emerge solo all'esame successivo | consentire accettazioni a basso rischio all'interno della polizza; richiede_approvazione in caso di accettazione al di sopra delle soglie di rischio definite; blocca le categorie vietate | Addetto all'onboarding/accettazione in prima linea come controllore sopra la soglia | Discendenza di ciò che l'agente ha controllato (dati CDD, screening, punteggio di rischio), ciò che ha concluso e la decisione di accettazione umana al di sopra della soglia | Due diligence della clientela AMLR (da 10 luglio 2027); spiegabilità Wolfsberg |
| Indagine sulla proprietà effettiva (UBO) | Una determinazione errata dell’UBO sottovaluta il rischio e si propaga in ogni decisione a valle sulla relazione | consentire catene di proprietà dirette; richiede_approvazione laddove la proprietà è opaca, stratificata o attraversa giurisdizioni ad alto rischio | Analista di due diligence potenziata come controllore di strutture complesse | Documento sigillato della struttura proprietaria ricostruita dall'agente, delle fonti utilizzate e della determinazione umana laddove è stata richiesta la revisione | Trasparenza della proprietà effettiva in materia di antiriciclaggio; Date del registro AMLD6 (sfalsate, da 10 luglio 2027) |
Mappatura della mappa alle primitive di runtime
La mappa è deliberatamente neutrale rispetto al prodotto nelle sue colonne, ma è costruita per essere resa operativa da tre primitive di runtime che devono agire insieme. Se manca uno qualsiasi dei tre, la fila non è governata: è documentata, il che non è la stessa cosa.
Porte di policy builder trasformano la terza colonna in codice in esecuzione. Le decisioni nella mappa (consenti, avvisa, richiedi_approvazione, blocca) non sono aggettivi; sono i risultati letterali che un policy gate emette quando l'agente raggiunge un checkpoint. Crei la soglia ("sopra 0.85 confidenza con corrispondenza delle sanzioni, require_approval"), il gate la applica in linea e l'agente non può aggirarla. Questa è la differenza tra un controllo eseguito e un controllo descritto in un raccoglitore.
The Decision Desk trasforma la quarta colonna in una realtà bipersonale con nome. Ogni risultato require_approval viene indirizzato a una coda maker-checker in cui un essere umano reale e autorizzato approva, rifiuta o rimanda l'azione prima che venga eseguita. Questo è ciò che soddisfa il requisito di Wolfsberg secondo cui l’azienda (non il venditore, non il modello) rimane responsabile, e ciò che dà a un esaminatore un nome da opporre a ogni decisione consequenziale.
La stanza delle prove trasforma la quinta colonna in un artefatto sigillato. Nel momento in cui ogni gate viene risolto, gli input, la versione della policy, la decisione e l'essere umano che li approva vengono scritti come un unico record contemporaneo e a prova di manomissione. Poiché è sigillato nel punto di azione, risponde al test di ricostruzione dell’articolo 69 dell’AMLR e alle aspettative di resilienza DORA senza problemi forensi. Consulta un esempio di esportazione del lineage di esecuzione per sapere cosa contiene uno di questi record.
Perché una dashboard non riesce a raggiungere questa mappa
Il modo più comune in cui le implementazioni AML agentic falliscono il loro primo esame serio è confondendo l’osservabilità con le prove. Una dashboard ti mostra il presente; un file di registro mostra ciò che un sistema ha scelto di registrare su se stesso. Nessuno dei due soddisfa una singola riga di questa mappa, perché l'evidenza in senso normativo ha tre proprietà che mancano a un dashboard.
È contemporaneo, prodotto al momento della decisione e disponibile prima che arrivi la richiesta della UIF. È completo, cattura gli input, la politica applicata, la decisione e l'essere umano che li approva come un'unica unità sigillata che riunisce i record di cui un analista ha bisogno entro la scadenza. Ed è antimanomissione: un esaminatore può verificare che non sia stato alterato dopo il fatto, senza credervi sulla parola. Un orologio FIU di cinque giorni lavorativi ai sensi dell'articolo AMLR 69, comprimibile a meno di 24 ore in casi urgenti, non è una funzionalità di reporting a cui si accede in seguito; è una prova per verificare se il lignaggio nella quinta colonna fosse sigillato nel momento in cui accadde.
Questo è anche il momento in cui l'autocertificazione del fornitore supera ciò che può dimostrare. Una piattaforma principale di criminalità finanziaria può descrivere la traccia del suo agente come "tracciabile e verificabile", ma tale traccia è autocertificata all'interno della piattaforma del venditore: a un revisore viene chiesto di fidarsi della documentazione dell'agente del venditore. Una vera istituzione gestisce un fornitore principale, un fornitore di punti di screening separato e agenti interni altrove; tre percorsi autocertificati in tre formati non sono una strategia di prova. La mappa presuppone un unico livello neutrale di controllo e prova su tutti loro.
Rendere operativa ogni riga: il cluster di strumenti AML
Ogni riga della mappa ha uno strumento corrispondente per aiutarti a renderla operativa. Usali per trasformare la scheda di riferimento in un programma dal vivo, azione per azione.
Archiviazione SAR/STR (riga 3). Il gate maker-checker sulla segnalazione di attività sospette è il caso più pulito di require_approval nell'intera mappa. Il nostro generatore maker-checker SAR/STR redige la narrazione e la instrada attraverso un'approvazione obbligatoria di due persone, in modo che l'agente non archivi mai senza che un essere umano nominato sia registrato.
Triage di monitoraggio delle transazioni (riga 1). Decidere quali tipologie di avvisi un agente può consentire-chiudere rispetto a quelle che deve intensificare inizia con la conoscenza dei segnali di allarme rossi. La libreria dei segnali rossi di monitoraggio delle transazioni è il riferimento alla tipologia che dovrebbe stare dietro la politica di chiusura automatica, se un modello è nella libreria, il cancello non dovrebbe consentire all'agente di chiuderlo silenziosamente.
Onboarding, UBO e CDD (righe 5 e 6). Le soglie che decidono la richiesta_approvazione sull'accettazione e sulla revisione della proprietà derivano dal quadro del rischio a livello aziendale. Lo strumento AML enterprise-wide Risk Assessment ti aiuta a impostare tali fasce di rischio deliberatamente anziché per impostazione predefinita.
Preparazione del programma su tutte le righe. Poiché la scadenza vincolante è la data di applicazione 10 luglio 2027 di AMLR e non una data mobile dell'AI Act, lo strumento di preparazione AMLR 2027 controlla la governance dell'agente rispetto al singolo regolamento a cui è ancorata l'intera mappa. Eseguilo per vedere quali righe puoi già evidenziare e quali sono ancora documenti.
I tre regimi dietro ogni ancora
L’ultima colonna della mappa cita tre regimi che già convergono sulla stessa domanda operativa, e solo uno di questi è l’EU AI Act. Sapere quale regime determina quale obbligo ti dice perché il cancello è lì dove si trova.
DORA: in vigore ora e principale. Il regolamento (UE) 2022/2554 si applica dal 17 gennaio 2025. Un sistema antiriciclaggio, sanzioni o pagamenti può qualificarsi come una funzione critica o importante ai sensi dell'articolo 3(22) quando una valutazione documentata e specifica dell'entità dimostra che la sua interruzione comprometterebbe materialmente le prestazioni finanziarie dell'impresa, la solidità dei suoi servizi o il suo continuo rispetto dell'autorizzazione. Questo è il motivo per cui oggi le questioni relative allo screening dei pagamenti e al triage comportano obblighi di resilienza e ricostruzione, prima della data di applicazione 2027 dell'AMLR.
L'AMLR: vincolante da 10 luglio 2027, e la sostanza. Il regolamento (UE) 2024/1624 è il codice unico direttamente applicabile per l'adeguata verifica della clientela, le PEP e la trasparenza della titolarità effettiva. Il suo orologio di risposta FIU di cinque giorni lavorativi Articolo 69(1), comprimibile fino a meno di 24 ore, è il test di ricostruzione per cui la colonna Evidence Room è stata costruita. AMLA a Francoforte opera dal 1 luglio 2025 e inizia la supervisione diretta di una prima ondata di aziende selezionate da 2028.
La legge UE sull'intelligenza artificiale: le sfumature, non il panico. Per la maggior parte del monitoraggio AML autonomo, la classificazione come ad alto rischio non è né definita né decisiva e la data di applicazione dell'allegato III è 2 dicembre 2027, spostata da 2 agosto 2026 dal Digital Omnibus sull'intelligenza artificiale. Laddove un sistema rientra nell'ambito di applicazione, l'articolo 14 richiede una significativa supervisione umana inclusa la capacità di intervenire e ignorare, che è esattamente la disciplina di richiesta_approvazione e blocco che la mappa già codifica. Costruisci sulla mappa e l'obbligo dell'AI Act, dove arriva, è già soddisfatto. L'argomento completo della classificazione si trova nell'articolo allegato.
Domande frequenti
Che cos'è la mappa di controllo e prova degli agenti antiriciclaggio?
Si tratta di una tabella di riferimento che associa ogni attività svolta da un agente antiriciclaggio o IA dei pagamenti (triage di allerta, autorizzazione in caso di sanzioni, redazione di SAR/STR, screening dei pagamenti, onboarding e KYC, indagine sulla titolarità effettiva) a tre cose: il cancello di controllo che deve essere attivato quando l'agente agisce (decidendo di consentire, avvisare, richiedere_approvazione o bloccare), l'essere umano responsabile che firma una revisione del Decision Desk a due persone e il record Evidence Room sigillato e a prova di manomissione prodotto al momento della decisione. Ogni riga è ancorata a un vero e proprio regolamento pubblico: DORA, AMLR, AMLD6, i Principi Wolfsberg o l’EU AI Act.
In che modo i cancelli di controllo vengono mappati per consentire, avvisare, richiedere_approvazione e bloccare?
Ciascun cancello si risolve in una delle quattro decisioni in ordine di precedenza. Consenti consente che un'azione di routine a basso rischio proceda in modo autonomo. Avvisa consente di procedere ma lo contrassegna per una revisione successiva. Require_approval mette in pausa l'azione e la instrada a un essere umano nominato prima che venga eseguito qualsiasi cosa: questo è il gate del maker-checker per le sanzioni al di sopra di una soglia di confidenza, archiviazione SAR e onboarding ad alto rischio. Il blocco interrompe completamente l'azione. Scegliere la decisione giusta per ciascuna azione e fascia di rischio è la disciplina fondamentale del governo dell'agente.
Chi è l’essere umano responsabile di ogni azione dell’agente?
Laddove un gate decide di require_approval, un essere umano nominato e opportunamente autorizzato diventa il controllore in una revisione del Decision Desk composta da due persone, maker-checker: un revisore delle sanzioni per l'approvazione dei risultati, l'MLRO o un funzionario delegato nominato per l'archiviazione SAR, un approvatore delle operazioni di pagamento per il rilascio dei pagamenti, un funzionario di accettazione per l'onboarding. I Principi Wolfsberg chiariscono esplicitamente che questa responsabilità spetta all'azienda indipendentemente dal fatto che l'agente sia costruito internamente o acquistato da un fornitore; non viene trasferito al fornitore del modello.
Cosa conta come prova sigillata e perché un file di registro non è sufficiente?
Le prove sigillate sono documenti prodotti al momento della decisione e bloccati in modo che non possano essere alterati silenziosamente, catturando gli input, la versione politica, la decisione e l'essere umano che li approva come un'unica unità. Un file di registro o una dashboard mancano di tre proprietà di cui un esaminatore ha bisogno: deve essere contemporaneo (creato al momento, non ricostruito dopo una richiesta), completo (un'unità sigillata, non quattro sistemi messi insieme) e anti-manomissione (verificabile senza crederci sulla parola). L’orologio FIU di cinque giorni lavorativi dell’articolo AMLR 69, comprimibile fino a meno di 24 ore, è un test diretto per verificare se il lignaggio era sigillato quando è avvenuto.
Quali normative ancorano la mappa e quali si applicano ora?
Tre regimi convergono. DORA (il regolamento (UE) 2022/2554) si applica dal 17 gennaio 2025 e può rendere un sistema antiriciclaggio o di pagamento una funzione critica o importante ai sensi dell'articolo 3(22). Il regolamento antiriciclaggio (UE) 2024/1624) si applica dal 10 luglio 2027 e stabilisce gli obblighi di adeguata verifica della clientela, titolarità effettiva e risposta dell'UIF. Si applica la legge UE sull'AI (regolamento (UE) 2024/1689) caso per caso; dove arriva, l’Articolo 14 richiede la supervisione umana con la capacità di intervenire e ignorare i Principi Wolfsberg (1 dicembre 2022) stabiliscono oggi la linea di base della responsabilità dell’impresa.
Un agente AI può presentare una SAR o cancellare una sanzione da solo?
Può redigere una SAR in modo autonomo, ma l'archiviazione deve sempre essere un require_approval maker-checker gate con approvazione umana obbligatoria, con l'ufficiale di approvazione registrato. In caso di sanzioni, l'agente può eseguire la cancellazione automatica solo al di sotto di una soglia di confidenza ben definita; al di sopra di esso, l'autorizzazione deve essere indirizzata a un revisore nominato e le corrispondenze esatte negli elenchi designati dovrebbero bloccare la revisione in sospeso. In entrambi i casi una falsa decisione autonoma è effettivamente irreversibile (una denuncia archiviata è un documento legale, un riscontro erroneamente cancellato è una violazione delle sanzioni), motivo per cui il cancello si trova prima dell’azione, non in un cruscotto successivo.
Punti chiave
Considera questa pagina come la scheda di riferimento a cui tornare ogni volta che ti alzi, acquisti o estendi un AML o un agente di pagamento. La disciplina non cambia mai: per ogni azione intrapresa dall'agente, decidi il cancello di controllo (consenti, avvisa, richiedi_approvazione, blocca), nomina l'umano che firma al Decision Desk e sigilla le prove nella Evidence Room al momento della decisione. Ancorate ciascuno al regolamento che vi vincola effettivamente (DORA da gennaio 2025, l'AMLR da luglio 2027, Wolfsberg oggi) e non a una scadenza mobile dell'EU AI Act. Le aziende che vinceranno il prossimo dialogo sulla supervisione non saranno quelle con il vincolo politico più stretto; saranno loro le cui prove sono state sigillate alla velocità della macchina, nel percorso dell'esecuzione, una fila alla volta. Regola in base all'esecuzione, non alla documentazione, e utilizza gli strumenti di questa pagina per rendere reale ogni riga della mappa prima che un esaminatore lo chieda.