Financial Crime

monitoraggio delle transazioni

Governare un agente di triage degli alert AML per il monitoraggio delle transazioni

13 min · Updated 2026-06-02

Answer

Si governa un agente di triage degli alert AML intercettando ciascuna azione conseguente — chiudere automaticamente un alert, inoltrarlo a escalation, redigere una narrativa SAR/STR o scrivere una disposizione nel sistema di registrazione del caso — con un checkpoint di policy eseguito prima dell'azione. Le due decisioni che modificano un obbligo di segnalazione, la chiusura automatica e la narrativa SAR, sono indirizzate a una persona L2/L3 nominata in un controllo maker-checker; ogni disposizione è sigillata in una lineage verificabile in modo indipendente. Gli obblighi vincolanti derivano dal diritto AML (FATF R.20, AMLR UE art. 69/73, regole SAR BSA statunitensi) e dalla supervisione del rischio di modello (SR 11-7). L'AI Act UE aggiunge disciplina di supervisione umana e conservazione dei registri, senza classificare automaticamente il monitoraggio AML delle transazioni come ad alto rischio poiché non è elencato nell'allegato 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 sistema di monitoraggio delle transazioni genera alert quando le operazioni si discostano dal profilo atteso del cliente: è la forma operativa del dovere FATF R.10(d) di esaminare le operazioni nell'arco della relazione. Di norma un analista L1 valuta ogni alert, ne raccoglie il contesto e ne stabilisce la disposizione. L'agente di triage automatizza questo lavoro L1 e compie quattro azioni conseguenti: (1) respinge o chiude automaticamente un alert come nessuna ulteriore azione; (2) porta l'alert a un'indagine L2/L3; (3) redige o raccomanda una narrativa SAR/STR; (4) scrive la disposizione e la relativa motivazione nel sistema di gestione dei casi. Due azioni modificano silenziosamente un obbligo legale di segnalazione: una chiusura automatica può estinguere un sospetto segnalabile ai sensi della FATF R.20 e dell'AMLR UE art. 69(1), mentre la narrativa SAR alimenta il documento che l'autorità leggerà riga per riga. Le altre due azioni fissano la motivazione della disposizione, avviano il termine BSA e sono soggette al divieto di tipping-off su ciò che può essere divulgato.

Stakes

Why it's high-stakes

Una chiusura automatica errata è un falso negativo che rimuove interamente una transazione dalla revisione umana: nessun analista la rivede, quindi un sospetto genuino da segnalare tempestivamente ai sensi della FATF R.20 e dell'AMLR UE art. 69(1) non viene mai segnalato. Nel BSA statunitense il termine è rigoroso: una banca deve depositare una SAR entro 30 giorni di calendario dalla rilevazione iniziale dei fatti che possono giustificare la segnalazione, estendibili di 30 giorni solo per identificare un sospetto e mai oltre 60 giorni. Un agente che chiude automaticamente un alert può avviare e superare silenziosamente quel termine. Una narrativa SAR redatta dall'agente è un documento legale letto letteralmente dall'autorità; una disposizione errata indebolisce il controllo di monitoraggio continuativo R.10(d). Poiché il rilevamento di reati finanziari non è elencato nell'allegato III dell'AI Act UE, l'istituzione non può contare su una filiera ad alto rischio con marcatura CE e valutazione di conformità per compensare questi guasti: l'onere di governance ricade sui propri controlli AML e di rischio di modello.

What goes wrong

Failure modes specific to this agent

Estinzione silenziosa del sospetto al confine della chiusura automatica

L'agente chiude automaticamente un alert vero positivo come nessuna ulteriore azione con una motivazione fluida e plausibile ("coerente con il precedente schema di pagamenti salariali"), perciò la transazione non viene mai portata a escalation e non viene mai presentata alcuna SAR/STR. Diversamente da un'escalation mancata che una coda umana può infine far emergere, un alert chiuso automaticamente esce del tutto dalla coda: non resta alcun elemento in attesa, caso in scadenza o segnale per il supervisore. L'obbligo di segnalazione della FATF R.20 / AMLR art. 69(1) si estingue senza che una persona abbia mai deciso che ciò dovesse accadere.

Why it's hard to catch: I test ordinari misurano l'accordo con le etichette storiche degli analisti, ma tali etichette sono dominate dalle chiusure e i tassi di falsi positivi degli alert sono molto elevati. Un agente che chiude in modo aggressivo ottiene quindi buoni risultati di accuratezza mentre sopprime sistematicamente il raro vero positivo. L'errore è invisibile nelle metriche aggregate, non genera eccezioni né alert e può emergere solo anni dopo in una verifica regolatoria, quando i termini SAR sono ormai superati. Il danno è un non-evento, una segnalazione che non è mai avvenuta, che nessun registro delle azioni intraprese può rivelare.

