Modello operativo AML¶

Questa pagina descrive il modello operativo reale della piattaforma: come nasce un caso, come viene istruito, chi lo approva, come viene eseguito e come resta auditabile.

I pilastri¶

1. Three lines of defense¶

La piattaforma è costruita intorno alle tre linee di difesa:

1° livello: Team AML e operatori che identificano, verificano, monitorano e segnalano;
2° livello: RFA e RSOS che definiscono regole, analizzano anomalie e autorizzano;
3° livello: Internal Audit e Organo di Controllo che verificano il sistema nel suo complesso.

2. Risk-based approach¶

La profondità dei controlli non è uniforme:

rischio basso → processo semplificato dove consentito;
rischio medio → CDD ordinaria;
rischio alto → EDD, approvazioni senior, controlli rafforzati;
rischio severo → blocco, astensione, escalation o congelamento.

3. AI con responsabilità umana¶

Il prodotto usa AI in modo strutturato ma non deresponsabilizzante:

AI redige e propone;
l’umano approva o respinge;
il sistema esegue solo dentro limiti e policy dichiarate;
ogni step produce evidenza e stato.

Macro-flusso di compliance¶

sequenceDiagram
    participant Cliente
    participant Team as Team AML
    participant Core as Registro / Verifiche
    participant CEB as AI + CEB
    participant RFA
    participant RSOS
    participant Filing
    participant Archive

    Cliente->>Team: onboarding / rapporto / operazione
    Team->>Core: anagrafica, documenti, UBO, questionari
    Core->>Core: screening, profiling, CDD/EDD
    Core-->>CEB: trigger evento operativo
    CEB->>CEB: AI output + approval package + action plan
    CEB-->>RFA: approvazione / rigetto / richiesta modifica
    alt anomalia confermata
        RFA-->>RSOS: escalation istruttoria
        RSOS->>Filing: SOS / filing / comunicazioni
        Filing->>Archive: pacchetto firmato + evidenze + retention
    else falso positivo o chiusura
        CEB->>Archive: evidence chain e close-out
    end

Oggetti operativi principali¶

Oggetto	Scopo
`ChecklistTask`	unità operativa e approvativa principale
`TaskRun`	singola esecuzione AI su un task
`AIApproval`	decisione umana sul run
`AiActionPlan`	piano eseguibile generato dopo approvazione
`AiActionExecution`	esecuzione puntuale di una singola azione
`AiActionReceipt`	ricevuta verificabile dell’esecuzione
`EvlLedgerEntry`	ledger di evidenza e decisioni
`WorkerLease`	controllo ownership dei worker critici
`ReconciliationIssue`	deviazione da invarianti o attese operative

Stati macro del backbone¶

Il motore usa uno stato macro esplicito, leggibile anche in UI:

triggered
task_created
output_ready
awaiting_primary_approval
awaiting_secondary_approval
execution_running
execution_completed
manual_intervention_required
reconciled
failed

Questi stati non sono cosmetici: determinano retry, escalation, validazione, release gates e reconciliation.

Regola operativa non negoziabile¶

AI proposes, human approves

Nei punti che generano decisioni regolatorie, impatto sul cliente, filing, signoff o blocco operativo, l’AI non sostituisce il ruolo accountable. L’AI prepara il contenuto; l’umano decide e la piattaforma conserva l’evidenza della decisione.