El problema no es lo que ves, es lo que no ves.
Un dashboard verde que muestra "200 OK" no garantiza que tu agente de IA esté haciendo lo correcto. Es la paradoja más frustrante de la ingeniería de LLMs en producción: la respuesta HTTP es perfecta, pero el contenido es incorrecto, irrelevante o directamente peligroso. Esta brecha entre "funciona" y "funciona bien" es donde mueren los proyectos de IA.
MLflow tracing llega como respuesta a este problema, pero no como una solución mágica. La trazabilidad de MLflow permite registrar cada span —cada paso intermedio— dentro de una cadena de ejecución de un agente. No solo el prompt final y la respuesta del modelo, sino cada herramienta invocada, cada llamada a API, cada decisión de routing. Esto transforma la observabilidad de un ejercicio de fe a un proceso auditable.
¿Por qué importa? Porque en un entorno de notebook, donde todo se ejecuta secuencialmente y con datos controlados, los errores son evidentes. En producción, con múltiples agentes interactuando, herramientas externas fallando silenciosamente y usuarios haciendo inputs inesperados, el fallo se disfraza de éxito. El HTTP 200 es una mentira cómoda.
Los LLM judges añaden otra capa crítica: la evaluación automatizada de calidad. En lugar de depender de revisión manual, un judge —un modelo más grande o especializado— evalúa si la respuesta cumple criterios predefinidos: corrección factual, tono, seguridad, relevancia. Pero aquí está la trampa: el judge necesita estar calibrado. Un judge mal configurado puede validar respuestas incorrectas con alta confianza, creando una falsa sensación de seguridad.
Las cuatro decisiones de configuración que separan un prototipo de un sistema en producción son, en esencia, decisiones de arquitectura de confianza:
Primero, el nivel de granularidad del tracing. Registrar solo el input-output del modelo no basta. Hay que capturar cada span intermedio: llamadas a herramientas, pasos de razonamiento, revisiones de contexto. Sin esto, depurar es imposible.
Segundo, el criterio de evaluación del LLM judge. Definir qué significa "correcto" para tu caso de uso específico. Un juicio genérico no sirve para un dominio especializado como salud o finanzas.
Tercero, el umbral de confianza y los mecanismos de fallback. ¿Qué hace el sistema cuando el judge detecta una respuesta dudosa? ¿Reintenta? ¿Pasa a revisión humana? ¿Devuelve un error controlado? Sin esta decisión explícita, el sistema toma decisiones aleatorias ante la incertidumbre.
Cuarto, el almacenamiento y análisis retrospectivo. Los traces no son solo para debugging en tiempo real. Son el combustible para mejoras iterativas: identificar patrones de fallo, entrenar con datos difíciles, ajustar prompts basándose en evidencia real de uso.
La diferencia fundamental entre una demo de notebook y un sistema en producción no es tecnológica, es de rigor ingenieril. MLflow tracing, spans y LLM judges son herramientas, pero su valor depende de cómo se integren en un pipeline que asuma la fallabilidad como propiedad inherente de los sistemas de IA generativa.
Las empresas que están logrando desplegar agentes de IA de manera confiable no tienen modelos más grandes. Tienen mejor observabilidad. Y eso empieza por aceptar que un 200 OK no significa que todo está bien — significa que la solicitud llegó. Lo que importa es lo que pasó después.
