El core que llevaba 30 años intocable está empezando a moverse
Durante las últimas tres décadas, he visto repetirse la misma conversación en comités de dirección de organismos públicos, bancos, aseguradoras, telcos y utilities: «hay que modernizar el core, pero no es el momento». Y en buena medida era cierto. No era el momento porque los números no cuadraban. La IA generativa es lo primero en treinta años que obliga a revisar esa afirmación.
Este artículo no va de tecnología. Va de por qué una decisión que llevaba una generación aparcada empieza a tener sentido económico en 2026, qué riesgos hay detrás del relato optimista y qué debería estar haciendo hoy un CIO o un Director General de organismo público ante este cambio.
El diagnóstico que todos conocemos
Los grandes sistemas críticos de la AAPP española y de las grandes corporaciones privadas —core bancario, gestión tributaria, contabilidad pública, padrones, nóminas, facturación de telco, despacho energético, liquidación de seguros— se construyeron entre los años 80 y 90 sobre entornos host. COBOL sobre z/OS, Natural/Adabas, Oracle Forms/Reports, PL/1, RPG en AS/400. Millones de líneas de código que hoy siguen procesando el dinero, los impuestos, las nóminas y los servicios esenciales del país.
Sobre esos sistemas se ha construido una segunda y una tercera capa. Primero, aplicativos en Java EE de primera generación. Luego Spring, servicios REST, microservicios, tecnologías front modernas (Angular, React), portales, apps móviles. Resultado: una arquitectura híbrida —por decirlo en términos amables— donde la experiencia de usuario es contemporánea pero las reglas de negocio críticas siguen viviendo donde siempre.
El pegamento entre ambas capas es un ecosistema de integraciones que nadie diseñó como tal: MQ, batches nocturnos, ficheros planos, pasarelas CICS, scraping de pantallas 3270, APIs envolventes construidas en diferentes momentos por diferentes proveedores bajo diferentes normativas. Lo que en los mapas de arquitectura aparece como «integración», en la operación del día a día se parece más a un ecosistema frágil sostenido por dos o tres personas clave que, por cierto, están cerca de la jubilación.
Por qué esto no se ha resuelto antes
No es un problema técnico. Es una decisión económica que se ha revalidado año tras año.
Un programa de migración integral de un core legacy, con las técnicas disponibles hasta 2023, implicaba tres a cinco años de ejecución, un presupuesto típicamente entre veinte y cien millones de euros, y un ROI que se presentaba como «ahorro en mantenimiento a medio plazo». Ningún comité de dirección aprueba fácilmente un programa con esas características: sin funcionalidad nueva visible, con riesgo regulatorio elevado (no puede fallar ni un día), con dependencia crítica de conocimiento no documentado y con el recuerdo de los programas de migración fallidos de la década pasada todavía fresco.
Los datos lo confirman. Según IDC, el 47 % de los CIOs cita la deuda técnica como la principal causa de sobrecoste en cloud y en infraestructura digital. Gartner estima que cerca del 40 % de los sistemas de infraestructura críticos soportan hoy una carga significativa de deuda técnica. Y el coste operativo del legacy no es menor: se estima que una gran empresa pierde en torno a 370 millones de dólares anuales en ineficiencias derivadas de sistemas heredados.
La paradoja es conocida: todo el mundo sabe que hay que hacerlo, casi nadie lo aborda de verdad.
Qué cambia con la IA generativa
La IA generativa no acelera marginalmente la modernización. Cambia el orden de magnitud del problema, y lo hace en tres dimensiones muy concretas.
Primero, comprensión del código no documentado. El mayor consumo de horas en cualquier programa de modernización legacy no es reescribir: es entender qué hace el código actual. La documentación es parcial o está obsoleta, los desarrolladores originales no están, y los analistas funcionales han rotado varias veces. Los modelos de lenguaje actuales leen esos programas, reconstruyen su lógica, identifican dependencias ocultas entre copybooks, JCLs y módulos llamados, y generan documentación funcional equivalente. El caso público más citado —la Organización Nacional de Seguridad Social de Egipto, con IBM watsonx Code Assistant for Z— reporta una reducción del 79 % en el tiempo necesario para que un desarrollador entienda una aplicación COBOL compleja: de 24 horas a aproximadamente 5. Ese es el cuello de botella histórico, y está desapareciendo.
Segundo, traducción semántica con preservación de lógica de negocio. No hablamos de conversores sintácticos tipo «COBOL a Java literal» —esos existen desde hace veinte años y generan código ilegible e inmantenible—. Hablamos de reescritura que preserva el comportamiento y al mismo tiempo aplica estructura orientada a objetos, principios de diseño modernos y separación de capas. Herramientas como AWS Transform (que integra la tecnología BluAge adquirida por Amazon), IBM watsonx Code Assistant for Z, GitHub Copilot con agentes especializados, o plataformas de terceros como TSRI o Heirloom, ya están en producción. TSRI documenta una migración del sistema de soporte de la Agencia Tributaria canadiense (CRA) de COBOL/CICS a Java sobre AWS en seis semanas. Hace tres años, ese mismo proyecto habría sido un programa de dos años.
Tercero, generación automatizada de tests de paridad funcional. El riesgo regulatorio del legacy se gestiona con pruebas comparativas que demuestran que el sistema nuevo produce exactamente el mismo resultado que el antiguo ante los mismos inputs. La IA generativa acelera la producción de esos casos de prueba de forma muy significativa, y eso reduce el riesgo real —no el percibido— de la migración.
Las cifras agregadas del mercado son consistentes con lo anterior. Cognizant reporta incrementos de productividad del 70 % y reducciones de coste del 30 % en refactorización asistida por IA generativa. Gartner prevé que en 2028 la IA generativa habrá reducido los costes de modernización de aplicaciones un 30 % respecto a los niveles de 2025. El mercado global de modernización de legacy pasará de unos 25 mil millones de dólares en 2025 a 56 mil millones proyectados en 2030.
Traducido al lenguaje del comité de dirección: un programa que hace tres años costaba cincuenta millones y tardaba cuatro años, hoy es creíble en un plan trienal con un presupuesto significativamente inferior. Y, sobre todo, es creíble dentro de un ejercicio presupuestario. 
El stack tecnológico del cambio: del núcleo legacy a las plataformas modernas vía generativa.
Dónde la IA generativa todavía no llega (y conviene decirlo)
Sería intelectualmente deshonesto dejarlo aquí, porque hay mucha narrativa de proveedor ahora mismo y conviene separar el señal del ruido.
La IA generativa hace muy bien sintaxis y cada vez mejor semántica local. No entiende contexto de negocio. No decide qué reglas deben eliminarse porque el negocio ya no las usa, qué excepciones son errores históricos que se deben corregir y no replicar, qué dependencias implícitas entre procesos batch no pueden romperse sin consecuencias. Eso lo sigue haciendo un arquitecto con criterio, acompañado por el conocimiento funcional del cliente.
Los riesgos concretos, documentados en la literatura técnica reciente, son: alucinación de APIs inexistentes, reordenación silenciosa de lógica con impacto en resultados, omisión de hooks de auditoría obligatorios en normativas como GDPR, PCI DSS o ENS, y pérdida de dependencias ordinales en procesos batch que no son visibles en la sintaxis del código fuente. Si la arquitectura legacy de partida es espagueti, la IA generativa produce espagueti moderno en Java o Python, indistinguible en funcionalidad pero igualmente inmantenible.
El diferencial no está en la herramienta —todas las grandes van a converger en capacidades similares— sino en el método: quién gobierna la paridad funcional, quién valida los casos frontera, quién toma las decisiones de arquitectura objetivo, y quién se hace cargo del riesgo operativo durante la transición. Ese es el trabajo de consultoría real.
Qué debería estar haciendo hoy un CIO
Tres preguntas para llevar al próximo comité:
Primera: ¿cuáles de nuestros sistemas críticos siguen siendo indefendibles en un plan estratégico a tres años y qué parte de ellos pensábamos que no eran abordables hasta ahora? Probablemente haya que recalibrar el portfolio.
Segunda: ¿tenemos un inventario funcional vivo del código crítico o dependemos del conocimiento de cinco personas concretas? Si es lo segundo, la primera acción no es migrar, es usar IA para documentar y reducir el riesgo operativo ya, independientemente de que se migre después.
Tercera: cuando se lleve a comité una propuesta de modernización asistida por IA, ¿qué se está comprando exactamente? ¿Una herramienta, un servicio gestionado, un modelo de precio por resultado? La respuesta a esta pregunta separa a los proveedores que realmente entienden el problema de los que están reempaquetando su oferta anterior con una capa de IA por encima.
La posición de AXPE
Llevamos veinte años trabajando los sistemas core de AAPP y grandes cuentas en España. Conocemos el COBOL que nadie quiere tocar, los Natural/Adabas que nadie sabe parar, los Oracle Forms que siguen imprimiendo nóminas. Y conocemos, también, los entornos Java modernos que se han construido encima.
Nuestra posición frente a las grandes consultoras no es de escala, es de foco. No vendemos programas de mapping de dos años antes de tocar una línea de código. Tampoco vendemos herramientas de traducción automática como si fueran una caja negra. Combinamos equipos con conocimiento profundo del legacy —que no es commodity, cada vez hay menos— con las plataformas de IA generativa de referencia del mercado, bajo un método propio de paridad funcional y gobierno del riesgo, y con modelos económicos alineados con resultado y no con horas vendidas.
Para quien lleva años aparcando esta decisión: la ventana de oportunidad de abordarla sin prisas acaba de abrirse y no va a quedarse abierta indefinidamente. En dos o tres años, haber modernizado el core dejará de ser una ventaja competitiva y pasará a ser un requisito para seguir en la mesa.
Si estáis revisando vuestro plan de sistemas 2026-2028, estamos disponibles para contrastar hipótesis.