Google pone a Gemini a leer el mainframe. Quien demuestra que el sistema nuevo funciona es Dual Run

La modernización de sistemas heredados es donde la IA generativa parece más útil y más peligrosa a la vez. Un modelo que lee dos millones de líneas de COBOL y explica las reglas de negocio ahorra meses. Un modelo que además asegura que el sistema reescrito se comporta igual se está corrigiendo su propio examen. El lanzamiento de modernización de Google del 5 de octubre contiene una respuesta limpia a ese problema, y no es una función de IA.

Qué ha anunciado Google

En un artículo firmado por Souvik Choudhury, director sénior de producto, y Tom Nikl, del equipo de modernización y migración, Google presentó Google Cloud Modernize, una cartera que reúne herramientas de migración, VMware, mainframe y modernización de aplicaciones. Las piezas que importan aquí:

• Modernization Hub, una nueva experiencia en la consola donde desarrolladores y arquitectos analizan código, mapean dependencias y planifican la modernización de aplicaciones Java, .NET y mainframe.
• App Modernization CLI (CodMod), que usa Gemini para analizar repositorios grandes, entender arquitecturas heredadas, mapear dependencias ocultas y generar recomendaciones.
• Mainframe Assessment Tool, que analiza el código del mainframe, extrae reglas de negocio y mapea dependencias de aplicaciones y datos.
• Dual Run, que reproduce flujos reales de transacciones de producción a la vez en el mainframe y en la nueva aplicación en la nube, para verificar la equivalencia funcional antes de la migración definitiva.

El artículo no indica si Modernization Hub y CodMod están en disponibilidad general o en vista previa, así que conviene comprobar el estado de cada componente en la consola y en la documentación. Otras piezas sí llevan etiqueta explícita (Agentic Quick Estimator está en disponibilidad general; la migración agéntica de EKS a GKE, en Public Preview).

La cita del cliente es la que más dice. Claudio Balbo, responsable de arquitectura TI de Intesa Sanpaolo, explica que el banco debe dar confianza a su dirección, a sus funciones de control interno y a los reguladores antes de avanzar con la modernización del mainframe, y que Dual Run “va aportando gradualmente las evidencias” a los tres grupos.

El patrón: la IA propone, una comprobación determinista decide

1. Gemini lee el código y mapea dependencias
2. Reglas de negocio extraídas como hipótesis
3. Nuevos servicios construidos y revisados
4. Dual Run reproduce transacciones reales en ambos
5. Personas analizan cada diferencia
6. Riesgos y control aprueban el paso

• Entender: Gemini lee el código y mapea dependencias · Reglas de negocio extraídas como hipótesis
• Reconstruir: Nuevos servicios construidos y revisados
• Demostrar: Dual Run reproduce transacciones reales en ambos · Personas analizan cada diferencia · Riesgos y control aprueban el paso

Trabajo de la IADecisión humana

El diseño separa dos trabajos que suelen confundirse. Entender es probabilístico: la lectura que hace Gemini de un código heredado es un conjunto de hipótesis sobre lo que hace el sistema, y algunas serán erróneas. Demostrar es determinista: la misma transacción de producción entra en los dos sistemas y las salidas coinciden o no. El modelo no vota en el segundo trabajo.

Es el mismo principio que vimos en GPT-Synopsys, donde las herramientas de verificación tienen la última palabra, y en el sistema de cuentas a pagar de Snowflake. La modernización es, sencillamente, donde más está en juego.

Qué tiene que significar “equivalente” antes de empezar

Dual Run proporciona un motor de comparación. No decide qué cuenta como coincidencia. Esa definición es trabajo suyo, y ahí se va la mayor parte del esfuerzo:

• Reglas por campo. Marcas de tiempo, identificadores generados, redondeos y orden van a diferir de forma legítima. Decida qué diferencias son esperables antes de la primera réplica, para que nadie ajuste las reglas hasta que el panel salga en verde.
• Cobertura en el tiempo. Una semana de réplica no cubre cierres de mes, fin de año, liquidación de intereses ni productos poco frecuentes. Planifique la ejecución según el calendario del negocio, no solo según el volumen.
• Responsable del triaje. Cada diferencia es un error del sistema nuevo, un error del antiguo del que alguien dependía o un cambio aceptado. Cada una necesita una decisión con nombre, y la tercera, la validación del negocio.
• Expediente de evidencia. La lección de Intesa es que hay tres públicos. Guarde ejecuciones, diferencias, causas y decisiones de forma que auditoría interna pueda seguirlas sin el equipo de ingeniería delante.

La resiliencia operativa no se pausa durante la réplica

Para un banco europeo, este patrón encaja directamente con DORA. El artículo 9 exige que todo cambio en sistemas TIC se registre, pruebe, evalúe, apruebe, implante y verifique de forma controlada; una sustitución de core bancario es el cambio más grande posible, y una réplica con transacciones reales es una forma muy sólida de documentar la prueba y la verificación. Pero reproducir transacciones de producción también significa copiar datos financieros de clientes a un entorno nuevo antes de que sea oficialmente producción, y ese entorno, alojado por un tercero, entra en la gestión del riesgo TIC con proveedores desde la primera réplica, no desde el día del cambio.

Qué hacer ahora

1. Separe entender de demostrar en el plan de modernización: IA para lo primero, comparación determinista para lo segundo.
2. Trate las reglas extraídas por la IA como hipótesis y contraste cada una con los resultados de la réplica.
3. Escriba las reglas de equivalencia antes de la primera réplica y cámbielas solo con revisión.
4. Planifique la cobertura según el calendario del negocio, con cierres y productos poco frecuentes.
5. Proteja el entorno de réplica como producción e inclúyalo en su registro de proveedores TIC.
6. Prepare el expediente para tres públicos: dirección, control interno y supervisor.

En resumen

El lanzamiento de modernización de Google está lleno de IA, pero su componente más importante es un motor de comparación. Es la arquitectura correcta para cualquier sistema regulado: el modelo acelera la comprensión y la reescritura, y las transacciones reales, comparadas de forma determinista, deciden si el sistema nuevo está listo.