Hay una tentación muy común cuando se mira un sistema productivo desde afuera: asumir que está mal hecho.
Pasa en consultoría, en tecnología, en transformación digital y ahora también con IA. Llegas a una organización, ves planillas, pasos manuales, integraciones raras, sistemas heredados, validaciones duplicadas, excepciones por todos lados y decisiones que parecen difíciles de defender. La primera reacción puede ser pensar: “esto habría que rehacerlo desde cero”.
A veces es cierto. Hay sistemas que necesitan modernización profunda, procesos que ya no escalan y decisiones técnicas que se volvieron una carga para el negocio.
Pero muchas veces esa primera lectura es demasiado superficial.
Un sistema productivo no es solo una colección de errores técnicos. Es una historia acumulada de decisiones tomadas bajo presión, con la información disponible en ese momento y dentro de restricciones reales: presupuesto, plazos, personas, clientes, regulaciones, proveedores, urgencias comerciales, sistemas existentes y capacidad operativa.
Desde afuera es fácil ver deuda. Lo difícil es entender qué parte de esa deuda es simplemente mala decisión, qué parte fue una solución razonable para sobrevivir y qué parte contiene conocimiento operativo que la organización todavía necesita.
Producción no es una maqueta
Una demo puede verse limpia. Un prototipo puede seguir una arquitectura ideal. Un diagrama puede ordenar todo en cajas elegantes.
Producción no funciona así.
Producción carga con usuarios reales, datos incompletos, integraciones antiguas, clientes que no se comportan como el manual esperaba, excepciones que aparecen solo una vez al mes, reglas de negocio que nadie documentó y decisiones que se tomaron hace años porque algo tenía que salir en una fecha específica.
Por eso es peligroso mirar un sistema productivo como si fuera una maqueta mal construida.
Un sistema en producción no solo refleja diseño. Refleja historia.
Cada parche probablemente tiene una razón. Cada validación duplicada puede venir de un error que costó dinero. Cada paso manual puede existir porque en algún momento automatizarlo era más riesgoso que dejarlo en manos de una persona. Cada excepción puede ser el rastro de un cliente importante, una regulación, una condición comercial o una limitación técnica que nadie podía resolver en ese momento.
Eso no significa romantizar la deuda técnica. Significa reconocer que no toda complejidad visible es incompetencia.
A veces es memoria operacional.
El sesgo de supervivencia en los sistemas
La historia de los aviones que volvían de la guerra con impactos de bala es una buena analogía.
Durante la Segunda Guerra Mundial, se analizaban los aviones que regresaban con daños para decidir dónde reforzar el blindaje. La lectura inicial era reforzar las zonas más dañadas. Pero Abraham Wald, matemático del Statistical Research Group, vio el problema de otra forma: los aviones observados eran los que habían logrado volver. Las zonas sin impactos visibles en esos aviones probablemente eran las más críticas, porque los aviones que recibían disparos ahí no regresaban.
Era un problema de sesgo de supervivencia.
Con los sistemas productivos pasa algo parecido.
Vemos sistemas llenos de parches, workarounds, integraciones incómodas y procesos poco elegantes porque son los sistemas que lograron seguir funcionando. Los que no sobrevivieron ya no están para ser diagnosticados. Fueron reemplazados, abandonados, absorbidos por procesos manuales o simplemente dejaron de sostener al negocio.
Eso no convierte a un sistema sobreviviente en un buen sistema. Pero sí obliga a tratarlo con más respeto.
Si un sistema imperfecto permitió vender, facturar, atender clientes, cumplir contratos, operar durante años y mantener viva una necesidad del negocio, entonces hay aprendizaje ahí. Hay decisiones que entender antes de intervenir.
La pregunta no debería ser solamente: “¿por qué esto está tan mal hecho?”.
También debería ser: “¿qué problema estaba resolviendo esto para que siguiera existiendo?”.
La arrogancia del patrón conocido
Otro riesgo aparece cuando intentamos forzar sistemas ajenos a los patrones que nosotros conocemos.
Es muy humano. Vemos un problema y lo traducimos a nuestra experiencia: este sistema debería reescribirse con tal framework, esta arquitectura debería moverse a eventos, este flujo debería automatizarse con IA, este proceso debería parecerse a lo que ya hicimos en otra industria.
El problema es que la experiencia también puede convertirse en filtro.
Cuando conocemos poco de una operación, tendemos a sobreestimar cuánto entendemos. El sistema parece más simple de lo que realmente es. Sus bordes no están claros todavía. Sus excepciones no han aparecido. Sus reglas invisibles aún no nos han golpeado.
Desde esa mirada, reescribir parece fácil.
Pero mientras más se entiende un sistema productivo, más aparece la complejidad real: dependencias no documentadas, reglas comerciales implícitas, decisiones históricas, errores corregidos a medias, usuarios que aprendieron a operar alrededor del sistema, controles manuales que existen porque el riesgo era demasiado alto, reportes que nadie puede romper porque alimentan decisiones importantes.
Ahí cambia la conversación.
Modernizar no es imponer una arquitectura ideal sobre una realidad que todavía no entendemos. Modernizar bien exige entender primero por qué esa realidad tomó esa forma.
Qué cambia cuando entra la IA
Todo esto se vuelve más importante con IA.
Porque la IA puede hacer que una intervención superficial parezca más poderosa de lo que realmente es. Puede automatizar pasos, resumir documentos, clasificar casos, responder consultas, generar reportes, asistir decisiones o ejecutar tareas dentro de un flujo. Pero si se aplica sobre un proceso mal entendido, también puede amplificar errores.
Puede hacer más rápido un proceso que no debería acelerarse.
Puede eliminar una revisión humana que en realidad funcionaba como control.
Puede convertir una excepción importante en un caso “raro” que el sistema ignora.
Puede producir respuestas plausibles sobre datos incompletos.
Puede ocultar la complejidad detrás de una interfaz más cómoda.
Por eso muchas iniciativas de IA se quedan en demo. No porque el modelo sea malo, sino porque la demo no arrastra todo lo que arrastra producción.
La demo vive en un caso claro. Producción vive en el borde.
La demo responde bien cuando el contexto está limpio. Producción tiene datos sucios, permisos, auditoría, responsabilidades, costos, usuarios reales y consecuencias.
La demo muestra capacidad. Producción exige gobierno.
Antes de automatizar, hay que diagnosticar
Una buena intervención tecnológica no empieza preguntando qué modelo usar, qué herramienta comprar o qué sistema reemplazar.
Empieza con preguntas menos vistosas:
¿Por qué este proceso existe así?
¿Qué parte es deuda técnica y qué parte es conocimiento operativo?
¿Qué excepciones son ruido y cuáles protegen al negocio?
¿Qué pasos manuales son fricción inútil y cuáles funcionan como control?
¿Qué decisiones se pueden automatizar y cuáles necesitan revisión humana?
¿Qué sistemas se pueden reemplazar y cuáles deben convivir durante una transición?
¿Qué se rompe si aceleramos esto sin entenderlo?
Estas preguntas no son una forma de frenar la modernización. Son la condición para que la modernización funcione.
La IA puede ser una herramienta muy potente para rediseñar operaciones, reducir trabajo repetitivo, mejorar tiempos de respuesta, detectar riesgos y aumentar la capacidad de los equipos. Pero su valor no aparece por pegar una capa inteligente encima de cualquier flujo existente.
Aparece cuando se entiende el proceso, se identifica dónde hay fricción real y se diseñan controles para intervenir sin romper lo que todavía sostiene al negocio.
Respeto por lo que funciona, criterio para cambiarlo
Un sistema productivo que sigue funcionando merece mérito. No porque sea perfecto, sino porque permitió que una organización resolviera una necesidad durante suficiente tiempo como para seguir existiendo.
Eso no significa dejarlo intacto. Tampoco significa justificar toda deuda técnica como si fuera sabiduría histórica.
Significa intervenir con más criterio.
Hay partes que probablemente deben eliminarse. Otras deben rediseñarse. Otras deben automatizarse. Y algunas, al menos por un tiempo, deben mantenerse porque contienen reglas, controles o aprendizajes que todavía no han sido reemplazados por algo mejor.
La diferencia está en no llegar con la respuesta antes de entender el sistema.
En producción, lo feo no siempre es inútil. Lo antiguo no siempre es incorrecto. Lo manual no siempre es atraso. Y lo moderno no siempre es mejora.
Antes de automatizar con IA, hay que entender qué historia arrastra el sistema actual.
Porque modernizar no es borrar el pasado operativo de una empresa.
Es aprender de él lo suficiente como para construir algo mejor.