Tu IA puede tener un filtro de ruido perfectamente razonable y aun así mandarte 40 correos en una sola noche por un fallo que no había cambiado nada. No porque el filtro esté mal pensado, sino porque está pensado para un tipo de fallo distinto al que le llegó. Nos pasó hace poco con un sistema que vigila la conexión de varias farmacias, y merece la pena contarlo porque es un error fácil de cometer en cualquier sistema de avisos, con IA o sin ella.
El filtro que funcionaba bien, hasta que dejó de hacerlo
El sistema vigila la conexión de varias farmacias que comparten la misma plataforma de datos, y tiene una regla de sentido común para no molestar por tonterías: si detecta lentitud, no avisa a la primera. Espera a que se repita en dos ciclos de comprobación seguidos antes de escalar el aviso. Y si en el ciclo siguiente la conexión vuelve a ir bien, retira la alerta sin más.
Es una regla que funciona de maravilla contra el ruido que estaba pensada para filtrar: un parpadeo de un par de segundos, del tipo que puede dar cualquier red en un momento puntual y que no significa nada. Dos ciclos de margen bastan para no disparar una alarma por eso.
El problema llegó con un tipo de fallo distinto: una conexión que iba lenta de forma sostenida, no cortada del todo, sino degradada durante minutos, y que además fluctuaba dentro de esa degradación. Cambiaba de "va mal" a "se ha puesto al día un instante" cada 25 minutos aproximadamente, más rápido que la ventana de dos ciclos pensada para absorber un parpadeo de segundos. El resultado: el filtro veía "se arregló", retiraba el aviso, y unos minutos después volvía a verlo mal y lo mandaba de nuevo. Toda la noche.
El número: 40 correos, un solo fallo
Cuando se revisó a la mañana siguiente, la cuenta fue clara: cerca de 40 correos en una sola noche, alternando entre alerta y resuelto, sobre exactamente el mismo problema de conexión. No eran 40 incidentes distintos. Era uno solo, visto 40 veces desde ángulos que parecían nuevos cada vez porque el filtro comparaba contra el ciclo anterior, no contra si el problema de fondo seguía ahí.
Nada de esto afectó al servicio real de las farmacias: la plataforma de datos que unifica su información y que la IA usa para recomendar compras y validar ventas al céntimo siguió funcionando. El coste no fue operativo, fue de atención: 40 correos sobre el mismo asunto entrenan a cualquiera a dejar de abrirlos, que es justo lo que no quieres que pase el día que uno de esos correos sí sea nuevo.
Por qué un filtro bien diseñado puede fallar igual
Aquí está la parte que generaliza a cualquier sistema de avisos: una regla de "espera N repeticiones antes de escalar" no filtra ruido en general, filtra el ruido para el que se calibró. Si el fallo real cambia de ritmo más deprisa que la ventana elegida, la ventana deja de proteger de nada y empieza a generar el mismo ruido que se suponía que evitaba.
| Tipo de fallo | Duración típica | Qué necesita el filtro |
|---|---|---|
| Parpadeo puntual (un pico de red, un timeout suelto) | Segundos | Esperar 1-2 ciclos basta para ignorarlo |
| Degradación sostenida y estable (algo va mal y se queda así) | Minutos u horas sin cambiar | El filtro de "espera N repeticiones" funciona igual de bien |
| Degradación sostenida que fluctúa (va mal, se recupera un instante, vuelve a ir mal) | Minutos, cambiando varias veces | La ventana de repeticiones no basta: hace falta agrupar por el fallo de fondo, no por cada lectura |
La fila de en medio es la trampa: un fallo que dura minutos parece, a simple vista, que debería quedar cubierto por "esperar dos ciclos". Y lo está, siempre que no fluctúe. En cuanto fluctúa más rápido que la ventana, el mismo filtro que te protege de un parpadeo de segundos empieza a tratar cada oscilación como un evento nuevo.
La regla de decisión
Dos ideas, aplicables a cualquier sistema de avisos que use una ventana de "espera N repeticiones" antes de escalar, tenga o no una IA decidiendo encima:
- Conoce el ritmo real de tus fallos antes de fijar la ventana. No basta con elegir "dos ciclos" porque suena razonable; hace falta saber si un fallo típico dura segundos, minutos o cambia de estado varias veces dentro de ese rato. La ventana se calibra contra eso, no contra la intuición.
- Un fallo que oscila no es un fallo distinto cada vez que cambia de estado. Si el sistema compara solo contra el ciclo anterior, trata cada oscilación como un evento nuevo. Si compara contra si el problema de fondo sigue sin resolverse, agrupa las 40 lecturas en un solo aviso: "esto lleva inestable desde tal hora", no 40 correos sueltos.
Checklist antes de dar por bueno tu sistema de avisos
Si tu negocio depende de un panel, un canal de Slack o un agente de IA que decide cuándo interrumpirte, antes de confiar en el filtro de ruido que tiene montado:
- ¿Sabes cuánto dura, de media, un parpadeo real en tus sistemas? ¿Segundos, minutos, horas?
- ¿Tu ventana de "espera N repeticiones" es más lenta o más rápida que ese ritmo real?
- ¿El sistema agrupa un mismo fallo que oscila, o genera un aviso nuevo cada vez que cambia de estado?
- ¿Alguien ha probado qué pasa si un fallo dura justo el doble de tiempo que tu ventana de filtro?
- ¿Cuántos correos duplicados sobre lo mismo harían falta para que dejases de leerlos?
La última pregunta es la que más importa. Si la respuesta es "pocos", ya tienes la señal de que el filtro necesita revisión antes de que llegue la noche en que de verdad haga falta prestar atención.
Diseñar un sistema de avisos que distinga ruido real de una señal que solo cambia de forma es exactamente el tipo de trabajo técnico que hacemos en AutoBoost, dentro de plataformas de datos e IA que ya operan sobre negocios reales. Si quieres revisar cómo está montada la vigilancia de tus procesos, o estás valorando meter una IA que decida a partir de ese estado, consulta nuestros servicios o contacta con nosotros y lo miramos juntos.
