"Las aprobaciones manuales existen para garantizar control. Pero cuando todos las aprueban por inercia, el control es una ilusión. Y en el fondo, todos lo saben."
Hay un momento que ocurre en casi todos los equipos técnicos y que nadie documenta en los postmortems.
Alguien abre una solicitud de aprobación. Lee el título. Mira brevemente la descripción. Y hace click en aprobar.
No porque haya revisado cada detalle. No porque tenga total certeza de que todo está correcto. Sino porque conoce al equipo, confía en que ya lo revisaron, tiene otras cinco cosas pendientes, y en el fondo sabe que si no aprueba, el proceso se detiene y alguien va a preguntar ¿por qué?.
Así que aprueba.
Y lo mismo hace la persona que aprueba después. Y la que aprueba después de esa.
El proceso tiene tres aprobaciones requeridas. Las tres ocurren en menos de cuatro minutos. Nadie leyó nada en serio.
Aquí no aplica "hay que desconfiar hasta de la sombra"
Por qué existen las aprobaciones manuales
Las aprobaciones manuales nacen de una intención legítima: poner un punto de control humano antes de que algo importante ocurra. Un deploy a producción, un cambio de configuración crítico, un acceso a un sistema sensible.
La lógica es razonable. Si alguien con criterio revisa antes de que el cambio llegue a producción, hay una oportunidad de detectar errores que el autor no vio, decisiones que no siguen las políticas del equipo, o impactos que no fueron contemplados.
En teoría, la aprobación es una red de seguridad.
En la práctica, con frecuencia es otra cosa.
Cómo la aprobación se convierte en teatro
El problema no es la aprobación en sí. Es lo que ocurre cuando el volumen de solicitudes supera la capacidad real de revisión del equipo.
Cuando hay dos o tres solicitudes de aprobación por semana, es razonable revisarlas con cuidado. Cuando hay veinte por día, y cada una requiere entender contexto, revisar código o configuración, y tomar una decisión informada — la matemática no da.
El equipo tiene dos opciones reales: convertirse en un cuello de botella bloqueando todo hasta poder revisar apropiadamente, o desarrollar un criterio implícito de cuándo revisar de verdad y cuándo simplemente aprobar.
Casi siempre eligen lo segundo. No por negligencia — sino porque el sistema los puso en una posición donde no hay otra salida sostenible.
Y así, gradualmente, la aprobación deja de ser una revisión y se convierte en un ritual. Un paso del proceso que todos saben que existe, que todos cumplen, y que nadie espera que realmente detenga algo.
El problema más profundo: la confianza que no se nombra
Detrás de cada aprobación por inercia hay algo que vale la pena nombrar: una confianza implícita que el proceso oficial no reconoce.
Cuando alguien aprueba sin leer, generalmente no lo hace porque sea irresponsable. Lo hace porque conoce a quien hizo la solicitud, porque sabe cómo trabaja ese equipo, porque ha visto su historial y sabe que raramente se equivocan en cosas graves.
Es confianza real. Pero es confianza que vive en las personas, no en el sistema.
El problema es que esa confianza es invisible, no transferible y frágil. Funciona mientras las personas que la sostienen estén en el equipo, conozcan el contexto, y tengan el criterio para distinguir cuándo algo merece revisión real. Cuando alguien nuevo llega al equipo y hereda la responsabilidad de aprobar, no hereda el contexto — hereda el proceso vacío.
Y entonces aprueba igual, pero sin ni siquiera la confianza implícita que tenía el anterior. Solo el hábito.
Lo que el sistema debería saber
Aquí está la pregunta que pocos equipos se hacen en voz alta:
Si el 90% de las aprobaciones se otorgan sin revisión real porque todos confían en que el equipo ya verificó — ¿por qué el sistema no puede verificar eso mismo?
Si una solicitud cumple con las convenciones de nombres definidas, si el recurso solicitado está dentro de los permitidos para ese equipo, si el ambiente es el correcto, si los tags requeridos están presentes, si la región es la autorizada — eso no requiere un criterio humano. Requiere una validación.
Y una validación puede vivir en código.
La aprobación humana tiene valor real cuando hay criterio genuino que aplicar: cuando el cambio tiene implicaciones de arquitectura que no están capturadas en ninguna política, cuando hay un contexto de negocio que el sistema no conoce, cuando la decisión requiere sopesar factores que no son codificables.
Para todo lo demás — para las verificaciones que hoy se hacen por inercia — el sistema puede hacerlo mejor, más rápido y sin despertar a nadie a las 3am para que haga click en un botón.
El costo de la fricción sin valor
Cada aprobación que no agrega valor real tiene un costo que rara vez se contabiliza.
El tiempo del aprobador que podría estar haciendo algo que requiera su criterio real. El tiempo del solicitante esperando un proceso que en el fondo sabe que es automático. La sensación acumulada de que los procesos existen para cumplirse, no para proteger algo. Y en el largo plazo, la erosión de la seriedad con que el equipo trata los controles que sí importan.
Cuando todo requiere aprobación, nada parece realmente importante. Cuando la aprobación es automática por defecto, la excepción — el cambio que sí necesita revisión humana — pierde el peso que debería tener.
El ruido mata la señal. En alertas, en documentación, y también en aprobaciones.
Qué cambiaría si el sistema validara en lugar de que las personas aprobaran
No estoy hablando de eliminar el control humano. Estoy hablando de moverlo al lugar donde agrega valor.
Si el sistema valida automáticamente que una solicitud cumple todas las políticas codificadas, el aprobador humano puede enfocarse en lo que el sistema no puede evaluar. El volumen de aprobaciones reales baja. La calidad de la revisión sube. El proceso deja de ser un ritual y vuelve a ser lo que siempre debió ser: un punto de control con criterio.
Y el equipo que hacía click en aprobar por inercia recupera tiempo para hacer el trabajo que justifica que estén ahí.
En el siguiente post: el ingeniero que se fue y se llevó el contexto — y por qué el bus factor es un riesgo operacional que casi nunca aparece en los planes de continuidad.
¿Cuántas aprobaciones procesas por semana que en el fondo sabes que son automáticas? Cuéntalo en los comentarios — sin nombres, sin empresas. Solo el número. "¡Cuéntanos el pecado, pero no el santo!"
Top comments (0)