Perché il COBOL tradotto dall'IA manda in crash il database

Il problema

Una grande banca ha chiesto all'IA di riscrivere trent'anni di COBOL in Java. L'IA ha tradotto la sintassi alla perfezione. Il codice è stato compilato. I test unitari sono passati. Poi la prima transazione ha mandato in crash il database.

L'errore non aveva nulla a che vedere con codice difettoso. Il Java era grammaticalmente impeccabile. Il problema era una dipendenza nascosta: una variabile chiamata TRN-LIMIT definita in un file header condiviso a migliaia di righe di distanza dal codice che l'IA ha effettivamente tradotto. Quel file header conteneva una clausola REDEFINES, una funzionalità del COBOL che permette a un unico indirizzo di memoria di contenere due tipi di dati diversi a seconda di un flag impostato in un modulo completamente diverso. L'IA non ne ha mai visto traccia. Ha trattato TRN-LIMIT come un semplice numero. In realtà era un decimale compresso (packed decimal). Questa discrepanza ha portato l'applicazione Java a scrivere dati binari corrotti nel database, innescando un guasto di integrità referenziale.

Non si tratta di un caso limite. La ricerca dimostra che dal 70% all'80% dei progetti di modernizzazione del legacy non raggiunge i propri obiettivi. Probabilmente la vostra organizzazione gestisce sistemi critici su codice più vecchio della maggior parte dei vostri dipendenti. Se state pianificando una migrazione — o siete già in corsa — questo schema di guasto dovrebbe preoccuparvi profondamente. L'IA non ha commesso un errore di battitura. Ha trascurato una relazione che non poteva vedere. Si tratta di un tipo di rischio fondamentalmente diverso, e la maggior parte degli strumenti attuali non ha alcuna risposta a riguardo.

Perché questo riguarda la vostra azienda

L'esposizione finanziaria in gioco è enorme e tocca ogni voce del vostro bilancio.

Il debito tecnico solo negli Stati Uniti ha raggiunto una stima di $1,52 bilioni. Se la vostra organizzazione utilizza sistemi legacy, state portandone il peso in questo momento. Circa l'80% dei budget IT federali va in operazioni e manutenzione — lasciando solo il 20% per qualsiasi cosa nuova. Il settore bancario è particolarmente esposto: il 43% dei sistemi bancari gira ancora su COBOL, e quei sistemi elaborano il 95% di tutte le transazioni ATM.

Ecco cosa significa tutto questo per il vostro profilo di rischio:

• L'esposizione alla sicurezza triplica. I sistemi più vecchi di dieci anni hanno una probabilità statisticamente tripla di subire una violazione dei dati rispetto alle applicazioni moderne. Ogni trimestre in cui ritirate la modernizzazione, la vostra superficie di attacco cresce.
• La conformità normativa si stringe. Regolamentazioni come GDPR e DORA richiedono reportistica in tempo reale e controlli sulla privacy dei dati. I sistemi legacy non sono stati progettati per questi requisiti. La vostra incapacità di adattarvi sta diventando un rischio di conformità che i vostri regolatori noteranno.
• I vostri esperti stanno andando via. Gli sviluppatori che hanno scritto questi sistemi stanno andando in pensione. Il 58% degli sviluppatori dichiara di prendere in considerazione le dimissioni a causa delle tecnologie legacy. Quando la conoscenza istituzionale esce dalla porta, i vostri costi di manutenzione salgono ulteriormente.
• Le migrazioni fallite sprecano milioni. Con un tasso di fallimento del 70-80%, le probabilità sono contro di voi. Una migrazione mal riuscita non costa solo il budget del progetto — danneggia la fiducia nella vostra leadership tecnologica e ritarda le capacità aziendali per cui i vostri team aspettano.

Il vostro consiglio di amministrazione vuole la trasformazione digitale. I vostri regolatori vogliono controlli moderni. Il vostro budget è già sotto sforzo solo per mantenere le luci accese. Non potete permettervi una migrazione che fallisce in silenzio.

Cosa succede davvero sotto il cofano

Per capire perché l'IA standard fallisce in questo, pensate alla vostra base di codice come a una città. Ogni funzione, variabile e tabella di database è un edificio. Le connessioni tra loro — quale funzione chiama quale, quale variabile alimenta quale calcolo — sono le strade.

Ora immaginate di consegnare a qualcuno un elenco telefonico di ogni edificio della città e di chiedergli di riprogettare il sistema di trasporti. Ha nomi e indirizzi, ma nessuna mappa. Non può vedere quali strade collegano quali edifici. È esattamente ciò che fa un normale strumento di coding IA con il vostro codice. Legge il testo ma non può vedere la struttura.

