Come progettare un data lake in ambito insurtech: la guida passo per passo

In una compagnia assicurativa il dato non manca mai. Manca il modo di metterlo insieme. Il gestionale di polizza sa chi ha comprato cosa, il sistema sinistri sa cosa è successo dopo, il call center ha registrato le telefonate, la scatola nera invia cento punti GPS al minuto, l’attuariato lavora su estrazioni mensili in CSV e il marketing ha il proprio CRM in cloud. Ognuno di questi sistemi ha ragione sui propri numeri e nessuno riesce a rispondere a una domanda che li attraversi tutti: i clienti acquisiti tramite comparatore, con scatola nera attiva, hanno una frequenza sinistri diversa da quelli acquisiti in agenzia, a parità di profilo?

Il data lake è l’infrastruttura che rende possibile quella domanda. Non è un archivio più grande e non è un data warehouse con un altro nome: è il luogo dove convivono dati strutturati (polizze, sinistri, pagamenti), semi-strutturati (eventi telematici, log, risposte di API) e non strutturati (perizie fotografiche, PDF di contratti, audio delle chiamate), mantenuti nella loro forma originale e trasformati solo quando serve.

Nel settore assicurativo questa architettura ha però un vincolo che altrove non esiste con la stessa intensità: quasi ogni dato interessante è un dato personale, e una parte consistente è dato sanitario, giudiziario o comportamentale. Progettare un data lake insurtech senza mettere la governance al centro fin dal primo giorno significa costruire, con grande efficienza tecnica, un problema di conformità.

Questa guida percorre i dieci passi che portano da “abbiamo i dati sparsi in nove sistemi” a “abbiamo una piattaforma dati su cui attuariato, antifrode, pricing e marketing lavorano sugli stessi numeri”.

Data lake, data warehouse, lakehouse: chiarire i termini prima di partire

La confusione terminologica in questo campo produce riunioni inutili e, peggio, architetture ibride costruite per malinteso. Conviene fissare tre definizioni.

Per una compagnia o una insurtech che parte oggi, la risposta praticamente obbligata è la terza: un lakehouse, cioè file colonnari (Parquet) su object storage, organizzati in tabelle attraverso un formato tabellare aperto come Delta Lake, Apache Iceberg o Apache Hudi. Si ottengono le transazioni, l’evoluzione dello schema e la possibilità di rileggere lo stato di una tabella a una data passata — funzionalità che in ambito assicurativo non sono un lusso tecnico ma un requisito: quando l’attuario chiede “com’era la riserva stimata su questo sinistro al 31 dicembre”, il time travel è la risposta.

Nel resto dell’articolo continueremo a dire “data lake” per abitudine, intendendo però questa configurazione.

Passo 1 — Partire dai casi d’uso, non dalle sorgenti

L’errore che consuma più budget nel settore è iniziare dall’inventario delle sorgenti: “portiamo dentro tutto, poi vediamo”. Il risultato è prevedibile — un archivio costoso da mantenere, popolato al 70% da tabelle che nessuno interroga, e un progetto che dopo otto mesi non ha ancora prodotto un numero che qualcuno usi.

Il metodo che funziona è l’opposto: si scelgono da tre a cinque casi d’uso con un beneficiario identificabile per nome, e si porta nel lake solo ciò che serve a quei casi. In ambito insurtech i candidati abituali sono cinque.

• Pricing e tariffazione tecnica. Serve la storia completa di polizze e sinistri con le esposizioni corrette (anni-polizza, non numero di contratti) e le caratteristiche di rischio alla data di emissione, non quelle di oggi.
• Antifrode. Serve la rete delle relazioni fra soggetti, veicoli, officine, periti e testimoni, più la cronologia delle denunce e i dati delle banche dati esterne.
• Gestione del sinistro e riservazione. Servono gli eventi del ciclo di vita del sinistro con le loro date reali, i movimenti di riserva e i pagamenti, a granularità di singolo movimento.
• Retention e portafoglio. Servono scadenze, rinnovi, disdette, contatti, sinistri subiti, e la storia dei prezzi proposti e accettati.
• Reporting regolamentare e amministrativo. Solvency II, IFRS 17, segnalazioni all’autorità di vigilanza: qui i requisiti di tracciabilità e riproducibilità sono più stringenti di qualsiasi esigenza analitica.

