Come implementare SAFR: architettura, pattern e scelta tra sviluppo interno e acquisto

L'architettura di riferimento SAFR¶

SAFR si colloca tra l'agente e i sistemi su cui agisce, valutando le azioni proposte prima dell'esecuzione, lavorando al contempo insieme ai binari di pagamento esistenti, ai protocolli di regolamento, ai motori di conformità e ai sistemi bancari principali. L'obiettivo progettuale, secondo il documento, è che nessuna azione dell'agente raggiunga l'esecuzione senza essere stata dichiarata, autorizzata e valutata. Un'implementazione è una pipeline con un ordine fisso e un registro di controllo che ne registra ogni fase.

La pipeline funziona come segue. L'agente propone un'azione. Prima che qualsiasi cosa venga eseguita, la proposta viene confezionata in una Governance Envelope contenente tre classi di informazioni: l'azione stessa (tipo, ambito, parametri), la traccia dell'azione (i passaggi effettivamente eseguiti dall'agente per arrivare alla proposta, comprese le chiamate agli strumenti effettuate, i dati recuperati e i controlli eseguiti) e i metadati del contesto (identità dell'agente, mandato applicabile, conto corrente o stato del sistema e vincoli di politica operativa). La busta è convalidata per completezza e coerenza. L'identità dell'agente verifica quindi l'agente proponente rispetto al registro autorevole; una verifica fallita comporta un rifiuto immediato, registrato nel registro di controllo. Il repository dei controlli identifica quali controlli dell'istituzione applicare. Il motore delle disposizioni valuta l'azione rispetto a tali controlli e restituisce uno dei quattro risultati vincolanti: Nega, Escalate, Auto-Execute o Observe. I binari finanziari vengono eseguiti se e solo se il risultato lo consente e il registro di controllo registra la traccia completa della governance per ogni risultato, rifiuti inclusi.

