Vai al contenuto

Knowledge, evidenze e firme

Questa area tiene insieme tre piani che, in un sistema AML serio, non possono vivere separati:

  1. la base documentale (Normativa, policy, manuali, GDPR, TOS);
  2. la decisione operativa (controlli, delta, indicatori, approvazioni);
  3. la prova difendibile (ledger, receipt, bundle, firme).

Se vuoi capire perché una decisione AML è stata presa, questa è l’area da cui partire.

Cosa include davvero

  • Normativa e versioni
  • Proposte normative e delta AI
  • Indicatori UIF
  • Compliance controls
  • Evidence ledger
  • Firme regolatorie
  • Export logbook e verifiche
  • GDPR AML e TOS usati come base legale di consenso e accesso

Perché esiste

Un audit AML, legale o di piattaforma deve poter rispondere a sei domande:

  1. quale testo o regola era in vigore;
  2. come è stato tradotto in controllo operativo;
  3. chi ha approvato la decisione o il delta;
  4. quale contenuto è stato effettivamente firmato o accettato;
  5. quali prove tecniche esistono;
  6. dove quelle prove vengono conservate e come si verificano.

Flusso end-to-end

sequenceDiagram
    participant Norm as Normativa
    participant AI as Motore AI / Delta
    participant Human as Reviewer umano
    participant Ctrl as Compliance controls
    participant Sign as GoeSign ceremony
    participant Led as Evidence ledger

    Norm->>AI: testo vigente, nuova versione, gap
    AI->>Human: proposta strutturata
    Human->>Ctrl: approvazione, rigetto o modifica
    Ctrl->>Sign: genera pacchetto firmabile quando richiesto
    Sign->>Led: receipt, bundle, hash, stato verifica
    Human->>Led: motivazione e decisione finale

Conoscenza normativa e operatività

La base documentale non è un archivio passivo. È il punto in cui la piattaforma organizza il passaggio da:

  • fonte normativa;
  • interpretazione operativa;
  • controllo applicabile;
  • evidenza da produrre;
  • approvazione o firma necessaria.

Questo è ciò che consente al sistema di restare leggibile sia per l'operatore sia per audit e contenzioso.

Sottosistemi principali

Normativa

Serve a gestire:

  • documenti core AML;
  • GDPR AML e TOS da firmare/accettare in onboarding o registrazione;
  • capitoli, versioni, pubblicazione e ritiro;
  • relazioni tra testo, controllo e decisione.

Delta e proposte

Serve a confrontare:

  • testo vigente;
  • testo proposto;
  • suggerimento AI;
  • decisione finale dell’umano.

Compliance controls

Trasformano la conoscenza in comportamento di piattaforma:

  • controlli eseguibili;
  • test run;
  • copertura;
  • impatto sui workflow.

Evidence ledger e firme

È il punto in cui la piattaforma smette di “dire” e inizia a dimostrare:

  • chi ha firmato o approvato;
  • cosa è stato firmato;
  • quale policy era attiva;
  • se era richiesta la passkey;
  • quale bundle è stato archiviato;
  • quale receipt è verificabile.

Per il quadro completo leggi anche Firma SES Difendibile (eIDAS).

UI chiave

Funzione Pagina
Base documentale /normativa
Proposte / delta /normativa/proposte
Indicatori UIF /indicatori
Controlli /compliance/controls
Firme da completare /firme/pending
Firme massive sotto mandato /firme/massive/
Credenziali e identità firma /profilo/credenziali, /profilo/identita-firma
Ledger e export /logs/ledger, /logs/export

API chiave

  • POST /api/v1/compliance/controls/test
  • GET /api/v1/compliance/kpi
  • GET /api/v1/compliance/trend
  • POST /api/logs/export
  • POST /api/logs/verify
  • POST /api/logs/verify-export
  • POST /api/v1/goesign/ceremony/*

Cosa deve capire un revisore

Da questa area un revisore deve poter ricostruire:

  • il testo sorgente applicato;
  • la differenza rispetto alla versione precedente;
  • il controllo operativo derivato;
  • l’approvazione umana;
  • il pacchetto firmato;
  • la prova di verifica del bundle;
  • la retention applicata.

Massive signing: cosa cambia e cosa non cambia

La firma massiva non introduce una scorciatoia giuridica. Introduce un modello diverso di prova:

  • il soggetto umano firma il mandato;
  • il motore batch opera entro lo scope del mandato;
  • il batch produce un sigillo tecnico e un archivio verificabile;
  • il revisore deve poter risalire dal batch al mandato senza salti logici.

Per questo la revisione documentale di un batch deve sempre controllare:

  • mandate_id;
  • mandate_payload_hash;
  • mandate_intent_proof_id;
  • mandate_archive_record_id;
  • mandate_activation_session_id;
  • seal_artifact e archive_record_id del batch.

Il quadro completo è documentato in Firme Massive sotto Mandato.