Per ciascun caso d’uso vanno scritte, prima di toccare una riga di codice, quattro informazioni: chi è l’utente finale, quali domande deve poter fare, con quale latenza accettabile (il pricing tollera il dato di ieri, l’antifrode in fase di apertura sinistro no), e con quale numero già noto il risultato dovrà riconciliarsi. Quest’ultimo punto è il più sottovalutato e ne riparleremo al passo 7.

Passo 2 — Censire le sorgenti e disegnare la mappa del dominio

Solo ora si guarda cosa c’è. Il censimento in una realtà assicurativa restituisce quasi sempre le stesse famiglie di sorgenti, con caratteristiche tecniche molto diverse fra loro.

Per ogni sorgente vanno raccolte cinque informazioni operative: modalità di accesso, frequenza di aggiornamento, chiave che identifica univocamente un record, meccanismo per riconoscere un record modificato o cancellato, e — la più importante, la più dimenticata — il nome della persona che sa spiegare le stranezze. In un gestionale assicurativo di vent’anni le stranezze sono decine: il codice ramo che ha cambiato significato nel 2014, le polizze con data effetto al 1900 usate come segnaposto, i sinistri con importo negativo che sono in realtà recuperi.

Accanto al censimento tecnico serve la mappa del dominio: l’elenco delle entità assicurative canoniche e delle loro relazioni, indipendente da come i sistemi le chiamano. È un lavoro di una settimana che si ripaga per anni, perché è ciò che permette di dire “cliente” intendendo la stessa cosa in tutta l’azienda. Le entità di base sono sempre queste:

contraente / assicurato / beneficiario   (tre ruoli, spesso la stessa persona, mai la stessa colonna)
    |
polizza ──< garanzia ──< massimale, franchigia, premio
    |
    ├──< movimento di polizza   (emissione, variazione, sospensione, annullo, rinnovo)
    ├──< titolo / quietanza ──< incasso
    |
    └──< sinistro ──< evento di sinistro   (denuncia, perizia, riserva, pagamento, chiusura, riapertura)
                  └──< controparte, veicolo, testimone, perito, officina

Due avvertenze che valgono per qualsiasi compagnia. La prima: contraente, assicurato e beneficiario sono ruoli, non entità — modellarli come tre campi della polizza rende impossibile rispondere a “quante persone abbiamo in portafoglio”. La seconda: il sinistro non è un record, è una storia. Tutto ciò che conta nella gestione dei sinistri — durata, sviluppo della riserva, riaperture — si perde se si copia solo lo stato corrente.

Passo 3 — Definire le zone del lake

La struttura interna è la decisione architetturale più importante, e fortunatamente è anche quella più consolidata. Qualunque sia la tecnologia, servono quattro zone, con regole di accesso e di scrittura diverse.

• Landing. Il file arriva e viene depositato così com’è, senza alcuna trasformazione: il CSV con il suo separatore sbagliato, il JSON con i campi mancanti, il PDF. Immutabile, con la data di arrivo nel percorso. È l’unica copia che permette di rifare tutto da zero quando — e succederà — si scoprirà che una regola di pulizia era errata.
• Raw (o bronze). Gli stessi dati convertiti in formato colonnare e tabellare, con lo schema della sorgente intatto e l’aggiunta dei metadati tecnici: sistema di origine, timestamp di caricamento, identificativo del lotto. Nessuna regola di business è applicata qui. Nessuna.
• Curated (o silver). Il livello dove i dati diventano coerenti: tipi normalizzati, date validate, deduplica delle anagrafiche, riconciliazione dell’identità fra sistemi, applicazione delle definizioni aziendali, storicizzazione. Qui si concentra il 70% del codice e il 100% delle decisioni difficili.
• Consumption (o gold). I prodotti dati pensati per chi li usa: il data mart dimensionale per il reporting, le tabelle di feature per i modelli di pricing, le viste per l’antifrode, gli estratti per l’attuariato. Ogni prodotto ha un proprietario e un pubblico.

L’organizzazione fisica delle cartelle merita attenzione, perché condiziona per anni il costo delle query. Una convenzione che funziona:

