Por qué el COBOL traducido por IA colapsa su base de datos

El problema

Un gran banco pidió a la IA que reescribiera treinta años de COBOL en Java. La IA tradujo la sintaxis a la perfección. El código compiló. Las pruebas unitarias pasaron. Entonces, la primera transacción hizo caer la base de datos.

El fallo no tuvo nada que ver con código defectuoso. El Java era gramaticalmente impecable. El problema era una dependencia oculta: una variable llamada TRN-LIMIT definida en un archivo de cabecera compartido a miles de líneas de distancia del código que la IA tradujo realmente. Ese archivo de cabecera contenía una cláusula REDEFINES, una característica de COBOL que permite que una misma dirección de memoria contenga dos tipos de datos distintos según un indicador establecido en un módulo completamente diferente. La IA nunca vio nada de esto. Trató TRN-LIMIT como un número simple. En realidad, era un decimal empaquetado (packed decimal). La discrepancia provocó que la aplicación Java escribiera datos binarios corruptos en la base de datos, desencadenando un fallo de integridad referencial.

Este no es un caso aislado. La investigación muestra que entre el 70% y el 80% de los proyectos de modernización de sistemas heredados no alcanzan sus objetivos. Es probable que su organización ejecute sistemas críticos sobre código más antiguo que la mayoría de sus empleados. Si está planificando una migración —o ya está inmerso en una— este patrón de fallo debería preocuparle profundamente. La IA no cometió un error tipográfico. Pasó por alto una relación que no podía ver. Ese es un tipo de riesgo fundamentalmente distinto, y la mayoría de las herramientas actuales no tienen respuesta para él.

Por qué esto importa para su negocio

La exposición financiera aquí es enorme, y afecta cada línea de su balance.

Solo la deuda técnica en Estados Unidos se estima en $1,52 billones. Si su organización opera sistemas heredados, está cargando con una parte de esa carga ahora mismo. Aproximadamente el 80% de los presupuestos de TI federales se destina a operaciones y mantenimiento, dejando apenas un 20% para cualquier cosa nueva. El sector bancario está especialmente expuesto: el 43% de los sistemas bancarios aún funciona sobre COBOL, y esos sistemas procesan el 95% de todas las transacciones de cajeros automáticos.

Esto es lo que significa para su perfil de riesgo:

• La exposición de seguridad se triplica. Los sistemas con más de diez años tienen estadísticamente tres veces más probabilidades de sufrir una violación de datos que las aplicaciones modernas. Cada trimestre que posponga la modernización, su superficie de ataque crece.
• El cumplimiento se endurece. Regulaciones como el GDPR y DORA exigen informes en tiempo real y controles de privacidad de datos. Los sistemas heredados no fueron diseñados para estos requisitos. Su incapacidad de adaptación se está convirtiendo en un riesgo de cumplimiento que sus reguladores notarán.
• Sus expertos se están marchando. Los desarrolladores que escribieron estos sistemas se están jubilando. El cincuenta y ocho por ciento de los desarrolladores afirma que plantea renunciar debido a las pilas tecnológicas heredadas. Cuando el conocimiento institucional sale por la puerta, sus costos de mantenimiento aumentan aún más.
• Las migraciones fallidas desperdician millones. Con una tasa de fracaso del 70-80%, las probabilidades están en su contra. Una migración mal ejecutada no solo cuesta el presupuesto del proyecto: daña la confianza en su liderazgo tecnológico y retrasa las capacidades de negocio que sus equipos esperan.

Su consejo quiere transformación digital. Sus reguladores quieren controles modernos. Su presupuesto ya está estirado al máximo solo para mantener las luces encendidas. No puede permitirse una migración que falle en silencio.

Qué está sucediendo realmente bajo el capó

Para entender por qué la IA estándar fracasa en esto, piense en su base de código como una ciudad. Cada función, variable y tabla de base de datos es un edificio. Las conexiones entre ellos —qué función llama a cuál, qué variable alimenta qué cálculo— son las carreteras.

Ahora imagine que le entregan a alguien la guía telefónica de todos los edificios de la ciudad y le piden rediseñar el sistema de transporte. Tienen nombres y direcciones, pero ningún mapa. No pueden ver qué carreteras conectan qué edificios. Eso es exactamente lo que hace una herramienta estándar de codificación con IA con su código. Lee el texto, pero no puede ver la estructura.

