Observabilidad en IA: cómo monitorizar LLMs y agentes en producción

Share

En el post anterior vimos cómo integrar modelos de IA en una arquitectura de microservicios. Ahora toca el problema que aparece al día siguiente del despliegue: no sabes qué está haciendo el modelo, cuánto cuesta ni cuándo está fallando.

Un LLM puede devolver un 200 OK con una respuesta inventada. Ningún dashboard clásico lo detecta. Por eso la observabilidad de la IA no es una variante de la monitorización tradicional: mide cosas distintas. En este artículo vas a ver qué medir, cómo instrumentarlo con OpenTelemetry y qué herramientas elegir.

Respuesta corta: la observabilidad de la IA es la capacidad de entender el comportamiento interno de un sistema con modelos (prompts, contexto, llamadas a herramientas, tokens, coste y calidad de la respuesta) a partir de la telemetría que emite. Se implementa con trazas distribuidas, métricas y evaluaciones continuas.

infografia-observabilidad-200-ok.svg Un 200 OK no significa que la respuesta sea correcta.

¿Qué es la observabilidad de la IA y en qué se diferencia de la clásica?

La observabilidad clásica responde a "¿está funcionando?". La de IA responde también a "¿está respondiendo bien y a qué precio?".

Aspecto Observabilidad clásica Observabilidad de IA
Comportamiento Determinista Probabilístico: la misma entrada puede dar salidas distintas
Qué es un "error" Excepción, 5xx, timeout Respuesta incorrecta con éxito técnico (alucinación, tono, fuga de datos)
Unidad de coste CPU, memoria, peticiones Tokens de entrada y de salida
Qué se traza Petición entre servicios Prompt, contexto recuperado, llamadas a herramientas, razonamiento del agente
Control de calidad SLO de latencia y disponibilidad Evaluaciones (evals), feedback de usuario, LLM-as-judge

Las dos son necesarias. La de IA se apoya en la clásica: sigues necesitando latencia, errores y saturación.

Qué medir en un sistema con LLMs

Latencia, tokens y coste por petición

Es lo primero que debes registrar porque es lo más barato de obtener. Mide como mínimo:

  • Latencia total y tiempo hasta el primer token (si usas streaming).
  • Tokens de entrada y de salida por llamada.
  • Coste estimado por petición, por usuario y por funcionalidad.
  • Tasa de reintentos y errores del proveedor.

Un agente que encadena diez llamadas multiplica el coste sin que cambie ni una línea de tu API. Sin trazas, ese gasto es invisible.

Calidad y alucinaciones

Aquí está la diferencia real. Necesitas una señal de calidad que no dependa de un código HTTP:

  • Evals offline sobre un conjunto de casos de referencia antes de cada despliegue.
  • Evals online que puntúan una muestra del tráfico real (relevancia, fidelidad al contexto, toxicidad).
  • LLM-as-judge con una rúbrica explícita, validado contra muestras revisadas por humanos.
  • Feedback del usuario (pulgar arriba/abajo, reformulaciones, abandonos).

Trazas de agentes y llamadas a herramientas

En un agente, el fallo casi nunca está en la última llamada. Traza cada paso: la decisión del modelo, la herramienta invocada, sus argumentos, su resultado y el siguiente paso. Así reconstruyes por qué el agente hizo lo que hizo.

Seguridad y privacidad

  • Detecta intentos de prompt injection y salidas que contengan datos sensibles.
  • No guardes el contenido de los prompts por defecto. Regístralo solo cuando lo necesites y enmascara datos personales, algo clave bajo el RGPD.

OpenTelemetry y microservicios: la base común

OpenTelemetry (OTel) es el estándar para trazas, métricas y logs, y ya define convenciones específicas para IA generativa (gen_ai.*). Su gran ventaja en una arquitectura de microservicios es que la traza viaja con la petición: el servicio de API, el de recuperación de contexto y la llamada al modelo quedan en una sola traza distribuida.

Hay un matiz importante que muchos artículos omiten: las convenciones GenAI siguen en estado "Development", no estables. Los nombres de atributos pueden cambiar. Además, en junio de 2026 (versión 1.42.0 de las convenciones semánticas) se movieron a un repositorio propio, semantic-conventions-genai. Las instrumentaciones existentes no deben cambiar lo que emiten por defecto: para activar la versión más reciente hay que optar explícitamente con la variable OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental.

Ejemplo mínimo en Python con atributos gen_ai.*:

from opentelemetry import trace
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter

provider = TracerProvider(
    resource=Resource.create({"service.name": "asistente-soporte"})
)
provider.add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter(endpoint="http://localhost:4318/v1/traces"))
)
trace.set_tracer_provider(provider)
tracer = trace.get_tracer("xevi.eu.llm")