s3://compagnia-lake/
  landing/   {sorgente}/{entita}/ingestion_date=2026-09-15/file_originale.csv
  raw/       {sorgente}/{entita}/ingestion_date=2026-09-15/part-0001.parquet
  curated/   {dominio}/{entita}/anno=2026/mese=09/part-0001.parquet
  gold/      {prodotto_dati}/{tabella}/...

Domini tipici in curated/:  anagrafica  portafoglio  sinistri  telematica  distribuzione  finanza

Sul partizionamento, una regola pratica ricavata dagli errori altrui: si partiziona per la colonna su cui si filtra sempre, e nel mondo assicurativo quella colonna è quasi sempre una data. Ma quale data non è ovvio. Per i sinistri, partizionare per data di accadimento sembra naturale e produce un disastro operativo, perché ogni denuncia tardiva riscrive partizioni vecchie di mesi; partizionare per data di caricamento rende invece ogni scrittura un’aggiunta pura. La soluzione abituale è partizionare il livello raw per data di caricamento e il livello curato per la data di business, accettando il costo della riscrittura dove serve davvero.

Passo 4 — Progettare l’ingestione

Le sorgenti censite al passo 2 richiedono tre modalità di ingestione diverse, e una quarta che nel settore assicurativo è quasi sempre necessaria.

Batch da sistemi relazionali

È il caso più semplice e il più frequente. La domanda decisiva è come si riconoscono i record modificati. Se il gestionale ha una colonna di ultima modifica affidabile, si fa un caricamento incrementale su quella. Se non ce l’ha — situazione comune nei sistemi legacy assicurativi — le opzioni sono due: un caricamento completo notturno (accettabile fino a qualche decina di milioni di righe) oppure il Change Data Capture dai log di transazione del database, che ha il vantaggio non trascurabile di catturare anche le cancellazioni fisiche, invisibili a qualsiasi confronto per data.

Il CDC è anche l’unica tecnica che risolve alla radice il problema della storicizzazione: se il gestionale sovrascrive l’indirizzo del cliente, solo il CDC conserva quello precedente. E in assicurazione l’indirizzo precedente non è un dettaglio, è un fattore tariffario.

Streaming per la telematica

I dati da scatola nera, sensori domestici o app di guida arrivano continuamente e in volume sproporzionato rispetto a tutto il resto: un portafoglio di 50.000 veicoli connessi genera più righe in una settimana di quante ne produca l’intero sistema di polizza in dieci anni. Vanno trattati con una logica diversa dal resto del lake.

Il pattern consolidato prevede un bus di eventi (Kafka o equivalente gestito) che scrive in continuo sul livello raw, e un processo di aggregazione che produce, sul livello curato, le metriche per viaggio e per polizza-mese: chilometri, distribuzione oraria, frenate brusche normalizzate, tipologia di strada percorsa. Sono le aggregazioni a finire nei modelli di pricing, non i punti grezzi, ed è una scelta che serve tanto le prestazioni quanto la minimizzazione dei dati: la traccia GPS punto per punto rivela dove una persona dorme, lavora e passa il tempo libero, e conservarla oltre il necessario è un rischio sproporzionato rispetto al suo valore analitico marginale.

Documenti e dati non strutturati

Perizie fotografiche, moduli di constatazione amichevole, referti, contratti firmati, registrazioni del call center: nel lake il file è l’inizio, non la fine. Il pattern è depositare il documento nella landing, estrarne il contenuto con OCR o trascrizione, e scrivere nel livello curato una tabella con i campi estratti, il riferimento al file originale e — questo è essenziale — un indicatore di confidenza dell’estrazione.

La regola che evita guai: un dato estratto automaticamente non è un dato verificato. Va marcato come tale, e nessun processo con effetti sul cliente (liquidazione, rifiuto, segnalazione antifrode) dovrebbe basarsi su un campo estratto senza controllo umano. È una cautela tecnica che diventa un requisito giuridico nel momento in cui il processo rientra fra quelli disciplinati dalla normativa sulle decisioni automatizzate.

Fonti esterne e riferimenti

Banche dati antifrode, anagrafiche veicoli, dati meteorologici storici, dati territoriali ISTAT, indici di rivalutazione. Hanno due caratteristiche da gestire esplicitamente: cambiano lentamente ma cambiano (e servono nella versione valida alla data dell’evento, non in quella odierna), e spesso arrivano con vincoli contrattuali su finalità d’uso e periodo di conservazione, che vanno registrati come metadati della tabella e non in una mail.