Disallineamento tra disposizione e motivazione

L'agente scrive una disposizione, ad esempio escalation, ma genera una motivazione che sostiene il contrario oppure allega testo standard che non fa davvero riferimento al comportamento che ha generato l'alert. Poiché entrambi i campi sono testo libero prodotto dallo stesso modello in un unico passaggio, la disposizione e la giustificazione possono divergere pur risultando entrambe plausibili. Gli investigatori a valle e gli esaminatori successivi usano la motivazione per capire la decisione; una motivazione disallineata corrompe l'Audit Trail e il punto di partenza dell'investigatore L2.

Why it's hard to catch: Ogni campo supera il proprio controllo superficiale: la disposizione è un valore enum valido e la motivazione è grammaticale e pertinente. Perciò la convalida a livello di campo e i controlli umani di ciascun campo isolato riescono. Il difetto sta nella relazione tra due campi, che i test unitari e il confronto con le etichette non verificano. SR 11-7 descrive proprio questo rischio di modello: conseguenze avverse dell'uso di un output errato; richiede un'effettiva verifica critica da parte di soggetti obiettivi e competenti, non l'autovalutazione del modello.

Fuga di tipping-off attraverso le scritture e i log dell'agente

L'agente scrive una narrativa di disposizione, una nota di caso visibile al cliente o una traccia dettagliata che dichiara o implica fortemente che una SAR/STR è stata o sarà presentata, oppure che è in corso un'analisi ML/TF; il testo giunge a un cliente o a un terzo fuori perimetro, ad esempio una nota CRM, una coda del relationship manager, un messaggio in uscita o un sink di log eccessivamente ampio. L'AMLR UE art. 73 e il BSA statunitense (31 U.S.C. § 5318(g)(2) / 31 CFR § 1020.320(e)) rendono illecita questa divulgazione e il divieto si estende espressamente agli agenti.

Why it's hard to catch: Il compito dell'agente è produrre buone narrative: testo dettagliato e informativo appare quindi come segnale di successo. Il guasto riguarda il percorso e la riservatezza della destinazione, non la qualità del testo, proprio ciò che le valutazioni di qualità dei contenuti tendono a premiare. I test standard verificano che l'agente abbia prodotto una narrativa utile; non verificano che nessun campo di riservatezza livello 2 attraversi un canale leggibile dal cliente. Un singolo strumento vincolato in modo errato o un esportatore di log troppo ampio trasforma una narrativa corretta in una violazione di tipping-off.

Disposizione con contesto obsoleto

L'agente valuta un alert usando uno snapshot di contesto — stato sanzioni/PEP, SAR precedenti del cliente, casi aperti correlati, stato di aggiornamento KYC — corretto al momento del recupero ma obsoleto quando viene scritta la disposizione, oppure che omette silenziosamente un alert correlato sullo stesso cliente. Chiude automaticamente o riduce l'escalation perché, nella sua vista parziale, l'attività appare coerente con il profilo. Il dovere R.10(d) richiede di valutare la coerenza con la conoscenza dell'istituzione sul cliente; agire su uno snapshot parziale elude silenziosamente tale dovere.

