El 23 de febrero de 2026, el precio de las acciones de IBM cayó un 13 % en un solo día, su mayor descenso diario desde octubre de 2000. El detonante fue el anuncio de un laboratorio de IA que afirmaba tener la capacidad de modernizar COBOL. Los consejos de administración con sistemas mainframe leyeron el anuncio y preguntaron si la IA podría ahora convertir su COBOL y permitirles apagar el mainframe. La respuesta de IBM, publicada ese mismo día, fue precisa: la traducción no capta prácticamente ninguna de las complejidades reales, que residen en la arquitectura de datos, la sustitución del tiempo de ejecución, la integridad de las transacciones y los requisitos no funcionales integrados en la plataforma. El mercado había confundido dos problemas distintos y había valorado la solución a uno como si fuera la solución a ambos.
Los dos problemas son la comprensión y la traducción. No son fases de la misma actividad. Son desafíos técnicos genuinamente distintos que la IA aborda con capacidades y riesgos genuinamente distintos. La IA ha abaratado drásticamente la comprensión del entorno COBOL, pero no su sustitución. Esta distinción es crucial precisamente porque las organizaciones que toman decisiones de inversión en modernización necesitan saber qué problema están intentando resolver, qué aporta realmente la IA a cada uno y dónde el trabajo de verificación, que permanece independientemente de las herramientas de IA, consumirá el presupuesto liberado gracias a los ahorros en comprensión y traducción.
La base estructural que necesita la IA
SMART TS XL Identifica los programas inaccesibles antes de que comience la traducción por IA, de modo que se traduce lo que se ejecuta, no lo que existe.
DESCUBRE MÁS…La distinción en la que el mercado se equivocó
La comprensión y la traducción no son el mismo problema.
La comprensión es la disciplina de entender qué hace el código y por qué, extrayendo la intención del negocio de la implementación técnica. En un contexto COBOL, la comprensión implica: ¿qué reglas de negocio codifica este programa? ¿Qué condiciones rigen cada ruta de ejecución? ¿Qué datos lee y produce? ¿Qué sistemas posteriores dependen de sus resultados? ¿Qué necesitaría saber un analista de negocio sobre este programa para escribir una especificación para su reemplazo? La comprensión se centra en la semántica, el significado, no la sintaxis.
La traducción es la disciplina de convertir código de un lenguaje a otro conservando su comportamiento. En el contexto de COBOL, traducir significa producir código Java (o Python, o Go) que haga lo mismo que el código COBOL, para todas las entradas, bajo cualquier condición, con una equivalencia numérica suficiente para los sistemas posteriores que consumen las salidas. La traducción se centra en la equivalencia estructural y de comportamiento; el nuevo código debe superar todas las pruebas que habría superado el código original, incluidas las pruebas para casos límite que el desarrollador original consideró y cuya existencia quizás desconocías.
| Dimensión | Comprensión | Traducción |
|---|---|---|
| Pregunta respondida | ¿Qué significa este código? | ¿Qué hace exactamente este código? |
| Tipo de salida | Lenguaje natural, documentación | Código ejecutable |
| Consecuencia del error | Corregible mediante revisión humana | Incidente de producción |
| Capacidad de IA | Sólidos, los LLM sobresalen en prosa. | Débil, se requiere determinismo |
| Restricción de escala | Gestionable con ventanas de contexto | La escala de cartera no alcanza el límite de contexto |
| Perfil de riesgo | Bajo, los errores son revisables | Alto, los errores son invisibles hasta que se producen. |
| papel humano | Validador y enriquecedor | Revisor y probador |
Estos problemas están relacionados; se necesita cierta comprensión para realizar una buena traducción, pero no son el mismo problema, y la brecha de capacidad de la IA entre ambos es significativa. La comprensión del código COBOL por parte de la IA es realmente impresionante. La traducción del código COBOL a Java para producción mediante IA es realmente difícil, y la confusión que existe en el mercado entre ambos explica por qué Gartner predijo que más del 70 % de los proyectos de migración de mainframes iniciados en 2026 no lograrán los beneficios previstos.
Donde la comprensión de la IA realmente da resultados
El problema de la comprensión tiene una característica que hace que la IA sea idónea para resolverlo: el resultado es lenguaje natural, y la generación de lenguaje natural es precisamente lo que hacen bien los grandes modelos lingüísticos. Cuando la IA lee un programa COBOL y genera documentación (una descripción de su funcionamiento, una explicación de sus reglas de negocio y una enumeración de sus flujos de datos), el resultado es texto. Los errores en ese texto son recuperables: un revisor humano puede detectar una regla de negocio mal caracterizada y corregirla sin consecuencias técnicas posteriores. El coste de los errores de comprensión se reduce a una corrección de la documentación, no a un incidente en producción.
Documentación de reglas de negocio. Un modelo de lenguaje extenso, presentado con un bloque COBOL EVALUATE, que potencialmente contiene cientos de condiciones WHEN acumuladas durante décadas de cambios regulatorios, puede generar una descripción estructurada del significado de cada condición en términos de negocio. Para programas cuya documentación original ya no existe o nunca existió, esto resulta sumamente valioso. Un programa COBOL que implementa la lógica de cálculo de impuestos en 63 jurisdicciones tiene esas reglas codificadas en su estructura EVALUATE; la IA puede extraerlas y documentarlas más rápido que cualquier proceso manual. Lo que produce debe ser validado por un experto en el dominio, pero el experto valida la salida de la IA en lugar de reconstruir el conocimiento desde cero, lo cual es un proceso mucho más rápido.
Así es como se ve la comprensión de la IA en la práctica. Dado este código fuente COBOL:
cobol
EVALUATE TRUE
WHEN CUST-COUNTRY = 'US' AND CUST-STATE = 'CA'
COMPUTE TAX-AMT = GROSS-AMT * 0.0725
WHEN CUST-COUNTRY = 'US' AND CUST-STATE = 'TX'
COMPUTE TAX-AMT = GROSS-AMT * 0.0825
WHEN CUST-COUNTRY = 'UK'
COMPUTE TAX-AMT = GROSS-AMT * 0.20
WHEN CUST-COUNTRY = 'DE'
COMPUTE TAX-AMT = GROSS-AMT * 0.19
WHEN OTHER
MOVE ZERO TO TAX-AMT
END-EVALUATE.
Un programa de máster en derecho bien planificado produce:
Business Rule: Tax Calculation
This paragraph applies jurisdiction-specific tax rates to GROSS-AMT:
- US/California: 7.25% (CA state sales tax)
- US/Texas: 8.25% (TX state sales tax)
- United Kingdom: 20% (UK VAT standard rate)
- Germany: 19% (DE MwSt standard rate)
- All other countries: tax-exempt (TAX-AMT = 0)
Note: No rate exists for other US states. Orders from NY, FL, IL
will be tax-exempt under current logic -- likely a gap requiring review.Este resultado es realmente valioso: documenta cuatro reglas de negocio, identifica una posible deficiencia (estados de EE. UU. sin tarifas explícitas) y lo hace en cuestión de horas. Un experto en la materia lo revisa, confirma la deficiencia y la añade a los casos de prueba. La tarea de comprensión se completó correctamente.
Narrativa de dependencias. Las herramientas de análisis estático generan gráficos de dependencias que muestran qué programas llaman a cuáles, qué archivos de copia se comparten y qué conjuntos de datos fluyen entre programas. La IA puede generar una narrativa en lenguaje natural a partir de ese gráfico: «CUSTPROC es llamado por 14 programas, principalmente en la ventana de procesamiento por lotes nocturna. Comparte CUSTMSTR con 47 programas y genera resultados para CUST-REPORT-FILE, que es utilizado por el flujo de trabajo de informes regulatorios». Esta narrativa es más útil para la incorporación y la revisión de la arquitectura que un gráfico de dependencias por sí solo, y la IA la genera en segundos a partir de los datos de dependencias estructurados.
Generación de casos de prueba a partir del comportamiento comprendido. Una vez que la IA ha documentado el comportamiento del programa, puede generar casos de prueba que cubran las rutas de ejecución documentadas. Esto no equivale a demostrar la equivalencia de comportamiento, ya que los casos de prueba cubren las rutas que la IA comprendió, pudiendo omitir otras que desconocía. Sin embargo, cubrir el 60 % de las rutas de ejecución mediante pruebas generadas por IA es mejor que la cobertura del 0 % que presentan muchos programas heredados, y proporciona un punto de partida para la ampliación de las pruebas manuales que requiere la validación de la equivalencia de comportamiento.
Reconocimiento de patrones en programas similares. Los grandes portafolios de COBOL suelen contener muchos programas estructuralmente similares, con el mismo patrón de procesamiento aplicado a diferentes entidades y el mismo cálculo regulatorio parametrizado de forma distinta. La IA puede identificar estas similitudes en miles de programas y agruparlos por tipo de patrón, lo que permite una estrategia de migración que aborda cada patrón una sola vez y aplica la solución sistemáticamente, en lugar de tratar cada programa como único.
El denominador común es que los resultados de la comprensión de la IA son texto, este texto puede ser revisado por humanos, y la revisión humana detecta los errores antes de que tengan consecuencias técnicas. El perfil de riesgo de la comprensión de la IA es lo suficientemente bajo como para que el valor que aporta sea real y los errores que comete sean manejables.
Donde la traducción automática promete demasiado
La traducción tiene una característica que la hace fundamentalmente más difícil para la IA que la comprensión: el resultado es código ejecutable, y este debe ser absolutamente correcto. Una traducción con un 95 % de precisión produce un programa que falla en el 5 % de los casos, lo que en un sistema de procesamiento de transacciones financieras puede representar un error en los informes regulatorios, una discrepancia en el cálculo de saldos o un incumplimiento normativo. El costo de los errores de traducción no se reduce a una corrección de documentación, sino a un incidente en producción.
El fallo de precisión numérica. La aritmética decimal empaquetada de COBOL (COMP-3) produce resultados decimales exactos. double y Python float utiliza el formato de punto flotante binario IEEE 754, que no puede representar con exactitud la mayoría de las fracciones decimales. Un programa COBOL que calcula 0.1 + 0.2 con COMP-3 produce exactamente 0.3. El mismo cálculo en Java con double produce 0.30000000000000004Para una institución financiera donde este cálculo se ejecuta 10 millones de veces por noche en presentaciones regulatorias, el error acumulado no es una curiosidad de punto flotante, sino una discrepancia en los informes financieros. Una traducción de IA que genera Java sin manejar explícitamente el mapeo COMP-3 a BigDecimal introduce este error sistemáticamente, y lo hace para cada campo que la IA traduce como double más bien que BigDecimal.
La diferencia en el código es sutil; la consecuencia no lo es:
cobol
* COBOL: COMP-3 packed decimal -- exact arithmetic
77 UNIT-PRICE PIC S9(7)V99 COMP-3.
77 QUANTITY PIC S9(5) COMP-3.
77 LINE-TOTAL PIC S9(11)V99 COMP-3.
COMPUTE LINE-TOTAL = UNIT-PRICE * QUANTITY.
* UNIT-PRICE = 19.99, QUANTITY = 3
* LINE-TOTAL = exactly 59.97 -- no rounding error
Java
// Java: naive AI translation uses double -- introduces error
double unitPrice = 19.99;
int quantity = 3;
double lineTotal = unitPrice * quantity;
// lineTotal = 59.96999999999999... not 59.97
// Correct translation requires BigDecimal:
// BigDecimal lineTotal = new BigDecimal("19.99").multiply(new BigDecimal(3));En una sola transacción, el error es imperceptible. En 10 millones de transacciones diarias, sumadas en un informe de capital regulatorio, se trata de una discrepancia significativa. Una traducción automática que no aborde explícitamente los campos COMP-3 realizará esta sustitución en todos los casos.
Dependencia de las opciones del compilador. El mismo código fuente COBOL puede generar comportamientos diferentes con distintas opciones del compilador. NUMPROC(MIG) frente a NUMPROC(NOPFD) modifica el manejo de las excepciones numéricas. Las opciones RMODE, AMODE y DATA afectan al direccionamiento. Una IA que traduce código fuente COBOL sin conocer las opciones del compilador traduce el código fuente del programa, no su comportamiento. El código Java traducido puede coincidir con el código fuente, pero no con el comportamiento en producción.
El problema de las alucinaciones a gran escala. Las investigaciones demuestran que los modelos de la clase GPT-4 presentan tasas de alucinaciones de entre el 33 % y el 60 % en tareas generales de traducción de código, generando código de apariencia plausible que añade o elimina comportamientos no presentes en el código fuente. Para un programa con 847 condiciones de EVALUACIÓN, una tasa de alucinaciones del 5 % significa que aproximadamente 42 condiciones se traducen incorrectamente. Estas 42 condiciones representan reglas de negocio que la traducción infringió silenciosamente. Sin un corpus de prueba completo que ejercite todas las condiciones, estas infracciones son indetectables hasta que la combinación de entrada específica que las desencadena llega a producción.
Lo que está en juego en términos de números:
Error Type | Detection Point | Cost Range
--------------------|--------------------|------------------
Comprehension error | Human review | Hours to fix
Translation error | Test suite | Days to isolate
Translation error | Production | $10K-$500K+ incident
Equivalence gap | Regulatory audit | $50K-$5M+ penaltyLa asimetría: Los errores de comprensión se detectan antes de que tengan consecuencias técnicas. Los errores de traducción sobreviven a la revisión y se propagan durante la producción o, peor aún, en una presentación regulatoria.
El límite de la ventana de contexto. WatsonX Code Assistant para Z de IBM logra una precisión estructural del 80 % o superior en la traducción de COBOL a Java para programas individuales dentro de una ventana de contexto. Un portafolio de COBOL de 5 millones de líneas consta de miles de programas, con dependencias entre programas que no pueden estar todos en la misma ventana de contexto simultáneamente. Un programa que llama a un subprograma cuya interfaz la IA tradujo de forma diferente a las suposiciones del programa que lo llama crea una discrepancia de interfaz que ninguna traducción por sí sola revelaría. La traducción a escala de portafolio requiere comprensión entre programas, no solo dentro de ellos.
El problema de la traducción sin contexto. Un programa COBOL que procesa un evento empresarial específico lo hace con un contexto integrado en el sistema que lo rodea: la planificación por lotes que determina cuándo se ejecuta, los conjuntos de datos que deben estar disponibles al iniciarse, el orden en que procesa los registros y los programas posteriores que leen su salida antes de ejecutarse. Una IA que traduce el programa sin comprender este contexto traduce el código fuente, pero no la función. El código Java traducido puede ser internamente correcto y aun así fallar operativamente porque se ejecuta en el momento y el orden incorrectos, sin los requisitos de datos en los que se basaba su predecesor COBOL.
La brecha de equivalencia conductual
El problema más importante que ni la IA de comprensión ni la IA de traducción resuelven es la prueba de equivalencia de comportamiento, es decir, la demostración de que el sistema modernizado produce los mismos resultados que el sistema anterior para todas las entradas que son importantes para la empresa y sus reguladores.
La equivalencia de comportamiento no es un problema de pruebas en el sentido tradicional. No se trata de preguntar "¿el nuevo sistema supera el conjunto de pruebas?", ya que el conjunto de pruebas para un sistema COBOL heredado a menudo no existe o cubre solo una fracción de las rutas de ejecución del programa. Se trata de preguntar: para cada entrada que el sistema de producción haya recibido, ¿el sistema modernizado produce la misma salida? Y para cada entrada que el sistema de producción pueda recibir en el futuro, incluyendo casos excepcionales que ocurren solo durante condiciones de mercado poco frecuentes, períodos de informes regulatorios o circunstancias específicas del cliente, ¿el sistema modernizado produce el resultado equivalente?
Para responder a esta pregunta se requiere: una caracterización del comportamiento del sistema existente derivada de la ejecución real en producción (no de la documentación, ni solo del código fuente), un corpus de prueba que abarque toda la gama de ese comportamiento y un marco de comparación que pueda determinar qué significa "equivalente" para salidas donde la representación difiere (EBCDIC frente a UTF-8, decimal empaquetado frente a BigDecimal, archivo por lotes frente a registro de base de datos).
Nada de esto es lo que ofrecen las herramientas de traducción con IA. La evaluación de IBM es directa: la traducción no refleja prácticamente la complejidad real de la modernización. El trabajo de equivalencia de comportamiento, la ejecución en paralelo, el marco de conciliación y la aprobación regulatoria son los aspectos donde se concentran el costo y el riesgo, y donde la IA tiene el menor impacto en el costo total del programa. La IA simplifica la fase inicial del proyecto de modernización: la comprensión y la traducción inicial. No simplifica la fase posterior: la verificación, las pruebas de equivalencia y la validación en paralelo.
El modelo correcto: Fundamentos del análisis estático, capa semántica de IA
La capacidad de comprensión más eficaz de la IA no reside únicamente en la IA, sino en la IA que opera sobre una base estructural proporcionada por el análisis estático. Las limitaciones de la comprensión de la IA (limitaciones de la ventana de contexto, ilusiones con lógica compleja entre programas, análisis probabilístico en lugar de determinista) se abordan mediante el análisis estático. Las limitaciones del análisis estático (produce hechos estructurales pero no descripciones semánticas) también se abordan mediante la IA.
La correcta división del trabajo: El análisis estático proporciona certeza estructural (determinista, completo, sin ilusiones). La IA proporciona riqueza semántica (descripciones en lenguaje natural, reconocimiento de patrones, generación de pruebas). Ninguno de los dos por sí solo es suficiente. Juntos cubren el requisito de comprensión total.
La base estructural que proporciona el análisis estático:
Inventario completo del programa. Todos los programas del portafolio, incluidos aquellos que no aparecen en la documentación y los que la ventana de contexto de la IA nunca podría procesar simultáneamente. El análisis estático procesa todo el portafolio sin limitaciones de contexto.
Gráfico de dependencias preciso. Cada relación de llamada, cada relación de copia, cada flujo de datos entre programas, se deriva de forma determinista de la fuente, no probabilística a partir de datos de entrenamiento. Cuando una herramienta de comprensión de IA describe las dependencias de un programa, esa descripción debe basarse en un gráfico de dependencias generado por un análisis estático, no en la estimación probabilística que hace la IA de las dependencias típicas de los programas.
Identificación de código muerto. Los programas inaccesibles desde cualquier ruta de ejecución de producción no entran dentro del alcance de la modernización. El análisis estático los identifica con certeza; la IA no puede, porque carece de los rastros de ejecución necesarios para distinguir el código activo del código muerto mediante el análisis estático únicamente.
Inventario de esquemas de datos. Cada entrada FD, cada copybook, cada campo COMP-3 con su especificación de precisión, extraídos de los artefactos fuente en lugar de reconstruirse a partir de la memoria de datos de entrenamiento de la IA sobre cómo suelen ser las definiciones de campos COBOL.
Sobre esta base estructural, la comprensión mediante IA añade la capa semántica: las descripciones en lenguaje natural de la función de cada programa, la documentación de las reglas de negocio, la descripción de los flujos de datos entre programas y el reconocimiento de patrones que agrupa programas similares. Esta combinación —precisión estructural determinista derivada del análisis estático y riqueza semántica en lenguaje natural gracias a la IA— constituye el modelo que genera resultados de comprensión fiables para un equipo de modernización.
Qué significa esto para su programa de modernización.
Asignación práctica de la inversión en IA basada en este análisis:
Invierta en la comprensión de la IA. La generación de documentación, la extracción de reglas de negocio, la descripción de dependencias y la generación de casos de prueba a partir del comportamiento documentado son usos de la IA de alto valor y bajo riesgo que reducen la fase de modernización, tradicionalmente manual y más costosa. Realice estas tareas primero, antes de la traducción, porque la comprensión influye en cada decisión posterior.
Utilice la traducción automática como un borrador, no como un finalizador. La traducción automática genera un punto de partida en Java o Python que un desarrollador revisa, corrige y valida, no código listo para producción que pueda implementarse sin revisión humana. Tratar la traducción automática como un borrador reduce el costo de la traducción, manteniendo al mismo tiempo la responsabilidad humana que requiere la validación de equivalencia.
No contabilice el ahorro derivado de la traducción con IA como parte del costo de verificación. La IA reduce el tiempo de producción de un programa traducido, pero no el tiempo necesario para demostrar que dicho programa es equivalente al original. Presupueste la fase de verificación independientemente del ahorro derivado de la traducción con IA, ya que el alcance de la verificación no disminuye al aumentar la velocidad de traducción.
Primero, es fundamental construir la base estructural. Las herramientas de comprensión de IA que carecen de una base estructural sólida, un gráfico de dependencias preciso, un inventario completo del programa y un inventario del esquema de datos, generan una comprensión incompleta en las zonas más complejas del código. Los programas que más necesitan la comprensión de la IA suelen ser los más complejos, los que presentan mayor dependencia entre programas y los que tienen más probabilidades de superar la capacidad de análisis preciso que la IA puede ofrecer únicamente a partir del código fuente.
Cómo SMART TS XL Admite la comprensión de COBOL mejorada mediante IA.
SMART TS XL Proporciona la base de análisis estructural que hace que la comprensión de las carteras COBOL por parte de la IA sea precisa en lugar de probabilística.
La capacidad de análisis de código estático genera los datos estructurales a nivel de programa que necesitan las herramientas de comprensión de IA: se enumeran todas las condiciones de EVALUATE, se extraen todas las fórmulas de COMPUTE y se caracterizan todos los patrones de acceso a datos. Cuando las herramientas de documentación de IA operan sobre el código fuente con estos datos estructurales como contexto, generan descripciones basadas en el contenido real del código, en lugar de en el comportamiento típico de programas similares.
El mapeo de dependencias de la aplicación proporciona el contexto entre programas que las ventanas de contexto de la IA no pueden contener simultáneamente. Un gráfico de dependencias que muestra los 14 llamadores de CUSTPROC, sus 47 compartidores de copybook y sus 3 salidas de flujo de datos ofrece a las herramientas de comprensión de la IA una visión completa del rol de un programa en el portafolio, sin necesidad de que todos los programas dependientes estén en la misma ventana de contexto al mismo tiempo.
El análisis de modernización de sistemas heredados genera un inventario de código muerto y una distribución de complejidad que la comprensión de la IA no puede producir de forma fiable por sí sola: qué programas son inaccesibles desde producción (excluidos del alcance), qué programas tienen la mayor complejidad (donde los errores de comprensión son más costosos) y cómo es el alcance de la migración de datos derivado de las entradas reales de los descriptores funcionales en lugar de la documentación.
La capacidad de búsqueda empresarial permite consultar el inventario estructural para facilitar la comprensión asistida por IA: encontrar todos los programas que implementan un patrón específico, todos los bloques EVALUATE con más de N condiciones, todos los programas que acceden a un conjunto de datos específico, consultas que basan la comprensión de la IA en evidencia estructural en lugar de en la probabilidad de los datos de entrenamiento.
Para las organizaciones donde la IA ahora forma parte de la cadena de herramientas de modernización, SMART TS XLEl análisis estructural es la capa que hace que la comprensión de la IA sea precisa a escala de cartera, abordando el límite de la ventana de contexto, el riesgo de alucinación en la lógica entre programas y la brecha de determinismo que separa el análisis estructural de la generación probabilística.
La IA cambió el costo de comprender, no el costo de demostrar.
Lo que cambió en 2026 fue el costo de la comprensión. La IA ha abaratado y acelerado drásticamente la comprensión de un programa COBOL, la documentación de sus reglas de negocio, la caracterización de su comportamiento y la descripción de su lugar en el portafolio. Esto representa una contribución genuina y sustancial a la economía de la modernización. Para programas cuya fase de comprensión requería semanas de trabajo especializado, la IA puede generar un borrador en horas que los especialistas revisan y perfeccionan, en lugar de tener que construirlo desde cero.
Lo que no ha cambiado es el coste de la verificación. La validación de la equivalencia de comportamiento, la ejecución en paralelo, la aprobación regulatoria y la verificación de la migración de datos siguen siendo las mismas que antes de la IA, consumiendo entre el 40 y el 50 por ciento del presupuesto de modernización, independientemente de la rapidez con la que se completen las fases de comprensión y traducción. IBM tenía razón el 23 de febrero de 2026: la traducción no refleja prácticamente ninguna de las complejidades reales. La verdadera complejidad reside en la verificación de la equivalencia de comportamiento, y esta complejidad no disminuye al aumentar la velocidad de traducción.
Las organizaciones que utilizan la IA con éxito en la modernización de COBOL son aquellas que invierten en la comprensión de la IA, donde esta demuestra su excelencia, y consideran la traducción de la IA como un punto de partida para la revisión humana, en lugar de un producto final listo para su implementación. Entienden que abaratar la fase inicial del proyecto no implica abaratar la fase final. Además, construyen la base de análisis estructural que la comprensión de la IA necesita para ser precisa a escala de cartera, donde se realiza el trabajo de comprensión más importante.
