CATALYST è il layer di metodo, governance e gate deterministici. Sopra i frontier model — Claude Opus 4.7 e GPT-5.5 — 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 primario gruppo bancario-assicurativo italiano. Target .NET 9, C# 13. Non è un PowerPoint.
§ 01 / 11
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 Linee Guida — tutte in enforcement tra 2025-2027. Sanzioni fino al 7% del turnover globale.
Governance gap
0%
>
Penetrazione AI: 70% assicurazioni, 59% banche italiane. Solo il 16% ha framework di governance strutturato (Banca d'Italia + OCSE, apr. 2026).
§ 02 / 11
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
Test Foundation obbligatoria
Senza copertura del comportamento legacy in produzione, la migrazione è un atto di fede. Niente migrazione senza Test Foundation.
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 proof formale: 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 / 11
Cosa fa CATALYST
Cinque domini operativi · Otto stack supportati
Dal sorgente legacy all'evidence pack regolamentare.
Cinque domini operativi convergono nelle tre fasi di pipeline. Ogni dominio ha un obiettivo, capability, output strutturato e un gate di uscita. Il framework si applica oggi su otto stack documentati — architettura stack-agnostic, aggiungere un nuovo target è un nuovo domain adapter, non un 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
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
Dove si applica
Otto stack documentati, programmi in produzione.
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-assicurativo IT — programma in produzione
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.
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 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
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. 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
§ 06 / 11
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.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.
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). Replicabile su Codex CLI via AGENTS.md per scenari multi-vendor.
§ 07 / 11
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 51° agg. 03.02.2026AGID LG 17/2025 · 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
⚑ 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.
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
Circolare 285 51° agg. rimuove i Capitoli 4-5 Parte I Tit. IV cross-referenziando direttamente DORA: il framework si allinea senza duplicare. AGID Linee Guida 17/2025 + Determinazione 43/2026 tracciano 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 differenze concrete che separano CATALYST dal Code Modernization Playbook di Anthropic (23 feb. 2026)
§ 08 / 11
MCP attack surface
Superficie d'attacco, non capability acquisita
MCP — trattato come superficie d'attacco, non capability acquisita.
Oltre 9.400 server MCP pubblici nel registry a metà aprile 2026, donato alla Linux Foundation Agentic AI Foundation a dicembre 2025. Vulnerabilità design-level negli SDK MCP STDIO hanno toccato ≥7.000 server (OX Security disclosure); CVE successive tra dicembre 2025 e maggio 2026 hanno colpito MCPJam Inspector (CVE-2026-23744, CVSS 9.8), Windsurf, Microsoft Copilot Studio, mcp-server-git. Il framework adotta sette policy operative — registry ufficiali, STDIO untrusted by default, sandbox least-privilege, MCP Gateway centralizzato, runtime guardrail, audit trail 5+ anni, prompt injection come classe — e tiene un registro CVE aggiornato.
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 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
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.
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 primario gruppo bancario-assicurativo italiano.