Why it's hard to catch: Ogni disposizione individuale è internamente coerente e difendibile rispetto ai dati visti dall'agente, quindi una revisione caso per caso non trova errori. Il difetto appare solo correlando l'intera cronologia degli alert del cliente e osservando che attività collegate sono state trattate isolatamente. Le fixture di test presentano in genere un solo alert con contesto completo e congelato; il guasto di produzione nasce invece da contesto concorrente, frammentato e temporalmente disallineato.

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
Chiudere automaticamente o respingere un alert come nessuna ulteriore azione	Un checkpoint dell'SDK KLA avvolge la chiamata dello strumento close_alert dell'agente (Govern in Place); il checkpoint invia una Decision Request a POST /v1/decisions.evaluate con gli attributi dell'alert prima che la chiusura sia scritta. I deployer che usano il proxy gestito applicano lo stesso passaggio tramite la Executions API.	require_approval quando lo scenario dell'alert o il cliente ha attributi di rischio elevato (PEP, giurisdizione ad alto rischio, SAR precedente del cliente, tipologia di strutturazione o rapida movimentazione) — reasonCode AML_AUTOCLOSE_ELEVATED_RISK require_approval quando la confidenza dell'agente o la completezza della motivazione scende sotto la soglia configurata — reasonCode AML_AUTOCLOSE_LOW_CONFIDENCE block quando esiste un alert o caso aperto correlato sullo stesso cliente, per impedire una chiusura basata su snapshot isolato — reasonCode AML_AUTOCLOSE_LINKED_CASE_OPEN warn sulle chiusure ordinarie a basso rischio, così l'avviso e il reason code sono comunque registrati nel Lineage Record	Un esito require_approval apre un'Escalation in Decision Desk indirizzata dalla policy a un investigatore nominato L2 per reati finanziari (maker-checker: l'agente è il maker e il revisore L2 è il checker). Il revisore vede l'alert, la chiusura proposta dall'agente e la motivazione, i reason code attivanti e un link al Lineage Record; poi approva, nega o reindirizza a L3.	Decision Request (action=close_alert + attributi) esito di policy + reasonCodes + remediation ID dell'Escalation e verdetto approve/deny del revisore nominato con timestamp hash della Release attiva che ha prodotto la disposizione Lineage Record append-only con prova Merkle
Redigere o raccomandare una narrativa SAR/STR	Un checkpoint dell'SDK KLA avvolge la chiamata dello strumento draft_sar_narrative; la Decision Request inviata a POST /v1/decisions.evaluate contiene la narrativa in bozza e il contesto del caso prima che la bozza sia persistita o instradata al deposito.	require_approval per ogni narrativa SAR/STR prodotta dall'agente: l'agente non deposita mai e una persona autorizza sempre — reasonCode AML_SAR_NARRATIVE_HUMAN_SIGNOFF warn + reason code quando la narrativa omette elementi obbligatori, il chi/cosa/quando/dove/perché dell'attività sospetta, così il revisore vede il divario — reasonCode AML_SAR_NARRATIVE_INCOMPLETE block se la bozza è instradata a una destinazione fuori dal percorso di deposito approvato — reasonCode AML_SAR_DESTINATION_UNAPPROVED	require_approval apre un'Escalation in Decision Desk instradata a un funzionario nominato per il deposito SAR o a un delegato MLRO. Il ruolo dell'agente è fissato a redigere o raccomandare; il revisore umano è l'unico soggetto che può autorizzare la decisione di deposito e avviare il termine formale. Decision Desk registra chi ha approvato e quando.	testo esatto della narrativa in bozza prodotta dall'agente esito require_approval + reason code verdetto e timestamp dell'approvatore nominato, a prova dell'autorialità umana della decisione di deposito hash della Release + snapshot di modello e istruzioni che ha generato la bozza Lineage Record sigillato
Portare a indagine L2/L3 oppure scrivere disposizione e motivazione nel sistema di registrazione del caso	Un checkpoint dell'SDK KLA avvolge la chiamata dello strumento write_disposition / escalate_case; la Decision Request a POST /v1/decisions.evaluate porta sia l'enum della disposizione sia il testo della motivazione come attributi accoppiati prima che la scrittura sia confermata nel SoR.	block quando il testo della motivazione è vuoto, standard o non supera il controllo di coerenza con la disposizione, per intercettare il disallineamento disposizione-motivazione — reasonCode AML_DISPOSITION_RATIONALE_MISMATCH block quando la narrativa di disposizione o la nota del caso contiene contenuto di riservatezza livello 2, dichiara o implica un deposito SAR o un'analisi ML/TF, e la destinazione è leggibile dal cliente o fuori perimetro — reasonCode AML_TIPPING_OFF_RISK require_approval quando un'escalation viene declassata a chiusura durante il ri-triage — reasonCode AML_DISPOSITION_DOWNGRADE warn e registra ogni scrittura ordinaria, così ogni disposizione reca un reason code nel Lineage Record	Un block per tipping-off o disallineamento della motivazione restituisce all'agente un diniego strutturato, senza scrittura nel SoR, e viene portato al team di controllo dei reati finanziari responsabile. Un declassamento require_approval apre un'Escalation per un revisore L2 nominato. Le regole di instradamento sono dichiarate nella policy, così l'Escalation raggiunge per impostazione predefinita il team che possiede quel rischio.	disposizione e motivazione accoppiate come inviate esito block/approval + reason code, incluso ogni block di tipping-off strumento di destinazione e associazione al Tool Catalog, a prova che la scrittura ha raggiunto soltanto il SoR approvato Lineage Record che collega prompt → chiamata dello strumento → decisione → verdetto umano prova Merkle che ancora il record alla radice del ledger ImmuDB
Trasversale: mantenere rieseguibile il run governato e verificabile in modo indipendente l'evidenza	Ogni checkpoint precedente passa attraverso la stessa pipeline Evidence-by-Default: ogni Decision Request, decisione di policy, chiamata dello strumento e verdetto umano viene acquisito automaticamente mentre avviene, senza un passaggio di logging separato nel codice dell'agente.	predefinito fail-closed: se il motore di policy non può valutare un'azione sottoposta a gate, l'azione non procede ogni esito diverso da allow deve riportare reasonCodes + remediation, applicato al lint e alla pubblicazione della policy	n/d — questo controllo è il substrato di evidenza in cui sono registrati i verdetti umani precedenti.	log automatico degli eventi lungo la vita dell'agente, senza strumentazione manuale un Lineage Record per disposizione, verificabile tramite GET /v1/lineage/{id}/verify ricalcolando la radice Merkle senza fidarsi di KLA Sealed Evidence Bundle esportabile e EU AI Act Annex IV Control Pack conservazione dei log generati automaticamente per almeno il minimo di sei mesi

