El control mínimo que el sistema ya pedía
Hace unos meses me encontré con una plataforma crítica que tocaba operación, seguridad y dinero, y el dilema real no era si frenábamos el negocio, sino cuánto riesgo ya se estaba aceptando sin decirlo en voz alta. En ese punto ya no estabas discutiendo procesos; estabas discutiendo consecuencias, y de las que luego salen caras.
El problema es seguir operando como si aún no hiciera falta
En muchas organizaciones, la idea de no meter más proceso suena pragmática, pero muchas veces solo está tapando una decisión que nadie quiere tomar. Mientras la plataforma responde, la inercia hace el trabajo. Luego llegan cambios urgentes, se multiplican las excepciones, se amplían permisos y el conocimiento termina concentrado en unas cuantas personas.
Eso parece velocidad durante un tiempo. Después deja de serlo. El coste aparece cuando la operación ya depende de excepciones que nadie revisa, y ahí la supuesta fluidez se convierte en fragilidad acumulada.
Como CTO, me interesa menos discutir si el control ralentiza y más entender qué riesgo estás aceptando cuando lo evitas. En un sistema crítico, la ausencia de gobierno no elimina la complejidad. Solo la esconde. Y lo que queda fuera de la vista normalmente termina dentro del incidente.
Burocracia y gobierno operativo no son lo mismo
La diferencia es bastante simple, aunque rara vez se explica bien. Burocracia es meter pasos que no mejoran la decisión. Gobierno es definir el circuito mínimo para que una plataforma cambie con trazabilidad, se valide con criterio y se pueda auditar sin depender de la memoria de dos personas.
Ese umbral ya se había pasado. La plataforma había crecido sobre una base centralizada, con permisos difusos y cambios reactivos. El equipo era pequeño, sí, pero la criticidad no tiene mucho que ver con el tamaño. Tiene que ver con el impacto sobre la operación, los datos, la exposición legal y la seguridad.
Ahí aparece el dilema de siempre. Si controlas más, parece que el negocio se frena. Y muchas veces pasa lo contrario. Lo que de verdad frena es no haber definido quién aprueba, quién implementa, quién valida y cómo queda registro de todo eso.
El control deja de parecer coste cuando evita seguir acumulando riesgo
Antes de mover nada, lo correcto fue auditar. No para cumplir con una casilla, sino para saber qué riesgo real estaba asumiendo la empresa. Esa revisión confirmó algo que era difícil de esquivar: tocar el sistema sin orden podía empeorar el problema.
La prueba de seguridad fue bastante clara. En menos de diez minutos se demostró que un usuario podía manipular flujos hasta activar compras por un valor cercano a 3.000 euros. No hacía falta imaginar un escenario extremo, porque el riesgo ya era operativo. Y a eso se sumaba una arquitectura que no permitía crecer con seguridad ni aislar partes del sistema sin comprometer el conjunto.
Desde ahí, reconstruir dejó de ser una decisión radical y pasó a ser una decisión prudente. Era más rápido que seguir parchando, más barato que estirar una base frágil y más coherente con la necesidad de operar sin dejar la continuidad en manos de la suerte. El control mínimo empezó a verse como una condición de trabajo, no como una carga añadida.
El circuito mínimo que una plataforma crítica necesita
La lección no es gobernarlo todo. Es definir lo mínimo indispensable. Ownership funcional y técnico, registro de cambios, validación previa, permisos claros y documentación suficiente para que el sistema no dependa de conocimiento tácito.
Ese mínimo no es un lujo. Es la condición para seguir evolucionando sin perder control. La pregunta ya no es si conviene meter gobierno. La pregunta es cuánto tiempo puede una organización seguir llamando agilidad a una improvisación que ya tiene coste operativo.
Cuando esa pregunta se responde con honestidad, la discusión cambia de tono. Ya no se trata de proteger la forma de trabajar, sino de proteger la capacidad de seguir operando. Y ahí el control deja de ser un gesto defensivo para convertirse en una decisión madura.
