Proposta ricevuta: vita ramo I, cliente Bianchi M. 72 anni. Target market pass (over-50 bilanciato). Vulnerable customer over-65: richieste disclosure aggiuntive (informativa precontrattuale rafforzata + consenso espresso). Registro POG: eccezione target market documentata. Proposta sospesa.
AGENTE · IDD GATE
Le proposte di polizza vita e salute passano il controllo IDD prima dell'invio.
IDD Gate verifica ogni proposta di polizza vita e salute prima dell'invio al cliente: disclosure obbligatorie IDD (Insurance Distribution Directive), target market check, vulnerable customer check, aggiornamento del registro POG. Esito tracciato per audit IVASS Reg. 38/40/41. L'intermediario procede solo con proposte conformi.
IDD Gate al lavoro.
Aggiungo le disclosure richieste. Confermo invio pacchetto completo.
Proposta aggiornata: disclosure integrate. Controllo superato. Evento registrato nel registro POG e nel registro audit per audit IVASS.
Perché esiste.
L'Insurance Distribution Directive impone alle compagnie assicurative e agli intermediari vincoli precisi sulla distribuzione di polizze vita e salute: verifica del target market per ogni prodotto distribuito, gestione delle categorie di cliente vulnerabile con disclosure dedicate, aggiornamento del registro POG per ogni transazione. In Italia il quadro è completato dai regolamenti IVASS. Il pre-screening manuale di ogni proposta è lento e soggetto a errori.
Come lavora pre-invio.
IDD Gate si attiva pre-invio della proposta. Estrae i dati del prodotto e del cliente, applica le regole IDD configurate dal team compliance, classifica l'esito: pass silente per le proposte conformi, segnalazione con alternative per le borderline, blocco con escalation al compliance officer per le violazioni significative. Il registro di ogni decisione è disponibile per audit IVASS.
La decisione finale resta all'intermediario.
Per proposte palesemente non conformi, blocco con escalation. Per borderline, segnalazione senza bloccare. Per conformi, pass silente. La decisione finale sull'invio resta sempre dell'intermediario o del compliance officer secondo le procedure della compagnia.
Le figure che gestiscono la conformità distributiva in modo strutturato.
Intermediario RUI o consulente
Riceve feedback in tempo reale sulla proposta prima di inviarla al cliente. Recupera il tempo della verifica manuale, riduce gli errori di disclosure, evita i blocchi successivi del compliance officer.
Target market POG CONFORME
Vulnerable customer VERIFICA
Informativa precontrattuale CONFORME
Registro POG AGGIORNATO
1 verifica richiesta prima dell'invio
Compliance officer IVASS
Ha la traccia ispezionabile di ogni decisione IDD — con il prodotto, il cliente, le regole applicate, l'esito — per gli audit IVASS Reg. 38/40/41.
Tipo sinistro RC Auto
Gravità Media
Liquidatore Dott. Ferrari · Nord-Est
Riserva iniziale € 4.200
Instradato ✓
Responsabile rete distributiva
Vede in modo aggregato i pattern di errore IDD della rete: quali prodotti generano più segnalazioni, quali categorie di cliente richiedono più spesso disclosure aggiuntive. La formazione della rete si basa su dati, non su impressioni.
fnol.receive 09:14:22 ALLOW
triage.classify 09:14:25 ALLOW
idd.check 09:14:31 WARN
liquidation.propose 09:15:02 ALLOW
SELECT * FROM audit_log WHERE claim_id = '2024-0847'
Una proposta borderline gestita in pochi minuti senza blocchi.
Target market, vulnerable customer, registro POG.
Un intermediario RUI prepara una proposta di polizza vita ramo I per un cliente over-70. La proposta arriva nel canale di lavoro dell'agente al momento della compilazione. IDD Gate avvia i tre controlli in sequenza. Target market check: prodotto vita ramo I disegnato per il segmento over-50 con profilo bilanciato. Cliente over-70: dentro il target. Pass.
Vulnerable customer: disclosure aggiuntive richieste.
Vulnerable customer check: cliente over-65, categoria vulnerabile confermata. Il prodotto richiede disclosure aggiuntive — informativa precontrattuale rafforzata e dichiarazione di consenso espresso al rischio del prodotto. Segnalazione con l'elenco esatto delle disclosure mancanti. Aggiornamento registro POG: la transazione richiede tracciatura dell'eccezione target market con documentazione.
L'intermediario integra. La proposta esce conforme.
L'intermediario riceve la segnalazione nel proprio canale di lavoro, aggiunge le disclosure indicate, conferma. La proposta esce con il pacchetto completo. L'evento — proposta, regole applicate, segnalazioni generate, azioni del consulente, esito finale — resta nel registro POG e nel registro audit del runtime per audit IVASS.
Regole dichiarative del team compliance IDD della compagnia.
Le regole di IDD Gate sono dichiarative. Il team compliance IDD della compagnia definisce in formato leggibile le regole di target market per ciascun prodotto (segmento target, eccezioni documentate), le categorie di cliente vulnerabile applicabili (over-65, basso reddito, vulnerabilità finanziaria dichiarata), le disclosure aggiuntive richieste per ciascuna categoria. Le regole vivono nel repository del cliente, versionate. L'integrazione con il gestionale assicurativo e il registro POG si realizza in fase di delivery tramite adapter dedicato.
- 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, topic-guardrail, tool-param-validator
- Canali nativi di consegna
- Slack, Telegram, WhatsApp, HTTP OpenAI-compatible
- Integrazione gestionale assicurativo
- adapter dedicato realizzato in fase di delivery dal team Exelab
- Integrazione registro POG
- adapter dedicato realizzato in fase di delivery dal team Exelab
- Regole IDD
- dichiarative, versionate, scritte dal team compliance della compagnia
- Memoria
- persistente per istanza, pgvector + PostgreSQL FTS
- Registro
- immutabile, interrogabile con client SQL standard (audit IVASS ispezionabile)
Come funziona IDD Gate nel dettaglio.
Per proposte palesemente non conformi (prodotto fuori target market senza motivazione documentata, disclosure obbligatorie mancanti), IDD Gate blocca con escalation al compliance officer. Per proposte borderline, segnala le disclosure aggiuntive richieste all'intermediario senza bloccare. Per proposte conformi, pass silente. La decisione finale sull'invio resta sempre dell'intermediario o del compliance officer secondo le procedure della compagnia.
Le regole sono dichiarative nel repository del cliente. Quando IVASS pubblica un aggiornamento normativo (nuovo regolamento, circolare interpretativa), il team compliance della compagnia aggiorna il file dichiarativo, lo testa in ambiente di sviluppo, lo promuove in produzione. Il ciclo di aggiornamento resta interamente dentro la compagnia, senza dipendenza da un fornitore esterno per ogni variazione normativa.
La configurazione standard è ottimizzata per vita e salute perché l'IDD ha vincoli più stringenti su questi rami. L'estensione ad altri rami (responsabilità civile, property) è possibile aggiungendo le regole dichiarative specifiche. La copertura dei rami prioritari si definisce in fase di discovery con il team compliance della compagnia.
Il pattern tipico per IDD Gate è 12-18 settimane. Discovery e mappatura dei prodotti vita e salute in distribuzione due settimane, configurazione delle regole IDD e delle categorie di cliente vulnerabile tre o quattro settimane, integrazione gestionale e registro POG tre settimane, test con proposte reali e hand-off al compliance officer tre settimane. La durata dipende dalla varietà dei prodotti e dalla struttura del registro POG del cliente.
Da una conversazione di 30 minuti alla squadra in produzione.
Una conversazione di 30-45 minuti per capire come IDD Gate si configurerebbe sul caso del cliente. Quale gestionale assicurativo, quali prodotti vita e salute in distribuzione, quali categorie di cliente vulnerabile prioritarie secondo i regolamenti IVASS.