Least-privilege execution & data boundaries

Chiudere automaticamente o respingere un alert come nessuna ulteriore azione: Lo strumento close_alert è associato, nella Release immutabile dell'agente, al Tool Catalog; l'agente non può concedersi da solo uno strumento a maggiore impatto. I Data Boundaries mantengono alert e dati cliente nella regione e nel sistema approvati, così lo snapshot letto dall'agente resta quello governato.
Redigere o raccomandare una narrativa SAR/STR: draft_sar_narrative è associato a sola lettura e bozza; l'agente non ha uno strumento che possa presentare una segnalazione alla FIU. Il contesto per la bozza della narrativa resta dentro il Data Boundary, così la bozza non transita in un sistema non approvato.
Portare a indagine L2/L3 oppure scrivere disposizione e motivazione nel sistema di registrazione del caso: write_disposition è associato soltanto all'endpoint governato del case SoR; l'agente non ha associazioni a CRM, messaggistica o code di relationship manager visibili al cliente. Data Boundaries e l'associazione al Tool Catalog impediscono meccanicamente il tipping-off: l'agente non può fisicamente scrivere su una superficie leggibile dal cliente.
Trasversale: mantenere rieseguibile il run governato e verificabile in modo indipendente l'evidenza: l'agente opera con una sola Release immutabile; ogni modifica a modello, istruzioni, parametri o associazioni agli strumenti produce una nuova Release con hash, quindi la domanda su quale configurazione operasse alla data della disposizione ha una risposta dimostrabile.

Mapped to regulation

Regulatory mapping

