Observabilidad de automatizaciones con IA: qué registrar cuando el paso no es determinista

Un flujo con un paso de IA puede devolver HTTP 200 en todas y cada una de sus ejecuciones durante una semana mientras clasifica mal, en silencio, una de cada ocho entradas. Tu disponibilidad es perfecta. Tu automatización está rota. Ninguna monitorización convencional te lo va a decir, porque no ha fallado nada.

Ese hueco es lo que tiene que cerrar la observabilidad de las automatizaciones con IA, y necesita una instrumentación distinta de la del resto de tu stack.

El registro que hay que escribir en cada ejecución

Una fila por ejecución, en una tabla que puedas consultar con SQL. No una línea de log: una fila, porque vas a querer agregarla.

Captura: identificador de ejecución, flujo y versión, identificador de la entrada (no necesariamente la entrada), un hash de la plantilla de prompt, el modelo y su versión exacta, tokens de entrada y de salida, latencia, el coste calculado a partir de esos tokens, la decisión o salida en forma estructurada, y el resultado: completado automáticamente, enviado a una persona o fallido.

Los dos campos que la gente omite y luego necesita son el hash del prompt y la versión fijada del modelo. Sin ellos, «la calidad bajó hace tres semanas» es una pregunta sin respuesta, y te la van a hacer.

Los tres cuadros de mando

Volumen y mezcla de resultados. Ejecuciones por día, partidas por resultado. La línea que importa es la proporción que va a revisión humana. Es tu métrica de calidad, está disponible desde el primer día, no exige esfuerzo de etiquetado y es directamente proporcional al coste: mira lo que cuesta una automatización por ejecución. Una deriva en ese ratio es la señal más temprana que vas a tener de que ha cambiado algo: el modelo, las entradas o un sistema de arriba.

Distribuciones de coste y latencia, no medias. La media de tokens esconde la entrada patológica que gasta cuarenta veces la mediana. Dibuja p50, p95 y máximo. El p95 es donde debería estar tu tiempo límite, y el máximo suele ser un bug.

Tasa de corrección. Donde una persona revisa o edita la salida del agente, registra si la cambió y, si puedes capturarlo barato, por qué la cambió. Es la única verdad de referencia que obtienes gratis, y se acumula hasta formar un conjunto de evaluación sin que nadie haya tenido que construirlo.

Muestreo para medir calidad de verdad

Los cuadros de mando te dicen que algo se ha movido. No te dicen si la salida es correcta, porque en las ejecuciones automáticas no miró nadie.

Muestrea. Saca veinte ejecuciones automáticas a la semana al azar, que una persona las puntúe contra el criterio que aplicarías tú, y anota el resultado en la misma tabla. Veinte a la semana son dos horas al mes y producen algo que ningún cuadro de mando puede: una precisión medida con una fecha al lado, de modo que cuando alguien pregunte si la automatización está empeorando respondas con una tendencia en vez de con una impresión.

Sesga la muestra hacia los casos de baja confianza si tu paso emite una confianza, pero guarda una parte uniformemente aleatoria, porque una muestra sacada solo de problemas sospechados no puede medir la tasa base.

Alerta sobre ratios, no sobre errores

Las alertas que importan aquí son estadísticas:

• Tasa de excepciones por encima de su media móvil más de un umbral, sobre una ventana lo bastante larga para significar algo: un ratio diario, no horario, o te despertará el ruido.
• Coste por ejecución subiendo: normalmente es que un prompt se alargó, una fuente empezó a mandar más, o apareció un bucle de reintentos.
• Distribución de salidas desplazándose: si un clasificador que normalmente devuelve 60/30/10 empieza a devolver 20/20/60, ha cambiado algo aunque todas las ejecuciones terminaran bien. Esta única comprobación caza cambios de modelo, cambios de formato aguas arriba y regresiones de prompt, y son unas quince líneas de SQL.
• Cero ejecuciones cuando debería haberlas. La parada silenciosa es la caída que nadie instrumenta.

Trazas cuando hay un bucle

Para un paso de una sola llamada, la fila basta. Para un agente que llama herramientas en bucle quieres la secuencia: cada llamada, sus argumentos, el tamaño del resultado y la razón declarada del modelo. OpenTelemetry sirve para esto y hay herramientas específicas de LLM que dibujan una cascada más agradable, pero el listón es bajo: la primera vez que depures un bucle que dio once vueltas lo construirás igualmente.

Qué hacer esta semana

Añade la tabla de ejecuciones a tu automatización con IA de más volumen si no existe. Luego escribe una consulta: resultados agrupados por día en los últimos treinta días. Casi todos los equipos que ejecutan esa consulta por primera vez encuentran algo: un escalón en una fecha que coincide con un despliegue, o una deriva lenta que nadie había notado.