Una IA (o cualquier sistema automático) que vigila tus procesos puede engañarte sin inventar un solo dato, solo confundiendo dos cosas que no tienen nada que ver: "no puedo comprobarlo ahora mismo" y "ya está arreglado". Nos pasó hace poco en la infraestructura que sostiene una de nuestras plataformas, y el resultado fueron avisos falsos por partida doble, uno detrás de otro, hasta que lo detectamos y lo corregimos.
El problema: el silencio se interpretó como buena noticia
Tenemos un sistema que vigila varias piezas de infraestructura y avisa por email en cuanto detecta un problema. Hasta ahí, nada raro. El fallo estaba en cómo decidía que un problema ya no existía: en cuanto dejaba de recibir respuesta de la pieza vigilada, lo marcaba como resuelto. No comprobaba que estuviera bien, comprobaba que ya no le contestaba con un error, y trataba esa falta de respuesta como si fuera la mejor de las noticias.
El problema es que una pieza puede dejar de responder por motivos completamente normales, como un reinicio que corta la respuesta unos segundos. Eso es justo lo que pasaba:
- Al arrancar el reinicio, la pieza dejaba de contestar durante unos segundos.
- El vigilante interpretaba ese silencio como "el problema ya no está" y mandaba un email de resuelto.
- En el siguiente ciclo, cuando la pieza volvía a responder con normalidad, el vigilante veía un estado "nuevo" respecto al anterior y mandaba un segundo email, esta vez de "problema nuevo".
Dos correos falsos por cada reinicio real, sin que ninguna de las farmacias que dependen de esa plataforma hubiera tenido ningún problema de verdad. La misma pareja de avisos (3 problemas dados por resueltos y los mismos 3 reabiertos 20 minutos después) se repetía cada vez que el sistema vigilado se reiniciaba, que no es un evento raro: es mantenimiento normal.
La regla de decisión: la ausencia de dato no es una resolución
Aquí está la parte que sirve para cualquier negocio, tenga o no infraestructura técnica de por medio: cuando un sistema de vigilancia (con IA o sin ella) no puede comprobar el estado de algo, tiene tres respuestas posibles, no dos. No es "roto" o "arreglado". Es "roto", "arreglado" y "no lo sé ahora mismo", y la tercera nunca se puede tratar como si fuera la segunda.
| Situación | Respuesta mal diseñada | Respuesta bien diseñada |
|---|---|---|
| La pieza no contesta | Se marca como "resuelto" (ausencia = buena noticia) | Se mantiene el último estado conocido hasta poder comprobarlo |
| La pieza vuelve a contestar bien | Se marca como "problema nuevo" (porque cambió respecto al ciclo anterior) | Se compara contra el estado real, no contra el ciclo anterior, y si estaba bien no se avisa de nada |
| Un problema real sigue abierto pero no se puede leer su estado | Se cierra solo porque "no hay dato que diga que sigue roto" | Se queda abierto hasta que algo confirme, de verdad, que se arregló |
| El propio vigilante no responde | Silencio total, nadie se entera | Alarma aparte, porque un vigilante mudo es un punto ciego distinto (y ya lo contamos aquí) |
La regla corta: si no tienes dato, no tienes una respuesta, tienes una pregunta sin contestar. Cerrar un problema sin confirmación positiva de que se arregló es la misma familia de error que dar por bueno un dato que en realidad falta, solo que aquí el que se equivoca es el sistema de avisos, no el que analiza el negocio.
Por qué esto sale más caro cuanto más automatizas con IA
Un email falso de vez en cuando parece inofensivo. El problema real es lo que provoca con el tiempo: un canal de avisos que anuncia arreglos que no han ocurrido se deja de creer tan rápido como uno que grita de más, y es esa pérdida de confianza, no el ruido en sí, la que hace que la próxima alerta real se ignore. Es el mismo mecanismo que la fábula del pastor y el lobo, aplicado a una bandeja de entrada.
Esto pesa más en cuanto metes una IA que no solo avisa, sino que actúa a partir de ese estado: escala un incidente, prioriza qué revisar primero, o decide si merece la pena avisar a una persona a las 3 de la madrugada. Si la señal de entrada ("está roto" / "está bien") es poco fiable, cualquier decisión construida encima hereda ese mismo error, con la misma seguridad aparente que si el dato fuera perfecto. Es la misma lección que aplicamos en la plataforma de datos e IA de un grupo de farmacias: antes de dejar que un sistema recomiende compras o envíe pedidos reales al distribuidor, cada dato que entra tiene que estar validado, no asumido.
Cómo lo corregimos
El arreglo no fue añadir más avisos, fue quitarle a la falta de dato la capacidad de decidir nada por sí sola:
- Un estado desconocido ya no cierra nada. Si no se puede leer si una pieza sigue viva, los problemas ya abiertos se quedan abiertos hasta que algo confirme lo contrario.
- Se compara contra el estado real, no contra el ciclo anterior. Antes bastaba con que el estado cambiase respecto a la última lectura para disparar un aviso; ahora hace falta que cambie respecto a lo que de verdad está pasando.
- Se añadió una suite de tests que antes no existía, que cubre explícitamente los dos escenarios que fallaban: "la pieza deja de responder" y "la pieza vuelve a responder tras un corte breve". Así, si alguien vuelve a tocar este código dentro de un año, esos dos casos concretos no se pueden romper sin que algo lo avise antes de llegar a producción.
Checklist para tu propio sistema de avisos (con IA o sin ella)
Si tu negocio depende de un panel, un email automático o un agente de IA que te dice "todo va bien" o "esto está roto", antes de confiar en él, comprueba:
- ¿Distingue explícitamente entre "roto", "arreglado" y "no lo sé ahora mismo", o solo tiene dos estados?
- ¿Un problema se cierra solo porque dejó de dar señal, o hace falta una confirmación positiva de que se arregló?
- ¿Compara el estado actual contra la realidad, o contra la última lectura (que puede estar mal)?
- ¿Se ha probado alguna vez qué pasa cuando la pieza vigilada se reinicia o se corta unos segundos?
- ¿Cuántos avisos falsos harían falta para que dejaras de leer los correos de esa alarma?
Si la última pregunta te incomoda, ya tienes la respuesta a si merece la pena revisarlo ahora, antes de que la alarma que sí importa llegue el día que de verdad haga falta y nadie la mire.
Construir bien esta pieza (para infraestructura, para un ERP o para cualquier proceso con IA que actúa sola) es exactamente el tipo de trabajo que hacemos en AutoBoost: sistemas que no solo avisan, sino que avisan de lo que de verdad está pasando. 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.
