Tu IA de vigilancia puede tener toda la lógica bien hecha y aun así estar entrenando a tu equipo para que deje de leer sus correos. Nos pasó hace poco con un sistema que vigila la salud de varias integraciones: en cuanto detectaba un problema dos veces seguidas, lo daba por real y avisaba. Parecía razonable. Al ponerle números encima, dejó de parecerlo.
El problema: avisar a la primera entrena a que nadie escuche
La regla original era simple: si una comprobación falla dos ciclos consecutivos, es un problema real y toca avisar. Y si en el ciclo siguiente vuelve a salir bien, se marca como resuelto y se manda otro correo. Sobre el papel, dos comprobaciones seguidas parecen suficiente margen para descartar un fallo puntual de una sola vez.
En la práctica no lo eran. Muchos de los problemas que detecta un sistema de este tipo (una conexión que tarda en responder, un servicio que se reinicia solo, una cola que se vacía con unos minutos de retraso) se arreglan sin que nadie toque nada, simplemente porque el propio sistema vigilado se recupera solo. El correo de "roto" y el de "resuelto" llegaban igual, aunque nadie hubiera hecho nada entre uno y otro.
Lo que salió al medir 40 casos reales
En vez de seguir ajustando la regla a ojo, se repasaron las últimas parejas de avisos "roto" / "resuelto" que había mandado el sistema: unas 40 en total. El resultado fue contundente: todas menos 3 se habían cerrado solas en menos de una hora, con tiempos de resolución de entre 10 y 70 minutos. Es decir, de cada 10 alarmas, menos de una era un problema que necesitara que alguien interviniera. Las otras nueve eran ruido con forma de urgencia.
Ese es el coste real de avisar demasiado pronto, y no es solo el tiempo que alguien pierde abriendo el correo. Es el hábito que se forma: si el 90% de las alarmas resultan ser nada, la siguiente alarma real (la que sí necesita que alguien actúe ya) se lee con la misma calma que las 39 anteriores que no lo eran. Cuando eso pasa, el sistema de avisos ha dejado de cumplir su función, aunque siga técnicamente "funcionando" y mandando correos.
Antes y después de medir
| Regla anterior (sin medir) | Regla nueva (con datos) | |
|---|---|---|
| Cuándo avisa de "roto" | A la segunda comprobación seguida en fallo | Tras una hora seguida en fallo, sin interrupción |
| Cuándo avisa de "resuelto" | En cuanto una comprobación sale bien | Tras media hora seguida sin fallo |
| Si el problema reaparece antes de la media hora | Se trata como un caso nuevo, aviso nuevo | Se trata como el mismo incidente, no se repite el aviso |
| Alarmas reales sobre el total medido | Sin medir (se avisaba de todo) | Alrededor de 1 de cada 10 |
La nueva regla: una hora de presencia, media hora de ausencia
Con los datos de los 40 casos delante, la regla cambió de raíz. Ahora un problema tiene que estar presente de forma continua durante una hora antes de generar un aviso de "roto". Y para marcarlo como "resuelto" tiene que llevar media hora seguida sin aparecer. Si reaparece antes de esa media hora, no se trata como un incidente nuevo: es el mismo de antes, y no se vuelve a anunciar.
La diferencia con la regla anterior no es solo el tiempo, es de dónde sale el número. Antes, "dos comprobaciones seguidas" era una cifra elegida a ojo, sin comprobar cuánto tardaban en resolverse los problemas reales. Ahora, la hora y la media hora salen de mirar cuánto tardaba de verdad en resolverse solo el 90% de los casos que resultaron ser ruido, y poner el umbral por encima de ese tiempo. Un problema que se resuelve en 70 minutos por sí solo ya no dispara nada; uno que sigue ahí a la hora y media, sí.
Por qué esto no es solo cosa nuestra
Cualquier pyme que use un sistema de alertas automáticas (de un ERP, de un pedido, de un pago, de una web caída) tiene el mismo dilema, aunque no lo haya medido todavía. La tentación al montar cualquier sistema de avisos es fijar un umbral que "suene razonable" y avisar cuanto antes, porque parece lo más seguro. El problema es que "cuanto antes" y "cuanto antes se puede confiar en la alarma" no son lo mismo, y solo se descubre la diferencia midiendo cuánto tardan en resolverse solos los problemas que no eran nada.
Lo vimos ya en un caso parecido, cuando un parpadeo de conexión hacía sonar 40 correos en una sola noche sobre el mismo fallo sin nada nuevo que corregir: la ventana de espera cubría un tipo de fallo pero no otro. La lección de fondo es la misma en los dos casos: un umbral de alerta que no se ha medido contra el comportamiento real del sistema vigilado es, como mucho, una intuición con forma de configuración.
Checklist antes de fijar el tiempo de espera de tus propias alertas
- Revisa tus últimos 20 o 30 avisos "roto" / "resuelto". ¿Cuánto tardó cada uno en resolverse desde que apareció?
- Calcula qué proporción se resolvió sola, sin que nadie interviniera entre el aviso de roto y el de resuelto.
- Pon el umbral de aviso por encima del tiempo de resolución habitual del ruido, no por debajo. Si el 90% se arregla en menos de una hora, avisar a los dos minutos no añade seguridad, añade correos.
- Separa el umbral de "avisar" del umbral de "dar por resuelto". No tienen por qué ser el mismo tiempo, y en nuestro caso no lo son (una hora contra media hora).
- Decide qué pasa si el problema reaparece justo después de darse por resuelto. Tratarlo como nuevo duplica avisos sobre el mismo incidente; tratarlo como continuación evita el efecto parpadeo.
Diseñar sistemas de vigilancia que avisen de lo que importa, y solo de eso, es el mismo tipo de trabajo que hacemos dentro de la plataforma de datos e IA que unifica la información de varias farmacias y decide sola cuándo recomendar una compra. Si te reconoces en el problema de las alarmas que nadie mira ya, revisa nuestros servicios o escríbenos y lo vemos juntos.
