OpenAI reporta 86,6 % al migrar COBOL y exige revisión

En la publicación técnica de OpenAI del 19 de octubre de 2026, la compañía reportó un 86,6 % de aciertos de GPT‑6.1 Sol en su evaluación de migración de COBOL, frente al 5,4 % de GPT‑5.6 Sol con esfuerzo de razonamiento bajo y un coste estimado de API un 39 % menor. El uso de esa capacidad en producción sigue requiriendo revisión experta y pruebas de las reglas de negocio y las dependencias del sistema. Para una empresa que estudia sustituir código COBOL, la cifra muestra progreso en tareas delimitadas; la aceptación del reemplazo depende de cómo se comporte su propio programa.

La cobertura de TokenPost recoge también un 97,9 % para GPT‑6.1 Sol cuando aumenta el esfuerzo de razonamiento. Es otra configuración de la misma evaluación, no el resultado de trasladar una aplicación empresarial completa. El ahorro comunicado corresponde al uso estimado de API durante la prueba: deja fuera el trabajo de reconstruir reglas, probar integraciones y autorizar un despliegue.

Qué cuenta como una migración correcta

Una diferencia de redondeo rompe la paridad entre la salida de un programa COBOL y la de su versión migrada.

La evaluación propone convertir programas COBOL a C++, Java, Kotlin, Python o Rust conservando su comportamiento. Los programas convertidos se enfrentan a pruebas ocultas que exigen que las salidas observables coincidan byte por byte con las del original. Una tarea de migración solo se considera superada cuando pasa todos los casos que le corresponden; compilar el nuevo código o lograr que se ejecute no basta.

Por tanto, el porcentaje expresa la proporción de tareas aprobadas bajo ese criterio. No mide líneas traducidas, facilidad de mantenimiento del código generado ni probabilidad de éxito de una cartera empresarial. Tampoco indica cuántos programas de cada tipo hay en el banco de pruebas. Sin ese desglose público, la cifra principal no permite estimar el rendimiento para un sistema concreto a partir de su tamaño, sector o lenguaje de destino.

El rigor de la comparación responde a diferencias que pueden parecer menores en el código y ser decisivas en el negocio. La aritmética de punto fijo de COBOL descarta decimales sobrantes salvo que se solicite expresamente un redondeo. Una versión que redondee puede ejecutarse sin errores y devolver un importe diferente. El tratamiento de registros ausentes plantea un problema parecido: cambiar la respuesta ante una entrada excepcional puede alterar una regla que otros procesos dan por supuesta.

Las pruebas ocultas detectan esas desviaciones cuando contienen las entradas pertinentes. En una aplicación real, los datos históricos, las excepciones y los contratos con otros sistemas determinan qué entradas importan. La equivalencia observada en el banco de pruebas es una señal técnica sólida dentro de su perímetro, pero no sustituye la definición de los casos que deben preservarse en cada instalación.

Qué se puede reproducir con MultiLangBench

MultiLangBench comprueba una implementación de SQLite; la evaluación de migración de COBOL sigue una prueba separada.

El repositorio público de MultiLangBench documenta otra evaluación: implementar un motor compatible con SQLite 3.40.1; explica que se adaptaron unas 24.000 de las 51.000 pruebas originales y recomienda una selección de 272 para las ejecuciones ordinarias por su coste. El candidato recibe una base inicial y una consulta SQL; después, una implementación de referencia comprueba el contenido de la base resultante. El repositorio incluye instrucciones para preparar el entorno y calificar las respuestas.

Esta publicación permite inspeccionar y ejecutar la prueba de construcción de software. La migración de COBOL examina una capacidad distinta: conservar el comportamiento de programas existentes al trasladarlos a otro lenguaje. En el repositorio de MultiLangBench no figura una suite equivalente con los casos ocultos de esa migración. Por ello, la disponibilidad del código de MultiLangBench no convierte automáticamente el resultado de COBOL en una medición reproducible por terceros.

La separación también evita confundir porcentajes obtenidos con criterios diferentes. En MultiLangBench se contabilizan pruebas superadas por una implementación nueva; en la migración, cada programa convertido debe pasar todos sus casos ocultos para contar como acierto. Comparar directamente ambas puntuaciones mezclaría unidades de medida, tareas y modelos. Lo que sí ofrece el repositorio es una descripción concreta de cómo se prepara una evaluación abierta y qué partes de su ejecución pueden examinarse.

Los controles que siguen en manos del equipo

El primer control de una migración real es decidir qué comportamiento debe permanecer idéntico. Una salida antigua puede ser necesaria porque otro sistema la consume, incluso si una regla histórica parece extraña; modificarla puede ser una decisión válida, pero requiere identificarla y aprobarla por separado. Los especialistas del dominio deben distinguir las reglas que el reemplazo ha de conservar de los cambios funcionales que el proyecto quiere introducir.

Después hacen falta comprobaciones sobre el sistema que se pretende sustituir:

Regresión funcional: ejecutar el original y el convertido con datos representativos y casos límite, y comparar salidas, errores y efectos persistentes. Los cálculos con decimales y los registros ausentes merecen atención cuando forman parte de las reglas del servicio.
Reglas de negocio: validar con quienes conocen la operación los cálculos y excepciones que quizá solo estén expresados en el código legado. Un caso que nunca se ejecuta en las pruebas no queda cubierto por la coincidencia de los demás.
Dependencias: comprobar formatos de datos, interfaces y secuencias de operación con los sistemas conectados. Una pieza puede producir la salida esperada de forma aislada y fallar al integrarse en el servicio.
Seguridad y operación: revisar permisos, tratamiento de datos, código generado y recuperación ante fallos antes del despliegue. Estas verificaciones pertenecen al entorno de producción y quedan fuera de la puntuación del modelo.

El coste estimado de API tampoco abarca esos controles ni el tiempo de los expertos que los realizan. Para decidir si un reemplazo COBOL puede entrar en servicio, la evidencia decisiva será la regresión con datos propios, la validación de sus reglas y el funcionamiento de sus conexiones: resultados que la evaluación anunciada no mide por cada empresa.