Descubrí que una única métrica de la puerta de seguridad ocultó una caída de servicio de todo un día en una función de explicaciones generadas por IA. Al tratar el "rechazo de la puerta" y el "fallo de carga del modelo" como lo mismo, la métrica dio una falsa sensación de buen funcionamiento. Registró cuatro rechazos y cero éxitos, pero el modelo nunca se ejecutó durante ese periodo; un error que podría haber dejado a los operadores ciegos ante un sistema averiado.
Cómo ocurrió la confusión
La funcionalidad utiliza un modelo de lenguaje local para convertir la lógica bruta de la máquina en frases legibles para humanos. Una puerta de seguridad (safety gate) aguas abajo bloquea cualquier salida que viole reglas predefinidas. En producción, expuse un único contador que se incrementaba cada vez que la puerta rechazaba una frase. Cuando el dron registró cuatro explicaciones de IA, el contador reportó cuatro rechazos y ninguna salida exitosa. Interpreté eso como que la puerta estaba haciendo su trabajo, no como que la funcionalidad estuviera caída.
Lo que el contador ocultaba era un fallo en dos etapas:
- El modelo no se está ejecutando – El modelo comparte una máquina con el resto del sistema. Para ahorrar memoria, el host lo descarga tras un periodo de inactividad.
- Tiempo de espera agotado al recargar – Cuando apareció una nueva amenaza, el sistema intentó recargar aproximadamente dos gigabytes de datos del modelo. La recarga superó el tiempo de espera de respuesta de treinta segundos, por lo que la solicitud expiró y devolvió una respuesta vacía.
Debido a que el contador trataba un rechazo de la puerta y una respuesta vacía inducida por un tiempo de espera como el mismo evento, el panel de control mostraba una "puerta de seguridad funcionando" mientras la función de IA estaba, en efecto, muerta.
Por qué es importante
En productos impulsados por IA, las puertas de seguridad detienen salidas dañinas o sin sentido. Los operadores vigilan la tasa de activación de la puerta como una señal de salud. Cuando esa señal se mezcla con modos de fallo no relacionados, la métrica se convierte en una mentira silenciosa: tranquiliza mientras el servicio no está disponible.
La solución que restauró la visibilidad
Realicé tres cambios prácticos:
- Mantener el modelo residente – Ajusté el host para que retenga el modelo en memoria, eliminando el retraso de la recarga.
- Ampliar el tiempo de espera – Aumenté la ventana de respuesta para manejar cargas lentas ocasionales.
- Dividir el contador – Reemplacé la métrica única de "rechazado por la puerta" con cuatro contadores distintos: aceptado, rechazado, respuesta vacía y sin respuesta.
El tercer paso resultó decisivo. En lugar de un único número que podía interpretarse de ambas formas, el desglose en cuatro partes muestra si la puerta de seguridad está activa, si el modelo está respondiendo o si la solicitud ni siquiera llegó al modelo.
Trade-offs and counter-arguments
Qué vigilar a continuación
Los desarrolladores que implementen componentes de IA deberían auditar cualquier contador agregado que mezcle comprobaciones de seguridad con fallos a nivel de sistema. Construir un registro de historial detallado que registre la ruta de cada solicitud —inicio de carga del modelo, evaluación de la puerta, resultado final— proporciona los datos forenses necesarios para detectar problemas ocultos.
Lección aprendida: Una única métrica de "rechazo de la puerta" puede ocultar un servicio de IA caído; dividir esa métrica en sus eventos constitutivos revela la verdad y evita la falsa confianza en un sistema que en realidad no está funcionando.