El software que mueve tu dinero tiene más de 40 años

   
Portada | Opinión
Foto: <a href="https://eltamiz.com/elcedazo/2009/03/27/historia-de-un-viejo-informatico-nostalgia-un-programa-cobol-en-tarjetas-perforadas/" rel="nofollow noopener" target="_blank">El Tamiz</a>

Foto: El Tamiz

Cada vez que retiras efectivo de un cajero, cobras tu sueldo o pagas con tarjeta, es muy probable que estés confiando tu dinero a un programa informático más viejo que tú. No es una metáfora. Según un reporte de Reuters de 2017, el 95 % de las operaciones en cajeros automáticos del mundo y el 43 por ciento de los sistemas bancarios siguen funcionando sobre COBOL, un lenguaje de programación diseñado en 1959. Se calcula que quedan unos 220 mil millones de líneas de ese código en producción, moviendo muchas de las transacciones bancarias cada día.

Recuerdo en uno de mis primeros proyectos en México, en 2011, en uno de los 6 bancos más grandes de México en aquél entonces que nos tocó un proyecto de migración de COBOL a un sistema más moderno. Y llamaron a su casa al programador que lo hizo, que ya estaba jubilado, para que apoye. Pero el proyecto de migración nunca funcionó. Me contaron que lo llamaron 5 años después, y ese mismo programador ya no estaba en este mundo. Y nadie quería tocar el código por miedo a romper algo.

Dicho de otra forma: la columna vertebral de la economía moderna no está hecha de inteligencia artificial ni de aplicaciones brillantes. Está hecha de software que la mayoría de los ejecutivos que hoy dirigen esas instituciones no sabrían leer, y que muy pocos ingenieros vivos saben mantener.

La infraestructura que nadie ve

Estos sistemas comparten una característica peligrosa: funcionan. Funcionan tan bien, y desde hace tanto, que se volvieron invisibles. Nadie toca lo que no falla. Y como no se tocan, tampoco se documentan, ni se actualizan, ni se cuestionan, hasta que un día dejan de andar.

El ejemplo más elocuente no está en un banco pequeño de un país emergente, sino en el gobierno más rico del planeta. El sistema que procesa las declaraciones de impuestos de más de 100 millones de contribuyentes en Estados Unidos —el Individual Master File del IRS (El SAT de Estados Unidos)— fue escrito en los años sesenta, en lenguaje ensamblador y COBOL. La Oficina de Rendición de Cuentas del Congreso (GAO) lo ha señalado repetidamente como uno de los sistemas más antiguos y de mayor riesgo de todo el gobierno federal. Llevan más de una década intentando reemplazarlo, con presupuestos millonarios, y aún no lo logran del todo.

Si la mayor potencia económica del mundo no ha podido jubilar un sistema de sesenta años, conviene preguntarse en qué estado real está el núcleo tecnológico de nuestros bancos, aseguradoras e institutos de seguridad social en América Latina.

El conocimiento también se jubila

Dado el contexto, el verdadero riesgo del software legado no es el código viejo. Es que el conocimiento de cómo funciona se fue con las personas que lo escribieron, y casi nunca quedó por escrito.

En abril de 2020, cuando la pandemia disparó las solicitudes de seguro de desempleo, los sistemas de 40 años del estado de Nueva Jersey colapsaron ante un aumento de más del mil 600 % en los reclamos. El gobernador Phil Murphy tuvo que salir públicamente a pedir voluntarios que supieran programar en COBOL. El problema no era la máquina: era que quienes entendían ese código se habían jubilado o fallecido. La mayoría de los expertos en COBOL hoy superan los 60 años.

Esa es la paradoja incómoda de la era de la inteligencia artificial: mientras discutimos qué modelo es más potente, buena parte de la infraestructura crítica depende de un puñado de profesionales mayores cuya sabiduría nunca fue codificada. La memoria institucional no está en la nube. Está en la cabeza de gente que está por retirarse.

Modernizar mal cuesta más que no modernizar

