La presentazione è progettata su canvas 1920×1080 e diventa illeggibile sui telefoni. Scarica il PDF per consultarla con calma o riapri il link da un computer.
Scarica il PDF ↓← Torna al sitoApplicazioni costruite anni o decenni fa reggono ancora pagamenti, polizze e contabilità. Finché funzionano nessuno vuole toccarle, ma rimandare non è gratis: intorno a quel software cambia tutto il resto.
Sistemi che nel 2020 erano “vecchi ma funzionanti” oggi sono passività regolamentari documentate. Il debito legacy non si paga aspettando.
In enforcement attivo, senza periodo di grazia formale. NCA conducono review attive, primi audit speciali in corso (stile BaFin §44 KWG).
Fino al 10% del fatturato (D.Lgs. 23/2025).
Solo per i sistemi AI high-risk dell'Annex III: credit scoring, pricing vita/salute, screening HR. Erano fissati al 2 ago 2026: il Digital Omnibus li ha differiti al 2 dic 2027 (Annex III) e al 2 ago 2028 (IA nei prodotti). DORA e NIS2 non sono cambiate. Nessuno standard armonizzato ancora in OJEU.
Fino al 3% del turnover globale (€15M).
Misure di sicurezza di base entro ottobre 2026. Per banche e assicurazioni prevale DORA.
Fino a 10M€ o 2% del fatturato.
Anthropic, IBM, Google e AWS pubblicano playbook agentici credibili. Nessuno affronta sistematicamente DORA artt. 6-30, i casi in cui scatta l'EU AI Act, NIS2, la Circolare 285 di Banca d'Italia e IVASS.
Ogni dominio CATALYST produce evidenze pronte all'audit nei formati richiesti dai regolatori europei e italiani.
La modernizzazione AI-driven fallisce silenziosamente quando il sistema modernizzato compila ma diverge sui casi limite.
Audit semantico statico legacy↔migrato (verifier read-only) + contratto di copertura a 3 stati + sign-off; il ciclo di validazione runtime (replay, side-by-side, diff) lo esegue il cliente in pre-produzione e CATALYST lo orchestra, raccogliendone le evidenze. L'automazione del dual-run è sul roadmap.
A differenza dei framework che vivono solo come PowerPoint, CATALYST è in esecuzione su un programma reale.
100+ applicazioni desktop nel perimetro di un primario gruppo bancario-assicurativo italiano — 15+ già consegnate, 300.000+ righe di codice legacy, in target su .NET 10 e C# 14.
Distribuzione Citrix · schema DB e stored procedure invariati su vincolo cliente.
I pattern .NET legacy → .NET 10, le decisioni archiviate e la knowledge base accumulata sul programma sono asset che richiedono 12–18 mesi di esecuzione reale per essere ricostruiti.
Un grande system integrator non lo replica in tre mesi di workshop. Ogni applicazione che migriamo lo allarga.
Ogni dominio ha obiettivo, input, capability, output strutturato e gate di uscita verso il dominio successivo.
Si migra ciò che è attivo, non ciò che è dismesso, non ciò che si vorrebbe attivare. Le ottimizzazioni di compliance, sicurezza o UX si segnalano come raccomandazioni post-migrazione, non si implementano durante la migrazione.
| Sorgente | Target primario |
|---|---|
| VB.NET / .NET Framework 3.5-4.x | .NET 10 / C# 14 / WPF |
| COBOL / CICS / IMS | Java / Spring Boot |
| PL/I | Java / Spring Boot |
| J2EE / Struts / EJB | Spring Boot 3 |
| SAP ABAP (custom) | Java / Spring |
| PHP legacy 5.x/7.x | PHP 8.x + Symfony 7+ |
Oggi in produzione su .NET; PHP, COBOL, PL/I, J2EE e SAP ABAP si aggiungono come domain adapter (Layer 2), senza toccare il pipeline core.
Parity assurance — non una prova matematica — su due livelli. Il meccanismo di CATALYST è un audit semantico statico legacy↔migrato (verifier read-only) + contratto di copertura a 3 stati + sign-off umano. Il ciclo di validazione runtime — replay, side-by-side, diff — lo esegue il cliente in pre-produzione e CATALYST lo orchestra, raccogliendone le evidenze fino al sign-off. La metodologia segue la fase Validate di IBM watsonx Code Assistant e Dual Run di Google Cloud — con cui un primario gruppo bancario europeo (caso pubblico) ha dichiarato di aver ottenuto l'approvazione del regolatore. L'automazione del dual-run è sul roadmap.
Per workload bancari, pattern dimostrato come efficace: confronto delle query SQL emesse dal layer moderno vs il legacy, in modalità side-by-side, su pre-produzione con dati reali.
Numeri illustrativi. Il pack reale archivia anche hash di trace, configurazione threshold e firma del business owner.
Il prossimo cliente con stack diverso aggiunge un domain adapter, non un framework.
Copre DISCOVER + DOCUMENT. Agente legacy-analyzer Opus 5.5 max.
Copre TRANSFORM. Agente migration-executor Opus 5.5 max.
Copre VALIDATE + SECURE. Skill deterministica + verifier-semantic read-only.
Chiunque, oggi, con un coding agent moderno produce codice migrato. Pochi consegnano un pacchetto di evidenze che attraversa DORA, AI Act, NIS2 e i requisiti dei regolatori italiani in formato direttamente utilizzabile dal Compliance Officer.
Ogni dominio CATALYST produce evidenze nei formati e nelle nomenclature attese dai regolatori europei e italiani — come deliverable strutturato dell'engagement, non come byproduct documentale.
| Articolo | Evidenza prodotta |
|---|---|
| Art. 6 | Perimetro documentato per il quadro del cliente: inventario, gate, bypass registrati |
| Art. 8 | Inventario e dipendenze per la valutazione dei sistemi legacy (par. 7) |
| Art. 9 | Change management: gate deterministici, sign-off separato, hook di perimetro |
| Art. 17-20 | Tracciabilità degli artefatti per l'analisi delle cause; notifica del cliente |
| Art. 24-25 | Pacchetto di parità: audit statico + validazione runtime del cliente (output VALIDATE) |
| Art. 28 | Dati per il Register of Information (KVA e provider del modello, LEI); submission a cura del cliente |
| Art. 29 | Asset portabili a supporto dell'exit plan del cliente; alternativa Mistral on-prem documentata |
| Articolo | Evidenza prodotta |
|---|---|
| Art. 9 | Risk management del cliente: input da inventario e decisioni registrate |
| Art. 10 | Dati del modello, solo se la migrazione li tocca |
| Art. 12 | Logging del sistema preservato e verificato nella parità |
| Art. 13 | Istruzioni d'uso aggiornate dagli output di DOCUMENT |
| Art. 14 | Misure di supervisione del sistema preservate nella parità |
| Art. 15 | Accuracy, robustness, cybersecurity: parity assurance (audit statico + validazione del cliente) + SECURE |
| Annex IV | Documentazione tecnica a supporto; fascicolo assemblato e conservato dal cliente |
L'agente produce modernizzazione attiva, con supervisione del developer. Effetto di apprendimento progressivo dopo le prime 3-5 app dello stesso stack.
dalla scheda applicativa al cutover in produzione. La differenza tra coding time e calendario è occupata da:
Onestà operativa. I cicli di validazione esterni sono governati dai tempi dell'organizzazione cliente, non dall'AI.
| # | Voce di costo | AI-augmented con CATALYST | Effetto netto atteso |
|---|---|---|---|
| 01 | Token / runtime LLM | Voce nuova ma marginale rispetto alle ore risparmiate, in single-agent Opus 5.5 | Costo netto nuovo, marginale rispetto alle voci successive |
| 02 | Ore sviluppo dev senior | Ridotto significativamente su reverse engineering, documentation e analisi del legacy | Riduzione netta significativa |
| 03 | Ore review umana | Aumentato — review tipizzata per livello di rischio richiede più tempo sui high-risk | Aumento netto, compensato dalla voce 02 |
| 04 | Ore test e validation | Copertura via contratto a 3 stati + audit statico; equivalence eseguita dal cliente | Variazione dipendente da baseline di test esistente |
| 05 | Ore audit e compliance | Contratti e decisioni tracciate; per i sistemi high-risk, evidenze per Annex IV; fascicolo assemblato dal cliente | Riduzione netta significativa |
| 06 | Costo del rischio residuo | Misurabile via evidenze di parità: diff dichiarati × probabilità × impatto | Visibile e governabile, non più opaco |
Nuove API, nuove UI, prototipi. Stack moderno, training data abbondante.
compressione del coding time, da misurare sul baseline del cliente
Refactoring di codebase mainstream <10 anni. Stack noto, pattern consolidati.
compressione del coding time, da misurare sul baseline del cliente
Banking COBOL / PL/I / VB.NET legacy, integrazione regolatoria.
effetto di apprendimento progressivo
CATALYST è il layer di orchestrazione: oggi gira su Claude Code ed è architettato per appoggiarsi anche agli altri runtime, da scegliere per workload e livello di rischio, non per fedeltà al vendor. Il rapporto con il Code Modernization Playbook di Anthropic (feb. 2026) è di estensione regolatoria, non di sostituzione.
| Player | Punto di forza per legacy modernization | Caveat per banking/insurance UE |
|---|---|---|
| Anthropic | Runtime locale eccellente, subagent + MCP, multi-agent orchestrator | STDIO è untrusted by default: caratteristica del trasporto (comportamento atteso), da hardenizzare a livello di deployment |
| OpenAI | Stack agentico più coerente cross-surface, Skills, Apps SDK, MCP nativo | API diretta con residenza dati UE, non sovrana; via Azure OpenAI Data Zone |
| Dual Run è benchmark di equivalenza comportamentale, casi banking | Sovereignty su S3NS PREMI3NS H2 2026; Antigravity exploited entro 24h | |
| IBM | Project Bob GA 28 apr. 2026, adiacenza mainframe Z/i, multi-model nativo | Bobcoins pricing non mappa pubblicamente a token |
| AWS | Transform “agent minute” $0.035/min trasparente, casi Allianz/Generali | ESC eusc-de-east-1 non offre Claude; CLOUD Act resta esposto |
| Microsoft | Distribuzione GitHub Copilot ubiqua, framework Bankdata open banking-grade | EU Data Boundary opt-in; “Mainframe MCP server” non è prodotto a sé |
| Mistral | Hybrid/on-prem/in-VPC, EU-headquartered, profilo migliore per sovereign | Quality gap su SWE-Bench rispetto a frontier US |
INPS, INAIL, Agenzia Entrate, sistemi sanitari regionali. Mainframe COBOL/PL-I + DB2.
Vincoli specifici: AGID Det. 17/2025 + 43/2026, livelli QC1-QC4 ACN, responsabilità non delegabile nella PA (Art. 14 L. 132/2025).
HIS, LIS, PACS/RIS. Migrazione protocolli legacy → API FHIR native per FSE 2.0.
Specificità: MDR + IVDR + MDCG 2025-6. Behavioral equivalence diventa obbligo morale, non opzione, per moduli life-critical.
Convergenza IT/OT, smart meter, dispatching. Porzioni IT modernizzate con pipeline standard.
Trade-off invertito: Availability + Safety prevaricano. Pattern Strangler con wrapper API che incapsula il legacy SCADA. NIS2 + NCCS.
Un modulo piccolo del legacy del cliente, e la versione migrata se esiste già: audit di parità in sessione. Sotto accordo di riservatezza, senza impegno: è l'unico momento in cui il codice passa da KVA.
Output: il report di parità sul modulo, al cliente.
CATALYST nell'infrastruttura del cliente, in sede o nel suo cloud. Un'applicazione analizzata, migrata e verificata; formazione del team.
Output: codice + fascicolo di evidenze + Go/No-Go.
Stesso percorso su altre due applicazioni, con il team del cliente al lavoro sullo strumento.
Output: tre fascicoli di evidenze, team formato.
Lo strumento sul resto del portafoglio. Documentazione, regole e decisioni accumulate restano al cliente.
Output: cliente autonomo sulla modernizzazione residua.
Il framework è scritto, eseguito e iterato da un team che gira AI coding agent in produzione su un cliente bancario reale, ogni giorno. Le decisioni metodologiche sono il sedimento di settimane di lavoro su codice reale, non l'output di un workshop di posizionamento.
Il Gruppo Excellence ha la storia banking/insurance italiana, le relazioni commerciali con i grandi gruppi del settore, la struttura legale e contrattuale per gestire engagement enterprise nel regolato.