Passo 5 — Modellare il livello curato

Qui il lake smette di essere un deposito e diventa una piattaforma. Tre decisioni concentrano quasi tutto il valore.

Risolvere l’identità

È il problema numero uno del dato assicurativo e non ha una soluzione puramente tecnica. La stessa persona compare come cliente auto con un codice, come cliente casa con un altro, come controparte in un sinistro con un terzo, e nel CRM con un indirizzo email. La domanda “quanti clienti abbiamo” non ha risposta finché non si decide cosa sia un cliente.

L’approccio che regge è a due livelli: una chiave deterministica dove esiste un identificativo forte e verificato (codice fiscale, partita IVA), e un abbinamento probabilistico dove non esiste, con una soglia di confidenza e la conservazione dei candidati scartati. Il risultato è una tabella ponte che assegna a ogni identità sorgente una chiave master, con l’indicazione del metodo e del punteggio.

-- Tabella ponte delle identità: mai sovrascritta, sempre versionata
CREATE TABLE curated.anagrafica_identita_ponte (
    identita_master_key   BIGINT      NOT NULL,   -- la persona "vera"
    sistema_origine       STRING      NOT NULL,   -- 'gestionale_auto', 'crm', 'sinistri'
    id_origine            STRING      NOT NULL,   -- la chiave nel sistema di origine
    metodo_abbinamento    STRING      NOT NULL,   -- 'codice_fiscale' | 'probabilistico' | 'manuale'
    punteggio             DECIMAL(5,4),           -- valorizzato solo se probabilistico
    valido_da             DATE        NOT NULL,
    valido_a              DATE,                   -- NULL = versione corrente
    rivisto_da_operatore  BOOLEAN     NOT NULL DEFAULT false
);

Il campo finale non è burocrazia: gli abbinamenti probabilistici sbagliati in assicurazione hanno conseguenze concrete — un sinistro attribuito alla persona sbagliata cambia la tariffa di rinnovo — e serve poter distinguere ciò che una persona ha confermato da ciò che un algoritmo ha ipotizzato.

Storicizzare tutto ciò che varia

Una polizza non è un record, è una successione di versioni: emissione, appendice per cambio veicolo, sospensione, riattivazione, rinnovo con premio diverso. Se il livello curato conserva solo lo stato attuale, qualsiasi analisi retrospettiva è falsata — e in un settore dove il ciclo di vita del prodotto si misura in anni, l’analisi retrospettiva è l’unica che conti.

La forma da adottare è la dimensione storicizzata con intervalli di validità: ogni versione ha una data di inizio, una di fine e un flag di corrente. La domanda “qual era il massimale il giorno dell’incidente” diventa allora una condizione nella clausola WHERE, invece che una ricostruzione manuale.

-- Il premio incassato nel 2025 per le polizze auto,
-- con le caratteristiche di rischio valide alla data del movimento
SELECT
    d.provincia_residenza,
    d.fascia_eta,
    p.alimentazione_veicolo,
    SUM(m.premio_imponibile) AS premio_2025
FROM curated.movimento_polizza  m
JOIN curated.dim_polizza        p
  ON  p.polizza_key = m.polizza_key
  AND m.data_effetto BETWEEN p.valido_da AND COALESCE(p.valido_a, DATE '9999-12-31')
JOIN curated.dim_contraente     d
  ON  d.identita_master_key = p.contraente_key
  AND m.data_effetto BETWEEN d.valido_da AND COALESCE(d.valido_a, DATE '9999-12-31')
WHERE m.ramo = 'AUTO_RCA'
  AND m.data_effetto >= DATE '2025-01-01'
  AND m.data_effetto <  DATE '2026-01-01'
GROUP BY 1, 2, 3;

Dichiarare la granularità delle tabelle di fatto

Ogni tabella di fatto va aperta da una frase che ne dichiara la grana, scritta prima del codice: “una riga per ogni movimento contabile di sinistro”, “una riga per ogni polizza-mese di esposizione”. Senza questa frase, prima o poi qualcuno farà una giunzione che duplica le righe e il premio risulterà più alto del vero. È l’errore più frequente in assoluto e il più difficile da individuare, perché il numero sbagliato resta plausibile.