Framework	Article / section	Obligation (plain language)	How a KLA runtime control satisfies it	Source
Raccomandazioni FATF	Raccomandazione 20 — Segnalazione di operazioni sospette	Se un'istituzione sa, sospetta o ha ragionevoli motivi di sospettare che fondi siano provento di reato o connessi al finanziamento del terrorismo, deve segnalarlo tempestivamente alla FIU. Un agente di triage degli alert influenza questo innesco ogni volta che respinge, porta a escalation o raccomanda una segnalazione.	Il checkpoint di chiusura automatica (runtime_controls[0]) impedisce all'agente di estinguere silenziosamente un sospetto segnalabile: le chiusure a rischio elevato e con caso correlato sono bloccate o instradate a una persona L2 nominata prima che l'alert esca dalla coda, perciò la decisione di non segnalare è sempre presa o ratificata da una persona.	Source
Raccomandazioni FATF	Raccomandazione 10(d) — CDD continuativa: esame delle operazioni	Le istituzioni devono esaminare continuativamente le operazioni nell'arco della relazione per assicurare che siano coerenti con la loro conoscenza del cliente, dell'attività, del profilo di rischio e dell'origine dei fondi. Il monitoraggio delle transazioni rende operativo questo dovere.	Il block sui casi correlati nel checkpoint di chiusura automatica e il block di coerenza disposizione-motivazione (runtime_controls[0], runtime_controls[2]) impediscono all'agente di disporre un alert su uno snapshot parziale e isolato, preservando il test di coerenza con la conoscenza dell'istituzione sul cliente contro il contesto obsoleto.	Source
AMLR UE — Regolamento (UE) 2024/1624	Articolo 69(1) — Segnalazione di sospetti	I soggetti obbligati devono segnalare tempestivamente alla FIU, di propria iniziativa, quando sanno, sospettano o hanno ragionevoli motivi di sospettare che fondi o attività, indipendentemente dall'importo, siano provento di reato o connessi al finanziamento del terrorismo. Devono essere segnalate tutte le operazioni sospette, comprese quelle tentate e i sospetti derivanti dall'impossibilità di completare la CDD.	Le regole require_approval/block per la chiusura automatica (runtime_controls[0]) assicurano che nessun sospetto nel perimetro sia chiuso senza firma umana; la regola di firma umana per la narrativa SAR (runtime_controls[1]) mantiene umana la decisione di segnalare o meno. Il dovere dell'art. 69(1) di agire di propria iniziativa resta quindi in capo a una persona responsabile, non all'agente.	Source
AMLR UE — Regolamento (UE) 2024/1624	Articolo 73 — Divieto di divulgazione (tipping-off)	I soggetti obbligati e il loro personale, inclusi espressamente gli agenti, non possono comunicare al cliente o a terzi che l'attività è valutata ai sensi dell'art. 69, che informazioni sono state o saranno trasmesse alla FIU o che è in corso un'analisi ML/TF.	Il block di tipping-off insieme all'associazione a strumenti a privilegio minimo (runtime_controls[2]) impedisce meccanicamente all'agente di scrivere contenuto di riservatezza livello 2 in una destinazione leggibile dal cliente o fuori perimetro: la scrittura è bloccata e l'agente non dispone in primo luogo di un'associazione del Tool Catalog a una superficie visibile al cliente.	Source
BSA / FinCEN statunitense — 31 CFR Capitolo X	31 CFR § 1020.320(b)(3) — Termine per il deposito SAR	Una banca deve depositare una SAR entro 30 giorni di calendario dalla rilevazione iniziale dei fatti che possono costituire base per il deposito; il termine può estendersi per identificare un sospetto, ma mai oltre 60 giorni dalla rilevazione iniziale.	L'acquisizione della decisione di chiusura automatica con timestamp sigillato nel Lineage Record (runtime_controls[0], runtime_controls[3]) rende dimostrabili e interrogabili la data di rilevazione iniziale e la disposizione che ha avviato o chiuso il termine. L'istituzione può quindi dimostrare il rispetto del termine di 30/60 giorni invece di superarlo silenziosamente con una chiusura dell'agente.	Source
BSA / FinCEN statunitense — 31 CFR Capitolo X e 31 U.S.C. § 5318	31 CFR § 1020.320(e) e 31 U.S.C. § 5318(g)(2)(A)(i) — Riservatezza SAR / divieto di notifica	Nessuna banca o suo agente può divulgare una SAR o informazioni che ne rivelerebbero l'esistenza; un'istituzione, inclusi agenti e appaltatori, non può notificare a una persona coinvolta in un'operazione che essa è stata segnalata.	Lo stesso block di tipping-off e l'associazione a privilegio minimo (runtime_controls[2]) applicano la soglia di riservatezza statunitense: l'agente, che è un agente ai fini del § 5318(g)(2), è bloccato dall'invio di contenuto rivelatore di SAR a ogni destinazione non approvata e le sue scritture sono confinate dai Data Boundaries al case SoR governato.	Source
Fed/OCC SR 11-7 — guida interagenzia sul rischio di modello	SR 11-7 / OCC 2011-12 — definizione di modello, rischio di modello, verifica critica effettiva	Un modello che elabora input in stime crea inevitabilmente rischio di modello; il controllo guida è l'effettiva verifica critica, un'analisi critica da parte di soggetti obiettivi e competenti che sappiano identificare limiti e produrre modifiche. Un agente LLM di triage degli alert è esso stesso un modello da convalidare, sottoporre a verifica critica e monitorare.	L'Escalation maker-checker di Decision Desk (runtime_controls[0], runtime_controls[1]) istituzionalizza la verifica critica effettiva sulle disposizioni a più alto rischio: una persona competente e nominata esamina indipendentemente la decisione dell'agente. Il block di coerenza disposizione-motivazione (runtime_controls[2]) intercetta l'output errato ma fluido che l'autovalutazione non rivelerebbe.	Source
AI Act UE — Regolamento (UE) 2024/1689	Allegato III — ambito della classificazione ad alto rischio e eccezione per il rilevamento di frodi nel credit scoring	L'allegato III elenca otto aree ad alto rischio; la voce sui servizi finanziari comprende l'affidabilità creditizia e il credit scoring, con l'eccezione dei sistemi IA usati per rilevare frodi finanziarie. Il monitoraggio AML delle transazioni e il rilevamento di reati finanziari non sono elencati nell'allegato III, quindi non sono automaticamente sistemi IA ad alto rischio.	È una mappatura di perimetro, non di controllo: indica al deployer che il regime di conformità per alto rischio non è qui l'obbligo portante. I controlli runtime sono quindi progettati prima per soddisfare i regimi AML e di rischio di modello, adottando volontariamente le discipline di supervisione umana e logging dell'AI Act UE come buona prassi e per i casi in cui il deployer rientri altrimenti nell'ambito.	Source
AI Act UE — Regolamento (UE) 2024/1689	Articolo 14(4)(b),(d),(e) — Supervisione umana	Le persone incaricate della supervisione devono restare consapevoli del bias di automazione, poter decidere di non usare, ignorare, sovrascrivere o annullare l'output e poter interrompere il sistema riportandolo a uno stato sicuro.	La pausa require_approval, la sovrascrittura e il reindirizzamento in Decision Desk (runtime_controls[0], runtime_controls[1]) sono l'analogo meccanico diretto di ignorare, sovrascrivere e annullare. block (runtime_controls[2]) è l'interruzione in stato sicuro: l'azione dell'agente è fermata con un diniego strutturato. Il revisore vede i reason code proprio per contrastare il bias di automazione invece di ratificare automaticamente l'agente.	Source
AI Act UE — Regolamento (UE) 2024/1689	Articolo 26(2) e 26(6) — Obblighi del deployer	I deployer devono assegnare la supervisione umana a persone fisiche con competenza, formazione e autorità necessarie e conservare sotto il proprio controllo i log generati automaticamente per almeno sei mesi.	Decision Desk indirizza le Escalation a revisori nominati L2/L3/delegati MLRO, competenti (runtime_controls[0–2]), soddisfacendo il requisito di competenza e autorità; la pipeline Evidence-by-Default conserva automaticamente i Lineage Record ben oltre il minimo di sei mesi (runtime_controls[3]).	Source
AI Act UE — Regolamento (UE) 2024/1689	Articolo 12(1) — Conservazione dei registri (logging automatico)	I sistemi IA ad alto rischio devono consentire tecnicamente la registrazione automatica degli eventi lungo la vita del sistema, per abilitare una tracciabilità appropriata alla finalità prevista.	Evidence-by-Default acquisisce automaticamente ogni Decision Request, decisione di policy, chiamata dello strumento e verdetto umano (runtime_controls[3]) e sigilla ciascuno in un Lineage Record append-only con prova Merkle. In questo modo logging automatico e tracciabilità sono proprietà incorporate, anche se l'art. 12 vincola strettamente solo quando il sistema rientra nell'ambito ad alto rischio.	Source

