Aviso de cookies

Utilizamos cookies propias y de terceros para mejorar nuestros servicios. Si continúa con la navegación consideramos que acepta las diferentes políticas y términos de este sitio web. Puede consultar el resumen de las políticas en nuestro resumen, o todo los documentos completos en Políticas de cookies, Términos de uso y Política de privacidad haciendo click en cada enlace.

Aceptar
Menú

La calma también acumula riesgo

Cuando no pasa nada, también se acumula riesgo

Hace unos meses me tocó revisar una plataforma crítica que, a simple vista, estaba “bien” porque no se caía, no levantaba alertas y nadie la mencionaba en las juntas. Pero la realidad era otra: esa calma también escondía una fragilidad que llevaba tiempo creciendo y que, cuando se deja avanzar, luego sale bastante más cara de corregir. Y no, no era que el sistema “estuviera tranquilo”, sino que la organización había confundido silencio operativo con salud real.

Ese tipo de fragilidad casi siempre se va armando en silencio. Se alimenta de deuda técnica, permisos difusos, cambios sin trazabilidad, dependencia de dos o tres personas y una arquitectura que ya cuesta trabajo tocar. Con los meses, lo que parecía control se vuelve costumbre, y la costumbre engaña porque te hace creer que todo está bajo control cuando en realidad solo estás pateando el problema para adelante.

Como CTO, he aprendido que la calma aparente también puede esconder una carga acumulada. La pregunta que de verdad importa no es si la plataforma hace ruido, sino si todavía se puede cambiar sin poner en juego lo que la sostiene. Y ahí es donde normalmente salen las respuestas incómodas.

La señal equivocada

Muchas organizaciones creen que una plataforma está bien mientras no interrumpa la operación. No genera avisos, no provoca caídas y no le da trabajo a nadie. Pero esa lectura mezcla continuidad aparente con resiliencia real, y termina premiando la quietud como si fuera una virtud.

El sistema que tenía en mente seguía funcionando con normalidad en el día a día. El problema es que esa normalidad tapaba una realidad bastante menos cómoda para quienes lo operaban. No había ownership claro, las decisiones se tomaban al vapor y la empresa ya llevaba rato viviendo de atajos.

Todo funcionaba, sí, pero mientras nadie tuviera que tocar una parte sensible. En ese momento aparecía el costo real de no tener criterio compartido. Desde fuera parecía eficiencia; desde dentro era riesgo acumulado, de ese que nadie quiere nombrar hasta que ya no se puede seguir pateando.

La ausencia de fallos no prueba seguridad

La prueba más útil no fue preguntar si el sistema había fallado. Fue ver qué pasaba cuando alguien intentaba modificarlo o atacarlo. La auditoría dejó claro que la superficie de riesgo seguía ahí, aunque la operación se viera tranquila.

En una prueba controlada de seguridad se demostró, en menos de diez minutos, que un usuario podía manipular flujos y llegar a generar compras por unos 3.000 euros. La compra no se ejecutó, pero la demostración alcanzó para cambiar la conversación en el comité, porque el problema ya no era teórico.

Ahí es donde se ve la diferencia entre funcionar y ser resiliente. Un sistema puede sostener el día a día y, al mismo tiempo, no estar listo para absorber un cambio, una auditoría o incluso un crecimiento moderado sin exponerse. Eso casi siempre se descubre tarde, cuando la presión ya te obliga a actuar.

Qué debe mirar un comité de dirección

Hay señales tempranas que merecen atención aunque todavía no haya incidentes visibles. Cambios urgentes sin registro, miedo a tocar ciertas partes del sistema, documentación pobre, dependencia de un tercero o de una sola persona, y una arquitectura demasiado centralizada forman un patrón bastante claro. Y ese patrón, la neta, suele anunciar problemas mayores.

Cuando aparece ese patrón, la pregunta correcta no es si ya pasó algo. La pregunta de fondo es cuánto tiempo más puede sostenerse la compañía sin pagar un precio más alto. En muchas organizaciones, esa respuesta termina definiendo el margen real de decisión.

Y la respuesta rara vez es “seguir un poco más”. Normalmente toca ordenar antes de seguir moviendo cosas. Definir ownership, poner trazabilidad mínima, modularizar la arquitectura y automatizar controles críticos ayuda a recuperar capacidad de evolución sin convertir cada cambio en una apuesta.

La estabilidad real se mide por el futuro

Un sistema que nunca da problemas puede seguir siendo un mal sistema para el negocio si no soporta cambios con seguridad. Esa es la lección que más importa a un CTO. La salud de una plataforma no se mide por la calma del presente, sino por el tipo de riesgo que todavía está escondiendo.

Si no podemos cambiarla sin poner en juego la operación, entonces no tenemos estabilidad. Tenemos una pausa que parece control mientras la complejidad sigue creciendo por debajo. Y la organización acaba pagando esa ilusión con más esfuerzo, más riesgo y menos margen de maniobra.

Esa pausa suele ser el punto donde conviene decidir. La empresa puede seguir viviendo con la inercia o puede recuperar disciplina antes de que el riesgo encuentre una forma más cara de aparecer. En ese momento, ¿qué vale más: actuar con criterio o seguir sosteniendo la apariencia de calma?

Escrito por: Aritz Pozo
lunes 14 de septiembre de 2026
Tema: