OpenAI mejora la migración de COBOL: qué significa para tu pyme

Esta semana OpenAI ha puesto el foco en un lenguaje que muchos equipos IT solo conocen por referencias: COBOL. La compañía ha anunciado resultados de dos evaluaciones internas que, según su propio relato, muestran una mejora muy notable a la hora de migrar programas COBOL a otros lenguajes y de construir software en lenguajes con menos código y documentación disponibles para entrenar modelos. El titular es llamativo, pero conviene leerlo con calma y con la mirada puesta en lo que de verdad afecta a una pyme o a un departamento de IT con recursos limitados.

Qué ha anunciado OpenAI, en corto

Según la información publicada, OpenAI ha presentado dos pruebas. La primera es una evaluación propia de migración de COBOL: el modelo GPT-6.1 Sol habría alcanzado un 86,6% de acierto con un esfuerzo de razonamiento bajo, frente al 5,4% de GPT-5.6 Sol, y con un coste un 39% menor. Con mayor esfuerzo de razonamiento, el modelo nuevo llegaría al 97,9%. La segunda prueba, llamada MultiLangBench, mide si un modelo puede construir desde cero un motor de base de datos compatible con SQLite en 20 lenguajes de programación. Ahí, GPT-6 Astra habría logrado una tasa media de pruebas superadas del 87,4%, frente al 26,8% de GPT-5.6 Sol, mientras que GPT-6 Luna, la opción más económica, se quedaría en un 40,3% de media, aunque con un coste estimado de API aproximadamente un 78% inferior.

El detalle importante: la evaluación de COBOL no se ha publicado. OpenAI sí ha liberado en GitHub el entorno y la suite de MultiLangBench, pero no los casos de prueba de COBOL. Eso significa que un tercero no puede inspeccionar ni reproducir esos resultados. La propia compañía reconoce que aplicar estas capacidades a software en producción sigue exigiendo revisión experta y pruebas contra las reglas de negocio y dependencias del sistema.

Por qué COBOL sigue siendo un hueso duro

COBOL no es un lenguaje de moda, pero sostiene una parte enorme de la operativa financiera y de registros de negocio. Según datos de IBM citados en la noticia, más del 40% de los sistemas de banca online, el 80% de las transacciones presenciales con tarjeta y el 95% de las operaciones en cajeros automáticos se apoyan en COBOL. El problema para la IA es doble: hay menos código y documentación de COBOL que de Python o JavaScript para aprender, y encontrar desarrolladores con experiencia real es cada vez más difícil. Además, la documentación suele ir por detrás de los sistemas que describe.

Por eso el salto que anuncia OpenAI, si se confirma, sería relevante. Pero no es la primera compañía que trabaja en esta dirección: Anthropic ya describió cómo Claude Code podía asistir en la modernización de COBOL, y AWS introdujo agentes de IA para migraciones de mainframe en 2024. La novedad aquí es el nivel de acierto declarado, no el concepto.

Lo que esto significa para una pyme

Para una pyme española, la mayoría de las veces COBOL no aparece en su stack propio, pero sí en el de su proveedor de core bancario, su gestoría, su ERP antiguo o la aplicación sectorial que lleva veinte años funcionando. La promesa de migrar COBOL con IA puede sonar a solución mágica, y no lo es. Lo que sí cambia es el coste de explorar una modernización: si un modelo puede traducir fragmentos de código y proponer equivalentes en Java, Python o Rust con mayor fidelidad, el trabajo de análisis y validación se reduce, aunque no desaparece.

Hay tres riesgos que conviene tener presentes:

• Resultados no auditables. Sin casos de prueba públicos de COBOL, no podemos verificar de forma independiente el 86,6% o el 97,9%. Un benchmark interno es una señal, no una garantía.
• Paridad byte a byte. La evaluación exige que las salidas observables coincidan exactamente. En producción, esa paridad depende de reglas de negocio, dependencias y casos límite que rara vez están documentados.
• Deuda oculta. Migrar código no es migrar el negocio. Los flujos, las integraciones y los procesos manuales asociados suelen ser la parte más costosa.

Qué recomendamos desde ForgeNEX

Nuestra recomendación para equipos IT con sistemas heredados es tratar la IA como un acelerador del análisis, no como un sustituto del criterio. En la práctica, esto se traduce en pasos concretos:

1. Inventariar antes de migrar. Identificar qué programas COBOL son críticos, qué interfaces tienen y qué documentación existe. Sin ese mapa, cualquier traducción automática es una caja negra.
2. Empezar por módulos acotados. Probar la traducción asistida en piezas pequeñas, con baterías de pruebas propias que comparen salidas reales frente a las esperadas.
3. Exigir trazabilidad. Cada cambio generado por IA debe poder revisarse, versionarse y revertirse. Si no hay revisión humana con conocimiento del negocio, no hay migración segura.
4. Medir coste total, no solo API. El ahorro en tokens o en horas de traducción puede diluirse si la validación y las pruebas se disparan.
5. No depender de un único proveedor. Los benchmarks cambian y los liderazgos también. Mantener la capacidad de evaluar modelos alternativos es una forma de gestión de riesgo.

En el fondo, la noticia encaja con una tendencia que ya venimos señalando: la IA generativa se está acercando a los sistemas que sostienen el negocio real, no solo a los proyectos verdes. Eso exige más rigor, no menos. Si tu equipo está valorando modernizar una aplicación heredada, merece la pena leer los resultados con interés, pero también con la misma cautela con la que abordamos otros riesgos técnicos, como los que tratamos en nuestro análisis sobre seguridad de agentes IA o en el repaso a los fallos RCE en KSMBD.

La conclusión práctica: la migración de COBOL asistida por IA deja de ser una promesa lejana y pasa a ser una línea de trabajo plausible, pero todavía sin evidencia pública suficiente para confiar en ella a ciegas. Para una pyme, la decisión sensata no es esperar a que todo esté resuelto ni lanzarse al vacío, sino preparar el terreno: documentar, inventariar y construir pruebas. Eso es lo que convierte una mejora de benchmark en un proyecto real.

Fuente: The New Stack. Análisis y adaptación: ForgeNEX.