Nel luglio 2026, il programma BuildFin.ai dell'Autorità monetaria di Singapore ha pubblicato SAFR (Safeguards for Agentic Finance at Runtime) un libro bianco scritto con otto membri del settore: Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC e Visa. SAFR è un approccio di riferimento per un livello di governance runtime: un checkpoint che si trova tra un agente AI e i sistemi su cui agisce e valuta ogni azione proposta prima che venga eseguita.
La tesi del documento si riassume in una riga: "nessuna azione agente raggiunge l'esecuzione senza essere stata dichiarata, autorizzata e valutata".
Questa spiegazione copre le specifiche complete: i quattro componenti di runtime, la busta di governance, i mandati, le quattro disposizioni e i relativi fattori di calibrazione, l'autorizzazione per azione nei flussi di lavoro a più fasi, i due modelli di distribuzione e la posizione di SAFR rispetto ai guardrail, alle piattaforme di conformità e ai regolamenti. È scritto per i responsabili della conformità, i responsabili dei rischi legati all’intelligenza artificiale e i team della piattaforma che cercano di capire cosa richiederebbe effettivamente l’adozione di SAFR.
Perché esiste SAFR
Le istituzioni finanziarie stanno implementando agenti IA che agiscono. Avviano pagamenti, inviano ordini di negoziazione, approvano richieste di credito, compilano rapporti normativi e liquidano sinistri assicurativi: spesso ad alta frequenza, senza che alcun essere umano riveda ogni singola azione. Il documento nomina cinque aree applicative in cui le preoccupazioni in materia di governance sono maggiori: pagamenti, gestione della liquidità, valutazione della conformità, valutazione del credito ed elaborazione post-transazione.
Esiste anche una dimensione sistemica. Quando molte istituzioni si affidano a un numero limitato di fornitori di servizi di intelligenza artificiale comuni, i loro agenti possono comportarsi in modi correlati. Il Financial Stability Board ha identificato questa correlazione come una potenziale vulnerabilità sistemica.
In questo contesto, SAFR identifica tre lacune nelle istituzioni infrastrutturali di governance già gestite.
Gap 1: garanzia pre-esecuzione. La gestione del rischio del modello convalida un sistema prima dell'implementazione. L'audit esamina ciò che è accaduto dopo il fatto. Nessuna delle due discipline coglie una decisione problematica dell'agente nel momento prima che venga eseguita.
Gap 2: l'interfaccia di governance uomo-agente. Oggi l'escalation a un essere umano è ad hoc (una notifica, un avviso e-mail, un flag sul dashboard) senza scadenza, senza formato decisionale standard e senza record di audit. Il documento definisce ciò “l’apparenza di un controllo umano senza la sua sostanza”.
Gap 3: frammentazione. Ogni schieramento costruisce i propri guardrail. I risultati non sono interoperabili e non possono essere verificati in un formato coerente in tutta l’istituzione.
SAFR è una proposta di risposta a tutti e tre: un punto di controllo permanente nel percorso di esecuzione, un contratto di escalation strutturato con scadenze e registrazioni delle decisioni e un formato di governance coerente per ogni agente.
Cos'è il SAFR?
Nelle parole stesse del documento, SAFR "definisce le strutture dei dati, la logica di valutazione e i contratti di escalation per l'implementazione dell'intelligenza artificiale degli agenti. 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."
Tre limiti contano per chiunque lo legga con un mandato di conformità.
Innanzitutto, la SAFR non esercita alcuna forza di supervisione. Il documento è esplicito: "Non costituisce una guida normativa o aspettative di vigilanza". Ogni istituzione rimane responsabile di determinare in che modo la propria implementazione si allinea alle aspettative di vigilanza applicabili e ai requisiti di governance interna.
In secondo luogo, il SAFR è una specifica sulla quale le istituzioni possono basarsi. "Funge da riferimento del settore per le istituzioni da implementare all'interno della propria infrastruttura, utilizzando le proprie configurazioni di regole e accordi di governance." Non esiste un servizio SAFR gestito da MAS a cui abbonarsi.
In terzo luogo, SAFR ha come ambito la decisione di runtime. Definisce come un'azione proposta viene identificata, autorizzata, valutata e registrata al momento dell'azione. La convalida del modello, la gestione del ciclo di vita e i più ampi quadri di rischio dell’intelligenza artificiale ruotano attorno ad esso (maggiori informazioni su quell’ecosistema di seguito).
I quattro componenti runtime SAFR
L'architettura di SAFR è composta da quattro componenti che interagiscono attraverso una struttura dati condivisa, la Governance Envelope. Ciascun componente risponde a una domanda sull'azione proposta.
L'identità dell'agente lega ogni azione proposta a un agente riconosciuto e registrato, verificato rispetto alla voce del registro di quell'agente prima che proceda qualsiasi altra valutazione. In un ambiente a circuito chiuso, il registro dell'istituzione risponde con una ricerca diretta. Sulle reti aperte, un agente può essere registrato in più database di identità (il registro interno dell'istituzione, il registro degli agenti di una rete di pagamento, una directory interistituzionale) e il componente determina quale registro è autorevole per l'azione in questione. Un controllo di identità fallito produce un rifiuto immediato, registrato nel registro di controllo.
L’archivio dei controlli è il luogo in cui l’istituzione codifica le sue regole. I controlli derivano da politiche organizzative, requisiti normativi, regole di prodotto e mandati o autorità concessi dagli utenti. I controlli generici come i controlli sulle autorizzazioni e i limiti di esposizione sono deterministici. I controlli specifici dell’intelligenza artificiale, come la qualità delle prove e l’integrità della busta, possono comportare una valutazione probabilistica o semantica. Ogni controllo codifica cinque cose: i tipi di azioni consentite, la logica decisionale, le condizioni di escalation, un periodo di validità e l'autorità principale dietro di esso.
Il Disposition Engine valuta ogni azione nell'ambito in modo deterministico rispetto ai controlli recuperati, producendo "un risultato definito e vincolante per ogni azione proposta calibrata sul rischio specifico che presenta". I quattro possibili risultati sono trattati in modo approfondito di seguito.
Il registro di controllo registra ogni decisione di governance in un formato a prova di manomissione e di sola aggiunta. Ciascuna voce cattura sei elementi: 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 ciascuna fase. Secondo il documento: "Il registro è un documento autorevole, indipendente da qualsiasi parte interessata al modo in cui gli eventi vengono caratterizzati dopo il fatto".
Il ciclo di vita lega insieme i quattro. Un'azione proposta viene inserita in una busta di governance e convalidata per completezza e coerenza. L'identità dell'agente viene verificata rispetto al registro pertinente; il fallimento significa un rifiuto immediato e registrato. Il repository dei controlli identifica quali controlli verificare. Il motore delle disposizioni determina le soglie applicabili e restituisce uno dei quattro risultati. Il registro di controllo registra la traccia completa della governance per ogni risultato, comprese le azioni che sono proseguite senza intervento.
| Componente | La domanda a cui risponde | Cosa contiene o fa |
|---|---|---|
| Identità dell'agente | Quale agente propone questa azione ed è riconosciuta? | Verifica ogni azione rispetto alla voce di registro dell'agente prima di procedere con qualsiasi altra valutazione |
| Repositorio dei controlli | Quali regole si applicano a questa azione? | Il regolamento configurabile dell'istituzione: politiche, requisiti normativi, regole di prodotto, mandati degli utenti |
| Motore di disposizione | Può procedere questa azione, e a quali condizioni? | Valuta l'azione rispetto ai controlli recuperati e restituisce uno dei quattro risultati vincolanti |
| Registro di controllo | Cosa è stato deciso esattamente e perché? | Una registrazione immutabile, a prova di manomissione e di sola aggiunta di ogni decisione di governance |
La busta sulla governance
Prima che venga eseguita, qualsiasi azione dell'agente viene confezionata con il contesto necessario per valutarla. La busta contiene tre classi di informazioni.
La busta presenta un problema di integrità che la carta affronta direttamente. La traccia dell'azione e i dettagli dell'azione sono entrambi dichiarati dall'agente, il che significa che una sofisticata iniezione avversaria potrebbe fabbricarli insieme: una traccia dall'aspetto plausibile avvolta attorno a un'azione non autorizzata. La risposta del giornale: "La busta va quindi trattata come un documento da autenticare rispetto alla sua provenienza, non semplicemente come una registrazione di quanto riferito dall'agente". Le implementazioni necessitano di un modo per verificare che la busta rifletta ciò che è realmente accaduto, alla fonte.
| Classe di informazioni | Contenuto |
|---|---|
| Azione | Il tipo di azione, oltre all'ambito e ai parametri dell'azione proposta |
| Traccia dell'azione | I passaggi effettivi eseguiti dall'agente per arrivare alla proposta: chiamate allo strumento effettuate, dati recuperati, controlli eseguiti |
| Metadati di contesto | L'identità dell'agente, il mandato applicabile, lo stato del conto corrente o del sistema e i vincoli di politica operativa |
Mandati e autorità basata sulle capacità
"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.
Il progetto si basa sulla sicurezza basata sulle capacità, un lignaggio che l'articolo fa risalire al lavoro 1966 di Dennis e Van Horn: la stessa tradizione alla base di OAuth 2.0.. La proprietà portante: "Un agente non può estendere la portata di un mandato attraverso il proprio ragionamento o inferenza. L'autorità è esplicita, strutturata e definita dal mandato, non dedotta dall'agente." Per quanto fluida sia la giustificazione di un agente per superare i propri limiti, il mandato è il confine.
Il documento cita l’Agent Payments Protocol (AP2) come un importante esempio di settore, con mandati firmati crittograficamente.
Le quattro disposizioni SAFR: Nega, Escalate, Auto-Execute, Observe
Il motore delle disposizioni risolve ogni azione nell'ambito in uno dei quattro risultati. Tutti e quattro alimentano il registro di controllo.
Observe consente a un'istituzione di mantenere un flusso di automazione a basso rischio creando allo stesso tempo un registro rivedibile dei casi che desidera tenere d'occhio in seguito.
Quale disposizione riceve un'azione è una questione di calibrazione, definita in fase di progettazione attraverso i parametri di governance dei controlli. Il documento nomina cinque fattori di calibrazione: reversibilità dell’azione, materialità finanziaria, gravità dell’impatto sul cliente, sensibilità normativa e novità o anomalia: ovvero l’allontanamento dai modelli stabiliti all’interno del mandato. I profili a rischio più elevato spostano i risultati verso Nega o Incrementa.
| Disposizione | Quando si applica | Che succede |
|---|---|---|
| Negare | L’azione viola un rigido vincolo normativo o politico, oppure il suo profilo di rischio supera le soglie definite | Rifiutato prima dell'esecuzione, con un motivo specifico registrato |
| Aumentare | Nell’ambito e al di sotto dei vincoli rigidi, ma al di sopra della soglia per l’esecuzione autonoma | Trattenuto in attesa di revisione umana prima di procedere |
| Esecuzione automatica | Nell’ambito dell’ambito, al di sotto di vincoli rigidi, entro soglie di rischio definite | Procede senza richiedere l'intervento umano |
| Osservare | Al di sotto della soglia di escalation, ma corrispondente a un modello o segnale che l'istituzione ha configurato come meritevole di attenzione | Viene eseguito, mentre un'osservazione strutturata viene registrata per la revisione successiva |
Nessuna autorità porta avanti tra i passaggi
I processi agentici sono raramente una singola azione. Un agente arricchisce i dati, richiama strumenti, si adatta ai risultati intermedi e propone il passaggio successivo in base a ciò che ha appena appreso. La risposta di SAFR è la governance per-azione: il flusso di controllo si applica a ciascuna azione dell'agente in modo indipendente.
Il documento è preciso sulla conseguenza: "Un risultato di esecuzione automatica o di osservazione in un passaggio non comporta alcuna autorità in quello successivo". L'autorizzazione preventiva non viene trasferita poiché l'agente si adatta ai risultati intermedi e alle condizioni mutevoli. Il passaggio tre di un flusso di lavoro prevede la stessa verifica dell'identità, recupero dei controlli e disposizione del passaggio uno. Per le istituzioni, questo chiude lo scenario in cui un agente ottiene un’approvazione in anticipo e poi si sposta, pienamente “autorizzato”, in un territorio che nessuno ha esaminato.
I due modelli di distribuzione SAFR
SAFR descrive due modi per inserire il checkpoint nello stack di un'istituzione.
Il documento offre una guida alla sequenza per le istituzioni che già utilizzano agenti: "Per le istituzioni con molti agenti esistenti, il modello gateway funge da punto di partenza pratico stabilendo prima la copertura e la strumentazione nativa può seguire per le nuove build". Prima la copertura, poi la profondità.
| Modello | Come funziona | Adatto per |
|---|---|---|
| Integrazione nativa | L'agente è dotato di strumenti per emettere una busta di governance prima di ogni azione proposta; il validatore SAFR lo valuta rispetto al repository dei controlli e restituisce un risultato prima che l'agente agisca | Nuove distribuzioni di agenti; integrazione più stretta, registrazione più granulare, traccia di controllo più pulita |
| Integrazione del gateway | Un gateway SAFR intercetta le chiamate API in uscita a livello dell'infrastruttura, avvolge ciascuna chiamata in una busta di governance e la valuta senza modifiche al codice dell'agente | Sistemi legacy, agenti di terze parti, implementazioni esistenti |
Cosa configurano le istituzioni: le quattro categorie di controllo
La SAFR lascia il regolamento all'istituzione. La sua tabella 1 definisce quattro categorie di controllo che un'implementazione dovrebbe supportare.
Spiccano due note progettuali tratte dal documento. I limiti di esposizione dovrebbero rispecchiare i quadri di autorità delegata che l’istituzione già gestisce per gli esseri umani, in modo che l’autorità dell’agente si inserisca in un vocabolario di governance esistente. E la qualità delle prove opera indipendentemente dal valore: un’azione con scarsa fiducia viene indirizzata a un essere umano anche quando la somma in gioco è irrisoria.
| Categoria di controllo | Cosa definisce l'istituzione |
|---|---|
| Autorizzazione | Quali agenti sono autorizzati ad agire per quali mandanti; chi può delegare l'autorità a chi e fino a che punto; quali tipi di azioni possono avviare ciascuna classe di agenti |
| Limiti di esposizione | Soglie di valore per azione e aggregato; al di sotto di essi sono consentite azioni autonome; al di sopra di essi è richiesta la revisione umana altrimenti l'azione viene bloccata |
| Limiti di velocità | Tasso di azione massimo per finestra temporale; protegge da agenti in fuga, errori di feed di dati e iniezioni di prompt avversari che causano velocità o volume anomali |
| Qualità delle prove | Soglia minima di confidenza e prove richieste per l'esecuzione autonoma; azioni in cui la fiducia dichiarata dall'agente scende al di sotto della soglia, vengono sottoposte a revisione umana indipendentemente dal valore |
Gestire il percorso di escalation
Una disposizione Escalate è valida tanto quanto il processo di revisione umana che sta dietro ad essa. SAFR nomina tre dimensioni operative che le istituzioni devono progettare deliberatamente.
Volume di escalation. Una funzione di escalation che genera più revisioni di quelle che l'istituto può elaborare in modo significativo vanifica il suo stesso scopo. Le soglie devono essere calibrate rispetto alla reale capacità del revisore.
Rivedi il turnaround. Le riassegnazioni dovrebbero includere una finestra di timeout. Se non arriva alcuna decisione al suo interno, l'impostazione predefinita è bloccare l'azione o passare a un revisore senior. La finestra dovrebbe riflettere una disponibilità realistica del revisore, inclusa la copertura notturna e nel fine settimana.
Autorità del revisore. I revisori devono avere una chiara autorità per approvare, modificare o rifiutare l'azione e le loro decisioni "hanno lo stesso peso istituzionale della decisione originale dell'agente". Un revisore che può solo timbrare riproduce il divario che SAFR si proponeva di colmare.
Dove SAFR si trova nello stack
Un modo utile per leggere SAFR è come uno strato con vicini definiti. Il flusso: l'agente AI produce un'azione proposta (i suoi guardrail possono modellare l'output); SAFR verifica l'identità e l'autorità dell'agente e valuta l'azione rispetto ai controlli in modo deterministico, restituendo Auto-Execute, Observe, Escalate o Deny; i binari finanziari vengono eseguiti se e solo se l'azione è stata approvata.
Relativo ai guardrail dell'intelligenza artificiale. Il filtraggio dei contenuti, le difese di prompt-injection e il filtraggio dell'output sono in genere probabilistici e governano ciò che produce il modello. Se un'azione finanziaria proposta sia autorizzata ed eseguibile è una decisione separata, ed è quella effettuata da SAFR. SAFR opera dopo il filtraggio dei contenuti e prima dell'esecuzione.
Relativo alle piattaforme di conformità. SAFR genera il record di governance strutturata a cui possono attingere le piattaforme di conformità esistenti. Non replica le loro valutazioni.
Relativo ai binari di regolamento. Gli schemi di pagamento e i binari di regolamento muovono denaro. SAFR regola la decisione di spostarlo. L'applicazione a livello di regolamento (regole della rete di carte, standard SWIFT, regole ACH, Machine Payments Protocol (MPP), Purpose Bound Money (PBM), controlli sulle stablecoin) opera dopo che SAFR ha determinato se l'agente può agire.
Relativo a un prodotto. SAFR è una specifica. Non è possibile acquistare un servizio gestito da MAS; ogni istituzione implementa il modello all'interno della propria infrastruttura o adotta strumenti che lo fanno.
Chi ha scritto SAFR e l'ecosistema che lo circonda
SAFR è il risultato di un flusso di lavoro dedicato MAS istituito nell'ambito del programma BuildFin.ai per sviluppare risorse di implementazione per i rischi dell'intelligenza artificiale degli agenti. È stato scritto con otto membri del settore: Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC e Visa. Il documento fonda le specifiche nei casi di studio dei membri: Agentic Treasury Protocol di Ant International, Agent Pay e Agentic Tokens di Mastercard, Visa Intelligent Commerce, Agent Wallet di Circle, ERC-8004, Circle Payments Network e Compliance Engine, OCBC con Source of Wealth Assistant (SOWA) di Bank of Singapore insieme a un mercato bancario aziendale interno e un agente informativo sui clienti, e il lavoro di abilitazione alle vendite GenAI di Manulife. HSBC e J.P. Morgan Chase hanno contribuito all'articolo senza menzionare casi di studio.
SAFR ha anche definito i vicini nella letteratura sulla governance. Progetto MindForge (MAS con un consorzio di istituzioni finanziarie nel settore bancario, assicurativo e dei mercati dei capitali) ha lanciato la sua fase 2 a novembre 2024 e pubblicato al Singapore FinTech Festival a novembre 2025: un manuale esecutivo con considerazioni 17 in quattro sezioni (ambito e supervisione, gestione del rischio AI, gestione del ciclo di vita dell'intelligenza artificiale, abilitatori) e un manuale di operatività che copre i privilegi minimi per lo strumento degli agenti e l'accesso ai dati, la certificazione degli agenti, la divisione di responsabilità in fase di progettazione tempo, kill switch e timeout e tracciabilità attraverso la registrazione ricercabile. Il Model AI Governance Framework for Agentic AI (2026) inquadra i sistemi ad agenti attorno a quattro componenti principali (modelli, memoria, strumenti, azioni) e un modello di governance in quattro parti (definizione dei casi d'uso, limitazione dell'accesso, supervisione umana, responsabilità della gerarchia principale). AI RMF del NIST (2023) contribuisce al ciclo Mappa, Misura, Gestisci, Governare. SAFR è il livello specifico del runtime di quello stack: strutture di dati, logica di valutazione e contratti di escalation per il momento dell'azione.
Il documento si chiude con un invito aperto: "Le FinTech e le istituzioni finanziarie sono invitate a contribuire al SAFR e al gruppo di lavoro BuildFin.ai condividendo i risultati pilota, identificando le lacune nelle specifiche e sollevando requisiti di dominio non ancora affrontati".
Cosa fare dopo
Per un team che valuta la propria posizione rispetto al SAFR, il primo passo produttivo è una valutazione strutturata del divario tra le dimensioni proprie del documento: inventario e identità degli agenti, mandati, controlli, disposizioni, busta e lineage, operazioni di escalation, audit e prove e modello di implementazione. La lista di controllo della preparazione al SAFR esamina all'incirca 35 domande in stile valutatore in queste otto sezioni e valuta il livello di preparazione per sezione, con una versione di foglio di calcolo modificabile per le sessioni di lavoro.
I team che hanno superato la valutazione e stanno pianificando la costruzione dovrebbero leggere il pezzo complementare, Come implementare SAFR: architettura, modelli e costruzione vs acquisto, che copre l'architettura di riferimento, esempi di controllo funzionanti e un'analisi build-versus-buy.
Come KLA si associa a SAFR
KLA Control Plane implementa il modello SAFR, disponibile oggi: Registro agenti per l'identità dell'agente, Policy Builder per il repository dei controlli, KLA Policy Engine per il motore delle disposizioni e Audit Trail per il registro di controllo, con le quattro disposizioni mappate uno a uno: Nega per bloccare, Escalate per require_approval, Auto-Execute per consentire e Observe per avvisare. La mappatura completa componente per componente, compresi i requisiti operativi e gli indicatori di stato attuali, si trova nella pagina di implementazione SAFR.
Domande frequenti
Cosa significa SAFR?
SAFR sta per Safeguards for Agentic Finance at Runtime. Si tratta di un white paper (versione 1.0, luglio 2026) pubblicato dal programma BuildFin.ai dell'Autorità monetaria di Singapore, che descrive un approccio di riferimento per un livello di governance runtime per l'intelligenza artificiale degli agenti nei servizi finanziari.
Il SAFR è obbligatorio?
No. Il documento afferma che il SAFR "non costituisce una guida normativa o aspettative di vigilanza". È un riferimento del settore. Ogni istituzione rimane responsabile di determinare in che modo la sua implementazione si allinea alle aspettative di vigilanza applicabili e ai suoi requisiti di governance interna.
Chi ha pubblicato SAFR?
Il programma BuildFin.ai di MAS, attraverso un flusso di lavoro dedicato istituito per sviluppare risorse di implementazione per i rischi dell'intelligenza artificiale degli agenti. È stato scritto con otto membri del settore: Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC e Visa.
Quali sono le quattro disposizioni SAFR?
Nega (l'azione viola un vincolo rigido o supera le soglie di rischio e viene rifiutata prima dell'esecuzione, con un motivo specifico registrato), Escalate (l'azione viene trattenuta in attesa della revisione umana), Esegui automaticamente (l'azione procede senza richiedere l'intervento umano) e Osserva (l'azione viene eseguita mentre un'osservazione strutturata viene registrata per la revisione successiva). Tutti e quattro i risultati vengono registrati nel registro di controllo.
Cos'è una busta di governance?
La struttura dati che confeziona l'azione proposta dell'agente con il contesto necessario per valutarla, prima dell'esecuzione. Trasporta tre classi di informazioni: l'azione (tipo, ambito, parametri), la traccia dell'azione (chiamate dello strumento, recupero dei dati e controlli effettivamente eseguiti dall'agente) e metadati di contesto (identità dell'agente, mandato applicabile, stato dell'account o del sistema, vincoli della politica operativa). Poiché il suo contenuto è dichiarato dall'agente, la busta viene trattata come un documento da autenticare rispetto alla sua origine.
In che modo SAFR si collega al progetto MindForge?
Entrambi nascono dalla collaborazione tra l'industria MAS. Project MindForge pubblica ampi manuali sulla governance dell'IA attraverso l'intero ciclo di vita dell'IA: un manuale esecutivo con considerazioni 17 e un manuale sull'operatività che copre pratiche come privilegi minimi, certificazione degli agenti, kill switch e tracciabilità. SAFR è il riferimento specifico del runtime: strutture dati concrete, logica di valutazione e contratti di escalation per valutare ogni azione proposta prima che venga eseguita.
Il SAFR si applica al di fuori di Singapore?
SAFR non ha alcuna forza di supervisione in nessuna giurisdizione, quindi un'istituzione ovunque può implementarla come riferimento del settore pur rimanendo responsabile dell'allineamento dell'implementazione con le aspettative dei propri regolatori. Per informazioni sulla relazione tra SAFR e EU AI Act e con la FINMA, consultare SAFR, EU AI Act e FINMA: Regulators Converge on Runtime Evidence.
Dobbiamo cambiare il codice agente per adottare SAFR?
SAFR definisce due modelli di distribuzione. L'integrazione nativa obbliga l'agente a emettere una busta di governance prima di ogni azione proposta e il documento lo consiglia per nuove implementazioni. Gateway Integration intercetta le chiamate API in uscita a livello dell'infrastruttura e le racchiude in una busta di governance senza modifiche al codice dell'agente, che è il modo in cui i sistemi legacy, gli agenti di terze parti e le distribuzioni esistenti possono essere sottoposti a governance. Il documento suggerisce la copertura del gateway innanzitutto per le istituzioni con molti agenti esistenti, seguita dalla strumentazione nativa per le nuove build.
Punti chiave
SAFR fornisce al settore un vocabolario condiviso e concreto per governare gli agenti di intelligenza artificiale nel momento in cui agiscono: verifica dell'identità, mandati espliciti, disposizioni deterministiche e un record di audit autonomo. Si tratta di un approccio di riferimento, pubblicato affinché le istituzioni possano implementarlo all’interno delle proprie infrastrutture, e il flusso di lavoro dietro di esso sollecita apertamente risultati pilota e rapporti sulle lacune.
La sequenza pratica per la maggior parte dei team: valuta il tuo stato attuale con la lista di controllo della preparazione a SAFR, quindi leggi la guida all'implementazione di SAFR per pianificare la compilazione.
Fonte: Safeguards for Agentic Finance at Runtime, white paper v1.0, MAS BuildFin.ai, luglio 2026. Passaggi citati © Monetary Authority of Singapore. Il SAFR è un riferimento del settore e non costituisce una guida normativa o aspettative di vigilanza. KLA è indipendente e non è affiliata, approvata o certificata da MAS o BuildFin.ai.