Aggiornamento inventario: deploy di nuova versione su agente Credit Scoring Spiegabile (v2.1.3 → v2.2.0). Prompt aggiornato. KB invariata. Tier: high. Inventario aggiornato.
L'inventario dei sistemi agentic resta aggiornato con tiering del rischio.
Model Risk Inventory e Tiering mantiene l'inventario di tutti i sistemi agentic della banca: agenti deployati, versione attuale, prompt e knowledge base in uso, tiering del rischio (low, medium, high). Si aggiorna automaticamente sui cambi di versione. Coerente con le linee guida Banca d'Italia sulla gestione del rischio dei modelli.
Model Risk Inventory al lavoro.
Confermato. Aggiungi nota: aggiornamento approvato dal comitato rischi del 14/05.
Nota registrata nel registro inventario. Evidenza disponibile per audit Banca d'Italia.
Perché esiste.
Le banche sono soggette a obblighi di model risk management. Le linee guida di Banca d'Italia, allineate alle linee guida BCE/EBA, richiedono inventario dei modelli usati per decisioni rilevanti, tiering del rischio per ciascun modello, governance del ciclo di vita. Per le banche che integrano sistemi agentic AI, ogni agente rientra nel perimetro: va inventariato e tiering assegnato.
Come mantiene il registro aggiornato.
Per ogni agente deployato nel runtime Polyant della banca, l'agente registra versione attuale, prompt configurato con versioning, knowledge base in uso, tier di rischio assegnato. Sui cambi di versione — modifica del prompt, aggiornamento della knowledge base, deploy di nuovo agente — l'inventario si aggiorna automaticamente. L'output è un registro ispezionabile in tempo reale dal team risk, dal team compliance e dai revisori interni.
La validazione resta al comitato.
L'agente classifica e aggiorna il registro. La validazione del comitato modelli sui cambi di versione resta del team model risk. L'agente apparecchia: aggiorna il registro, segnala i cambi rilevanti, prepara l'evidenza per l'ispezione.
Le figure che governano il rischio dei modelli AI in banca.
Responsabile model risk
Ha l'inventario aggiornato in tempo reale, senza dipendere da aggiornamenti manuali dei team di sviluppo. I cambi di versione rilevanti arrivano segnalati con la classificazione tier già proposta.
Revisore interno ed esterno
Trova l'evidenza strutturata per l'audit Banca d'Italia: versioni, prompt, tiering, motivazioni. Il registro è ispezionabile con un client SQL standard, senza dover ricostruire manualmente le evidenze a ogni revisione.
Responsabile compliance
Vede in un unico registro la copertura dei sistemi agentic rispetto agli obblighi model risk management. Le lacune di inventario diventano visibili prima dell'ispezione, non durante.
Un cambio di versione che entra nel registro senza intervento manuale.
Mercoledì mattina: nuovo deploy sull'agente di credit scoring.
Per la funzione model risk di una banca italiana con quindici agenti AI attivi, un aggiornamento del modello LLM sottostante all'agente di credit scoring viene deployato mercoledì mattina dal team IT. Nel momento del deploy, Model Risk Inventory si attiva. Legge la nuova versione: prompt aggiornato, stesso modello LLM, knowledge base immutata.
Tier high per variazione di prompt rilevante.
L'agente confronta con la versione precedente, identifica la variazione rilevante nel prompt. Classifica il cambio: tier high per effetto sulla decisione di erogazione credito, variazione che richiede validazione del comitato modelli. Il responsabile model risk riceve la notifica sul canale di lavoro con il dettaglio del cambio, la classificazione tier, la richiesta di validazione.
Il responsabile valida. Il registro registra.
Il responsabile avvia il processo di approvazione interno. La validazione del comitato viene registrata nel changelog del registro inventario. L'evento completo — deploy, rilevamento, classificazione, validazione — resta nel registro audit del runtime per ispezione di Banca d'Italia.
Criteri di tiering dichiarativi scritti dal team model risk della banca.
Le regole di Model Risk Inventory sono dichiarative. Il team model risk e compliance della banca definisce in formato leggibile i criteri di tiering del rischio (decisione su persona fisica, soglie di valore, settori regolati), il formato del registro, le regole di notifica sui cambi di versione. Le regole vivono nel repository della banca, versionate, validate all'avvio dell'agente. L'integrazione è nativa con il runtime Polyant: l'agente legge direttamente il registro degli agenti deployati, senza dipendere da segnalazioni manuali dei team di sviluppo. Per le banche con sistemi di model risk già esistenti (SAS Model Risk Management, sistemi proprietari), l'agente può alimentarli in parallelo via adapter dedicato realizzato in fase di delivery.
- Linguaggio
- TypeScript (Node.js)
- Modello LLM
- a scelta del cliente: Anthropic, OpenAI, Mistral, modelli open source ospitati internamente, AWS Bedrock per modello privato
- Controlli built-in usati
- pii-detector, credential-detector, tool-rate-limit
- Canali nativi di notifica
- Slack, Telegram, HTTP OpenAI-compatible
- Integrazione runtime Polyant
- nativa, lettura diretta del registro agenti deployati
- Sistemi di model risk esterni
- adapter dedicato realizzato in fase di delivery (SAS Model Risk Management, sistemi proprietari della banca)
- Memoria
- persistente per istanza, pgvector + PostgreSQL FTS
- Registro
- immutabile, interrogabile con client SQL standard (audit Banca d'Italia ispezionabile)
Domande frequenti sull'agente.
No. Model Risk Inventory si integra con sistemi di model risk esistenti (SAS Model Risk Management, sistemi proprietari della banca) via adapter dedicato realizzato in fase di delivery, oppure opera come registro dedicato ai soli sistemi agentic se la banca non dispone di uno strumento centralizzato. L'obiettivo è colmare il gap di copertura: i sistemi tradizionali di model risk non sono progettati per tracciare il versioning di prompt e knowledge base degli agenti AI.
I criteri di tiering sono dichiarativi e scritti dal team model risk della banca sulla base delle linee guida BCE/EBA recepite da Banca d'Italia: decisione su persona fisica, soglia di valore, settore regolato, reversibilità della decisione. I criteri vengono scritti nel repository della banca in formato leggibile, validati all'avvio e aggiornati ogni volta che le linee guida evolvono.
Il pattern tipico è 8-14 settimane. Discovery 2-3 settimane (mappatura degli agenti esistenti, criteri di tiering), configurazione del registro e delle regole dichiarative 3-4 settimane, eventuale integrazione con sistemi di model risk esistenti 2-4 settimane, hand-off al team model risk 1-2 settimane. La durata effettiva dipende dal numero di agenti attivi e dalla presenza di sistemi di model risk preesistenti.
Da una conversazione di 30 minuti alla squadra in produzione.
Una conversazione di 30-45 minuti per capire come Model Risk Inventory e Tiering si configurerebbe sulla banca. Quanti agenti nel runtime, quali criteri di tiering, quale formato del registro.