Nel dominio assicurativo tre tabelle di fatto coprono la gran parte dei bisogni: esposizione (una riga per polizza-garanzia-periodo, con gli anni-polizza calcolati), movimenti di premio (emissioni, storni, incassi) e movimenti di sinistro (aperture, variazioni di riserva, pagamenti, recuperi, chiusure). Da queste tre si derivano frequenza, costo medio, loss ratio e sviluppo delle riserve senza mai tornare ai sistemi di origine.

Passo 6 — Governance, privacy e conformità

Questo passo compare in sesta posizione per comodità espositiva, ma nella realtà del progetto va avviato insieme al passo 1 e attraversa tutti gli altri. In assicurazione è ciò che distingue una piattaforma dati utilizzabile da una che l’ufficio compliance bloccherà tre giorni prima del rilascio.

Classificare i dati prima di ingerirli

Ogni colonna che entra nel lake deve avere una classificazione dichiarata, e la classificazione deve essere leggibile da un programma, non da un essere umano che consulta un foglio di calcolo. Quattro livelli sono sufficienti:

La classificazione va scritta come metadato della tabella nel catalogo e verificata automaticamente in fase di caricamento: una colonna non classificata non entra. È una regola severa che evita l’esito più comune — la scoperta, due anni dopo, che il campo note_perizia del ramo infortuni contiene diagnosi in chiaro replicate in quattro data mart.

Pseudonimizzare per default

Il principio operativo è che il livello analitico non deve poter identificare una persona per svolgere il proprio lavoro. Un modello di pricing ha bisogno dell’età, della provincia e della storia sinistri; non ha bisogno del nome e del codice fiscale. La struttura che regge è il tokenizzato per default: nel livello curato gli identificativi diretti sono sostituiti da chiavi surrogate, e la corrispondenza con i dati identificativi vive in una tabella separata, in una zona con controllo d’accesso proprio, interrogabile solo dai processi che hanno una finalità operativa che lo richiede — la liquidazione di un sinistro, l’invio di una comunicazione contrattuale.

Accanto a questo servono tre meccanismi, tutti da prevedere nell’architettura e non da aggiungere dopo: il mascheramento dinamico in base al ruolo di chi interroga; la cancellazione selettiva, che è il motivo tecnico più solido per adottare un formato tabellare transazionale — cancellare le righe di una persona da un lake di file Parquet nudi è un’operazione che nessuno vuole dover improvvisare alla prima richiesta; e la conservazione differenziata, con politiche di eliminazione automatica diverse per zona e per classificazione.

I vincoli specifici del settore

Quattro filoni normativi incidono direttamente sull’architettura, e vale la pena conoscerne l’impatto tecnico prima di disegnare le tabelle.

Dati sanitari e categorie particolari. I rami vita, salute e infortuni trattano dati che il GDPR colloca fra le categorie particolari, con basi giuridiche ristrette e requisiti di sicurezza rafforzati. Sul piano architetturale questo si traduce in una separazione fisica, non logica: zona dedicata, chiavi di cifratura distinte, accesso nominale tracciato e divieto di replica verso i mart generalisti.

Decisioni automatizzate e AI Act. Il regolamento europeo sull’intelligenza artificiale classifica fra i sistemi ad alto rischio quelli usati per la valutazione del rischio e la tariffazione nei rami vita e salute, e dal 2 agosto 2026 i relativi obblighi sono operativi. Le implicazioni per il data lake sono concrete e riguardano proprio la piattaforma dati: documentazione della provenienza e della qualità dei dati di addestramento, tracciabilità delle versioni dei dataset, conservazione dei log, valutazione dei bias nei dati usati. Un lake che non versiona i dataset di training non è in grado di sostenere questi obblighi, e riadattarlo a posteriori è molto più costoso che prevederlo.

Antifrode e banche dati di vigilanza. Le compagnie che operano nella r.c. auto interagiscono con le banche dati antifrode gestite dall’autorità di vigilanza — archivio integrato antifrode, banca dati sinistri, anagrafi di testimoni e danneggiati. I dati che ne derivano hanno finalità d’uso vincolata: vanno isolati, e il modello di accesso deve poter dimostrare che non sono confluiti in usi diversi da quello previsto, per esempio nel marketing.