Il guasto tecnico specifico si chiama effetto "Lost in the Middle". I Large Language Model — i motori IA alla base di strumenti come gli assistenti di programmazione — elaborano il testo tramite un meccanismo di attenzione. La ricerca ha dimostrato che questi modelli mostrano un forte ricordo delle informazioni all'inizio e alla fine di un input lungo, ma le loro prestazioni calano bruscamente per le informazioni sepolte nel mezzo. In un programma COBOL che si estende per migliaia di righe e fa riferimento a file esterni, le definizioni critiche delle variabili spesso si trovano proprio in quel punto cieco.

Quando l'IA non trova una definizione, non si ferma a chiedere. Indovina. Colma la lacuna con qualcosa di statisticamente plausibile ma fattualmente sbagliato. Nella terminologia dell'IA, questo si chiama allucinazione. Nel vostro sistema bancario, significa che l'IA potrebbe presumere che una variabile sia un intero quando in realtà è un decimale compresso. Quella singola ipotesi sbagliata può corrompere dati finanziari, compromettere l'integrità del database e fermare un sistema di transazioni. Il vostro codice si compila. I vostri test passano. Il vostro ambiente di produzione fallisce.

Cosa funziona (e cosa no)

Partiamo da ciò che i vostri team hanno probabilmente già provato o preso in considerazione — e perché ciascun approccio resta corto.

Lift and Shift (Rehosting): Spostate l'applicazione compilata su un emulatore cloud. Questo cambia la vostra fattura di hosting ma preserva ogni riga di codice legacy aggrovigliato. Vi portate dietro tutto il debito tecnico in un nuovo ambiente senza acquisire alcuna flessibilità del cloud.

Riscrittura manuale: Assumete sviluppatori per riscrivere tutto a mano in Java. È dolorosamente lento, astronomicamente costoso e dipende dal trovare persone che capiscano sia COBOL sia architetture moderne. Con i vostri esperti COBOL in pensione, diventa più difficile ogni anno.

Strumenti AI wrapper: Puntate un assistente di programmazione IA commerciale alla vostra base di codice. Traduce rapidamente la sintassi. Ma, come mostra il fallimento della banca, tralascia le dipendenze tra file, allucina definizioni di variabili e produce codice che sembra corretto ma si comporta male.

Ecco ciò che funziona davvero — un approccio basato sui grafi che tratta il vostro codice come un sistema connesso anziché come una pila di file di testo:

1. Analizzate la struttura, non solo il testo. Invece di tagliare il vostro codice in blocchi di testo arbitrari, analizzate ogni file in un albero che ne rappresenta la struttura logica — ogni variabile, ogni funzione, ogni ramo del flusso di controllo. Questo garantisce che l'IA rispetti i confini del vostro codice. Una funzione viene trattata come un'unità completa di logica, non come una fetta casuale di testo.

2. Costruite una mappa di ogni relazione. Estraele ogni connessione nella vostra base di codice — quali moduli chiamano quali subroutine, quali file definiscono quali variabili, quali funzioni aggiornano quali tabelle di database — e conservatele in un knowledge graph. Quando l'IA deve tradurre una funzione di pagamento, non si limita a prendere testo che menziona "pagamento". Segue la vera catena delle dipendenze per includere ogni definizione di variabile, ogni header condiviso e ogni impatto a valle. Questo è ciò che Veriprajna chiama Knowledge Graph consapevole del repository, e risolve direttamente il problema dell'effetto "Lost in the Middle".

3. Verificate ogni output rispetto alla mappa. L'IA genera il codice Java, poi lo compila in una sandbox. Se il compilatore segnala un errore — per esempio, una variabile mancante — il sistema interroga il grafo, trova la dipendenza e rigenera il codice. Questo ciclo di compilazione-correzione gira automaticamente. I vostri sviluppatori revisionano output verificati, non semplici supposizioni dell'IA.

Il vantaggio che conta di più per i vostri team di compliance e audit: ogni decisione dell'IA è tracciabile. Il knowledge graph registra esattamente perché l'IA ha importato una specifica libreria o definito una variabile in un certo modo. Invece di una scatola nera, ottenete una catena di riferimenti. I vostri auditor possono seguire il percorso logico di ogni riga di codice generato.

Questo approccio elimina anche gli sprechi prima ancora che la migrazione inizi. Il knowledge graph individua il codice morto — funzioni che nulla nel vostro sistema chiama realmente. Rimuovere il codice morto riduce tipicamente la base di codice del 20-30%, il che significa costi di migrazione inferiori e un sistema finale più pulito.

Per le organizzazioni dei servizi finanziari soggette al controllo normativo, questo tipo di trasparenza non è opzionale. E se la vostra modernizzazione richiede di tracciare il data lineage attraverso i sistemi, le capacità di provenienza e tracciabilità dei dati estendono lo stesso approccio basato sui grafi all'intera pipeline di dati.

Potete leggere l'analisi tecnica completa per i dettagli ingegneristici, oppure esplorare la versione interattiva per una panoramica visiva di come il knowledge graph funziona nella pratica.