Prove the control held

Audit-evidence checklist

Per ogni chiusura automatica: la Decision Request, l'esito della policy con reasonCodes e, in caso di rischio elevato, il verdetto e timestamp dell'approvatore L2 nominato, sigillati nel Lineage Record. Dimostra che nessun sospetto nel perimetro è stato chiuso senza firma umana (FATF R.20 / AMLR art. 69).
Per ogni narrativa SAR/STR: il testo esatto della bozza dell'agente, il record require_approval e l'autorizzazione del funzionario nominato per il deposito SAR, che stabiliscono l'autorialità umana della decisione di deposito e che l'agente ha solo redatto (SR 11-7; AMLR art. 69(1) di propria iniziativa).
Per ogni scrittura di disposizione: la disposizione e motivazione accoppiate come inviate, più lo strumento di destinazione e l'associazione al Tool Catalog che dimostra che la scrittura ha raggiunto solo il case SoR approvato e mai una superficie leggibile dal cliente (tipping-off: AMLR art. 73 / 31 CFR § 1020.320(e) / 31 U.S.C. § 5318(g)(2)).
Un timestamp di rilevazione iniziale sigillato su ogni disposizione dell'alert, così il termine BSA SAR di 30/60 giorni è dimostrabile e non ricostruito (31 CFR § 1020.320(b)(3)).
L'hash della Release attiva, modello, istruzioni, parametri e associazioni agli strumenti, impresso su ogni Lineage Record, che risponde a quale configurazione esatta ha prodotto la disposizione.
Verifica indipendente: ogni Lineage Record è verificabile tramite GET /v1/lineage/{id}/verify ricalcolando la radice Merkle rispetto alla radice pubblicata del ledger ImmuDB, senza fidarsi di KLA.
Conservazione dei log generati automaticamente per almeno il minimo di sei mesi (AI Act UE art. 26(6)), esportabili come Sealed Evidence Bundle o EU AI Act Annex IV Control Pack per un esaminatore.
Un pacchetto periodico di verifica critica effettiva: un campione di alert chiusi automaticamente rivisto da una parte indipendente, con i relativi verdetti acquisiti, a prova che il monitoraggio del rischio di modello richiesto da SR 11-7 è stato realmente eseguito.

A concrete intercept