Reporting di vigilanza e contabile. Solvency II e IFRS 17 impongono che i numeri riportati siano riproducibili a distanza di anni. Tradotto in requisiti tecnici: versionamento dei dati e non solo del codice, capacità di rieseguire una pipeline con i dati come erano a una certa data, e tracciamento della derivazione dal dato di origine alla cifra pubblicata. Il time travel dei formati tabellari moderni e una disciplina rigorosa di lineage sono l’unica risposta sostenibile.

Il catalogo e i contratti dati

Un data lake senza catalogo diventa una palude in meno tempo di quanto si pensi, e il punto di non ritorno è più vicino del previsto: succede quando la persona che sapeva cosa contenesse una certa tabella cambia ruolo. Il catalogo deve contenere, per ogni tabella: proprietario nominativo, descrizione in italiano comprensibile, classificazione di riservatezza, frequenza di aggiornamento, derivazione a monte e a valle, e regole di qualità attese.

Il complemento utile è il contratto dati fra chi produce e chi consuma: un file versionato che dichiara schema, granularità, valori ammessi, latenza garantita e comportamento in caso di modifica. Rende esplicito ciò che altrimenti resta implicito, e soprattutto rende una modifica di schema una negoziazione anziché un’interruzione a sorpresa del reporting mensile.

Passo 7 — Qualità del dato e riconciliazione

La qualità del dato in assicurazione ha una caratteristica che la rende diversa da altri settori: esiste quasi sempre un numero ufficiale con cui confrontarsi. Il premio contabilizzato sta nel bilancio, la riserva sinistri è certificata, il numero di polizze in portafoglio è comunicato alla vigilanza. Questo è un enorme vantaggio e va sfruttato fino in fondo.

La regola: il primo test da scrivere, prima di qualunque altro, è quello di riconciliazione con la fonte di verità aziendale. Se il premio 2025 calcolato dal lake non coincide con quello del bilancio, il progetto è fermo finché non si capisce perché. Nella pratica la spiegazione è quasi sempre istruttiva: un tipo di movimento escluso, gli accessori contati due volte, le polizze in coassicurazione prese al 100% anziché per la quota di competenza. Ognuno di questi scarti, trovato prima del rilascio, è una crisi di credibilità evitata.

Attorno a questo test se ne costruiscono altri quattro tipi, eseguiti a ogni caricamento:

• Test strutturali — unicità delle chiavi, integrità referenziale fra sinistro e polizza, assenza di valori nulli dove non ammessi.
• Test di plausibilità di dominio — una data di denuncia non può precedere la data di accadimento; un sinistro non può avere data di accadimento fuori dal periodo di copertura; un premio imponibile negativo deve corrispondere a uno storno esplicito.
• Test di volume e continuità — se il caricamento di oggi porta il 40% di righe in meno della media dei trenta giorni precedenti, si ferma la pipeline e si avvisa: è quasi sempre un’estrazione incompleta, e propagarla a valle è peggio che ritardare il dato.
• Test di deriva — la distribuzione delle variabili usate dai modelli di pricing va monitorata nel tempo; un cambiamento improvviso nella distribuzione di una variabile segnala, il più delle volte, una modifica nel sistema di origine che nessuno ha comunicato.

# Esempio di regole di qualità dichiarative sulla tabella dei movimenti di sinistro
tabella: curated.movimento_sinistro
granularita: "una riga per ogni movimento contabile di sinistro"
proprietario: data.sinistri@compagnia.it
classificazione: personale_comune

test:
  - unico: [sinistro_key, movimento_seq]
  - non_nullo: [sinistro_key, data_movimento, tipo_movimento, importo]
  - riferimento:
      colonna: sinistro_key
      verso: curated.dim_sinistro.sinistro_key
  - espressione:
      nome: denuncia_non_anteriore_ad_accadimento
      regola: "data_denuncia >= data_accadimento"
      gravita: blocca
  - espressione:
      nome: accadimento_dentro_copertura
      regola: "data_accadimento BETWEEN polizza_effetto AND polizza_scadenza"
      gravita: avvisa          # le riaperture e le retroattività legittime esistono
  - volume:
      confronto: media_mobile_30g
      tolleranza_inferiore: 0.6
      gravita: blocca