L'integrità dell'involucro è un problema di progettazione di primo ordine. La traccia dell'azione e i dettagli dell'azione sono entrambi dichiarati dall'agente e una sofisticata iniezione avversaria può fabbricarli insieme. La prescrizione del documento: la busta va trattata come un documento da autenticare rispetto alla sua provenienza e non come una mera registrazione di quanto riferito dall'agente. In pratica questo spinge gli implementatori a catturare l'involucro in un punto che l'agente non può falsificare (all'interno del percorso di esecuzione o al confine della rete) ed è l'argomento più forte per scegliere deliberatamente il modello di distribuzione.

Nativo o gateway: scegliere un pattern di deployment¶

Il white paper definisce due pattern di integrazione, e la maggior parte delle istituzioni finirà per usarli entrambi. SAFR spiegato descrive il funzionamento di ciascuno, l’emissione dell’envelope nell’agente e l’intercettazione via gateway a livello di infrastruttura; la decisione di implementazione riguarda quando scegliere l’uno o l’altro.

La versione 1.1 aggiunge un punto sulla topologia: SAFR non richiede l’implementazione come un’unica piattaforma centrale all’interno di un’istituzione. I suoi componenti possono funzionare come servizio centrale, dentro i singoli deployment degli agenti, come servizi condivisi dell’istituzione o in forma ibrida, a condizione che ogni azione in ambito passi per le funzioni SAFR richieste prima dell’esecuzione e che ogni implementazione segua standard comuni per envelope, esiti di disposizione, semantica dei controlli e verificabilità.

L’indicazione sulla sequenza viene direttamente dal documento: per le istituzioni con molti agenti esistenti, il pattern gateway è un punto di partenza pratico perché stabilisce prima la copertura, e la strumentazione nativa può seguire per i nuovi sviluppi. In concreto: le nuove funzionalità hanno strumentazione nativa dal primo giorno, e il parco esistente riceve un gateway davanti. Fai girare entrambi i pattern su un unico controls repository, un unico disposition engine e un unico audit log, così un parco misto produce un solo record di governance coerente.

Cosa codificare nei controlli SAFR¶

Un controllo in SAFR codifica cinque cose: tipi di azioni consentite, logica decisionale, condizioni di escalation, un periodo di validità e l'autorità principale in base alla quale agisce l'agente. I controlli si basano su quattro fonti: politiche organizzative, requisiti normativi, regole di prodotto e mandati forniti dagli utenti.

Il mandato è l'ancora. Nel documento, un mandato è il meccanismo attraverso il quale un utente definisce i limiti dell'autorità delegata a un agente: esplicito e leggibile dalla macchina: cosa può fare l'agente, entro quali limiti, a quali condizioni. Un agente non può estendere la portata di un mandato attraverso il proprio ragionamento o inferenza. Il lignaggio del progetto è la sicurezza basata sulle capacità, il modello alla base di OAuth 2.0; il documento cita l’Agent Payments Protocol (AP2), con i suoi mandati firmati crittograficamente, come un importante esempio del settore.

Il documento raggruppa i controlli in quattro categorie:

Calibrazione dei controlli per un agente di pagamento della tesoreria¶

Ecco come appare calibrato per un agente di pagamento del Tesoro. I valori sono illustrativi; imposta il tuo dal quadro delle autorità delegate.

Per un agente di compliance-triage (arricchimento degli avvisi, proposte di disposizione del rischio, preparazione dell'archiviazione) i controlli che portano il carico sono soglie di qualità delle prove: la chiusura automatica di un avviso richiede che il contratto di prova sia soddisfatto pari o superiore alla soglia, le disposizioni ad alto rischio proposte passano a un revisore nominato e qualsiasi azione che sopprimerebbe un avviso aperto viene negata completamente. Percorriamo questo processo dall'inizio alla fine, attraverso tutti e quattro i componenti, in SAFR per AML e compliance triage.

Calibrare le quattro disposizioni¶

Ogni azione in ambito si risolve in uno dei quattro esiti del Disposition Engine:

Tutti e quattro gli esiti alimentano l’Audit Log. L’assegnazione dipende da cinque fattori di calibrazione indicati dal documento: reversibilità dell’azione, rilevanza finanziaria, gravità dell’impatto sul cliente, sensibilità regolamentare e novità o anomalia, cioè lo scostamento dai pattern consolidati all’interno del mandato. I profili a rischio più elevato spostano gli esiti verso Deny o Escalate. La calibrazione si fissa in fase di progettazione attraverso i parametri di governance dei controlli, ed è per questo che il piano pilota qui sotto dedica un’intera settimana alla taratura sul traffico reale.

Observe merita un’attenzione progettuale specifica: permette a un nuovo controllo di girare sul traffico reale e di generare materiale di revisione strutturato mentre l’esecuzione prosegue. È l’impostazione naturale per le soglie che intendi restringere dopo aver visto il comportamento reale.

Calibra sullo storico. Quando nell’ottobre 2026 abbiamo condotto un esercizio di onboarding bancario nei nostri tenant di test, con persona simulate per l’amministratore della banca, il compliance officer e l’approvatore, la nostra conclusione è stata che i casi di test di policy costruiti a mano con molti campi non sono praticabili: un compliance officer non scriverà unit test per una policy. Funziona invece riprodurre le esecuzioni recenti con i controlli in bozza e mostrare la differenza rispetto a quanto è successo, per esempio quante azioni in più sarebbero andate in revisione umana. Quel numero è la domanda sulla capacità dei revisori, e va messo davanti alle persone che presidieranno la coda.

Operazioni di escalation: progettarle prima del go-live¶

Il documento descrive la tipica escalation odierna come una notifica, un avviso via e-mail o un flag sul dashboard, senza scadenza, senza formato decisionale standard, senza registrazione di audit: per il documento, è l'apparenza di una supervisione umana senza la sua sostanza. Un'implementazione SAFR la sostituisce con un'operazione progettata, lungo tre dimensioni.

Volume. Secondo il documento, una funzione di escalation che genera più revisioni di quelle che l'istituzione può elaborare in modo significativo vanifica il suo stesso scopo. Soglie dimensionali rispetto alla capacità effettiva del revisore; se la simulazione produce più risultati di escalation di quelli che il team può eliminare, correggi i controlli prima del lancio.

Inversione di tendenza. Ogni escalation dovrebbe comportare una finestra di timeout. Se non arriva alcuna decisione al suo interno, l'impostazione predefinita è bloccare l'azione o passare a un revisore senior. Imposta la finestra temporale dalla disponibilità realistica del revisore, inclusa la copertura notturna e nel fine settimana.

Autorità. I revisori necessitano di una chiara autorità per approvare, modificare o rifiutare, e le loro decisioni hanno lo stesso peso istituzionale della decisione originale dell'agente. Ciò implica nominare i singoli revisori, registrare le motivazioni di ogni decisione e definire i ruoli che si adattano alla gerarchia di approvazione esistente.

Autorizza nuovamente ogni passaggio¶

Nei processi a più fasi, il flusso di controllo si applica a ciascuna azione dell'agente in modo indipendente. Un risultato di esecuzione automatica o di osservazione in un passaggio non comporta alcuna autorità in quello successivo, poiché l'agente si adatta ai risultati intermedi e alle condizioni mutevoli mentre funziona.

Questa singola frase ha grandi conseguenze implementative. Il percorso di valutazione deve essere sufficientemente veloce da poter essere eseguito su ogni azione, in modo che la latenza rientri nel budget di progettazione fin dall'inizio. I mandati devono essere risolvibili per azione. La memorizzazione nella cache dell'approvazione a livello di sessione è esclusa dalla progettazione. E un flusso di lavoro in dieci fasi produce dieci tracce di governance, ciascuna con il proprio involucro, disposizione e base: esattamente ciò che vorrà un ispettore che ricostruisce il percorso.

Il livello delle prove: il registro di controllo SAFR¶

Ogni voce del registro di controllo cattura sei cose: la busta di governance inviata, il mandato rispetto al quale è stata verificata l'azione, il risultato prodotto dal Disposition Engine, le regole specifiche applicate, la base per tale risultato e il tempo trascorso in ogni fase. Il registro è immutabile, antimanomissione e di sola aggiunta. Lo standard del documento: il registro è un documento autorevole, indipendente da qualsiasi parte interessata a come gli eventi vengono caratterizzati dopo il fatto.

Questo standard è superiore a quello fornito dalla normale registrazione delle applicazioni e tre proprietà necessitano di ingegneria fin dall'inizio: scritture di sola aggiunta, quindi i record si accumulano e non mutano mai; prove di manomissione, in pratica concatenamento crittografico, in modo che qualsiasi alterazione di un record passato sia rilevabile; e verificabilità indipendente, il che significa che un revisore può confermare l'integrità di un record esportato senza accedere alla piattaforma che lo ha prodotto. Perseverare le prove prima di restituire la disposizione. Se un'azione può essere eseguita mentre il suo record è ancora in corso, un arresto anomalo può lasciare le azioni eseguite senza traccia di governance.

Un mandato e un record decisionale di esempio¶

L’esempio che segue è sintetico. Northbridge Bank è fittizia, e nomi, importi e identificativi sono illustrativi. Usa la calibrazione di tesoreria vista sopra e segue un mandato dalla delega all’evidenza.

Il mandato. Il responsabile Treasury Operations di Northbridge delega i pagamenti a fornitori e infragruppo a un agente registrato, treasury-payments, release 3.2. Il mandato è il perimetro scritto di questa delega. L’istituzione lo redige partendo dal proprio sistema di deleghe esistente, lo versiona e lo approva con la stessa revisione che usa per le modifiche di policy.

Il perimetro di delega e i quattro esiti¶

Le ultime due righe del mandato tracciano il perimetro di delega. Tutto ciò che ne resta fuori è rifiutato, qualunque ragionamento offra l’agente, perché un agente non può estendere l’ambito di un mandato attraverso il proprio ragionamento o le proprie inferenze. Dentro il perimetro, i controlli assegnano ogni azione proposta a una delle quattro disposizioni SAFR. KLA Control Plane esprime gli stessi quattro esiti come allow, warn, require_approval e block.

Quattro azioni proposte dall’agente in una stessa mattina mostrano ciascun esito. Ogni riga è stata valutata a sé, senza alcuna autorità ereditata dalla riga precedente.

Un caso di approvazione, dall’inizio alla fine¶

09:41. L’agente propone il pagamento di US$118,000. L’envelope contiene l’istruzione di pagamento, la traccia dell’azione (ricerca della fattura, ricerca del contratto, verifica del beneficiario) e il contesto: identità dell’agente, mandato versione 2 e il totale delle 24 ore fino a quel momento, US$212,000. La verifica dell’identità è superata. Il controllo per azione restituisce Escalate; il controllo aggregato è superato, con un margine residuo di US$170,000 dopo questo pagamento.

09:41. L’azione è trattenuta. Una richiesta di revisione va al gruppo di approvatori di tesoreria con l’azione proposta, la fattura e i controlli scattati. Northbridge imposta per questa classe di escalation un timeout di quattro ore, con block come default.

10:17. Un treasury manager apre la richiesta, confronta la fattura con l’ordine d’acquisto e il master services agreement e approva con la motivazione «Annual licence renewal; PO 4471 and MSA clause 6.2 match invoice INV-20931.» L’approvazione vale solo per questo pagamento.

10:17. Il pagamento è rilasciato al circuito, che restituisce un riferimento di pagamento. Il record si chiude con il risultato dell’esecuzione.

Due scelte progettuali di questo caso vengono da un Process di rilascio dei pagamenti trattenuti che abbiamo costruito nel nostro tenant demo per un briefing con analisti nell’ottobre 2026, con pagamenti sintetici. Primo, ogni decisione umana ha esattamente un gate di approvazione. Il primo invio in revisione di quel Process è stato respinto perché due passaggi umani avevano anche un flag di approvazione separato, che avrebbe creato due attività di approvazione per una sola decisione; abbiamo rimosso i flag e mantenuto un gate per decisione. Secondo, la policy instrada verso require_approval qualsiasi caso che nessuna regola abbia previsto. Nella nostra prima policy AML di test il default in assenza di corrispondenza era block, quindi i casi imprevisti si fermavano senza mai arrivare a un revisore.

Se il manager non avesse risposto entro le 13:41, la richiesta sarebbe scaduta e l’azione sarebbe stata bloccata, con la scadenza registrata. Se il manager avesse rifiutato, l’agente avrebbe ricevuto un block con la motivazione del revisore, e una nuova proposta per lo stesso pagamento sarebbe stata valutata da capo.

Le evidenze che il caso lascia¶

SAFR elenca gli elementi che ogni voce di audit deve registrare: l’envelope così come è stata inviata, il mandato rispetto al quale è stata verificata l’azione, l’esito, le regole specifiche applicate, la motivazione dell’esito e il tempo trascorso in ciascuna fase. Il caso di approvazione aggiunge la decisione umana e il risultato dell’esecuzione. La tabella mostra il record del pagamento di US$118,000.

Approvazione e regolamento sono record separati. Nella demo dei pagamenti trattenuti, l’approvazione del rilascio e lo stato di regolamento confermato sono due voci distinte, e un pagamento è completo solo quando è registrato il riferimento di regolamento. Le teniamo separate perché un’approvazione prova una decisione, e solo il circuito può confermare che il denaro si è mosso.

Una lettura onesta di questo record deve tenere conto di tre limiti. Il record mostra che cosa ha proposto l’agente, quali regole si sono applicate, chi ha deciso e che cosa ha restituito il circuito. Non mostra che il fornitore abbia ricevuto i fondi: questo risulta dai record di regolamento e riconciliazione. Non prova nemmeno che la fattura sia autentica: il controllo sulla qualità delle evidenze verifica l’abbinamento, e i controlli antifrode stanno altrove nel processo di pagamento. Un auditor dovrebbe poter leggere questi limiti nel record senza doverlo chiedere.

Costruisci o acquista per il livello runtime SAFR¶

SAFR è un approccio di riferimento e la scelta del software è lasciata aperta. Divulgazione prima dell'analisi: KLA è un fornitore in questa categoria. KLA Control Plane implementa il modello SAFR, disponibile oggi. Leggi ciò che segue tenendo questo in mente.

Costruire internamente significa realizzare sei sottosistemi:

I sei sottosistemi insieme sono una costruzione su scala piattaforma e l'unità di pianificazione realistica è costituita dai quartieri del team. Il lavoro continua anche dopo il lancio: la calibrazione è un’attività operativa, perché le soglie cambiano con i volumi delle transazioni, i cambiamenti di prodotto e la capacità dei revisori.

Costruire ha senso quando si dispone di un team interno della piattaforma che possiederà il livello come prodotto, quando le ferrovie o l'infrastruttura di insediamento sono sufficientemente personalizzate da non poter ospitare un checkpoint standard o quando i sistemi adiacenti che già gestisci (diritti, gestione dei casi, strumenti politici) coprono parti reali della tabella sopra.

L’acquisto ha senso quando la priorità è la copertura governata e le prove esportabili entro un trimestre, quando non è disponibile un team della piattaforma per possedere sei sottosistemi o quando i revisori richiederanno record verificabili in modo indipendente prima che una tabella di marcia interna possa fornirli.

L'ibrido è spesso la risposta onesta: acquistare il checkpoint di runtime (registro, motore di disposizione, processo di escalation, archivio prove) e mantenere la creazione dei controlli internamente. La suddivisione corrisponde allo stesso SAFR: il quadro standardizza le strutture dei dati e i contratti, mentre le configurazioni delle regole e le disposizioni di governance rimangono dell’istituzione. In un ibrido, i team di rischio e conformità possiedono ciò che dicono i controlli e il fornitore gestisce il meccanismo che li applica e li dimostra.

Per la cronaca su KLA in particolare: KLA Control Plane mappa componente per componente (Registro agenti, Policy Builder, KLA Policy Engine, Audit Trail) con le quattro disposizioni espresse come consenti, avvisa, require_approval e blocca. Vengono forniti l'autorizzazione per azione, la valutazione a chiusura di errore e i pacchetti di prove sigillate con verifica offline. Sono in fase di sviluppo le finestre di esposizione aggregate, i limiti di velocità per finestra, le soglie di confidenza come primitiva di routing, i valori predefiniti di timeout di escalation per classe e il gateway autonomo. La mappa componente per componente, con indicatori di stato su ogni requisito, si trova sulla nostra pagina Implementazione SAFR.

Un pilota SAFR di quattro settimane¶

Una prima implementazione credibile richiede quattro settimane per un processo con ambito e il piano funziona indipendentemente dal fatto che il livello sottostante venga costruito, acquistato o ibrido.

Prima della prima settimana, segna la tua posizione. La SAFR Readiness Checklist è una valutazione interattiva delle lacune in otto sezioni, dall'identità dell'agente al modello di implementazione, con le prove che un valutatore richiederebbe allegate a ogni domanda.