Reference scenario: Un agente tenta di chiudere automaticamente un alert su un PEP con una motivazione fluida e un investigatore L2 nominato esercita il veto

1
L'agente di triage legge l'alert ALRT-77214, rapidi trasferimenti di importi tondi in entrata e in uscita da un conto aziendale, e decide di chiuderlo automaticamente come nessuna ulteriore azione, generando la motivazione 'schema coerente con precedenti pagamenti a fornitori'.
2
Prima che la chiusura sia scritta, il checkpoint dell'SDK KLA che avvolge close_alert invia una Decision Request a POST /v1/decisions.evaluate con gli attributi customer_pep=true, jurisdiction_risk=high, linked_open_alerts=1.
3
La policy trova due regole: AML_AUTOCLOSE_ELEVATED_RISK, PEP più giurisdizione ad alto rischio, restituisce require_approval; AML_AUTOCLOSE_LINKED_CASE_OPEN, esiste un alert correlato aperto, restituisce block. Per precedenza vince il singolo block: la chiusura non procede e l'agente riceve un diniego strutturato con reason code e remediation.
4
Poiché è aperto un caso correlato, la policy indirizza anche un'Escalation in Decision Desk all'investigatore L2 nominato per reati finanziari che possiede il caso del cliente. Il revisore vede l'alert, la chiusura proposta dall'agente e la motivazione, entrambi i reason code e un link al Lineage Record.
5
L'investigatore ignora la chiusura proposta dall'agente, applicando l'override dell'art. 14(4)(d), collega i due alert e porta il caso a L3: è il controllo maker-checker e la verifica critica effettiva di SR 11-7 in azione.
6
Ogni passaggio — la Decision Request, gli esiti block e require_approval, i reason code, identità e verdetto del revisore e hash della Release attiva — è sigillato in un Lineage Record append-only con prova Merkle, verificabile in seguito via GET /v1/lineage/{id}/verify ed esportabile in un EU AI Act Annex IV Control Pack senza fidarsi di KLA.

What most teams get wrong

The non-obvious insight

Un agente AML di monitoraggio delle transazioni quasi certamente NON è un sistema IA ad alto rischio ai sensi dell'allegato III dell'AI Act UE, ed è proprio per questo che necessita di una governance più deliberata. La voce sui servizi finanziari dell'allegato III copre il credit scoring ma esclude i sistemi IA usati per rilevare frodi finanziarie; il rilevamento dei reati finanziari non compare altrove nell'elenco. Il deployer non riceve quindi una marcatura CE, una valutazione di conformità del provider o un fascicolo tecnico dell'allegato IV come impalcatura di sicurezza. Gli obblighi vincolanti derivano invece dal diritto AML, FATF R.20, AMLR art. 69/73 e regole SAR BSA, e dalla supervisione SR 11-7 del rischio di modello, dove l'agente è inequivocabilmente un modello soggetto a convalida e verifica critica effettiva.

Why it matters: I team spesso ragionano a ritroso: se l'AI Act UE è il regime rigoroso, allora un agente non ad alto rischio può essere governato in modo leggero. Per il triage AML l'inferenza è invertita. L'assenza di un involucro di conformità dell'allegato III lascia i controlli runtime del deployer — firma umana sulla decisione di segnalare o non segnalare, contenimento del tipping-off, evidenza sigillata del termine — come unica protezione tra un alert chiuso automaticamente e una verifica regolatoria anni dopo. Qui l'AI Act UE va usato volontariamente come disciplina di supervisione umana e logging, mentre gli obblighi portanti sono AML e rischio di modello. Una classificazione errata conduce a controllare in modo insufficiente l'unica decisione, la chiusura automatica silenziosa, che non ha una persona nel loop né un'eccezione che la faccia emergere.

Il BSA statunitense impone a una banca un limite massimo di 60 giorni di calendario dalla rilevazione iniziale per depositare una SAR, 30 giorni estendibili di 30 per identificare un sospetto. Un agente di triage che chiude automaticamente un alert vero positivo non commette quindi solo un errore: avvia e poi supera silenziosamente un termine legale che nessuno sta controllando, poiché un alert chiuso esce dalla coda e non genera un'eccezione di anzianità. (source)

Q&A

Frequently asked questions

Un agente di monitoraggio delle transazioni AML è un sistema IA ad alto rischio ai sensi dell'AI Act UE?

