Alberto García Arrieta.
Durante años, el principio de “si funciona, no lo toques” ofreció estabilidad en entornos críticos. En un momento en el que los cambios eran costosos y la detección de fallos podía alargarse durante semanas, esa prudencia tenía sentido. Hoy el contexto es otro. La capacidad para analizar sistemas complejos, revisar código, rastrear dependencias o detectar fallos, impulsada por herramientas de IA capaces de recorrer bases de código enteras en minutos, ha cambiado por completo la ecuación del riesgo. Lo que no se revisa deja de entenderse, y lo que no se entiende termina convirtiéndose en un riesgo estructural para el negocio.
Los avances recientes, como los demostrados en Mythos, muestran con claridad ese cambio de escala. Ya no hablamos de utilidades que aceleran tareas, sino de sistemas capaces de leer grandes bases de código, razonar sobre dependencias, analizar binarios sin símbolos y detectar fallos con una rapidez que hace unos años era impensable. Ese salto obliga a revisar no solo el software, sino también la forma en que se gobierna.
Durante décadas, la deuda técnica se trató como un pasivo que podía aplazarse. Había un margen entre introducir una vulnerabilidad y sufrir su impacto. Ese margen se ha estrechado hasta casi desaparecer. Cada vez resulta más evidente que muchos incidentes de seguridad no son fallos aislados, sino la consecuencia de modelos tecnológicos y operativos que generan vulnerabilidades de manera constante. Las organizaciones no solo encuentran fallos, también los producen. En este escenario, limitarse a detectar vulnerabilidades y aplicar parches ya no basta. La seguridad deja de ser un ejercicio reactivo y pasa a convertirse en una herramienta que revela problemas más profundos en la arquitectura, los procesos y la gobernanza de IT.
Este cambio también se refleja en la evolución del propio concepto de responsabilidad. En mis primeros proyectos, en arquitecturas de core bancario escritas en Cobol, siempre había alguien que podía explicar qué hacía cada componente y qué ocurría si fallaba. Hoy, en sistemas mucho más modernos, no siempre está claro quién podría responder a esa pregunta. Esa pérdida de trazabilidad y de ownership es uno de los riesgos más subestimados en las organizaciones actuales.
El IT empresarial se construyó durante años alrededor de proyectos, versiones y tickets, un modelo que asumía que el principal riesgo estaba en el cambio. Ahora ocurre lo contrario. Cuando detectar un fallo puede llevar minutos, no cambiar se convierte en la opción más arriesgada. Un modelo operativo adaptado a esta nueva realidad exige que la unidad de trabajo no sea solo una funcionalidad, sino un artefacto verificable, con procedencia conocida y comportamiento observable. El foco deja de estar en el código línea a línea y pasa a situarse en la intención, las dependencias y las capacidades otorgadas a cada componente. Esto obliga a plantear preguntas que muchas organizaciones aún no han resuelto, como quién es el dueño real de cada artefacto, quién responde por su comportamiento en producción y quién tiene autoridad para retirarlo cuando deja de aportar valor o se convierte en un riesgo.
También se ha vuelto habitual encontrar componentes que llevan años en producción sin que nadie recuerde exactamente su origen. En más de una revisión técnica ha sido necesario invertir tiempo en reconstruir la procedencia de una librería o un módulo que funcionaba desde hace años, pero cuya aprobación nadie podía atribuirse. No es un problema de legacy, sino de opacidad. La cadena de suministro de software atraviesa múltiples capas, desde infraestructuras base y runtimes hasta componentes de terceros, modelos preentrenados y agentes automatizados. Si la gobernanza no abarca todas esas capas, en la práctica no gobierna ninguna. Los mecanismos tradicionales, basados en comités, aprobaciones periódicas y revisiones manuales, no operan a la velocidad que exige este entorno. La revisión debe ser continua y, en buena parte, automatizada.
La automatización impulsada por IA ya transforma tareas como la generación de código, las migraciones, el testeo o las refactorizaciones, pero esto no sustituye la ingeniería. La responsabilidad última sigue estando en quienes definen la intención del sistema, su arquitectura y su perfil de riesgo. La pregunta relevante no es cuántas líneas de código puede generar la IA, sino cuántos componentes podrían retirarse mañana sin comprometer la operación. Esa es la métrica que realmente expone la salud del sistema.
La alternativa no es congelar sistemas ni emprender modernizaciones masivas sin criterio. Es construir un núcleo digital que evolucione de forma continua, apoyado en un modelo operativo coherente y en mecanismos claros de ownership y retirada. Reservar presupuesto para reducir deuda técnica es necesario, pero insuficiente si no va acompañado de decisiones explícitas. Sin responsables claros y sin capacidad real de desmantelar lo que ya no aporta valor, esa inversión corre el riesgo de convertirse en mantenimiento encubierto.
“Si funciona, no lo toques” debe dar paso a un principio más exigente: si funciona, asegúrate de que puedes entenderlo,reconstruirlo y retirarlo. Antes de aprobar la próxima versión conviene plantear una pregunta sencilla y directa: ¿quién podría retirar mañana este sistema sin poner en riesgo la operación?. Si no hay respuesta, no hay responsabilidad. Y donde no hay responsabilidad, hay deuda.
*** Alberto García Arrieta es managing director responsable de Digital Core en Accenture en España y Portugal