HTTP 200 no es garantía: los fallos silenciosos de la IA

Un agente de IA corrió 47 veces la semana pasada. Las 47 devolvieron HTTP 200, con latencia por debajo de 2 segundos, cero excepciones y ningún error en los logs. ¿El detalle? Las 47 ejecuciones no produjeron absolutamente nada. La infraestructura vio éxito, el negocio vio silencio, y ninguna alerta se disparó. Ese es el problema: HTTP 200 no es garantía de que tu agente haya hecho su trabajo.

El fallo silencioso en agentes de IA es cuando el sistema reporta éxito técnico (HTTP 200, sin errores) mientras el valor de negocio cae a cero. El código de estado HTTP 200 indica que el request llegó, se procesó y se devolvió correctamente en la capa de transporte, pero no dice nada sobre si el modelo de lenguaje generó una respuesta válida. Es la clase de error más peligrosa porque no dispara ninguna alerta.

¿Qué significa HTTP 200 cuando un agente de IA no produce nada?

Pongámoslo simple. Si alguna vez armaste un pipeline con una API de LLM, sabés que lo primero que chequeás es el código de respuesta. ¿Vino 200? Listo, sigue todo para adelante. El problema es que ahí estás confiando en la señal equivocada.

El HTTP 200 te dice una sola cosa: el request se aceptó, se procesó y se devolvió sin romperse. La infraestructura funcionó perfecto. Pero HTTP 200 no es garantía de que dentro de esa respuesta haya algo. Según el análisis de OpsVeritas en dev.to, ese es exactamente el escenario donde un agente corrió 47 veces, devolvió éxito las 47, y generó cero salida útil. La infra estaba toda verde. El cliente no se enteró durante días.

¿Por qué duele tanto este tipo de error? Porque el dashboard muestra todo en orden, nadie recibe un aviso, y el que consume el producto tarda semanas en darse cuenta de que algo viene fallando.

Las tres formas de fallo silencioso que no disparan alertas

Lo interesante es que hay tres maneras distintas de que un agente “falle con éxito”. Las tres devuelven HTTP 200 y las tres se ven idénticas desde afuera. Te puede servir nuestra cobertura en tus pipelines de integración continua.

Forma 1: el respondedor vacío (Empty Responder)

El agente llama al LLM, recibe una respuesta y sigue como si nada. Pero choices.message.content está vacío. No hay error, no hay excepción, el pipeline continúa como si todo hubiera salido bien. Ponele que el siguiente paso toma ese string vacío y lo guarda en base, lo manda por mail o lo muestra en pantalla. Vos ni te enteraste.

Forma 2: el filtro de seguridad trabado (Stuck Safety Filter)

El modelo dispara una clasificación interna de seguridad y, en vez de devolverte un rechazo explícito, te devuelve una respuesta vacía. No es un error 4xx ni un mensaje de “no puedo responder esto”. Es silencio puro. Y el silencio, para tu código, es indistinguible de una respuesta válida si no lo estás validando.

Forma 3: el drenaje de tokens (Token Drain)

Este es el que te pega en el bolsillo. Los prompt tokens suben, o sea que estás mandando (y pagando) cada request completo, pero los output tokens se quedan en cero. Estás pagando por generar nada. Y como el request técnicamente “funcionó”, el 200 sigue apareciendo limpio en tu log.

¿Por qué el monitoreo tradicional no detecta estos fallos?

Acá está el nudo del asunto. La mayoría de los equipos monitorea lo que la API reporta: código de estado, latencia, excepciones en los logs. Todo eso vive en la capa de transporte.

El problema es que ninguna de esas métricas mira qué produjo el agente. Podés tener un P99 de latencia hermoso, un uptime de 99.9% y cero errores en el log, mientras el agente devuelve strings vacíos en cada corrida. La infraestructura te dice “verde”, el negocio está en rojo, y como nadie configuró una métrica que cruce ese puente, el problema vive en la sombra. Subís el modelo, lo probás en local, anda bárbaro, lo mandás a producción, el filtro de seguridad se traba con datos reales que en tu test nunca aparecieron, y de repente estás sirviendo silencio a escala sin que un solo panel te lo avise. Al elegir tu herramienta CI/CD profundizamos sobre esto.

La “observabilidad” tradicional, esa que heredamos de monitorear APIs REST comunes, no fue pensada para sistemas donde el request puede salir perfecto y el contenido puede estar vacío.

¿Cómo validar que un agente de IA realmente produce valor?

La idea de fondo es separar dos preguntas que solemos mezclar: “¿el request tuvo éxito?” y “¿la lógica de negocio tuvo éxito?”. Son cosas distintas y necesitás validar las dos.

• Chequeá que el contenido no esté vacío: validá que choices.message.content tenga algo antes de pasar la respuesta al siguiente paso del pipeline.
• Confirmá que se generaron tokens de salida: si output_tokens = 0, el modelo no produjo nada, sin importar que el HTTP haya sido 200.
• Validá contra el schema esperado: si esperabas un JSON con tres campos y llegó otra cosa (o nada), tratalo como fallo, no como éxito.
• Logueá a nivel aplicación, no solo de infra: registrá qué produjo el agente, no solo que la request terminó bien.

