Modernizziamo il legacy enterprise con AI agent governati. Parità verificabile.
Un agente AI lasciato solo produce codice che compila ma diverge in silenzio. CATALYST aggiunge gate deterministici, evidenze pronte all'audit, knowledge capture che resta al cliente.
●In esecuzione su un primario gruppo bancario-assicurativo italiano · Banking · Insurance · Manufacturing · PA · Sanità · Energy
Modernizzazione assicurata del legacy: migriamo i sistemi di banche e assicurazioni verso stack moderni con una pipeline AI-native governata — skill, hook, sub-agent e plugin di Claude Code.
02Per chi
Banking, insurance e PA italiana sotto DORA · EU AI Act · NIS2 · L. 132/2025.
03Prova
100+ applicazioni nel perimetro del programma, 15+ già modernizzate e consegnate (300.000+ righe legacy), su un primario gruppo bancario-assicurativo italiano — VB.NET / .NET Framework → .NET 10 / C# 14.
04Differenziatore
Parity assurance: audit semantico avversariale legacy↔migrato, contratto di copertura a 3 stati e gate deterministici, con evidenze pronte per il regolatorio EU. Niente cutover senza sign-off di parità.
CATALYST modernizza i sistemi legacy e ne garantisce la parità. Costruito su Claude Opus 4.8 e architettato per diventare model-agnostic — un'assurance indipendente dall'engine.
Nel 2026 la traduzione atomicadel codice si sta commoditizzando — ma modernizzare un parco di sistemi mission-critical interdipendenti, senza test e a parità di comportamento, resta tutt'altro che banale. Un agente lasciato in autonomia produce codice che supera i test sintattici e diverge silenziosamente dalla produzione. CATALYST esegue la modernizzazione con l'assurance dentro: governa e verifica i frontier model, non li sostituisce.
Specializzazione regolatoria by design
DORA, AI Act, NIS2, BCBS 239, FRIA, Banca d'Italia Circ. 285, AGID e Legge 132/2025 trattati come input di disegno. Evidenze pronte all'audit per ciascun dominio.
Equivalenza comportamentale come gate
Replay del traffico di produzione, side-by-side execution, diff con threshold dichiarati ex ante e sign-off del business owner. Niente cutover senza sign-off di parità.
Determinism over LLM
Lavoro probabilistico → agente LLM. Lavoro deterministico (schema, build, grep, AST) → script no-LLM. I gate tra le fasi sono machine-checkable, non checklist soggettive.
Implementazione già in produzione
Programma reale: 100+ applicazioni nel perimetro, 15+ già modernizzate e consegnate, 300.000+ righe di codice legacy, su un primario gruppo bancario-assicurativo italiano. Target .NET 10, C# 14. Non è un PowerPoint.
§ 01 / 12
Il problema
Debito legacy + regulatory cliff
Il debito legacy non si paga aspettando.
Trent'anni di debito stratificato — mainframe COBOL/PL-I, desktop VB6/.NET Framework, front-end moderni con business logic embedded nel core. Velocità di change in calo, concentrazione del rischio su pochi SME prossimi al pensionamento, pressione regolatoria crescente. Sistemi che nel 2020 erano “vecchi ma funzionanti” oggi sono passività regolamentari documentate.
Modernization · Failure rate
0%
>
Programmi di modernizzazione strutturati che falliscono o sforano significativamente (McKinsey 2025; Standish CHAOS Beyond Infinity).
Regulatory cliff
0norme
>
DORA, EU AI Act, NIS2, Banca d'Italia Circ. 285, AGID — in enforcement tra 2025 e 2027. Sanzioni fino al 3% del turnover globale (AI Act, sistemi high-risk), oltre alle penali DORA per i fornitori ICT critici.
Governance gap
0%
>
Penetrazione AI: 70% assicurazioni, 59% banche italiane. Solo il 16% ha introdotto assetti di governance dell'IA dedicati (Banca d'Italia + OCSE, apr. 2026).
§ 02 / 12
9 Principi del framework
Il filtro con cui si valuta ogni decisione operativa
I principi del framework.
Derivati dall'esecuzione su programmi reali, dalla letteratura indipendente e dall'esegesi delle norme europee e italiane. Raggruppati in tre famiglie: il lavoro operativo, il filtro tecnico, i vincoli che diventano disegno.
FAMIGLIA 01
Operativi
Come si svolge il lavoro
PRINCIPIO 01
Evolutivo, non Big Bang
Trasformazioni reversibili. Pattern strangler fig. Il legacy resta in piedi come fallback fino al sign-off di equivalenza.
PRINCIPIO 03
Copertura, non atto di fede
Il comportamento del codice legacy è l'oracolo: ogni elemento è coperto dal contratto a 3 stati e dall'audit semantico, senza richiedere una test suite preesistente. La generazione automatica di test è sul roadmap.
PRINCIPIO 08
Knowledge capture cumulativo
Knowledge curator agent come watchdog continuo: ogni applicazione migliora le successive. Asset di metodo trasferibile al cliente.
FAMIGLIA 02
Tecnici e di governance
Il filtro con cui valutare ogni decisione
PRINCIPIO 02
Human-in-the-loop tipizzato
Review singola / dual control / four-eyes — spettro graduato per livello di rischio AI Act. Codificato in hook bloccanti.
PRINCIPIO 05
Determinism over LLM
Lavoro probabilistico → agente LLM. Lavoro deterministico (schema, build, grep, AST) → script no-LLM. I gate sono machine-checkable.
PRINCIPIO 06
Tracciabilità completa
Ogni artefatto tracciato a prompt, modello, agente, revisore, hash del contesto. Requisito DORA Art. 9 e AI Act Art. 12.
FAMIGLIA 03
Regolatori e di relazione col cliente
Vincoli esterni che diventano input di disegno
PRINCIPIO 04
Equivalenza come gate
Niente cutover senza sign-off di parità: replay del traffico di produzione, side-by-side execution, diff con threshold dichiarati ex ante.
PRINCIPIO 07
Your-standards-first
Naming, pattern, checklist e workflow del cliente sono input di configurazione, non vincoli a posteriori. Project context come contratto epistemico.
PRINCIPIO 09
Regulatory-by-design
DORA, AI Act, NIS2, GDPR sono input di disegno. Ogni dominio produce evidenze pronte all'audit nei formati richiesti.
§ 03 / 12
Cosa fa CATALYST
Cinque domini operativi · architettura stack-agnostic
Dal sorgente legacy alle evidenze regolamentari.
Cinque domini operativi convergono nelle tre fasi di pipeline. Ogni dominio ha un obiettivo, capability, output strutturato e un gate di uscita. Oggi il framework è in produzione su .NET; l'architettura è stack-agnostic e nuovi stack (PHP, COBOL, PL/I, J2EE, SAP ABAP) si aggiungono come domain adapter, senza fork del core.
Dominio 01 · Analisi e comprensione
DISCOVER
Mappatura completa del sistema legacy, dipendenze, business logic embedded e rischi di migrazione. Reverse engineering accelerato con tagging epistemico esplicito.
Specifica per la migrazione, record-keeping per AI Act Art. 12, asset di conoscenza per il team del cliente. Documentazione bilateralmente collegata al simbolo di codice.
Capabilities
Documentazione generata dagli agenti con traceability codice ↔ specifica (file:riga)
Requirement harvesting in formato user story
Knowledge base navigabile (Markdown indicizzato)
Architecture diagrams (sequence, class, ERD) in formato Mermaid / SVG
Documentazione di moduli batch e processi schedulati
Output
Technical documentation nel template del cliente
API specs estratte dal codice
Architecture diagrams (sequence / class / ERD)
Data dictionary + glossario di dominio
Gate di uscita
Approvazione referente tecnico · sign-off SME funzionale per moduli con regole significative
Dominio 03 · Modernizzazione del codice
TRANSFORM
Trasformazione nel target stack preservando esattamente la logica di business attiva. Parità funzionale non negoziabile. Ottimizzazioni segnalate come raccomandazioni post-migrazione.
Capabilities
Idiomatic translation per linguaggio target (no traduzione letterale)
Architecture modernization — monolite → modulare via strangler fig
Pattern library di sostituzione per stack (MVVM, EF6→EFCore10, .csproj SDK-style)
Architettura stack-agnostic: .NET 10 in produzione; COBOL, PL/I, J2EE, SAP ABAP, PHP come domain adapter sul roadmap
Output
Modernized codebase idiomatica e maintainabile
Migration scripts e deployment artifact
Database modernization (no schema change senza autorizzazione)
Gate di uscita
Build verde · contratto a 3 stati valido · review tipizzata approvata
Dominio 04 · Equivalenza comportamentale
VALIDATE
Il dominio dove il framework prende la posizione più forte. L'equivalenza non è raccomandazione — è gate non negoziabile. Senza sign-off di parità, niente cutover in produzione.
Capabilities
Audit semantico statico legacy↔migrato (verifier read-only); la validazione side-by-side runtime la esegue il cliente in pre-produzione, orchestrata da CATALYST
Sign-off del business owner come compliance evidence AI Act Art. 14 e 15
Generazione automatica di test (unit/integration): sul roadmap — oggi la parità non richiede una test suite preesistente (oracolo = legacy)
Coverage analysis con target tipizzati per rischio (Annex III high-risk ≥ 90%)
Cluster escalation: ≥ 2 WARN sullo stesso tema → FAIL automatico del gate
Output
Contratto di copertura a 3 stati (ogni elemento legacy tracciato)
Evidenze di parità + sign-off del business owner
Performance benchmarking results (validazione del cliente)
Raccomandazioni per la regressione sui change futuri
Gate di uscita
Sign-off di parità del business owner · evidenze archiviate
Dominio 05 · Sicurezza, superficie agentica minima e compliance
SECURE
Sicurezza del codice modernizzato e conformità normativa, con una superficie agentica ridotta per design: controlli deterministici, tool in sola lettura, verifier read-only, distribuzione chiusa.
Capabilities
Skill security-review AI-aware su ogni diff + integrazione con SAST / DAST / SCA standard
Compliance checking: OWASP, PCI-DSS, GDPR, DORA Art. 6-30, AI Act Art. 9-15
Superficie agentica minima: tool nativi e in lettura, MCP solo per la documentazione, nessuna flotta di server da blindare
Difesa in profondità: verifier read-only, write-perimeter in whitelist, distribuzione Docker chiusa
Audit trail SIEM-compatibile, retention 5+ anni
Output
Security scan reports (SAST / DAST) con remediation tracking
Dependency vulnerability scanning + SBOM
Evidenze di conformità mappate (PCI-DSS · GDPR · DORA · AI Act Annex IV) a supporto delle attestazioni del cliente
Registro delle eccezioni e dei bypass tracciati (bypass.yaml)
Gate di uscita
Sign-off congiunto Risk Officer + Compliance Officer · evidenze allineate ad Annex IV per moduli high-risk
Dove si applica
Stack-agnostic: .NET 10 in produzione, gli altri stack sul roadmap.
Tecnologia sorgente
Target primario
Target alternativo
VB.NET / .NET Framework (3.5–4.x)
→
.NET 10 / C# 14 / WPF
Blazor / .NET MAUI
COBOL / CICS / IMS
→
Java / Spring Boot
Kotlin / .NET
PL/I
→
Java / Spring Boot
C# / .NET
J2EE / Struts / EJB
→
Spring Boot 3
Quarkus / Micronaut
SAP ABAP (custom)
→
Java / Spring
Clean-core / BTP
PHP legacy (5.x / 7.x)
→
PHP 8.x + Symfony 7+
Laravel 11+
100+
Applicazioni nel perimetro
Primario gruppo bancario-assicurativo IT — programma in produzione
15+
Consegnate e modernizzate
300.000+ righe di codice legacy migrate
1-7
Giorni di coding per app
Il calendario è dilatato dai cicli di validazione esterni
>90%
% coverage target high-risk
Moduli Annex III AI Act high-risk
Migration Distance
Quanto è lontana la migrazione calibra rischio e assurance.
B1 · in-linguaggio
Stesso linguaggio, stack aggiornato (es. C# legacy → C# 14). Distanza minima, rischio di divergenza contenuto.
B2 · cross-linguaggio
Stesso paradigma, linguaggio diverso (es. VB.NET → C# 14). Mappatura idiomatica, non traduzione letterale.
B3 · cambio di paradigma
Framework o modello applicativo diverso (es. WinForms → WPF / Blazor).
Un caso reale (anonimizzato) di trasformazione: un job di quietanzamento massivo scritto in VB.NET BackgroundWorker con connection string hardcoded e UI freeze su 250k+ polizze, modernizzato in un service C# 14 / .NET 10 con DbContextFactory, async pipeline, cancellation token e logging strutturato. La stored procedure non viene modificata — è vincolo del cliente.
Equivalenza comportamentale — il gate non negoziabile
AI Act Art. 14AI Act Art. 15DORA Art. 9ISO 42001 § 8.3Banca d'Italia Circ. 285Liu et al. 2026 · Zhang et al. ICSE 2026
Niente cutover senza garanzia di parità.
La modernizzazione AI-driven fallisce silenziosamente quando il sistema modernizzato compila e supera i test sintattici ma diverge dal comportamento di produzione sugli edge case accumulati in decenni. CATALYST rende la parità un gate obbligatoriosu due livelli: l'audit semantico statico legacy↔migrato del suo verifier read-only, e i cicli di validazione comportamentale in pre-produzione — replay, side-by-side, diff — che il cliente esegue e CATALYST orchestra, raccogliendone le evidenze fino al sign-off. Evidenza riproducibile e verificabile, non una prova matematica; l'automazione del dual-run è sul roadmap.
STEP 01
t+0s · replay
Replay
Replay del traffico di produzione
Registrazione di un campione rappresentativo di transazioni — tipicamente una settimana di produzione + i casi limite identificati in DISCOVER. SQL Profiler · application log · transaction journal.
STEP 02
t+30m · side-by-side
Side-by-side
Esecuzione parallela legacy vs modernizzato
Ambiente pre-produzione con dati allineati. Stessi input, due sistemi, due set di output capturati: funzionali · query SQL emesse · log · stato finale del database.
STEP 03
t+45m · diff
Diff
Diff con threshold dichiarati ex ante
Output testuali → exact match (diff hex se richiesto). Output numerici → range di tolleranza firmato dal business owner. Log → diff strutturale: stessi event, stessi level, payload tollerato.
STEP 04
t+sign-off · firmato
Sign-off
Firma del business owner
Pacchetto firmato con tutti i diff residui dichiarati e classificati come atteso / non atteso / da indagare. Compliance evidence per AI Act Art. 14 (human oversight) e Art. 15 (accuracy, robustness).
Google Cloud
Dual Run
Pattern industriale di parallel execution legacy ↔ cloud, con replay live di eventi di produzione e cifra di equivalenza funzionale. Precedente industriale pubblico: un primario gruppo bancario europeo ha dichiarato pubblicamente di aver ottenuto l'approvazione del regolatore sulla migrazione del proprio core con questa stessa metodologia.
IBM
watsonx Code Assistant — fase Validate
La fase Validate di IBM watsonx Code Assistant for Z formalizza un pattern equivalente per il mainframe Z, con sistemi side-by-side e validazione progressiva. CATALYST lo eredita e lo specializza come procedura obbligatoria a livello di gate.
Ricerca
Behavioral Specification Graphs
Liu et al. 2025/2026, “Preserving Business Logic in Legacy System Modernization”. Zhang et al. (IBM Research, ICSE 2026), pipeline ibride neuro-simboliche per traduzione COBOL→Java. Il consenso indipendente è netto: equivalenza comportamentale o niente.
“Questa firma del business owner contribuisce alla compliance evidence per AI Act Art. 14 (human oversight) e Art. 15(accuracy & robustness). Per workload bancari il pattern operativo dimostrato come efficace è il confronto SQL Profiler-based, side-by-side, su pre-produzione con dati reali.”
CATALYST_v2.md · § 3.4 Dominio VALIDATE — Giugno 2026
§ 06 / 12
Come garantiamo la parità
Copertura a 3 stati · audit avversariale · verifier read-only
Non una prova matematica. Una garanzia verificabile.
La parità si dimostra con un audit semantico avversariale del codice — legacy contro migrato — eseguito da un agente read-only che non può scrivere, e con un contratto di copertura in cui ogni elemento del legacy finisce in esattamente uno di tre stati. Validato a schema, con coverage ≥ 0.90 perché il gate passi. Funziona anche senza una test suite preesistente: l'oracolo è il comportamento del codice legacy stesso.
Stato 01
migrato
L'elemento ha un target esplicito nel codice modernizzato (file:riga). Presente e tracciato, non perso per strada.
Stato 02
omesso-con-decisione
Esclusione consapevole, motivata e referenziata. Una scelta firmata, non una dimenticanza silenziosa.
Stato 03
dead-documentato
Codice morto, dimostrato tale via analisi statica e documentato. Non riscritto per inerzia, non ignorato in silenzio.
Verifier read-only
Il verificatore semantico non può modificare il codice: confronta legacy e migrato cercando attivamente le divergenze. Nessun agente può dichiarare sé stesso “passato”.
Audit avversariale code-to-code
Confronto elemento per elemento, legacy ↔ migrato: regole di business spostate, semantica alterata, edge case persi, aggiunte non giustificate.
Gate deterministici · bypass tracciato
Build, schema, grep e AST → controlli a exit code riproducibile, non checklist soggettive. Un cluster di ≥2 WARN sullo stesso tema diventa FAIL; un FAIL si supera solo con motivazione, loggata in bypass.yaml.
Senza test suite
Gran parte del legacy mission-critical non ha test. Non li inventiamo a posteriori: la parità si misura sul comportamento del codice legacy, l'unica fonte di verità disponibile.
“Non è formal verification: nessuna prova matematica di equivalenza. È probabilismo governato — audit avversariale, copertura esplicita, gate deterministici e sign-off umano. La rivendicazione corretta è auditabile, governata e accountable, non ‘provata’.”
CATALYST · parity-assurance
§ 07 / 12
Come funziona
Tre strati architetturali · Tre fasi di pipeline
Una pipeline universale. Specializzata sullo stack del cliente.
Il framework si articola su tre strati che separano l'universale (Pipeline Core) dallo specifico (Domain Adapter) dal contesto cliente (Knowledge). La pipeline di lavoro attraversa tre fasi, ciascuna con un gate deterministico: /check-phase deve restituire PASS o bypass tracciato con motivazione. Niente fase chiude senza esito firmato.
Layer 01
Pipeline Core
Stack-agnostic — universale
Definisce come la pipeline lavora, indipendentemente da cosa migra. Skill generiche, agent orchestratori, hook deterministici, schema YAML dei contratti operativi.
Specializza il core su uno stack. Domain expert agent, detection rules, migration pattern. Aggiungere un nuovo stack = scrivere un nuovo Layer 2, senza toccare il core.
Ospita lo specifico del cliente: project context, knowledge base accumulata, documentation per applicazione e stato operativo del programma. Cresce con il progetto, resta al cliente.
// scenario · esempio illustrato per il flusso ANALYZE → MIGRATE → VERIFY · non è un report di failure reale
Skill vs Agent
Separazione netta: skill no-LLM per lavoro deterministico (grep, AST, schema, build). Agent LLM per lavoro interpretativo (cluster escalation, semantic drift, judgement).
Hook deterministici
Protezione legacy · gate enforcement · write perimeter · auto-build debounced · load memory for stack. Non passano dal modello, non possono allucinare.
Multi-agent orchestration
legacy-analyzer · migration-executor · verifier-semantic · knowledge-curator. Opus 4.8 max effort sui task critici; Sonnet 4.6 high per la curation.
Stato machine-readable
Mai grep su prosa per estrarre stato. Tre YAML schema-validati come Single Source of Truth: apps.yaml · batch.yaml · work-order.yaml.
Bypass log
Un gate FAIL bloccante è bypassabile solo via --force --reason "motivo concreto". Ogni bypass viene loggato in bypass.yaml e incluso come WARNING permanente nei report a valle.
Cross-app orchestration
/batch-prep identifica shared library, native binding e DAG di dipendenze; /batch-order calcola topological sort (Kahn) producendo wave parallelizzabili.
Implementazione
Su Claude Code (CLAUDE.md + Skills + Hooks + Subagents + Plugins). Gli asset sono portabili via standard aperti (AGENTS.md / CLAUDE.md); la replica multi-vendor è una direzione architetturale.
§ 08 / 12
Regulatory by design
DORA · EU AI Act · NIS2 · L. 132 · Banca d'Italia · AGID
DORA Art. 6-30AI Act Art. 9-72NIS2 D.Lgs. 138/2024L. 132/2025 Art. 14Circ. 285 · allineata a DORAAGID Det. 43/2026
Il vuoto che CATALYST riempie.
Anthropic, IBM, Google e AWS pubblicano playbook agentici tecnicamente solidi. Nessuno di essi affronta sistematicamente DORA Art. 6-30, EU AI Act Art. 9-72, NIS2, BCBS 239, FRIA, Banca d'Italia Circ. 285 e le Linee Guida AGID. Il vuoto è materiale — ed è quello che il framework riempie.
REGOLAMENTO UE 2022/2554
DORA
Digital Operational Resilience Act
⚑ Pienamente applicabile dal 17 gennaio 2025
Senza periodo di grazia formale. Sanzioni fino al 2% del turnover globale (Art. 50); per i fornitori critici (CTPP), penalità giornaliere fino all'1% del fatturato medio mondiale per max 6 mesi. Ogni dominio CATALYST produce evidenze mappate articolo per articolo.
⚑ High-risk: orizzonte 2026–2027 (Digital Omnibus) · fino al 3%
Standard armonizzati CEN-CENELEC JTC 21 non ancora in OJEU: nessuna presunzione di conformità disponibile. La doppia natura va dichiarata: il sistema modernizzato può essere high-risk Annex III, e l'agent che lo migra è un GPAI con propri obblighi.
Cybersicurezza UE + responsabilità umana non delegabile
⚑ Ispezioni ACN da ottobre 2026
NIS2 copre le entità non-financial della supply chain del cliente (DORA prevale per il finanziario). La L. 132/2025 con Art. 14 codifica la responsabilità umana non delegabile — confermata da Cons. Stato 4857/2025, coerente col Principio 02 del framework e da dichiarare esplicitamente nei contratti di engagement.
Circolare 285 + Linee Guida AGID 17/2025 e 43/2026
⚑ Circ. 285 51° aggiornamento — 3 feb 2026
La Circolare 285 allinea la governance ICT a DORA, abrogando le disposizioni duplicate del Titolo IV Parte I: il framework si allinea senza duplicare. AGID e la Determinazione 43/2026 tracciano sviluppo e procurement AI nella PA — punto di ingresso per gli engagement pubblica amministrazione.
Specializzazione regolatoria by design · Equivalenza comportamentale come gate · Implementazione già in produzione
Tre aree in cui CATALYST specializza ed estende il Code Modernization Playbook di Anthropic (feb. 2026)
§ 09 / 12
Sicurezza operativa
Superficie agentica minima, per design
Non blindiamo una flotta di tool. Riduciamo la superficie.
Far toccare a un agente AI codice, build e dati di una banca è una superficie di rischio operativo e di supply-chain — terreno di DORA (terze parti ICT) e NIS2. CATALYST la tiene piccola per costruzione: lavoro deterministico (non tool-call LLM), tool nativi e in lettura, verifier read-only, write-perimeter in whitelist, distribuzione chiusa. MCP è usato solo in letturaper la documentazione: nessuna flotta di server da hardenizzare. L'ecosistema agentico è giovane e accumula CVE — una ragione per ridurre la superficie, non per espanderla.
Estensione e specializzazione del Code Modernization Playbook di Anthropic
CATALYST non compete con gli engine di trasformazione. Li governa — sopra di essi.
Il 23 febbraio 2026 Anthropic ha pubblicato The Code Modernization Playbook; il giorno di mercato successivo il titolo IBM ha perso circa il 13% — il peggior calo dal 2000. Il segnale è chiaro: la trasformazione del codice si commoditizza. CATALYST estende e specializza il Playbookper il banking/insurance dell'Unione Europea. La sua assurance è indipendente dall'engine: oggi governa e verifica la propria migrazione, ed è architettata per governare anche l'output di engine terzi (AWS, Devin, IBM watsonx, Copilot) — pattern documentato, non ancora eseguito.
Estensione 01
Perimetro stack
Il Playbook Anthropic copre COBOL→Java/Python come caso esemplare. CATALYST tratta il vero parco legacy italiano: .NET Framework, VB6, FoxPro, Clipper, PHP legacy, oltre al COBOL mainframe.
Estensione 02
Equivalenza obbligatoria
Il Playbook indica il "parallel run" come buona pratica ma non ne formalizza la procedura. CATALYST la rende obbligatoria: replay produzione, side-by-side, diff, sign-off, in coerenza con Google Dual Run e IBM Validate.
Estensione 03
Verifica deterministica come gate
Il Playbook tratta i test come parte del workflow agentico. CATALYST li separa architetturalmente (skill no-LLM vs agent LLM) e li mette come gate obbligatorio tra le fasi: nessuna fase chiude senza esito PASS o bypass tracciato.
Divergenza 01
Governance regolamentare
Il Playbook non discute DORA, AI Act, NIS2, BCBS 239, FRIA, e non affronta la doppia natura per cui il sistema modernizzato può essere Annex III e l'agent che lo migra è un GPAI. CATALYST è regulatory-by-design.
Divergenza 02
Superficie agentica minima
Il Playbook dà per acquisita la capability MCP. CATALYST minimizza la superficie agentica: lavoro deterministico, tool in lettura, verifier read-only — meno superficie da difendere in un workload regolato, non una flotta di server da blindare.
Ecosystem map · maggio 2026
Multi-vendor by design. La scelta dello stack è documentata, motivata, soggetta a review.
Apri la tabella comparativa otto vendor →
Vendor
Modello / prodotto
Punto di forza per legacy modernization
Caveat per banking/insurance EU
Anthropic
Claude Opus 4.8 · Sonnet 4.6
Runtime locale eccellente · subagent + MCP · multi-agent orchestrator · Code Modernization Playbook (feb. 2026) · piattaforma su cui CATALYST è costruito
STDIO MCP è untrusted by default (natura del trasporto); CATALYST riduce la superficie usandolo solo in lettura — vedi Sicurezza operativa
"Mainframe MCP server" non è prodotto a sé · EU Data Boundary opt-in
Cognition
Devin
"Autonomous teammate" narrazione forte · casi Goldman Sachs / Mercedes-Benz
Benchmark pubblici comparabili meno chiari del marketing · richiede stringenti gate HiL in regolato
Mistral
Codestral 25.08 · Devstral 2 123B
Hybrid/on-prem/in-VPC · EU-headquartered · profilo migliore per sovereign EU
Quality gap su SWE-Bench rispetto a frontier US · Cohere post-merger Aleph Alpha apre opzione DE
Principio operativo: il framework non prescrive un singolo stack. Prescrive che la scelta sia documentata, motivata, soggetta a review periodica, e che gli asset prodotti siano portabili via standard aperti — MCP, AGENTS.md / CLAUDE.md, OpenRewrite recipes, Annex IV documentation.
Test generation auto-tested
Diffblue Cover
Java + Python · GA marzo 2026 · air-gapped · su Java: 81% line / 61% mutation
Il pricing emergente 2026 — AWS “agent minute” $0.035/min, IBM Bobcoins, GitHub Copilot usage-based — sposta il mercato dal Time & Material verso modelli ibridi orientati al risultato. Il framework si posiziona dove il mercato sta andando: quattro fasi di engagement, un business case bottom-up su sei voci misurabili, anti-promesse esplicite.
FASE 01
Discovery
2–4 settimane
Audit tecnico del portafoglio applicativo. Risk classification preliminare Annex III vs standard. Dichiarazione del threat model. Selezione del domain adapter Layer 2.
FASE 02
Pilot
4–8 settimane
Esecuzione completa delle tre fasi su 1 applicazione di complessità medio-bassa. Deliverable concreti + baseline di metriche reali condivise col cliente.
FASE 03
Scale-out
3–12 mesi
Definizione del piano per 5–15 applicazioni successive. Throughput e team adattati. Knowledge curator attivo come watchdog continuo.
FASE 04
Consolidamento
4–6 settimane
Trasferimento integrale della knowledge base al team interno del cliente: sub-agent, skill, hook, pattern, glossario di dominio, decisioni archiviate.
Bottom-up su sei voci di costo
Il business case non è una percentuale di produttività.
È la composizione di sei voci misurabili prima e dopo, calibrabili sul baseline reale del cliente durante il pilot. Non promettiamo un numero, descriviamo il bilancio.
#
Voce di costo
Pre-AI baseline
AI-augmented (CATALYST)
Effetto
01
Token / runtime cost LLM
Inesistente
Nuova voce, marginale rispetto alle ore di sviluppo risparmiate
+ nuovo
02
Ore sviluppo dev senior
Maggior parte dell'effort di programma
Ridotto significativamente su reverse engineering, documentation e analisi del legacy
- riduzione
03
Ore review umana
Spesso sottostimato
Aumentato: review tipizzata per livello di rischio richiede più tempo per high-risk
+ aumento
04
Ore test e validation
Spesso il collo di bottiglia
Copertura via contratto a 3 stati + audit statico; equivalence comportamentale eseguita dal cliente
= variabile
05
Ore audit e compliance
Spesso a programma chiuso, costo elevato
Evidenze già strutturate per Annex IV; bozze di RoI entry e FRIA; fascicolo assemblato dal cliente
- riduzione
06
Costo del rischio residuo
Difficile da quantificare
Misurabile via evidenze di parità: # diff dichiarati × probabilità × impatto
- governabile
Cosa NON promettiamo
Non promettiamo autonomia: l'agente non sostituisce la review umana qualificata.
Non promettiamo percentuali di produttività uniformi: la varianza esiste, si dichiara, si misura.
Non promettiamo compressione lineare del calendario totale: i cicli esterni sono governati dal cliente.
Cosa promettiamo
Coding time significativamente ridotto sulle applicazioni dello stack supportato.
Documentazione, evidenze regolatorie e contratti di copertura prodotti insieme al codice (la generazione di test è sul roadmap).
Knowledge base trasferibile al cliente: il programma prosegue autonomamente.
Tracciabilità completa di ogni decisione AI-generated, in formato audit-compatibile.
Chi siamo
KVA — Kakashi Venture Accelerator.
“Un team di builder, non una consulting firm camuffata.
Il framework è scritto, eseguito e iterato da un team che gira AI coding agents in produzione su un cliente reale, ogni giorno.”
AI Venture StudioBanking · InsurancePA · Sanità · EnergyProgramma in produzioneGruppo Excellence
Specializzazione regolatoria
DORA, AI Act, NIS2, BCBS 239, FRIA, Banca d'Italia Circ. 285, AGID, Legge 132/2025 — input di disegno, non vincoli a posteriori.
Equivalenza comportamentale
Procedura obbligatoria: replay produzione, side-by-side, diff con threshold ex ante, sign-off del business owner.
Esecuzione reale
Programma operativo: 100+ applicazioni nel perimetro, 15+ consegnate, 300.000+ righe legacy, su un primario gruppo bancario-assicurativo italiano.
