CATALYST porta su tecnologie attuali il software che da anni regge i processi critici di banche, assicurazioni e grandi aziende, e prima di ogni rilascio verifica che si comporti come prima. Gira nell'infrastruttura del cliente: il codice non passa dai server di KVA.
Molte aziende si reggono su applicazioni legacy: software costruito anni o decenni fa, spesso con tecnologie che non si sviluppano più, che gestisce ancora processi critici come pagamenti, polizze e contabilità. Finché funziona, nessuno vuole toccarlo. Ma rimandare non è gratis: intorno a quel software cambia tutto il resto.
debito tecnico
Chi ha scritto e mantenuto questi sistemi, con gli anni, va in pensione o cambia lavoro, e ogni modifica finisce per dipendere da poche persone. Sostituirle non è semplice: Banca d'Italia indica il difficile reperimento di personale qualificato fra i principali ostacoli alle strategie digitali degli intermediari.
Banca d'Italia, Indagine Fintech 2025 (dic. 2025)Un esempio: molte applicazioni aziendali sono scritte per .NET Framework. Nel 2019 Microsoft ne ha indicato la 4.8 come ultima versione principale. Le applicazioni esistenti possono restarci, perché resta supportato, ma gli investimenti futuri, dal linguaggio alle librerie, vanno solo su .NET moderno.
Microsoft, .NET Blog (mag. 2019)Collegare sistemi vecchi a canali digitali, dati e intelligenza artificiale è lento e costoso. Per Banca d'Italia la scarsa interoperabilità fra le nuove tecnologie e i sistemi legacy è l'altro grande ostacolo alle strategie digitali.
Banca d'Italia, Indagine Fintech 2025 (dic. 2025)Il regolamento europeo DORA chiede a banche e assicurazioni una valutazione del rischio specifica per tutti i sistemi legacy, almeno una volta l'anno e comunque prima e dopo ogni connessione di tecnologie, applicazioni o sistemi.
Reg. UE 2022/2554 (DORA), art. 8, par. 7Modernizzare vuol dire portare un'applicazione su tecnologie attuali senza cambiarne il comportamento: stessi calcoli, stessi controlli, stessi risultati. Il codice migrato compila, la demo funziona, il collaudo passa. Ma il legacy quasi mai ha test automatici, e senza test non c'è un modo ovvio di dimostrare che nulla è cambiato: le differenze emergono in produzione, a volte mesi dopo. Capita che l'unica traccia della parità sia una checklist di collaudo con le colonne vuote.
parità funzionale
Nella valutazione annuale della BCE rischio operativo e ICT ricevono i punteggi medi peggiori, e i fermi non pianificati nascono spesso da modifiche ai sistemi ICT. Nel ciclo 2026-28 la BCE ne rivede la gestione. Una migrazione è una modifica ICT.
BCE, priorità di vigilanza 2026-28 (nov. 2025)L'AI è già in uso nel 70% delle assicurazioni e nel 59% delle banche italiane intervistate. Solo il 16% dei rispondenti ha introdotto un quadro di governance dedicato; altri hanno adattato quelli esistenti. Chi usa l'AI per migrare deve poterlo governare.
OCSE con Banca d'Italia, apr. 2026 · 450 risposteCATALYST esegue la modernizzazione dall'analisi del codice legacy alla verifica finale. Gli agenti AI — programmi basati su modelli di intelligenza artificiale che leggono e scrivono codice — fanno il lavoro interpretativo. A decidere se si può proseguire sono controlli automatici con esito ripetibile e, alla fine, una persona.
assured migration
Codice .NET 10 / C# 14 scritto come lo scriverebbe oggi uno sviluppatore esperto, non tradotto riga per riga. Anche l'interfaccia passa a tecnologie attuali (per esempio da WinForms a WPF), a parità di funzioni. Lo schema del database resta com'è.
Dove è finito ogni elemento del vecchio sistema, quali differenze sono emerse e come sono state chiuse, quali eccezioni sono state decise e da chi. In fondo, la firma del responsabile di business del cliente.
Regole di business, dipendenze e documentazione tecnica ricostruite dal codice, ciascuna con il riferimento al punto da cui viene. Restano al cliente, anche quando il programma finisce.
CATALYST si installa nell'infrastruttura del cliente, in sede o nel suo cloud (AWS, Google Cloud, Azure): il codice resta lì, e lo strumento lo usa il team del cliente.
Mettere mano a un'applicazione vecchia è l'occasione per fare ciò che si rimanda da anni: nuove funzioni, un'interfaccia ridisegnata, controlli di sicurezza aggiornati. CATALYST le raccoglie durante l'analisi come raccomandazioni e le tiene fuori dalla migrazione: prima si verifica che nulla si sia rotto, poi le migliorie si realizzano su codice moderno e documentato, come modifiche dichiarate. Mescolarle renderebbe impossibile distinguere una modifica voluta da un errore.
Il lavoro procede un'applicazione alla volta, in tre fasi. Fra una fase e l'altra un controllo automatico decide se si può proseguire; un'eccezione richiede una motivazione scritta e un autore, che restano registrati nel fascicolo.
gate deterministici · bypass tracciato
Prima di partire, CATALYST legge l'intero parco applicativo: librerie condivise e dipendenze fra applicazioni decidono l'ordine in cui affrontarle.
Legge il codice legacy e ne censisce ogni elemento — schermate e controlli, funzioni, eventi, regole di business, dipendenze — con il riferimento al punto del codice da cui viene. Valuta anche quanto è lontano il punto d'arrivo: passare da VB.NET a C# è più vicino che passare da COBOL a Java.
Riscrive l'applicazione nello stack di destinazione in modo idiomatico e registra, per ogni elemento censito, dove è finito o perché non c'è più. Nelle applicazioni grandi lo fa con controlli intermedi lungo la strada.
Prima i controlli automatici: compilazione e ricerca di schemi d'errore noti. Poi un agente distinto, configurato con soli strumenti di lettura, confronta vecchio e nuovo elemento per elemento e cerca attivamente le differenze. Il verdetto è un conteggio: due o più scostamenti sullo stesso tema danno esito negativo.
Dove si applica oggi. In produzione su applicazioni .NET, da VB.NET e .NET Framework a .NET 10 / C# 14. Il metodo è separato dal linguaggio: COBOL, PL/I, J2EE, SAP ABAP e PHP sono in roadmap.
Costruito su Claude Code di Anthropic, oggi con Claude Opus 5.5 e Sonnet 5.5.
Non c'è documento più affidabile del sorgente in produzione: la migrazione parte da lì, non da documentazione esterna o dalla memoria di chi c'era.
La migrazione conserva il comportamento attivo, senza aggiungere né togliere funzioni. Le migliorie si annotano e si fanno dopo.
Se un controllo si può fare contando e confrontando, lo fa un programma con esito ripetibile. L'AI interviene dove serve interpretare.
Ogni agente ha un ruolo e strumenti limitati a quel ruolo: chi verifica legge e segnala, non corregge i propri risultati.
Ogni controllo distingue tre esiti: a posto, problema, non verificato. Il terzo non diventa mai un via libera.
Le lezioni emerse diventano regole del metodo, ma solo dopo l'approvazione di una persona.
Il rischio di una migrazione con l'AI non è il codice che non compila: è quello che compila e si comporta in modo diverso. Per questo ogni elemento del vecchio sistema — schermata, funzione, regola — finisce in uno di tre stati, e un verificatore distinto controlla che sia vero.
contratto di copertura a 3 stati
' QuietanzeBatch.vb — VB.NET · .NET Framework 4.6.1Public Class QuietanzeBatch Private ReadOnly _cs As String = "Server=db01;User Id=sa;Password=***" Public Function Esegui() As Integer Using conn As New SqlConnection(_cs) conn.Open() Dim cmd = conn.CreateCommand() cmd.CommandText = "EXEC sp_quietanze @data = '" & DateTime.Today.ToString("dd/MM/yyyy") & "'" Return cmd.ExecuteNonQuery() End Using End Function Private Sub EsportaSuFax(n As Integer) FaxGateway.Invia("Quietanze: " & n) End SubEnd Class// QuietanzeService.cs — C# 14 · .NET 10public sealed class QuietanzeService( IDbContextFactory<PolizzeContext> dbFactory, TimeProvider clock){ public async Task<int> EseguiAsync(CancellationToken ct = default) { await using var db = await dbFactory.CreateDbContextAsync(ct); var oggi = DateOnly.FromDateTime(clock.GetLocalNow().Date); return await db.Database.ExecuteSqlAsync( $"EXEC sp_quietanze @data = {oggi}", ct); }}| Elemento del legacy | Stato | Dove finisce, o perché |
|---|---|---|
| Classe QuietanzeBatch | Migrato | QuietanzeService, riga 2 |
| Metodo pubblico Esegui() | Migrato | EseguiAsync, riga 6: ora asincrono e annullabile |
| Connessione al database | Migrato | Righe 3 e 8: le connessioni le gestisce il framework |
| Regola: elabora le quietanze del giorno | Migrato | Righe 4 e 9–11. Scostamento dichiarato: la data passa come tipo data, non più come testo gg/mm/aaaa |
| Credenziali nel codice | Omesso con decisione | Non migrate: la connessione arriva dalla configurazione protetta. Decisione di sicurezza, firmata |
| Metodo EsportaSuFax() | Codice morto dimostrato | Nessun chiamante nel perimetro: documentato, non riscritto |
Copertura 6 su 6Controllo superato · in attesa della firma del responsabile di business
Il verificatore confronta vecchio e nuovo e cerca attivamente le differenze: regole spostate, semantica alterata, casi limite persi, aggiunte non giustificate. Ogni scostamento ha il riferimento a file e riga da entrambe le parti.
Nel programma, la versione nuova viene avviata e ogni schermata confrontata con un riferimento versionato, controllo per controllo, con esito ripetibile.
Il confronto sui dati reali, in pre-produzione, lo esegue il team del cliente: CATALYST ne orchestra e archivia le evidenze nel fascicolo, fino alla firma. Il confronto automatico in esecuzione parallela è in roadmap.
Un difetto che i controlli automatici non vedevano. Su un'applicazione del programma, un errore di visualizzazione aveva superato compilazione e test di avvio ed era emerso solo al primo uso reale: ogni area di lavoro appariva vuota. Reintrodotto apposta per misurare la verifica a runtime, viene rilevato subito: gli elementi dell'interfaccia passano da 165 a 33, con la compilazione ancora verde. La stessa classe di difetto è stata verificata su una seconda applicazione.
Una migrazione è una modifica ICT: le norme tecniche DORA chiedono che sia testata e approvata prima dell'uso. CATALYST produce quel materiale durante il lavoro, non a programma chiuso. La valutazione di conformità e le comunicazioni alle autorità restano della banca o dell'assicurazione: CATALYST fornisce gli artefatti che le sostengono.
| Norma | Che cosa serve | Che cosa produce CATALYST |
|---|---|---|
| DORAReg. UE 2022/2554 · in vigore dal 17 gennaio 2025 · vigilanza Banca d'Italia e IVASS | Sui sistemi legacy, una valutazione del rischio ICT almeno annuale e prima e dopo ogni nuova connessione (art. 8.7). Per ogni modifica, test e approvazione prima dell'uso, documentati. | L'inventario degli elementi e delle dipendenze di ogni applicazione, a supporto della valutazione. Per ogni applicazione migrata, il registro di copertura, l'esito dei controlli, le eccezioni motivate e la firma del responsabile di business. |
| AI ActReg. UE 2024/1689 · alto rischio dal 2 dicembre 2027 | Se nel perimetro c'è un sistema di AI ad alto rischio, per esempio per il merito creditizio o per il pricing delle polizze vita e salute: documentazione tecnica, registrazione degli eventi, supervisione umana. | Evidenze a supporto della documentazione tecnica: contratti di fase versionati, con autore, data ed esito di ogni passaggio. Gli obblighi del modello di AI per finalità generali restano del suo fornitore. |
CATALYST gira nell'infrastruttura del cliente: un server in sede o una macchina nel suo cloud (AWS, Google Cloud, Azure), come immagine chiusa che non contatta alcun servizio di KVA. Non vediamo, non archiviamo e non riceviamo il codice: l'unico servizio esterno che lo elabora è il modello di AI, con la chiave e il contratto del cliente.
Il modello si può raggiungere anche attraverso Amazon Bedrock, Google Vertex AI o Microsoft Foundry, sul contratto cloud che il cliente ha già: si configura con le variabili standard di Claude Code, su cui CATALYST è costruito.
CATALYST si licenzia e gira nell'infrastruttura del cliente. Si parte in piccolo, e ogni passo si decide sui risultati del precedente.
Chi vuole provarlo porta una parte piccola del proprio software legacy, e la versione già migrata se esiste. Il team di KVA la elabora sotto accordo di riservatezza: in un'ora esegue la verifica di parità e lascia il report, senza impegno. È l'unico momento in cui il codice passa da noi: con CATALYST installato, resta nell'infrastruttura del cliente.
Prenota la sessioneSi parte da un'applicazione: migrata, verificata, con il suo fascicolo di evidenze e la formazione del team del cliente. Se il risultato convince, il pilota prosegue con altre due.
Nel programma di riferimento, le prime prove negli ambienti del cliente sono arrivate entro due settimane dall'avvio di ogni applicazione.
Una licenza annuale per proseguire sulle altre applicazioni. Documentazione, regole di business e decisioni accumulate restano al cliente.
L'accesso ai sorgenti, una macchina nella sua infrastruttura per l'immagine CATALYST, una chiave del servizio di AI, un referente tecnico e il responsabile di business che firma.
CATALYST è costruito e usato ogni giorno da KVA — Kakashi Venture Accelerator, il venture studio AI-native del Gruppo Excellence, sul programma in esecuzione. Il Gruppo affianca banche e assicurazioni nell'innovazione dei servizi finanziari.
Banche e assicurazioni che lavorano già con il Gruppo Excellence possono passare anche dal loro referente.
Chi vuole provarlo porta una parte piccola del proprio software legacy, e la versione già migrata se esiste: il team di KVA la elabora sotto accordo di riservatezza, in un'ora esegue la verifica di parità e lascia il report. Senza impegno. Risponde il team tecnico, non una sequenza automatica.
In alternativa, per email: catalyst@kakashi.ventures.