riconciliazione:
  - nome: pagato_annuo_vs_bilancio
    query_lake: "SELECT anno, SUM(importo) FROM ... WHERE tipo_movimento = 'PAGAMENTO'"
    fonte_verita: finanza.riepilogo_sinistri_bilancio
    tolleranza_eur: 1.00
    gravita: blocca

Passo 8 — Esporre i dati a chi li usa

Un data lake a cui accedono solo tre data engineer ha fallito, per quanto sia ben costruito. Il livello di consumo va progettato per pubblici distinti, ognuno con strumenti e aspettative diverse.

Sul fronte del pricing vale la pena insistere su un punto che è la causa numero uno di modelli che funzionano in laboratorio e deludono in produzione: la contaminazione temporale. Se il modello di tariffazione viene addestrato usando le caratteristiche del cliente come sono oggi, e non come erano al momento dell’emissione della polizza, impara relazioni che al momento della decisione reale non saranno disponibili. In un settore dove fra l’emissione e il sinistro possono passare anni, l’effetto è tutt’altro che marginale. Un feature store con validità temporale esplicita — ogni variabile ha una finestra di validità e viene letta “come era a quella data” — è il modo strutturale per non doverci pensare ogni volta.

Passo 9 — Orchestrazione, osservabilità e costi

Le pipeline vanno orchestrate con uno strumento che gestisca dipendenze, tentativi ripetuti e ricariche retroattive: Airflow è lo standard diffuso, Dagster e Prefect sono alternative più moderne nella gestione delle dipendenze fra dati. Tre requisiti valgono in ogni caso: idempotenza (rieseguire due volte lo stesso caricamento non deve duplicare nulla), ricarica retroattiva parametrica (ricalcolare marzo senza toccare aprile) e notifica dei fallimenti a una persona con nome e cognome.

L’osservabilità della piattaforma dati è diversa dal monitoraggio dei sistemi: qui non conta solo se il processo è andato a buon fine, ma se il dato è arrivato, è completo, è puntuale ed è coerente. Le quattro metriche da esporre in un cruscotto che qualcuno guardi davvero sono: freschezza per tabella (quanto tempo è passato dall’ultimo aggiornamento), volume caricato rispetto all’atteso, percentuale di test superati e derivazione aggiornata.

Sui costi, il modello del data lake su object storage è ingannevolmente economico allo stoccaggio e sorprendentemente caro nell’interrogazione. Quattro accorgimenti risolvono la gran parte dei casi: usare sempre formati colonnari compressi; compattare i file piccoli, perché mille file da un megabyte costano molto più di un file da un gigabyte; spostare la telematica grezza su classi di archiviazione fredde dopo poche settimane, visto che il valore analitico dopo l’aggregazione è marginale; e monitorare i costi per prodotto dati, non per servizio, così che la domanda “vale la pena mantenere questo mart” abbia una risposta numerica.

Passo 10 — Mettere in esercizio e mantenere

Il rilascio di una piattaforma dati non è un evento ma una serie di passaggi di consegne. Tre pratiche fanno la differenza fra un lake che cresce e uno che si degrada in silenzio.

Un periodo di esecuzione in parallelo. Per almeno due cicli di chiusura, il nuovo sistema produce i numeri accanto a quello vecchio e ogni scostamento viene spiegato. È noioso, allunga il progetto di qualche settimana ed è l’unico modo per arrivare al rilascio con la fiducia dell’amministrazione.

Un proprietario per ogni prodotto dati. Non un team generico: una persona, responsabile della qualità, delle definizioni e delle richieste di modifica. I data lake che degradano sono quasi sempre quelli in cui tutte le tabelle appartengono a “il team dati”.

Un documento di contesto vivo. Una pagina che raccoglie gli obiettivi, le definizioni aziendali decise, le convenzioni di denominazione, le stranezze note delle sorgenti e le decisioni architetturali con la loro motivazione. Serve alle persone nuove, serve agli assistenti basati su AI che oggi si usano per generare trasformazioni, e serve a voi fra otto mesi quando non ricorderete perché quel tipo di movimento era stato escluso.