def preguntar(cliente, modelo: str, mensajes: list[dict]) -> str:
    # Convención: "{operación} {modelo}"
    with tracer.start_as_current_span(f"chat {modelo}") as span:
        span.set_attribute("gen_ai.operation.name", "chat")
        span.set_attribute("gen_ai.provider.name", "openai")
        span.set_attribute("gen_ai.request.model", modelo)
        try:
            r = cliente.chat.completions.create(model=modelo, messages=mensajes)
            span.set_attribute("gen_ai.response.id", r.id)
            span.set_attribute("gen_ai.response.model", r.model)
            span.set_attribute("gen_ai.usage.input_tokens", r.usage.prompt_tokens)
            span.set_attribute("gen_ai.usage.output_tokens", r.usage.completion_tokens)
            return r.choices[0].message.content
        except Exception as exc:
            span.set_attribute("error.type", type(exc).__name__)
            span.record_exception(exc)
            raise

Si añades la instrumentación HTTP de tu framework, el encabezado traceparent (W3C Trace Context) se propaga solo a los demás microservicios y el span del modelo cuelga de la misma traza.

traza-distribuida-opentelemetry.svg Traza distribuida: API → servicio de contexto → LLM → herramienta.

Comparativa de herramientas de observabilidad LLM

No hay una herramienta ganadora: depende de si priorizas self-hosting, licencia, integración con tu stack o evaluación. Datos a octubre de 2026; los precios cambian a menudo, así que confirma siempre en la web oficial.

Herramienta Licencia Self-hosting Precio de referencia Encaja si…
Langfuse MIT (carpetas ee/ con licencia comercial) Sí, gratis Cloud: Hobby gratis, Core 29 $, Pro 199 $, Enterprise 2.499 $/mes Quieres control de datos y coste predecible
LangSmith Propietaria Solo como complemento Enterprise (Kubernetes) Plus: 39 $/usuario/mes; 2,50 $ por 1.000 trazas base (retención 14 días) Ya usas LangChain/LangGraph
Arize Phoenix Elastic License 2.0 (código disponible, no OSI) Sí, sin coste de licencia Gratis; SSO/RBAC solo en Arize AX (de pago) Priorizas evaluación y OpenTelemetry
Datadog (antes LLM Observability, ahora Agent Observability) Propietaria No (SaaS) Nuevo modelo de precios desde mayo de 2026 Ya usas Datadog para APM e infraestructura
OpenLLMetry Apache 2.0 Es una librería, no un backend Gratis Quieres instrumentar con OTel y elegir backend después

Tres notas para decidir con criterio:

  1. Langfuse pasó a formar parte de ClickHouse en enero de 2026, que declaró que no cambiaría precios, licencia ni self-hosting. Aun así, en self-hosting, funciones como SCIM o auditoría requieren clave Enterprise.
  2. Datadog soporta de forma nativa las convenciones GenAI de OTel. Cuidado: por defecto procesa los atributos gen_ai.* reconocidos, lo que puede generar cargos de LLM Observability que no esperabas. Filtra los atributos en el Collector si no los quieres.
  3. OpenLLMetry (de Traceloop, adquirida por ServiceNow) y OpenInference (de Arize) son capas de instrumentación: te evitan el lock-in porque emiten telemetría estándar.

Checklist mínimo para empezar

  1. Instrumenta con OTel desde el primer día, aunque el backend sea provisional.
  2. Registra tokens y coste en cada llamada al modelo.
  3. Propaga el contexto de traza entre todos los microservicios.
  4. Define 20-50 casos de evaluación y ejecútalos en cada despliegue.
  5. Enmascara datos personales antes de guardar prompts y respuestas.
  6. Fija alertas de coste por usuario y de caída de calidad, no solo de latencia.

Preguntas frecuentes

¿Qué es la observabilidad en LLMs?

Es el conjunto de trazas, métricas y evaluaciones que permiten entender qué hace un modelo de lenguaje en producción: qué recibe, qué responde, cuánto tarda, cuánto cuesta y si la respuesta es correcta.

¿Son estables las convenciones OpenTelemetry para IA generativa?

No. A octubre de 2026 siguen en estado "Development". Úsalas, pero fija versiones y revisa los cambios.

¿Qué herramienta de observabilidad LLM es gratuita?

Langfuse (MIT) y Arize Phoenix (Elastic License 2.0) se pueden alojar por tu cuenta sin coste de licencia. OpenLLMetry es gratuito, pero solo instrumenta.

¿Puedo usar mi herramienta de APM actual?

Sí, si acepta OTLP y atributos gen_ai.*. Perderás parte de la evaluación y la gestión de prompts que ofrecen las plataformas especializadas.

Conclusión

La observabilidad de la IA añade tres preguntas a la monitorización clásica: qué hizo el modelo, cuánto costó y si lo hizo bien. La base técnica ya existe (OpenTelemetry y sus convenciones GenAI), con la salvedad de que aún no son estables. Instrumenta pronto, mide tokens y calidad, y elige backend según licencia, self-hosting y el stack que ya tienes.

¿Y ahora qué?

  • Cuéntame en los comentarios qué herramienta usas y qué te ha fallado.
  • Comparte este artículo con tu equipo de plataforma.
  • Lee el post anterior sobre IA y microservicios y no te pierdas el siguiente: evaluación continua y control de costes en IA.

Fuentes (datos a 18/10/2026)