CATALYST non è un altro AI coding agent. È il layer di metodo, governance e gate deterministici sopra i frontier agent. Modernizza il legacy di banche, assicurazioni e settori regolati italiani con equivalenza comportamentale provata, evidenze pronte per DORA · EU AI Act · NIS2, e knowledge capture che resta al cliente.
Code & Architecture Transformation Accelerated by LLM & Intelligent Systems Technology.
DORA Reg. UE 2022/2554 — enforcement attivo dal 17.01.2025EU AI Act Annex III high-risk — sanzioni dal 02.08.2026NIS2 — ispezioni ACN da ottobre 2026Banca d'Italia Circ. 285 — 51° aggiornamento 03.02.2026AGID Determinazione 43/2026 — procurement AI nella PAGPAI Code of Practice — firmato luglio 2025CEN-CENELEC JTC 21 — nessuno standard armonizzato in OJEUDORA Reg. UE 2022/2554 — enforcement attivo dal 17.01.2025EU AI Act Annex III high-risk — sanzioni dal 02.08.2026NIS2 — ispezioni ACN da ottobre 2026Banca d'Italia Circ. 285 — 51° aggiornamento 03.02.2026AGID Determinazione 43/2026 — procurement AI nella PAGPAI Code of Practice — firmato luglio 2025CEN-CENELEC JTC 21 — nessuno standard armonizzato in OJEU
§ 00 / 13
Manifesto
Executive summary — CATALYST v2.0
CATALYST non è un altro AI coding agent. È il layer di metodo, governance e gate deterministici sopra i frontier agent — Claude Opus 4.7, GPT-5.5, Codex — che li rende difendibili in un contesto regolato.
Nel 2026 l'AI non rende la modernizzazione legacy facile. La rende finalmente industrializzabile, ma solo se governata con metodo. Su sistemi mission-critical, un agente lasciato in autonomia produce risultati che superano i test sintattici e divergono silenziosamente dal comportamento di produzione. CATALYST è la modernization factory che chiude questo gap — orchestrando i frontier model, non sostituendoli.
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 proof formale.
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 su ~80 applicazioni desktop di un'assicurazione di un primario gruppo bancario italiano. Target .NET 9, C# 13. Non è un PowerPoint.
§ 01 / 13
Il problema
Debito legacy + regulatory cliff
Il debito legacy non si paga aspettando.
Velocità di change in calo. Concentrazione del rischio in pochi SME prossimi al pensionamento. Pressione regolatoria crescente. Sistemi che nel 2020 erano “vecchi ma funzionanti” oggi sono passività regolamentari documentate.
Modernization · Failure rate
70%
Programmi di modernizzazione strutturati che falliscono o sforano significativamente (McKinsey 2025; Standish CHAOS Beyond Infinity).
Debito stratificato
30+anni
Banche e assicurazioni IT su mainframe COBOL/PL-I + desktop VB6/.NET Framework + front-end moderni con business logic embedded nel core.
Regulatory cliff
5norme
DORA, EU AI Act, NIS2, Banca d'Italia Circ. 285, AGID Linee Guida — tutte in enforcement tra 2025-2027. Sanzioni fino al 7% del turnover globale.
Governance gap
16%
Penetrazione AI: 70% assicurazioni, 59% banche italiane. Solo il 16% ha framework di governance strutturato (Banca d'Italia + OCSE, apr. 2026).
§ 02 / 13
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. Insieme costituiscono il contratto del framework con il cliente.
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 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 03
Test Foundation obbligatoria
Senza copertura del comportamento legacy in produzione, la migrazione è un atto di fede. Niente migrazione senza Test Foundation.
PRINCIPIO 04
Equivalenza come gate
Niente cutover senza proof formale: replay del traffico di produzione, side-by-side execution, diff con threshold dichiarati ex ante.
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.
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 08
Knowledge capture cumulativo
Knowledge curator agent come watchdog continuo: ogni applicazione migliora le successive. Asset di metodo trasferibile al cliente.
PRINCIPIO 09
Regulatory-by-design
DORA, AI Act, NIS2, GDPR sono input di disegno. Ogni dominio produce evidenze pronte all'audit nei formati richiesti.
Dal sorgente legacy all'evidence pack regolamentare.
Ogni dominio ha un obiettivo, input richiesti, capability, output strutturato e un gate di uscita verso il successivo. Convergono operativamente nelle tre fasi di pipeline.
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
Auto-documentation con line-level traceability codice ↔ specifica
Requirement harvesting in formato user story
Knowledge base interrogabile (Markdown + docs-assistant agent)
Architecture diagrams: sequence, class, ERD in SVG + Mermaid live
Runbook generati per 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→EFCore9, .csproj SDK-style)
Database modernization (no schema change senza autorizzazione)
Gate di uscita
Build verde · Test Foundation passante · 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 prova formale, niente cutover in produzione.
Capabilities
Behavioral equivalence pack: replay traffico produzione · side-by-side · diff threshold ex ante
Sign-off del business owner come compliance evidence AI Act Art. 14 e 15
Automated test generation: Diffblue Cover (Java/Python) + AI-augmented
Coverage analysis con target tipizzati per rischio (Annex III high-risk ≥ 90%)
Regression test optimization via test impact analysis
Output
Test suite completa (unit · integration · functional)
Behavioral equivalence pack firmato
Performance benchmarking results
Regression test selection rules per i futuri change
Gate di uscita
Equivalence pack firmato dal business owner · archiviato come evidence pack
Dominio 05 · Sicurezza, MCP hardening e compliance
SECURE
Sicurezza del codice modernizzato e conformità normativa. Attenzione esplicita alla superficie MCP — trattata come superficie di attacco, non come capability acquisita.
Capabilities
SAST · DAST · SCA + AI-aware layer per pattern di codice generato AI
Compliance checking: OWASP, PCI-DSS, GDPR, DORA Art. 6-30, AI Act Art. 9-15
MCP attack surface management: registry ufficiali, STDIO untrusted by default
MCP Gateway centralizzato + runtime guardrail per workload high-risk
Audit trail SIEM-compatibile, retention 5+ anni
Output
Security scan reports (SAST / DAST) con remediation tracking
Dependency vulnerability scanning + SBOM
Compliance attestations: PCI-DSS · GDPR · DORA · AI Act Annex IV
MCP security register di progetto
Gate di uscita
Sign-off congiunto Risk Officer + Compliance Officer · Annex IV pronto per moduli high-risk
§ 04 / 13
Il differenziatore tecnico
Equivalenza comportamentale — il gate non negoziabile
Niente cutover senza proof formale.
La modernizzazione AI-driven fallisce silenziosamente quando il sistema modernizzato compila e supera test sintattici ma diverge dal comportamento di produzione sugli edge case che il codice legacy ha accumulato in decenni. CATALYST rende la prova formale di equivalenza un gate obbligatorio, non una raccomandazione.
STEP 01
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
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
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
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. Caso reale documentato: Intesa Sanpaolo — la stessa metodologia con cui ha dichiarato pubblicamente di aver ottenuto l'approvazione del regolatore sulla migrazione del proprio core.
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 — Maggio 2026
§ 05 / 13
Architettura
Tre strati — Core · Domain Adapter · Knowledge
Tre strati che separano l'universale dallo specifico.
Il problema legacy non è specifico di una banca o di un linguaggio. Il framework è strutturato come strumento generale a cui si applica lo specifico del cliente — non come implementazione ad-hoc che si replica copiando-incollando.
LAYER 01
Pipeline Core
Stack-agnostic
Definisce come la pipeline lavora, indipendentemente da cosa migra. Skill generiche, agent orchestratori, hook deterministici, schema YAML dei contratti operativi. Vocabolario obbligatoriamente neutro: “controllo UI”, “event handler”, “business rule embedded”.
Specializza la pipeline core su uno stack specifico. Domain expert agent (oracle read-only), detection rules grep-able, migration pattern documentati. Aggiungere un nuovo stack = scrivere un nuovo Layer 2, senza toccare il core.
Ospita lo specifico del cliente: project context (convenzioni, vincoli, infrastruttura), knowledge base accumulata, documentation per applicazione e stato operativo del programma. Cresce con il progetto.
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.7 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.
§ 06 / 13
Pipeline
Tre fasi · Gate machine-checkable
Tre fasi. Gate machine-checkable.
Ogni fase produce due artefatti distinti: un contratto operativo YAML (machine-readable, schema validato) e un deliverable narrativo Markdown. La separazione è strutturale: niente fase chiude senza che la skill deterministica /check-phase abbia esito PASS o bypass tracciato con motivazione.
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). Replicabile su Codex CLI via AGENTS.md per scenari multi-vendor.
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# 13 / .NET 9 con DbContextFactory, async pipeline, cancellation token e logging strutturato. La stored procedure non viene modificata — è vincolo del cliente.
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
⚑ Enforcement attivo dal 17 gennaio 2025
Periodo di tolleranza chiuso da Q1 2026. Sanzioni potenziali fino al 2% del turnover globale (Art. 50); CTPP fino a €5m + 1% del turnover giornaliero per 6 mesi. Ogni dominio CATALYST produce evidenze mappate articolo per articolo.
⚑ Sanzioni dal 2 agosto 2026 — fino al 7% turnover globale
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.
Art. 9Art. 10Art. 12Art. 13Art. 14Art. 15Art. 17Annex IV
D.LGS. 138/2024
NIS2
+ Banca d'Italia Circ. 285 51° agg.
⚑ Ispezioni ACN da ottobre 2026
DORA prevale su NIS2 per ICT risk management e incident reporting nel finanziario, ma le entità non-financial della supply chain del cliente restano sotto NIS2.
LEGGE 132/2025
AI Nazionale
ACN authority + Art. 14 PA
⚑ Responsabilità umana non delegabile
Confermata anche da Cons. Stato 4857/2025. Coerente col Principio 02 di CATALYST e da dichiarare esplicitamente nei contratti di engagement.
MCP SECURITY
Attack surface
~9.400 server pubblici (apr. 2026)
⚑ CVE-2026-23744 critica CVSS 9.8
STDIO untrusted by default. Solo registry ufficiali. MCP Gateway centralizzato + runtime guardrail per workload Annex III high-risk. Audit trail SIEM-compatibile con retention 5+ anni.
Specializzazione regolatoria by design · Equivalenza comportamentale come gate · Implementazione già in produzione
Tre differenze concrete che separano CATALYST dal Code Modernization Playbook di Anthropic (23 feb. 2026)
§ 09 / 13
MCP attack surface
Trattato come superficie d'attacco, non come capability
MCP — superficie d'attacco, non capability acquisita.
L'ecosistema Model Context Protocol è in espansione rapida — oltre 9.400 server pubblici nel registry a metà aprile 2026, donato alla Linux Foundation Agentic AI Foundation a dicembre 2025 — ma ha mostrato vulnerabilità strutturali significative tra dicembre 2025 e maggio 2026. La policy del framework è netta.
Disclosure rilevanti · dic. 2025 – mag. 2026
8 segnalazioni tracciate
OX Security disclosure
Design-level
Command-injection design-level negli SDK Anthropic MCP STDIO (Python, TypeScript, Java, Rust). ≥7.000 server pubblici, ~150M download. Anthropic ha rifiutato la patch a livello protocollo.
mcp-server-git (Anthropic) — path bypass su git_init / git_diff.
CERT-AgID, aprile 2026
Threat report
Documenta scenari SSRF e Proxy Hijacking via MCP server mal configurati. Riferimento operativo per PA italiana e workload regolati.
Policy operativa
Le sette regole del framework per MCP in workload regolato.
01
Solo registry ufficiali
Anthropic registry · Linux Foundation MCP registry · registry self-hosted del cliente · vendor enterprise certificati. Mai server da repo personali o community non verificati.
02
STDIO untrusted by default
Si preferisce HTTP-SSE con TLS 1.3 + OAuth 2.1 + PKCE. Quando STDIO è inevitabile, il container è full-sandboxed con outbound network bloccato.
03
Sandbox + least privilege
Ogni server MCP gira in container con permessi minimi, allowlist esplicita di endpoint, no shell access.
04
MCP Gateway centralizzato
Per progetti enterprise: tutto il traffico LLM ↔ MCP passa da un gateway che centralizza autenticazione, audit logging, rate limiting. Niente connessioni dirette agente ↔ server esterno.
05
Runtime guardrail
Per workload Annex III high-risk: guardrail di terze parti (Palo Alto Prisma AIRS, Capsule Security) sul flusso LLM ↔ tool ↔ response, con detection di prompt injection ed exfiltration.
06
Audit trail completo
Logging di ogni invocazione MCP (server, tool, parametri, risultato) in sistema SIEM-compatibile. Retention 5+ anni allineata a DORA Art. 9 e AI Act Art. 12.
07
Prompt injection come classe
Trattata come classe di rischio SaaS, non come singola CVE. Aggiornamento continuo del registro via threat intelligence; review trimestrale della superficie MCP del progetto.
Niente patch protocollo
Anthropic ha rifiutato di patchare il difetto STDIO a livello di protocollo, definendo il comportamento “expected”. Implicazione operativa per workload regolati: STDIO MCP è untrusted by default.
Maturità di mercato
MCP Gateway commerciali maturi: MintMCP, Truto. Runtime guardrail: Palo Alto Prisma AIRS, Capsule Security. Stack di hardening ricostruibile, non da inventare.
Disclosure attiva
Nessuno dei competitor in ambito modernizzazione AI-driven (Anthropic Playbook, Google Mainframe Rewrite, AWS Transform, IBM Project Bob) dichiara una policy MCP equivalente. È una scelta di metodo esplicita del framework.
§ 10 / 13
Posizionamento nell'ecosistema
Estensione e specializzazione del Code Modernization Playbook di Anthropic
CATALYST non compete con i frontier model. Li orchestra.
Il 23 febbraio 2026 Anthropic ha pubblicato il Code Modernization Playbook. Il giorno della pubblicazione il titolo IBM ha perso il 13% intraday — il mercato ha letto l'annuncio come un cambio di equilibrio. CATALYST si posiziona come estensione e specializzazione del Playbook per il contesto banking/insurance dell'Unione Europea — con tre estensioni concrete e due divergenze esplicite.
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
MCP come superficie d'attacco
Il Playbook tratta MCP come capability acquisita. CATALYST lo tratta come superficie d'attacco con riferimento esplicito alle CVE 2025-2026 e presidi runtime obbligatori per workload Annex III high-risk.
Ecosystem map · maggio 2026
Multi-vendor by design. La scelta dello stack è documentata, motivata, soggetta a review.
"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 · coverage 81% line / 61% mutation
Il framework è progettato come strumento generale. Aggiungere il supporto a un nuovo stack significa scrivere un nuovo domain adapter, non modificare il core. Otto stack documentati, altri in evoluzione attiva.
Tecnologia sorgente
Target primario
Target alternativo
COBOL / CICS / IMS
→
Java / Spring Boot
Kotlin / .NET Core
PL/SQL / Oracle Forms
→
Java / Python
PostgreSQL + REST API
Natural / Adabas
→
Java / Spring
.NET / cloud-native
RPG / AS400
→
Java / cloud
Python / serverless
VB6 / .NET legacy (3.5–4.x)
→
.NET 9 / C# 13 / WPF
Blazor / .NET MAUI
PowerBuilder
→
Java / Angular
React / Vue.js
Struts / EJB 2.x
→
Spring Boot 3
Quarkus / Micronaut
PHP legacy (5.x / 7.x)
→
PHP 8.x + Symfony 7+
Laravel 11+
80
Applicazioni desktop in delivery
Primario gruppo bancario IT — programma in produzione
1-7
Giorni di coding effettivo per app
In funzione di dimensione e complessità
3-6
Settimane di calendario per app
Inclusi cicli di validazione esterni del cliente
>90%
% coverage target high-risk
Moduli Annex III AI Act high-risk
Bottom-up su sei voci di costo.
Il business case si costruisce su sei voci misurabili prima e dopo, non su una singola percentuale di produttività. Il cliente può calibrarle sul proprio baseline reale durante il pilot.
#
Voce di costo
Pre-AI baseline
AI-augmented (CATALYST)
Effetto
01
Token / runtime cost LLM
Inesistente
Centinaia di USD/app medio-grande; multi-agent può raddoppiare
+ nuovo
02
Ore sviluppo dev senior
Maggior parte dell'effort di programma
Ridotto significativamente su reverse engineering, documentation, test generation
- 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
Ridotto su test generation; aumentato su behavioral equivalence
= variabile
05
Ore audit e compliance
Spesso a programma chiuso, costo elevato
Evidence pack già strutturato come Annex IV, RoI entry pronta, FRIA template
- riduzione
06
Costo del rischio residuo
Difficile da quantificare
Misurabile via equivalence pack: # diff × 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, test asset e evidence regolatori prodotti insieme al codice.
Knowledge base trasferibile al cliente: il programma prosegue autonomamente.
Tracciabilità completa di ogni decisione AI-generated, in formato audit-compatibile.
§ 12 / 13
Modello di engagement
Quattro fasi · Metodologia + servizio
Metodologia + servizio. Non licenza software.
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.
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.
§ 13 / 13
Settori adiacenti
L'architettura a tre strati si applica oltre il banking
Banking è il focus. PA, Sanità ed Energy sono i settori adiacenti.
L'architettura a tre strati permette di applicare il framework a domini diversi modificando solo Layer 2 (domain adapter per stack) e Layer 3 (knowledge project-level). I principi restano invariati; gli adattamenti operativi sono specifici.
SETTORE 01
Pubblica Amministrazione
Stato di modernizzazione
Piano Triennale ICT 2024-2026 → 75% PA migrate al cloud entro 2026. PSN (TIM, Leonardo, CDP Equity, Sogei) come spina dorsale.
Sistemi legacy tipici
INPS / INAIL su COBOL/PL-I + DB2. Agenzia Entrate / Sogei su monoliti di anagrafe tributaria. Sistemi sanitari regionali eterogenei.
Vincoli regolamentari specifici
AGID Determinazione 17/2025 + 43/2026. NIS2 con ispezioni ACN da ottobre 2026. Livelli QC1-QC4 di qualificazione cloud. Responsabilità umana non delegabile (CAD Art. 71 + L. 132/2025 Art. 14).
Applicazione di CATALYST
DISCOVER + DOCUMENT prezioso per recuperare la conoscenza tacita da sistemi soggetti a brain drain dei sistemisti storici. SECURE è l'argomento di NIS2-readiness.
Limite di trasferibilità diretta
Procurement via cataloghi cloud qualificati ACN o framework SPC. CATALYST come metodologia all'interno di contratti-quadro, non come licenza stand-alone.
SETTORE 02
Sanità
Stato di modernizzazione
FSE 2.0 fase 3 di piena operatività dal 31 marzo 2026 — alimentazione strutturata CDA2/HL7-FHIR entro 5 giorni. Sogei/AGID/MEF + Min. Salute + Agenas + Regioni.
Sistemi legacy tipici
HIS, LIS, PACS/RIS datati, spesso isolati. Mix di Java EE vecchio, .NET Framework, vendor proprietari.
Vincoli regolamentari specifici
MDR (UE 2017/745) + IVDR (2017/746) per software medical device. MDCG 2025-6: Medical Device AI è high-risk quando il device richiede notified body. GDPR Art. 9. PLD presunzioni di causalità per software difettosi.
Applicazione di CATALYST
VALIDATE configurato per generare test esaustivi sul legacy con dati sintetici GDPR-conformi. Differential trace analysis per ogni traduzione in microservizi. Tracciati legacy → API HL7-FHIR native per inserimento one-click nel FSE 2.0.
Limite di trasferibilità diretta
Doppia compliance MDR + AI Act è onerosa e richiede partner notified body. Per moduli life-critical il principio HiL si applica al grado massimo (four-eyes obbligatorio, FRIA esteso).
SETTORE 03
Energy / Utilities
Stato di modernizzazione
Convergenza IT/OT in espansione (smart meter, rinnovabili, dispatching). Iberdrola con €58B 2025-2028 (IA4TES per modernizzazione reti).
Sistemi legacy tipici
SCADA, EMS/DMS su architetture decennali in C/C++ o logiche PLC. Sopra: ERP, CRM, Billing utility, piattaforme di mercato dell'energia.
Vincoli regolamentari specifici
NIS2 con energia in Annex I come entità essenziali (D.Lgs. 138/2024). ISO/IEC 27019 baseline SCADA. Network Code on Cybersecurity (Reg. UE 2024/1366) — DORA non si applica all'energia, NCCS riempie il gap. AI Act Annex III §2 per safety component.
Applicazione di CATALYST
Le porzioni IT (billing, CRM, batch consumi) → pipeline standard. Le porzioni OT/SCADA → adattamento severo: pattern Strangler con wrapper API che incapsula il legacy SCADA per il cloud, mantenendo il controllo real-time governato dal legacy.
Limite di trasferibilità diretta
Compliance ARERA + NCCS aggiunge un livello regolatorio non presente in banking. OT/SCADA richiede competenze ingegneristiche (IEC 61508/61511) — CATALYST è componibile con un partner di safety engineering, non sostitutivo.
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 formale obbligatoria: replay produzione, side-by-side, diff con threshold ex ante, sign-off del business owner.
Esecuzione reale
Programma operativo su ~80 applicazioni desktop di un'assicurazione appartenente a un primario gruppo bancario italiano.