Sette errori che fanno fallire questi progetti

1. Ingerire tutto prima di sapere a cosa serve. Produce una palude costosa e un progetto senza risultati visibili per mesi. Tre casi d’uso e le sorgenti che li servono valgono più di novanta tabelle caricate “per completezza”.
2. Copiare solo lo stato corrente dei sistemi. In assicurazione l’analisi è retrospettiva per natura: senza storicizzazione delle polizze e senza gli eventi dei sinistri, il lake risponde solo a domande sul presente, che sono le meno interessanti.
3. Rimandare la governance a dopo il rilascio. Classificare i dati e separare le categorie particolari a posteriori significa rifare le pipeline. È il ritardo più costoso del settore.
4. Non riconciliare con il bilancio. Un numero che non coincide con quello ufficiale distrugge la fiducia nella piattaforma, e la fiducia si guadagna una volta sola.
5. Trattare la telematica come le altre sorgenti. Volume, frequenza e sensibilità sono di un ordine diverso: senza una strategia dedicata di aggregazione e conservazione, i costi e il rischio privacy crescono insieme.
6. Costruire modelli su variabili contaminate dal futuro. Prestazioni eccellenti in prova, deludenti in produzione, e settimane perse a cercare la causa nel modello anziché nei dati.
7. Considerarlo un progetto che finisce. Le sorgenti cambiano, i prodotti assicurativi cambiano, la normativa cambia. Senza presidio continuo il lake degrada in silenzio, e ci si accorge del problema quando un numero sbagliato arriva in un comitato.

Checklist prima di dichiarare il data lake operativo

• Esistono da tre a cinque casi d’uso con un beneficiario identificato per nome.
• La mappa del dominio distingue contraente, assicurato e beneficiario come ruoli.
• Le quattro zone sono separate e il livello di atterraggio è immutabile.
• Le tabelle usano un formato transazionale con time travel e cancellazione selettiva.
• Ogni sorgente ha un meccanismo dichiarato per riconoscere modifiche e cancellazioni.
• Le polizze sono storicizzate con intervalli di validità.
• Ogni tabella di fatto dichiara la propria granularità in una frase.
• Ogni colonna ha una classificazione di riservatezza nel catalogo; nessuna colonna non classificata entra.
• I dati sanitari stanno in una zona separata con accesso nominale e tracciato.
• Esiste una procedura provata di cancellazione dei dati di una persona su richiesta.
• I dataset usati per addestrare modelli di pricing sono versionati e documentati.
• Il test di riconciliazione con il bilancio esiste, è automatico e passa.
• Le pipeline sono idempotenti e ricaricabili per periodo.
• Freschezza, volume e qualità sono esposti in un cruscotto che qualcuno guarda.
• Ogni prodotto dati ha un proprietario con nome e cognome.
• Il documento di contesto è aggiornato e accessibile.

Conclusioni

Progettare un data lake in ambito insurtech è, per la parte tecnologica, un problema ampiamente risolto: object storage, formati colonnari, un formato tabellare transazionale, un orchestratore e un motore di interrogazione. Le scelte tecniche contano, ma nessuna di esse decide l’esito del progetto.

Ciò che lo decide è altro, e si concentra in tre punti. Il primo è la fedeltà al dominio assicurativo: un lake che non distingue i ruoli sulla polizza, non storicizza le versioni e non conserva gli eventi del sinistro risponderà velocemente a domande che non interessano a nessuno. Il secondo è la governance nativa: in un settore dove il dato è quasi sempre personale e spesso sensibile, classificazione, pseudonimizzazione e tracciabilità non sono un livello aggiuntivo ma parte della struttura portante. Il terzo è la riconciliazione: la piattaforma vive o muore sulla capacità di produrre numeri che coincidono con quelli che l’azienda già conosce.

Il consiglio operativo per iniziare è di restringere drasticamente il campo: un ramo solo, due sorgenti, tre tabelle di fatto, un caso d’uso con un destinatario che ha fretta di avere la risposta. Un data lake piccolo di cui tutti si fidano vale infinitamente più di una piattaforma completa su cui l’attuario continua a rifare i conti per conto proprio — e l’estensione, da lì, è una questione di aggiungere sorgenti, non di rifare l’architettura.