La diferencia práctica es tratar la salida del agente como un dato que hay que verificar, no como algo que se da por hecho porque el transporte anduvo.

¿Qué alertas y métricas deberías monitorear en agentes de producción?

Más allá del 200, estas son las señales que sí te avisan cuando algo se rompió en serio. La tabla resume qué mirar, qué umbral usar de referencia y contra cuál de las tres formas de fallo te protege.

Métrica	Qué detecta	Umbral de referencia
Empty response rate	Respondedor vacío y filtro de seguridad trabado	Racha de requests consecutivos sin contenido, dispará alerta
Output token consumption	Drenaje de tokens	output_tokens = 0 mientras suben los prompt_tokens
Prompt-to-output ratio	Costo generando nada	Ratio que se dispara sin salida útil
Schema validation failures	Salida fuera de formato	Cualquier respuesta que no matchea el schema
Safety filter triggers	Filtro de seguridad silencioso	Todo trigger, aunque no haya error explícito

El punto es armar métricas de producto, no solo de infraestructura. Si varios requests seguidos pasan sin generar output, eso es una alerta. Si los prompt tokens suben y el output es cero, eso es token drain y tenés que saberlo hoy, no cuando llega la factura. Complementá con la seguridad de tus despliegues.

Esto vale para cualquier equipo que corra agentes de IA sobre su propia infraestructura. Si tenés tu stack en un VPS o en servidores propios, sumá estas validaciones a tu capa de monitoreo. Y si estás armando el proyecto desde cero y necesitás dónde alojarlo, en donweb.com tenés hosting y cloud en Argentina para montar el backend sin vueltas.

Si querés saber más sobre esto, mirá nuestro artículo de HTTP y garantías.

Errores comunes al monitorear agentes de IA

• Confiar solo en el código de estado: asumir que 200 = todo bien. Corregilo validando el contenido de la respuesta, no el transporte.
• No medir tokens de salida: ignorar output_tokens te deja ciego ante el drenaje de tokens. Agregá esa métrica a tu dashboard sí o sí.
• Tratar la respuesta vacía como respuesta válida: un string vacío que sigue por el pipeline contamina todo lo que viene después. Frená ahí y marcá el fallo.
• Alertar solo por excepciones: el fallo silencioso no lanza excepciones. Si tus alertas dependen de errores en el log, este tipo de error nunca te va a llegar.

Preguntas Frecuentes

¿Qué significa HTTP 200 en un agente de IA?

HTTP 200 significa que el request al modelo se aceptó, se procesó y se devolvió sin errores en la capa de transporte. No significa que el agente haya generado una respuesta válida ni útil. Un agente puede devolver 200 con el campo de contenido completamente vacío.

¿Por qué un agente devuelve HTTP 200 si no funcionó?

Porque el código HTTP mide el transporte, no el producto. La request técnicamente viajó y volvió bien, así que la API responde 200 aunque el LLM haya devuelto una respuesta vacía, se haya trabado en un filtro de seguridad o haya generado cero tokens de salida.

¿Cómo detectar fallos silenciosos en agentes de IA?

Validá que el contenido de la respuesta no esté vacío, que output_tokens sea mayor a cero y que la salida cumpla el schema esperado. Sumá alertas por empty response rate y por drenaje de tokens. El monitoreo de HTTP y latencia por sí solo nunca los detecta.

¿Cuál es la diferencia entre éxito de infraestructura y éxito de negocio?

El éxito de infraestructura es que la request se procesó sin errores (HTTP 200, baja latencia). El éxito de negocio es que el agente produjo el output que se esperaba de él. Un sistema puede tener el primero al 100% y el segundo en cero al mismo tiempo.

¿El drenaje de tokens tiene costo aunque no genere output?

Sí. En el drenaje de tokens los prompt tokens suben porque estás enviando el request completo, y eso se factura, mientras los output tokens quedan en cero. Pagás por cada prompt sin recibir nada a cambio, y el HTTP 200 oculta el problema.

Conclusión

El caso de las 47 corridas con 200 y salida vacía deja una lección clara: monitorear la capa de transporte no alcanza cuando el producto vive en el contenido de la respuesta. HTTP 200 no es garantía de que tu agente hizo algo útil, y confiar solo en él es lo que deja a un sistema sirviendo silencio durante días sin que salte una alerta.

¿Qué hacer con esto hoy? Sumá tres validaciones concretas a tu pipeline: contenido no vacío, output_tokens > 0 y schema correcto. Y armá alertas de producto (empty response rate, token drain) que corran en paralelo a las de infra. Es la diferencia entre enterarte del fallo en el momento o enterarte cuando te lo dice el cliente.

Fuentes

• HTTP 200 Is Not a Product Guarantee – OpsVeritas, dev.to (serie AI Agents in Production)