Aprobado una vez, renovado para siempre
Hace cuatro años, un equipo aprobó el acceso de un proveedor externo a un sistema interno para un proyecto puntual de tres meses. El proyecto terminó, pero nadie revocó el acceso. La plataforma estaba configurada para renovar el permiso automáticamente cada año, salvo que alguien lo cancelara a mano. Nadie lo canceló, porque nadie recordaba que existía. Cuatro renovaciones después, una auditoría de seguridad encontró la cuenta activa, con permisos de escritura, perteneciente a una empresa que ya ni siquiera trabajaba con la organización.
Este patrón no es exclusivo de la tecnología. Aparece en comités, proveedores, plantillas de proceso y hasta en reuniones recurrentes: una decisión tomada en un momento concreto se convierte en una regla permanente simplemente porque nadie volvió a preguntarse si seguía teniendo sentido. La aprobación inicial fue razonada. Su continuidad no lo fue.
Algunos síntomas típicos de este problema:
- Permisos o accesos que "siempre han estado ahí" y nadie sabe justificar.
- Reuniones semanales que siguen ocurriendo mucho después de que su propósito original desapareciera.
- Excepciones aprobadas "solo por esta vez" que se convierten en la norma no escrita.
- Contratos o acuerdos que se renuevan automáticamente sin una revisión sustantiva.
Una decisión sin fecha de revisión no es una decisión: es una suposición que se hereda sin cuestionarla.
Facilitar bien un proceso no es solo diseñar cómo se toma una decisión, sino diseñar cuándo se vuelve a mirar. Si en tu organización hay aprobaciones que llevan años renovándose solas, puede que sea un buen momento para revisarlas: en la página de contacto podemos ver por dónde empezar.
Perspectiva Poka-yoke (Shigeo Shingo)
Este es un caso claro de ausencia de un tipo de inspección de autoinspección (self-check) programada: nadie estaba diseñado para volver a revisar la propia decisión en el tiempo. La aprobación original funcionó como control puntual, pero el sistema no incluía ningún método de detección de secuencia (motion-step method) que obligara a pasar, periódicamente, por un nuevo paso de verificación antes de continuar.
La solución Poka-yoke más simple aquí no es tecnológica, es estructural: fijar una fecha de caducidad obligatoria en cada aprobación, de modo que el permiso o el acuerdo se desactive por defecto si nadie lo revisa y renueva conscientemente. Esto convierte una función reguladora de aviso (warning method) débil -confiar en que alguien se acuerde de revisar- en una función de control (control method) real, donde la inacción produce automáticamente el resultado seguro.
Es un ejemplo útil de por qué, en diseño de procesos, el estado por defecto debería ser el más seguro. Cuando "no hacer nada" mantiene un riesgo activo indefinidamente, el problema no es la falta de vigilancia humana: es que el proceso nunca debió depender de ella.
Lección: si una decisión necesita revisión periódica para seguir siendo segura, esa revisión debe estar integrada en el proceso, no en la memoria de alguien.