Una reacción intuitiva obvia es: "migremos todo, subámoslo a la nube, pongámosle IA". Correcto en la intención, peligroso en la ejecución. El cementerio de las migraciones fallidas es enorme, y sus lápidas son caras.

En 2018, el banco británico TSB migró a más de 5 millones de clientes a una nueva plataforma central en un solo fin de semana. La plataforma no estaba lista: al momento de encender el nuevo sistema seguían abiertos más de 4 000 defectos conocidos. Cerca de 2 millones de clientes quedaron días sin poder acceder a su dinero, el fraude se disparó, el director ejecutivo renunció y la operación terminó costando alrededor de 330 millones de libras. Los reguladores luego multaron al banco con 48,6 millones de libras adicionales. El informe independiente encargado al despacho Slaughter and May fue lapidario: ni la plataforma ni la operación estaban preparadas.

La lección es dura pero clara: una migración mal hecha no solo falla técnicamente. Rompe la confianza, y la confianza es el único producto real de un banco.

Nuestra región carga, además, un peso extra. Buena parte del núcleo bancario, gubernamental y asegurador corre sobre sistemas importados y envejecidos, mantenidos por equipos cada vez más reducidos, bajo reguladores que —con razón— exigen continuidad por encima de todo. La presión por no fallar hoy es exactamente lo que hace que se posponga la decisión de modernizar mañana.

La deuda técnica es un pasivo financiero, no una nota al pie

Aquí está el punto que debería sacar el tema de la oficina de sistemas y llevarlo al consejo de administración. Según una investigación de McKinsey, los directores de tecnología estiman que la deuda técnica equivale a entre el 20 y el 40 por ciento del valor de todo su patrimonio tecnológico, antes de depreciación.

Vale la pena releerlo: hasta un 40 % del valor tecnológico de una empresa es, en la práctica, una deuda. No es una metáfora de ingenieros. Es una cifra que pertenece al balance, al lado de la deuda financiera. Una compañía que no puede mover sus sistemas críticos al ritmo que exige el mercado no va a quebrar por falta de inteligencia artificial: va a quebrar porque el cimiento sobre el que se para no aguanta el siguiente piso.

¿Qué hacer, entonces? No una migración heroica de fin de semana; TSB ya mostró dónde termina eso. La disciplina que funciona es menos vistosa y más efectiva, y empieza por una palabra poco glamorosa: observar.

Antes de tocar un sistema crítico hay que entender qué hace realmente: qué partes se usan y cuáles no, qué es verdaderamente crítico, qué reglas de negocio viven solo dentro de ese código y en la cabeza de nadie más. Evidencia de producción, no suposiciones. Después se moderniza por etapas, validando cada paso contra datos reales y manteniendo gobierno humano sobre los cambios críticos. La inteligencia artificial hoy permite leer, documentar y migrar código legado a una velocidad impensable hace cinco años; pero la IA sin evidencia de producción y sin supervisión humana solo acelera el choque.

Lo intangible es lo que hay que salvar

Detrás de cada sistema legado hay una paradoja: es, al mismo tiempo, lo más valioso y lo más frágil que posee una organización. Valioso porque en él viven décadas de conocimiento de negocio acumulado. Frágil porque ese conocimiento nunca se hizo explícito y depende de máquinas y personas que se están agotando.

Mi abuela, me repetía de chico que había que invertir en lo intangible porque lo material te lo pueden quitar. Los sistemas legados son justamente eso: conocimiento intangible atrapado en código que envejece. La tarea de esta década no es tirarlos a la basura ni venerarlos. Es sacarles el conocimiento, volverlo trazable y moverlo —con cuidado— a un terreno capaz de sostener el futuro.

Así las cosas, el banco que lo haga seguirá siendo un banco dentro de diez años. El que no, descubrirá, una mala mañana, que su infraestructura más crítica era también la más invisible.




DESCARGA LA NOTA  SÍGUENOS EN GOOGLE NEWS