Modernizar un sistema core puede parecer, a primera vista, un desafío tecnológico centrado en tomar código legado, comprenderlo y transformarlo hacia tecnologías más actuales. Sin embargo, detrás de ese código existen comportamientos, operaciones, dependencias y reglas de negocio que llevan años sosteniendo procesos críticos de las organizaciones.
Sobre esa tensión giró la conferencia “La frontera probabilística. ¿Cómo orquestar agentes en sistemas core que exigen certezas?”, presentada por Daniel Menal, Head of IA & Data de IT Patagonia, en Nerdearla 2026.
A lo largo de la ponencia, Menal compartió la experiencia desarrollada a partir de un desafío concreto de modernización de sistemas core y el recorrido que llevó al equipo a revisar algunas de sus hipótesis iniciales sobre el uso de inteligencia artificial.
El punto de partida parecía sencillo. Si hoy la IA puede leer COBOL o assembler, interpretar código antiguo y generar Java, ¿podría utilizarse para acelerar la modernización de estos sistemas?
La experiencia mostró que el desafío iba mucho más allá de transformar código de un lenguaje a otro.
Modernizar no es solamente traducir código
Uno de los primeros aprendizajes que surgieron durante el desarrollo fue entender que generar código nuevo no garantiza haber comprendido correctamente el comportamiento del sistema original.
Una IA puede producir código que se vea correcto, compile e incluso supere determinadas pruebas. Pero los sistemas core contienen reglas construidas durante años a partir de excepciones, secuencias particulares, cálculos y decisiones que muchas veces no se encuentran documentados.
Ese fue uno de los primeros cambios de perspectiva del proyecto. El problema dejó de ser únicamente cómo pasar de un lenguaje antiguo a uno nuevo y comenzó a formularse de otra manera: ¿cómo cambiar algo crítico sin romper aquello que ya funciona?
A partir de ese aprendizaje, se redefinió el objetivo. La experiencia dejó de pensarse como la construcción de un traductor automático de código y comenzó a orientarse hacia una forma de modernizar sistemas críticos sin perder el control sobre el proceso.
Abrir la caja negra
En ese recorrido, la IA generativa resultó una herramienta para comenzar a comprender mejor los sistemas existentes. Al analizar código legado, permitió explicarlo, identificar funcionalidades, ordenar información y proponer posibles transformaciones.
Pero la experiencia también puso en evidencia una distinción central: una explicación convincente generada por IA no equivale necesariamente a una verdad sobre el sistema.
Las respuestas generadas debían funcionar como propuestas para investigar y contrastar. A partir de allí, el equipo comenzó a diferenciar las tareas en las que resultaba útil incorporar capacidades generativas de aquellas donde se necesitaba un comportamiento determinístico.
Mientras comprender una lógica compleja o proponer una transformación podía beneficiarse de la IA generativa, revisar dependencias, comparar resultados, repetir procesos conocidos o conservar evidencia requería que, ante las mismas condiciones, el sistema respondiera de manera consistente.
Entender mejor el sistema abrió además la posibilidad de evaluar qué era lo que realmente debía migrarse.
La aparición de piezas de código sin dependencias o integraciones activas aparentes durante el análisis, no constituían señales suficientes para descartarlas, ya que podían existir procesos poco visibles o ejecuciones esporádicas. No obstante, permitieron reformular el problema. La pregunta dejó de ser “¿cómo migramos todo?” para convertirse en “¿qué vale la pena transformar y con qué evidencia?”.
Orquestar agentes no significa darles autonomía absoluta
Otro de los aprendizajes de la experiencia estuvo relacionado con la forma de distribuir las tareas entre diferentes agentes.
La solución desarrollada no se basó en una única IA capaz de realizar todo el proceso. Se trabajó con agentes separados, a los que se les asignaron tareas, herramientas y permisos específicos. Uno podía leer y comprender, otro proponer una transformación, y el tercero realizar comprobaciones que necesitaran resultados repetibles.
Esta separación permitió establecer una diferencia fundamental: tener capacidad para leer no implica tener permiso para modificar, y tener capacidad para proponer tampoco significa poder publicar un cambio.
La autonomía comenzó así a pensarse como una escala y no como una decisión binaria. Cuanto mayor fuera el impacto potencial de una acción, mayor debía ser también la evidencia y los controles necesarios antes de habilitarla.
Como se planteó durante la presentación, un buen prompt no funciona como un permiso. Indicarle a una IA que actúe con cuidado no reemplaza la necesidad de definir qué herramientas puede utilizar y qué acciones puede realizar.
La IA propone; el sistema contrasta
Esta lógica llevó a otra de las distinciones surgidas durante el desarrollo: una propuesta no es una prueba.
La IA puede sugerir cómo transformar una funcionalidad, pero esa propuesta necesita ser contrastada. El sistema debe revisar dependencias, ejecutar verificaciones repetibles, comparar resultados y conservar evidencia de lo realizado.
La experiencia también mostró el límite de esas verificaciones. Que un proceso produzca resultados consistentes no significa automáticamente que esos resultados sean correctos desde la perspectiva del negocio.
A partir de la evidencia obtenida, se definieron distintos caminos. Algunas piezas podían avanzar hacia una transformación. En ciertos casos, la información incompleta, las señales contradictorias o el nivel de impacto requerían una revisión. También podía ocurrir que una pieza no tuviera sentido de negocio para ser modernizada.
De esta manera, la experiencia fue dando forma a una definición concreta de orquestación. No se trataba simplemente de conectar diferentes agentes, sino de establecer quién puede hacer qué, con qué herramientas, con qué evidencia y hasta dónde.
Diseñar sistemas que puedan responder por lo que hacen
Hacia el cierre de su ponencia, Menal recuperó algunos de los límites que la propia experiencia permitió identificar:
- Una respuesta que parece convincente no necesariamente es correcta.
- Un proceso que produce siempre el mismo resultado no comprende por sí mismo el negocio.
- No todas las tareas mejoran por incorporar un agente.
El objetivo del enfoque desarrollado no fue, entonces, eliminar por completo la incertidumbre, sino identificar dónde se encuentra, reducirla cuando es posible y no ocultarla cuando no puede eliminarse.
De ese recorrido surgieron tres preguntas para pensar la incorporación de agentes en procesos críticos: qué puede proponer, qué se puede comprobar y qué no puede hacer por sí solo.
La experiencia presentada comenzó con la posibilidad de utilizar IA para acelerar la transformación de código legado y terminó planteando un desafío más amplio.
La frontera, señaló Daniel Menal hacia el cierre, no está únicamente entre el código antiguo y el código nuevo, ni entre utilizar o no inteligencia artificial. Está entre dejar que una IA parezca inteligente y diseñar un sistema que pueda responder por lo que hace.
En sistemas core, modernizar no significa solamente generar código nuevo. Implica cambiar lo que hace falta sin perder lo que importa.