Sicurezza, permessi e approval model¶

Questa piattaforma non si limita a mostrare schermate AML. Governa chi può vedere cosa, chi può decidere, chi può eseguire e quale evidenza resta.

I quattro confini di accesso¶

Zona	Autenticazione	Scopo
Pubblica	nessuna o magic link	login, onboarding iniziale, ceremony GoeSign pubblica
Autenticata utente	sessione + tenant	operatività ordinaria AML
Amministrativa	sessione + RBAC forte	tenant, utenti, console amministrative, policy
Sistema	worker, scheduler, integrazioni	orchestrazione, queue, reconciliation, evidenze

Modello di autenticazione¶

Il personale interno accede via:

pagina /login;
setup TOTP su /totp/setup;
verifica TOTP su /totp/verify;
logout esplicito su /logout.

Magic link onboarding¶

Il cliente o il soggetto esterno non entra nel dominio “operatore”. Usa un perimetro dedicato:

creazione case onboarding;
magic link firmato;
accesso limitato al solo fascicolo in lavorazione;
completamento wizard, upload, CDD, Travel Rule e submit.

Sessione e tenant¶

Ogni sessione interna è sempre filtrata dal tenant attivo. Le pagine e le query critiche sono quindi soggette a:

autenticazione;
tenant context;
controllo ruolo;
eventuale verifica ownership/assegnazione.

Modello di autorizzazione¶

L’autorizzazione è multilivello:

RBAC applicativo per API e pagine;
vincoli di ruolo sul task per checklist, approvazioni e workbench;
dual control quando una stessa decisione richiede più di un firmatario;
gating di esecuzione per impedire azioni automatiche non autorizzate.

Regola architetturale fondamentale¶

AI propone, umano decide

L'AI può preparare testo, analisi, action plan e raccomandazioni.
Non può chiudere da sola un processo regolatorio che richiede responsabilità umana.

Approval model¶

sequenceDiagram
    participant Trigger as Evento o richiesta
    participant Run as TaskRun
    participant AI as AI Orchestrator
    participant Reviewer as Reviewer umano
    participant Executor as Action Executor
    participant Ledger as Evidence Ledger

    Trigger->>Run: crea run sul task
    Run->>AI: genera proposta e package
    AI->>Reviewer: richiede approvazione
    alt approvazione concessa
        Reviewer->>Executor: autorizza esecuzione
        Executor->>Ledger: receipts + evidenza effetto
    else approvazione respinta
        Reviewer->>AI: note / correzioni
        AI->>Ledger: rigetto motivato
    end

Cosa viene approvato davvero¶

In piattaforma l’approvazione non è un pulsante generico. Può riguardare:

esito CDD/EDD;
override rischio;
rilascio assessment;
istruttoria SOS;
pacchetto filing;
signoff formale compliance;
azione proposta dall’AI;
repair di issue reconciliation;
aggiornamento knowledge o policy.

Dove vivono i permessi¶

Ambito	Esempi
Pagine	`PageRBAC`, require role, tenant-bound pages
API	group con `authMw`, `tenantMw`, `rbacMw`
Workflow	checklist role, approver role, assigned owner
Firma	pending signatures, cosign, revoke
Onboarding	magic-link boundary separato dall’operatività interna

Evidenza dell’approvazione¶

Un’approvazione valida deve lasciare traccia di:

reviewer;
ruolo;
timestamp;
decisione;
note e motivazione;
run/task collegato;
eventuale action plan autorizzato;
eventuale receipt o signature record successivo.

Failure mode che il modello previene¶

AI che esegue senza reviewer;
reviewer che approva fuori dal proprio ambito;
task cross-tenant;
dual control solo apparente;
state machine che segna “done” senza evidenza materiale;
firma regolatoria senza pacchetto verificabile.

Schermate chiave¶

/checklist
/checklist/:id
/ai/approvals
/ai/approvals/:runId
/firme/pending
/admin/ceb/ops
/admin/ceb/evidence-nav
/organizzazione

API chiave¶

POST /api/checklist/:id/ai-assist
POST /api/ai-approvals/:runId/approve
POST /api/ai-approvals/:runId/reject
POST /api/ai-runs/:id/gate/complete
POST /api/checklist/:id/transition
POST /api/filing/:id/sign