Tu IA puede arreglar una alarma falsa hoy y, sin que nadie toque nada más, la misma trampa reaparece semanas después en un rincón mucho más pequeño del sistema. Nos pasó hace poco con el vigilante que revisa la salud de varias integraciones de clientes, y lo interesante no es el bug en sí, es por qué "ya lo arreglamos" no siempre significa lo que creemos que significa.
En AutoBoost construimos sistemas de IA que vigilan integraciones reales (facturación, contabilidad, ERP) y avisan cuando algo falla. Cuando uno de esos vigilantes empieza a mentir sobre su propio estado, la lección casi nunca se queda en "arreglado y ya está": hay que preguntarse si el mismo fallo puede estar escondido un nivel más abajo, en una pieza más pequeña y más específica del mismo sistema.
El fallo original: confundir "no sé" con "arreglado"
Hace unas semanas contamos cómo un monitor de infraestructura confundía la ausencia de respuesta con una buena noticia: si el sistema vigilado dejaba de responder un instante, el vigilante lo interpretaba como "problema resuelto", y en cuanto volvía a responder, generaba una alarma de "problema nuevo". Dos correos falsos por cada corte real, sin que hubiera pasado nada de verdad. Se corrigió a ese nivel: si no hay respuesta, los problemas abiertos se quedan abiertos hasta que se compruebe de verdad que se arreglaron.
Esa corrección funcionó exactamente donde se aplicó: en el nivel de "todo el sistema vigilado deja de responder". Lo que no cubría era el nivel de abajo.
La misma trampa, un nivel más abajo
Esta semana apareció otra vez, pero más pequeña y más difícil de ver. Una comprobación concreta (la que revisa si un tipo de movimiento contable de un cliente cae en la cuenta correcta) empezó a contestar "no disponible" cada vez que el sistema de origen reconstruía su base de datos interna, algo que no tiene nada que ver con que hubiera un problema real. El vigilante leyó esa falta de respuesta exactamente igual que la vez anterior: como si el problema ya no existiera. Lo cerraba, mandaba un correo de "resuelto", y en cuanto volvían los datos, lo reabría con un correo de "nuevo problema".
El resultado, en número: más de 20 parejas de correos falsos de "nuevo" y "resuelto" sobre el mismo problema real, en solo 5 días, sin que nada hubiera cambiado de verdad en el sistema vigilado. La regla que ya se había aprendido (la ausencia de dato no es una buena noticia) seguía siendo cierta. Solo que nadie la había aplicado también a esta comprobación concreta, porque vivía en una pieza distinta del código, un nivel más pequeño que el que se arregló la primera vez.
El arreglo, esta vez, fue el mismo principio aplicado más abajo: cuando una comprobación concreta no se puede leer, sus problemas anteriores se mantienen abiertos, no se dan por resueltos. Y de paso se sumaron 2 pruebas automáticas nuevas a la suite existente, que ya llevaba 15 pruebas en verde antes de este episodio, para que la próxima vez que alguien toque esa pieza, un fallo así no vuelva a colarse en silencio.
Por qué "ya está arreglado" es una frase peligrosa
El error de fondo no es técnico, es de alcance. Cuando una regla nueva soluciona un problema real, es fácil dar por hecho que la regla "ya existe" en todo el sistema, cuando en realidad solo existe en el sitio donde se escribió. Un sistema de vigilancia con IA no suele ser una sola pieza: es una capa general que decide "todo el sistema responde o no", y por debajo, decenas de comprobaciones concretas, cada una con su propia forma de fallar y de callarse. Arreglar la capa general no arregla automáticamente cada comprobación de abajo, aunque comparta la misma trampa de fondo.
| Nivel | Qué vigilaba | Cómo falló | Cuándo se arregló |
|---|---|---|---|
| Sistema completo | Si el cliente entero deja de responder | Ausencia de respuesta leída como "resuelto" | Hace unas semanas |
| Una comprobación concreta | Si un tipo de movimiento contable cae en la cuenta correcta | La misma trampa, pero solo en esta pieza | Esta semana, 20+ parejas de avisos falsos después |
La regla de decisión
Cuando arregles un fallo sistémico en tu IA de vigilancia, pregúntate explícitamente si la misma causa puede repetirse en una pieza más pequeña y específica, no des por cerrado el tema al nivel donde lo viste la primera vez. No es una cuestión de si el equipo trabajó bien (la corrección original era correcta), es una cuestión de que un mismo patrón de fallo casi nunca vive en un solo sitio del código.
Checklist para auditar tu propio sistema de avisos con IA
- ¿La regla que arreglaste la última vez está aplicada solo donde apareció el bug, o en todos los sitios que comparten la misma lógica?
- ¿Alguna comprobación concreta puede quedarse "sin dato" por un motivo normal (un proceso de mantenimiento, una reconstrucción interna) que no sea un problema real?
- Si una comprobación no puede leer su estado, ¿los problemas ya abiertos se mantienen abiertos, o se cierran por defecto?
- ¿Tienes una prueba automática que reproduzca ese "no disponible" temporal, para cada comprobación crítica, no solo para el sistema en general?
- Cuando corriges un fallo, ¿alguien pregunta en voz alta "¿dónde más puede estar pasando esto"?
Por qué esto no es solo nuestra fontanería
Este patrón no depende de que tengas un vigilante de infraestructura. Aparece en cualquier sistema con capas: un ERP que valida pedidos a nivel general y también línea a línea, un CRM que marca clientes en riesgo por cuenta y también por producto, una IA que audita facturas por proveedor y también por cada línea de detalle. Si arreglas el error de raíz solo donde lo viste la primera vez, el mismo error puede seguir vivo en cada pieza más pequeña que use la misma lógica sin que nadie la haya revisado.
Es justo lo que aplicamos 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, y una regla de validación que funciona bien "a nivel de venta" no garantiza nada sobre cómo se comporta esa misma regla a nivel de línea de producto o de lote. Cada nivel se prueba por separado, precisamente porque un mismo fallo de fondo puede colarse en uno y no en el otro.
La pregunta que vale la pena hacerse
La próxima vez que alguien te diga "ya está arreglado" sobre un fallo de tu IA, la pregunta que de verdad importa no es "¿seguro?". Es "¿arreglado dónde exactamente, y qué otras piezas comparten esa misma lógica sin haberse revisado todavía?". Es la diferencia entre cerrar un ticket y cerrar de verdad un patrón de fallo.
En AutoBoost diseñamos los sistemas de IA que vigilan tus integraciones para que este tipo de trampa se pruebe en cada nivel, no solo en el más visible. Puedes ver cómo lo planteamos en nuestros servicios de IA aplicada al negocio. Si tu sistema de avisos lleva tiempo funcionando y quieres saber si el mismo patrón de fallo puede estar escondido un nivel más abajo, hablemos.
