Tu IA de vigilancia puede tener razón cuatro veces seguidas y aun así estar haciendo mal su trabajo. Nos pasó con el sistema que vigila la salud de las integraciones de un grupo de farmacias: un solo ordenador dejó de responder una noche y, en vez de un aviso, llegaron cuatro. Todos verdaderos. Todos sobre lo mismo. Y ese exceso de "verdad" es justo lo que hace que un equipo deje de leer sus propios avisos.
En AutoBoost construimos sistemas de IA que vigilan integraciones reales de clientes (ERP, facturación, contabilidad) y que tienen que decidir, cada pocos minutos, qué merece interrumpir a alguien y qué puede esperar. Este episodio nos enseñó que "el aviso es correcto" y "el aviso está bien diseñado" son dos cosas distintas, y que confundirlas sale caro en forma de bandeja de entrada ignorada.
El síntoma: una causa, cuatro correos
Cuando el ordenador de una farmacia deja de responder, todo lo que depende de él se marca como roto: la sincronización de stock, la lectura de albaranes, el envío de pedidos al distribuidor, la comprobación de que el día se ha cerrado bien. Hasta hace poco, cada una de esas cuatro consecuencias generaba su propio aviso, de forma independiente, porque cada comprobación vigilaba su propia pieza sin saber nada de las demás.
El resultado: la misma noche, por la misma avería, llegaron 4 avisos independientes, cada uno hablando de un síntoma distinto sin mencionar que compartían origen. Quien los recibe no ve "un ordenador caído en la farmacia X", ve cuatro problemas sueltos que parecen requerir cuatro diagnósticos distintos. La primera vez se investiga cada uno. La segunda vez, ya se sospecha que son el mismo. La tercera vez, se deja de mirar el canal con la atención que merece una avería real.
El segundo problema, escondido dentro del primero
Al revisar este caso encontramos algo que no era una avería, sino una decisión de diseño equivocada: los avisos de calidad del dato (un descuadre contable, un adjunto sin procesar, una comprobación de paridad entre sistemas) se recordaban cada 24 horas, exactamente con la misma cadencia que una avería real como un ordenador caído.
El problema de fondo es que esos dos tipos de aviso no son comparables:
- Una avería real (una conexión caída, un ordenador sin responder) es algo que hay que mirar ya, porque cada minuto que pasa se acumula trabajo perdido.
- Un descuadre de calidad del dato es algo que se puede revisar con calma, y recordarlo cada mañana no hace que se arregle más rápido: solo añade ruido a un canal que también lleva avisos urgentes.
Tratar ambos igual entrena al equipo a leer todo el canal con la misma calma, que es exactamente lo contrario de lo que se busca cuando algo sí es urgente.
La regla que aplicamos
Agrupa por causa, no por síntoma; y haz que la frecuencia del recordatorio dependa de si hay algo que hacer ya, no del tipo de dato que lo generó.
En la práctica fueron dos cambios distintos, aplicados a la misma pieza de vigilancia:
- Agrupación por causa raíz. Cuando el sistema detecta que varias comprobaciones fallan al mismo tiempo por el mismo origen (el mismo ordenador, la misma conexión, la misma sede), las agrupa en un único aviso que nombra la causa y lista qué se ha quedado parado como consecuencia. Un aviso, no cuatro.
- Frecuencia por urgencia, no por tipo de aviso. Las averías reales (algo caído ahora mismo) se siguen recordando a diario, porque cada día cuenta. Los avisos de calidad del dato pasaron de recordarse cada 24 horas a una vez por semana: siguen ahí, siguen visibles, pero no compiten por atención con lo que sí necesita una reacción inmediata.
Antes y después, en números
| Antes | Después | |
|---|---|---|
| Avisos por una avería con 4 consecuencias | 4 correos independientes | 1 aviso agrupado por causa |
| Recordatorio de una avería real | Diario | Diario (sin cambios) |
| Recordatorio de calidad del dato (descuadre, adjunto sin procesar) | Cada 24 horas | Una vez por semana |
Por qué esto importa a quien no gestiona un sistema de vigilancia
Este patrón no depende de tener un vigilante técnico como el nuestro. Aparece en cualquier sistema que avisa de varias cosas a la vez:
- Un CRM que manda una notificación por cada campo que falta en una ficha de cliente, en vez de un único aviso de "ficha incompleta".
- Un ERP que avisa por separado de que un pedido no tiene stock, no tiene tarifa asignada y no tiene forma de envío, cuando las tres cosas vienen del mismo cliente mal dado de alta.
- Un panel de soporte que manda un ticket por cada síntoma de una caída de servicio, en vez de uno que agrupe "esto es una sola incidencia con varios efectos".
En todos los casos, la pregunta que vale la pena hacerse es la misma: cuando algo falla, ¿tu sistema está contando causas o está contando síntomas? Si cuenta síntomas, cada avería real se multiplica en tu bandeja de entrada, y cada aviso que no es urgente compite con los que sí lo son.
Checklist para auditar tu propio sistema de avisos
- ¿Sabes, sin mirar el histórico, cuántos avisos distintos puede generar una sola avería real en tu sistema?
- ¿Tus avisos urgentes (algo caído, algo roto ahora mismo) usan la misma frecuencia de recordatorio que los que se pueden revisar con calma?
- Cuando dos o más comprobaciones fallan a la vez, ¿tu sistema comprueba si comparten origen antes de avisar por separado?
- ¿Alguien en tu equipo ha empezado a "leer por encima" el canal de avisos porque llega demasiado de lo mismo?
- Si agruparas tus avisos por causa en vez de por síntoma, ¿cuántos correos de la última semana se habrían quedado en uno solo?
Es el mismo trabajo que hicimos en la plataforma de datos con IA que construimos para un grupo de farmacias: la IA razona sobre más de un millón de líneas de varias oficinas, y una alerta mal diseñada en un sistema así no se nota con un cliente, se nota multiplicada por cada sede que comparte la misma causa de fondo.
La pregunta que vale la pena hacerse hoy
No es "¿mi sistema de avisos funciona?". Los cuatro correos de la noche del ordenador caído eran, cada uno, técnicamente correctos. La pregunta es "¿mi sistema de avisos distingue entre lo que hay que mirar ya y lo que puede esperar, y agrupa lo que viene de la misma causa?". Si la respuesta es no, tienes un sistema que grita mucho y comunica poco, que es peor que uno que avisa menos pero mejor.
En AutoBoost diseñamos los sistemas de IA que vigilan tus integraciones para que agrupen por causa y avisen con la urgencia que corresponde a cada tipo de problema, no a la cantidad de síntomas que produce. Puedes ver cómo lo planteamos en nuestros servicios de IA aplicada al negocio. Si tu canal de avisos lleva tiempo funcionando y sospechas que una sola avería se te está multiplicando en varios correos, hablemos.
