Un asistente lleva semanas en producción sin sobresaltos y un día alguien de finanzas pregunta por qué subió la factura del proveedor. La respuesta honesta, en la mayoría de las organizaciones, es que nadie lo sabe. El sistema guarda la pregunta del usuario y la respuesta final, y con eso no se reconstruye nada: no se puede distinguir si el aumento vino de más tráfico, de contextos que se hicieron más largos, de reintentos silenciosos o de un cambio de modelo que nadie anunció internamente.
La observabilidad de un sistema de IA no es un panel que se agrega después. Es lo que separa operar con criterio de operar por intuición, y se decide cuando se escribe la primera integración. Estas son las señales que consideramos mínimas, y una advertencia sobre lo que estás acumulando al registrarlas.
Qué medir
La traza de la cadena completa
Es la señal base, la que hace posibles a todas las demás. Una traza útil registra, para cada petición: la versión del prompt de sistema vigente, la entrada del usuario, los fragmentos recuperados y su origen, cada llamada a herramienta con sus parámetros y su resultado, la salida del modelo en cada paso intermedio y la acción ejecutada al final.
Con la pregunta y la respuesta se hace control de calidad. Solo con la cadena completa se investiga: es la diferencia entre saber que el agente borró un registro y saber qué texto, recuperado de qué documento, lo convenció de que debía borrarlo. Cuando llega el momento de responder a un incidente, esta es la evidencia que sirve, y no se puede reconstruir hacia atrás.
Costo por petición, atribuido a alguien
El total mensual del proveedor no es una métrica operable: es un número que provoca reuniones y no decisiones. Lo que sirve es el costo desagregado por tokens de entrada, de salida y de razonamiento cuando el modelo los cobra aparte, y atribuido a una dimensión que tenga dueño: caso de uso, equipo, cliente o endpoint. Sin atribución no hay conversación posible sobre eficiencia; con ella se descubre rápido si el gasto se concentra en unos pocos flujos y cuál de ellos crece sin control.
Latencia medida por tramos
La latencia total agregada esconde la causa. Conviene separar al menos cuatro tramos: la recuperación de contexto, el tiempo hasta el primer token, la generación completa y lo que consumen las herramientas externas. Un agente que llama a tres APIs pasa la mayor parte de su tiempo esperando, no generando; si solo mides el total, vas a intentar optimizar el modelo cuando el problema está en una consulta lenta a tu propia base de datos.
Mide percentiles, no promedios. Estas distribuciones tienen cola larga por construcción, y el promedio describe una experiencia que casi ningún usuario vive.
Tasa de rechazo
Qué proporción de peticiones termina en una negativa del modelo, y de qué tipo. Es una señal de doble filo que hay que leer con cuidado: una tasa que sube puede significar que los controles están funcionando frente a un uso indebido, o que el modelo se volvió más conservador tras una actualización y está bloqueando trabajo legítimo. Las dos cosas importan y se distinguen mirando qué categorías de petición se rechazan, no el número agregado.
El caso que más daño hace es el rechazo silencioso: el modelo no dice que no, entrega una evasiva genérica y el usuario la acepta. Ese no aparece en ningún contador salvo que lo clasifiques de forma explícita.
Deriva de comportamiento entre versiones
Tu proveedor puede cambiar el modelo por debajo sin que tú toques una línea de código. La única forma de enterarte es tener un conjunto fijo de entradas de referencia que se ejecute contra cada versión y compare resultados: cambios en el formato de salida, en la disposición a usar herramientas, en el tono, en qué considera aceptable responder. Es la puerta de entrada natural a una suite de evaluaciones versionada, y sin ella las regresiones se descubren cuando las reporta un cliente.
La instrumentación mínima
Nada de lo anterior exige comprar una plataforma. Con tres decisiones de ingeniería se cubre casi todo el terreno. Primero, un identificador de correlación que nazca en la petición y viaje por todos los componentes, incluidos los que no son el modelo. Segundo, un evento estructurado por cada paso —no texto libre en un log— con campos consistentes: identificador, paso, modelo y versión, tokens, latencia, herramienta invocada, resultado. Tercero, una política de muestreo: guardar todas las trazas de peticiones que ejecutaron acciones con efecto, y una muestra de las conversacionales.
Si tu organización ya usa un estándar de trazabilidad distribuida como OpenTelemetry, aprovéchalo: un paso del modelo encaja bien en la noción de span, y evitas construir un sistema paralelo que después nadie mantiene.
Lo que estás acumulando sin darte cuenta
Hay una consecuencia que rara vez se discute antes de activar el registro completo: esas trazas son, casi con certeza, el repositorio de datos personales más rico y menos gobernado de tu organización. Contienen lo que los usuarios escribieron con sus palabras, los documentos internos que el sistema recuperó, y a veces credenciales o datos de terceros que alguien pegó en un chat sin pensarlo.
El registro que necesitas para investigar un incidente es también el que puede convertirse en uno.
El tratamiento correcto es el mismo que darías a cualquier log sensible, y conviene definirlo antes de encender la instrumentación: retención acotada y justificada, cifrado en reposo, control de acceso por rol con registro de quién consultó qué, enmascaramiento de los campos que sabes identificar, y una respuesta preparada para cuando alguien ejerza su derecho de supresión sobre una conversación que quedó dentro de una traza.
La regla práctica con la que revisamos estos despliegues es simple: instrumenta primero la cadena completa, aunque el resto quede pendiente, porque es la única señal que no se puede recuperar después; y decide la política de retención en la misma reunión en que decides registrar. Un sistema de IA que no puedes explicar tampoco lo puedes defender, ni ante un auditor ni ante el equipo que tiene que arreglarlo de madrugada.