Un banco de pruebas de nuestra IA de vigilancia decía "todo en verde" desde hacía tiempo, y era mentira a medias: solo ejecutaba 6 de las 13 pruebas que existían. Las otras 7 estaban escritas, guardadas en el repositorio, y no se habían corrido ni una sola vez. Nadie lo vio hasta que se revisó el propio mecanismo que decide qué se prueba. Contamos qué pasó y la regla que sacamos, porque el mismo hueco puede estar hoy en cualquier sistema (con IA o sin ella) que dependa de una lista mantenida a mano.
El problema: el semáforo miraba menos de lo que decía mirar
El sistema en cuestión es el que vigila la salud de varias integraciones de facturación para un grupo de clientes: comprueba que los documentos llegan, que se procesan y que los importes cuadran. Como cualquier pieza que toma decisiones sola, tiene su propio banco de pruebas automáticas para asegurarse de que sigue haciendo bien su trabajo cada vez que se cambia algo.
El proceso que ejecuta ese banco llamaba a cada prueba por su nombre, apuntado a mano en una lista dentro del propio código. Funcionaba perfecto el día que se escribió esa lista. El problema apareció después, cada vez que alguien añadía una prueba nueva (para cubrir un caso que había fallado, por ejemplo) y se olvidaba de sumarla a esa lista, o daba por hecho que el sistema la recogería sola.
No la recogía. El banco de pruebas seguía ejecutando exactamente las mismas 6 que llevaba ejecutando desde el principio, marcando el resultado como verde, mientras las 7 pruebas nuevas dormían en el repositorio sin correr nunca. Y un verde que no cambia se lee como "esto sigue cubierto", no como "esto lleva tiempo sin revisarse de verdad".
Por qué "verde" y "cubierto" no son lo mismo
Aquí está el error de fondo, y vale para cualquier negocio con algún tipo de comprobación automática (una IA, un script, un informe programado):
| Lo que parece que significa el verde | Lo que de verdad significa |
|---|---|
| "Todo lo que hay que comprobar está bien" | "Todo lo que se ejecutó salió bien" |
| "El sistema sabe si algo nuevo se rompe" | "El sistema sabe si algo de lo que ya probaba se rompe" |
| "Si añado una regla, queda cubierta sola" | "Si añado una regla y no la conecto, no existe para el banco de pruebas" |
La trampa es que un banco de pruebas que falla grita: sale en rojo, alguien lo mira. Un banco de pruebas que no llega a ejecutar algo no grita nada, porque desde su propio punto de vista no ha pasado nada raro: ha hecho las 6 pruebas que tenía en su lista, y las 6 han salido bien. El fallo no está en ninguna prueba: está en el mecanismo que decide cuáles existen.
La regla de decisión
Si te llevas una sola idea de este post, que sea esta: un sistema de comprobación que depende de una lista mantenida a mano tiene, por diseño, una fecha de caducidad silenciosa. Funciona perfecto el primer día y se queda corto un poco más cada vez que el sistema real que vigila crece, hasta que alguien lo audita y descubre cuánto se había quedado atrás.
La solución no es "acordarse mejor" de actualizar la lista. Eso ya se intentó sin decirlo (nadie decidió dejar 7 pruebas sin correr; simplemente se fue quedando así) y volverá a pasar. La solución es que el propio mecanismo descubra solo qué pruebas existen, en vez de depender de que un humano lo apunte en un sitio aparte. Aplicado aquí: se cambió el proceso para que recorra el código y encuentre cada prueba nueva automáticamente, así que ahora una prueba escrita y una prueba ejecutada son, por construcción, la misma cosa.
Cómo lo comprobamos, no solo cómo lo arreglamos
Arreglar el mecanismo no es lo mismo que saber que funciona. Antes de dar el cambio por bueno, hicimos dos cosas:
- Contamos cuántas pruebas corrían antes y después del cambio (6 y 13), en vez de fiarnos de que "ya debería ser más". Un número es lo único que no se puede discutir.
- Escribimos una prueba nueva a propósito y comprobamos que aparecía sola en el siguiente ciclo, sin tocar ninguna lista. Si el propio mecanismo que se acaba de arreglar no pasa esta comprobación, no está arreglado, solo parece arreglado.
Checklist: audita tu propio "verde"
Esto no es solo un problema de IA ni de departamentos técnicos. Cualquier negocio que confía en que "algo se revisa solo" (un informe automático, un cuadro de mando, un checklist de calidad, una IA que vigila procesos) puede tener el mismo hueco. Antes de dar por bueno cualquier verde:
- ¿Sabes cuántas comprobaciones existen hoy en el sistema, o solo sabes que "hay comprobaciones"? Si no puedes poner un número, no puedes saber si el número bajó.
- ¿El sistema descubre solo lo que tiene que revisar, o depende de una lista que alguien mantiene a mano? Toda lista a mano tiene fecha de caducidad.
- La última vez que alguien añadió una regla nueva, ¿comprobó que se ejecutaba de verdad, o asumió que sí?
- ¿Cuánto tiempo lleva el número de comprobaciones sin subir, aunque el sistema que vigila haya crecido? Un número congelado mientras el negocio crece es la misma señal que vimos aquí.
- Si alguien externo (un cliente, un auditor) preguntara "¿qué estáis comprobando exactamente?", ¿tendrías una respuesta con número, o una respuesta con "en general, todo"?
Por qué pesa más cuando el vigilante es una IA
Cuando la comprobación la hace una persona, un hueco así se nota antes: alguien revisa a ojo de vez en cuando y pregunta "¿esto también se comprueba?". Cuando la comprobación la hace un sistema con IA, ese ojo humano desaparece por diseño, que es justo lo que hace valiosa a la IA el resto del tiempo. La contrapartida es que si el propio mecanismo que decide qué vigila la IA tiene un hueco, nadie lo va a notar por casualidad: hay que auditarlo a propósito, como hicimos aquí.
Es el mismo principio que aplicamos en la plataforma de datos con IA para un grupo de farmacias, donde antes de dejar que la IA decida sobre más de un millón de líneas, hay que poder demostrar, con número, qué parte de ese dato se está comprobando de verdad. Y es el mismo cuidado que ponemos en las facturas que se contabilizan solas de un grupo veterinario: no basta con que el proceso funcione, hace falta poder probar que sigue funcionando cada vez que algo cambia.
La lección para cualquier pyme
No hace falta un equipo de ingeniería para aplicar esto, hace falta una sola pregunta incómoda: de todo lo que crees que tu sistema (con IA o sin ella) revisa por ti, ¿cuánto de verdad se está revisando hoy, y cuánto lleva tiempo apuntado en una lista que nadie ha vuelto a mirar? La diferencia entre las dos respuestas es exactamente donde vivían nuestras 7 pruebas.
Si tienes procesos automáticos o agentes de IA en tu negocio y no tienes del todo claro qué parte de lo que "deberían" comprobar están comprobando de verdad, hablemos. En AutoBoost construimos software e IA a medida integrados en tu sistema real, con la comprobación de que siguen funcionando incluida desde el primer día. Contáctanos y lo revisamos juntos.