El fallo técnico específico se llama efecto «Lost in the Middle». Los grandes modelos de lenguaje —los motores de IA detrás de herramientas como los asistentes de codificación— procesan el texto mediante un mecanismo de atención. La investigación ha demostrado que estos modelos muestran una gran capacidad de retención para la información situada al principio y al final de una entrada larga, pero su rendimiento cae bruscamente para la información enterrada en el medio. En un programa COBOL que abarca miles de líneas y hace referencia a archivos externos, las definiciones críticas de variables suelen estar justo en ese punto ciego.

Cuando la IA no encuentra una definición, no se detiene a preguntar. Adivina. Rellena el hueco con algo estadísticamente plausible pero fácticamente incorrecto. En la terminología de IA, esto se llama alucinación. En su sistema bancario, esto significa que la IA podría asumir que una variable es un entero cuando en realidad es un decimal empaquetado. Esa única suposición errónea puede corromper datos financieros, romper la integridad de la base de datos y detener un sistema de transacciones. Su código compila. Sus pruebas pasan. Su entorno de producción falla.

Qué funciona (y qué no)

Empecemos por lo que sus equipos probablemente ya han intentado o considerado —y por qué cada enfoque se queda corto.

Lift and Shift (Rehosting): Mueve la aplicación compilada a un emulador en la nube. Esto cambia su factura de alojamiento, pero preserva cada línea del código heredado enmarañado. Carga toda la deuda técnica en un entorno nuevo y no obtiene ninguna de la flexibilidad de la nube.

Reescritura manual: Contrata desarrolladores para reescribir todo en Java a mano. Esto es dolorosamente lento, astronómicamente costoso y depende de encontrar personas que entiendan tanto COBOL como la arquitectura moderna. Con sus expertos en COBOL jubilándose, esto se vuelve más difícil cada año.

Herramientas de IA tipo wrapper: Apunta un asistente comercial de codificación con IA a su base de código. Traduce la sintaxis rápidamente. Pero, como muestra el fallo del banco, pasa por alto las dependencias entre archivos, alucina definiciones de variables y produce código que parece correcto pero se comporta mal.

Esto es lo que realmente funciona: un enfoque basado en grafos que trata su código como un sistema conectado en lugar de una pila de archivos de texto:

1. Analice la estructura, no solo el texto. En lugar de trocear su código en fragmentos arbitrarios de texto, analice sintácticamente cada archivo en un árbol que represente su estructura lógica: cada variable, cada función, cada rama de flujo de control. Esto garantiza que la IA respete los límites de su código. Una función se trata como una unidad completa de lógica, no como un corte aleatorio de texto.

2. Construya un mapa de cada relación. Extraiga cada conexión en su base de código —qué módulos llaman a qué subrutinas, qué archivos definen qué variables, qué funciones actualizan qué tablas de base de datos— y almacénelas en un grafo de conocimiento. Cuando la IA necesite traducir una función de pago, no simplemente toma texto que menciona «pago». Sigue la cadena real de dependencias para incorporar cada definición de variable, cada cabecera compartida y cada impacto aguas abajo. Esto es lo que Veriprajna llama un grafo de conocimiento consciente del repositorio, y resuelve directamente el problema del «Lost in the Middle».

3. Verifique cada resultado contra el mapa. La IA genera código Java y luego lo compila en un sandbox. Si el compilador lanza un error —por ejemplo, una variable faltante— el sistema consulta el grafo, encuentra la dependencia y regenera el código. Este ciclo de compilación y corrección se ejecuta automáticamente. Sus desarrolladores revisan resultados verificados, no suposiciones brutas de la IA.

La ventaja que más importa a sus equipos de cumplimiento y auditoría: cada decisión que toma la IA es trazable. El grafo de conocimiento registra exactamente por qué la IA importó una biblioteca específica o definió una variable de cierta manera. En lugar de una caja negra, obtiene una cadena de citas verificables. Sus auditores pueden ver el rastro lógico de cada línea de código generado.

Este enfoque también elimina el desperdicio antes de que comience la migración. El grafo de conocimiento identifica código muerto: funciones que nada en su sistema llama realmente. Eliminar código muerto típicamente reduce la base de código en un 20-30%, lo que significa menores costos de migración y un sistema final más limpio.

Para las organizaciones del sector de servicios financieros que enfrentan escrutinio regulatorio, este tipo de transparencia no es opcional. Y si su modernización requiere rastrear la procedencia de los datos entre sistemas, las capacidades de procedencia y trazabilidad de datos de Veriprajna extienden el mismo enfoque basado en grafos a toda su canalización de datos.

Puede leer el análisis técnico completo para conocer los detalles de ingeniería, o explorar la versión interactiva para un recorrido visual de cómo funciona el grafo de conocimiento en la práctica.