Probabilmente no. L'allegato III dell'AI Act UE elenca otto aree ad alto rischio; la voce sui servizi finanziari copre l'affidabilità creditizia e il credit scoring ma esclude espressamente i sistemi IA usati per rilevare frodi finanziarie, e il rilevamento AML o dei reati finanziari non compare altrove nell'allegato III. Un agente di triage AML non è quindi automaticamente ad alto rischio. Gli obblighi di governance derivano soprattutto dal diritto AML, FATF R.20, AMLR UE art. 69/73 e regole SAR BSA statunitensi, e dalla supervisione SR 11-7 del rischio di modello; l'AI Act UE contribuisce come buona prassi di supervisione umana e conservazione dei registri quando il deployer rientra nel suo ambito. Confermate la classificazione per il vostro deployment e chiedete consulenza: non ad alto rischio non significa bassa governance.

Quali decisioni dell'agente richiedono la firma umana e quali possono essere automatiche?

Le due decisioni che modificano un obbligo legale di segnalazione ricevono un gate umano. Una narrativa SAR/STR è sempre require_approval: l'agente redige e un funzionario nominato per il deposito SAR autorizza la decisione. Una chiusura automatica riceve require_approval, o block, quando l'alert ha attributi di rischio elevato, come PEP, giurisdizione ad alto rischio o SAR precedente, oppure esiste un caso correlato aperto; viene così instradata a un investigatore L2 nominato. Le chiusure ordinarie a basso rischio e le scritture di disposizione possono procedere come allow o warn, ma ciascuna registra comunque un reason code nel Lineage Record per rendere ricostruibile la decisione.

Come impedisce il governo dell'agente una violazione di tipping-off?

Due livelli. Un controllo sul contenuto blocca ogni narrativa di disposizione o nota di caso che affermi o implichi un deposito SAR, oppure un'analisi ML/TF in corso, quando la destinazione è un campo leggibile dal cliente o fuori perimetro (reasonCode AML_TIPPING_OFF_RISK). Più a fondo, l'associazione del Tool Catalog a privilegio minimo e i Data Boundaries fanno sì che l'agente non abbia alcuno strumento per scrivere su CRM, messaggi o code del relationship manager visibili al cliente. L'AMLR UE art. 73 e il BSA statunitense estendono esplicitamente il divieto di tipping-off agli agenti, quindi il confinamento delle scritture dell'agente al case SoR governato è il meccanismo di controllo.

Come si dimostra a un esaminatore che l'agente non ha silenziosamente omesso un deposito?

Ogni disposizione, incluse tutte le chiusure automatiche, viene acquisita automaticamente come Lineage Record append-only con la Decision Request, l'esito della policy e i reason code, ogni verdetto umano, l'hash della Release attiva e un timestamp di rilevazione iniziale sigillato. Poiché i record sono ancorati a un ledger ImmuDB con prova Merkle, un esaminatore può verificarli tramite GET /v1/lineage/{id}/verify senza fidarsi di KLA; è inoltre possibile esportare la sezione pertinente come Sealed Evidence Bundle o EU AI Act Annex IV Control Pack. Anche gli alert chiusi sono evidenza, non un punto cieco: potete dimostrare quali sono stati chiusi come consentito dalla policy e quali ratificati da una persona nominata.

L'accuratezza dell'agente rispetto alle etichette storiche degli analisti è elevata: non basta come convalida?

No. Le etichette storiche sono dominate dalle chiusure perché il tasso di falsi positivi degli alert è molto alto. Un agente che chiude in modo aggressivo ottiene quindi buoni risultati di accordo con le etichette mentre sopprime sistematicamente il raro vero positivo che deve essere segnalato. SR 11-7 descrive il rischio di modello come conseguenze avverse dell'uso di output errati e prescrive una verifica critica effettiva da parte di soggetti obiettivi e informati, non l'accuratezza auto-riferita dal modello. La governance rende strutturale questa verifica con revisione maker-checker sulle chiusure ad alta posta e riesame indipendente periodico degli alert chiusi automaticamente, entrambi acquisiti come evidenza dell'esecuzione del monitoraggio.

KLA costruisce o gestisce l'agente AML?

No. Il cliente costruisce e possiede l'agente di triage AML, con LangGraph, CrewAI, Agentforce, Microsoft Copilot o internamente. KLA è il livello indipendente di governance e assurance runtime che governa l'agente in place: intercetta ogni azione conseguente prima dell'esecuzione, applica policy-as-code con i quattro esiti allow, warn, require_approval e block, instrada le decisioni ad alta posta ad approvatori umani nominati in Decision Desk e sigilla la lineage di esecuzione firmata e mappata alla normativa. KLA non deposita mai una SAR, non chiude mai un alert e non prende la decisione: le persone mantengono il veto su require_approval e la policy decide se un'azione può essere eseguita.

Related blueprints & guides

Primary sources

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.

Book a demo Read the governance guide