Observabilidad de agentes IA: qué métricas mirar

La observabilidad de agentes de IA se sostiene sobre cinco señales: traza por decisión, coste por tarea completada, tasa de intervención humana, reintentos y desviación de comportamiento en el tiempo. Sin la traza por decisión las demás no son diagnosticables: se ve que algo empeoró, pero no dónde.

Este artículo desarrolla qué se instrumenta de verdad cuando un agente pasa de la demo a producción, en qué orden y con qué límites.

---

¿Qué es la observabilidad de un agente de IA?

Definición. Observabilidad es la capacidad de reconstruir, únicamente a partir de los datos que el sistema emite, por qué el sistema hizo lo que hizo, sin necesidad de volver a ejecutarlo y sin acceso a la máquina.

La diferencia con la monitorización clásica no es de grado, es de naturaleza:

Monitorización	Observabilidad de agentes
¿Responde el servicio?	¿Qué decidió el agente y con qué información?
¿Cuánto tarda?	¿Cuántas veces lo intentó antes de darlo por bueno?
¿Devuelve errores?	¿Cuántas de sus salidas correctas en forma eran erróneas en contenido?
¿Está caído?	¿Se comporta hoy como se comportaba hace un mes?

Un agente casi nunca falla con un error de servidor. Falla devolviendo una respuesta bien formada, entregada a tiempo, con código de estado correcto — y equivocada. Ese es el modo de fallo que el instrumental heredado de los servicios web no ve.

¿Por qué las métricas de un servicio web se quedan cortas?

Latencia, tasa de errores y disponibilidad siguen siendo necesarias: un agente también se cae. Pero describen el transporte, no el juicio. Tres huecos concretos:

• El éxito no es binario. Una respuesta puede ser parcialmente correcta, o correcta pero fuera de política. No hay código de estado para eso.
• El coste es variable por ejecución. Dos peticiones idénticas pueden costar muy distinto según cuántas herramientas invoque el agente y cuántas veces reintente.
• El sistema cambia sin que nadie despliegue nada. El proveedor actualiza el modelo, el contexto recuperado cambia porque cambió el corpus, y el comportamiento se mueve sin un solo commit.

Ese tercer punto convierte la observabilidad en requisito de gobernanza, no solo de ingeniería: la cláusula 9 de ISO/IEC 42001 exige seguimiento y medición del desempeño del sistema de gestión de IA, como desarrollamos en ISO 42001: qué exige de verdad a quien usa IA.

---

Señal 1: traza por decisión

Es la base. Sin ella, las otras cuatro señales avisan de que algo va mal pero no permiten averiguar qué.

Una traza por decisión registra cada paso del agente como un tramo (span) anidado, no la ejecución completa como una caja negra. Los campos mínimos:

Campo	Por qué es imprescindible
Identificador de ejecución y de paso	Permite reconstruir el árbol completo de decisiones
Modelo y versión exacta	Sin la versión, un cambio de comportamiento es indiagnosticable
Entrada efectiva del paso	No el prompt de plantilla: el texto realmente enviado, con el contexto ya inyectado
Herramienta invocada y argumentos	La mayoría de los fallos graves están aquí, no en la generación de texto
Resultado de la herramienta	Incluido el error, si lo hubo
Política o guardarraíl aplicado y su veredicto	Distingue «no lo hizo» de «se le impidió hacerlo»
Identidad del actor	Agente o persona, con el rol con el que actuó
Instante y consumo	Marca temporal y unidades consumidas por paso

Para no inventar un esquema propio conviene apoyarse en las convenciones semánticas de OpenTelemetry, cuyo capítulo de IA generativa vive hoy en un repositorio dedicado con tramos, métricas y eventos específicos para clientes de modelos y para agentes. Adoptar una convención existente evita el escenario habitual: tres equipos con tres nomenclaturas y ninguna correlación posible entre ellas.

Advertencia de privacidad. La traza es la superficie de datos personales más grande que crea un sistema de IA, porque guarda entradas y salidas literales. Se diseña con minimización, redacción de campos sensibles y retención acotada desde el primer día, no después del primer incidente. Es tratamiento de datos como cualquier otro.

Señal 2: coste por tarea completada

El coste por token es una métrica de factura, no de decisión. La métrica que sirve para decidir si una automatización compensa es el coste por tarea completada con éxito, y en ella entran cuatro sumandos que casi nadie reparte:

1. Consumo del modelo en la ejecución que salió bien.
2. Consumo de las ejecuciones que se reintentaron o se abandonaron por el camino.
3. Coste de las herramientas externas invocadas, incluidas las de pago por llamada.
4. Tiempo humano de revisión y corrección, valorado.

Repartir los sumandos 2 y 4 es lo que cambia la conversación. Un agente barato por token puede ser caro por tarea si reintenta mucho o si obliga al revisor a rehacer buena parte de sus salidas; y al revés, un modelo más caro que reduce la corrección humana puede salir mejor.

Conviene además separar el coste por tipo de tarea: la media agregada esconde qué familia de casos consume desproporcionadamente y probablemente no debería estar automatizada todavía.

Señal 3: tasa de intervención humana

Aquí está el aporte que casi ningún panel de observabilidad trae de serie.

Definición. Tasa de intervención humana es la proporción de ejecuciones de un agente en las que una persona corrige, rechaza, completa o bloquea la salida antes de que produzca efecto.

No es una métrica de calidad del modelo. Es una métrica de gobernanza, y se lee en dos direcciones opuestas:

Lectura	Qué significa	Qué hacer
Tasa alta y sostenida	El agente no está ahorrando trabajo: lo está desplazando al revisor	Reducir alcance de la tarea o retirar el agente de ese flujo
Tasa que sube de forma progresiva	Degradación: cambió el modelo, el contexto o la naturaleza de las entradas	Investigar con la traza; comparar contra el conjunto de referencia
Tasa que cae hacia cero	Señal de alarma, no de éxito	Auditar si la revisión sigue siendo real o se ha vuelto un clic
Tasa cero desde el principio	O la tarea era trivial, o nadie está revisando nada	Verificar que el punto de aprobación existe de verdad

El cuarto escenario es el peligroso y el más frecuente. Una revisión que aprueba todo lo que le llega no es supervisión: es una firma que traslada la responsabilidad a una persona sin darle capacidad real de decidir. En cumplimiento es peor que no tener revisión, porque genera evidencia de un control que no opera.

Por eso en nuestro propio sistema de gestión de IA el indicador declarado no es «cuántos borradores aprueba el humano», sino la proporción de borradores generados por agente que son rechazados en la revisión, junto con el tiempo transcurrido entre borrador y decisión. Un tiempo de decisión que se desploma hacia cero es tan sospechoso como una tasa de rechazo nula. El detalle del alcance y de los controles está publicado en nuestro centro de confianza.

Para que esta métrica sea creíble, la arquitectura tiene que hacer imposible el atajo. Si un agente puede ejecutar la acción irreversible por sí mismo, la tasa de intervención mide una costumbre, no un control. Si la operación irreversible sencillamente no está expuesta al agente, mide un hecho. Esa es la diferencia entre una política escrita y un control implantado; cómo se diseña ese punto de corte está en agentes de IA con supervisión humana y es el criterio de nuestra práctica de automatización.

Señal 4: reintentos

Los reintentos son el coste invisible. Hay que separarlos por causa, porque significan cosas distintas:

• Reintento de infraestructura. Tiempo de espera agotado, límite de peticiones, error transitorio del proveedor. Es ruido operativo, se resuelve con política de reintento y cortacircuitos.
• Reintento semántico. El agente no valida su propia salida y vuelve a intentarlo. Esto no es ruido: es la métrica más honesta de que la tarea está mal definida o el contexto es insuficiente.
• Reintento en bucle. El agente alterna entre dos estados sin converger. Sin límite de pasos por ejecución, consume presupuesto hasta que alguien lo ve en la factura.

Un límite duro de pasos por ejecución, con alerta cuando se alcanza, cuesta una tarde de trabajo y evita la sorpresa en el cierre del mes.

Señal 5: desviación de comportamiento

Definición. Desviación es el cambio de comportamiento del sistema a lo largo del tiempo sin cambio deliberado en su código.

Tiene tres orígenes habituales, y conviene poder distinguirlos:

Origen	Cómo se detecta
Cambio de versión del modelo del proveedor	Registrando la versión exacta en cada traza y correlacionándola con la métrica de rechazo
Cambio en el contexto recuperado	Vigilando la composición de las fuentes que entran en el contexto, no solo la salida
Cambio en la naturaleza de las entradas	Comparando la distribución de las peticiones de este mes con la del periodo de validación

La detección exige algo que rara vez existe: un conjunto de referencia congelado. Un puñado de casos representativos con salida esperada, que se ejecuta con periodicidad fija y cuyo resultado se compara siempre contra la misma vara. Sin ese conjunto, «el agente funciona peor» es una impresión de pasillo. Con él, es un dato con fecha.

---

Tabla resumen: qué mirar y qué revela

Métrica	Qué revela	Señal de alarma
Traza por decisión	Reconstrucción del razonamiento y de las herramientas usadas	Pasos sin versión de modelo o sin argumentos registrados
Coste por tarea completada	Si la automatización compensa de verdad	Divergencia creciente entre coste por token y coste por tarea
Tasa de intervención humana	Si la supervisión es real y si el agente degrada	Caída hacia cero, o subida sostenida
Reintentos por causa	Definición deficiente de la tarea o contexto insuficiente	Predominio del reintento semántico sobre el de infraestructura
Desviación de comportamiento	Cambios no deliberados del sistema	Variación frente al conjunto de referencia sin despliegue asociado

---

¿Qué se instrumenta primero si hoy no hay nada?

Orden recomendado, de mayor a menor retorno por esfuerzo:

1. Identificador de ejecución propagado de extremo a extremo. Sin correlación no hay investigación posible. Es el primer paso y el más barato.
2. Registro de versión de modelo y de herramienta en cada paso. Convierte cualquier incidente futuro en diagnosticable.
3. Marca explícita de la decisión humana. Quién, cuándo, qué veredicto. Es la materia prima de la tasa de intervención y, a la vez, la evidencia de auditoría.
4. Límite de pasos y de presupuesto por ejecución. Contención antes que optimización.
5. Conjunto de referencia congelado y ejecución periódica. Es lo que permite hablar de deriva con datos.

Los cuatro primeros son instrumentación. El quinto es disciplina, y es el que más se abandona.

¿Qué no resuelve la observabilidad?

Conviene decirlo con claridad, porque se vende lo contrario:

• No evita los fallos. Los hace reconstruibles. Un sistema observable sigue equivocándose; la diferencia es que se sabe por qué.
• No sustituye a los controles de seguridad. La inyección de instrucciones, el abuso de herramientas y la exfiltración por contexto exigen controles propios. El proyecto OWASP para aplicaciones con modelos de lenguaje mantiene el catálogo de referencia de esos riesgos.
• No sustituye a la gestión de riesgos. Marcos como el AI Risk Management Framework del NIST sitúan la medición como una de sus funciones, no como el conjunto.
• No garantiza el cumplimiento por sí sola. Aporta la evidencia; el sistema de gestión aporta la estructura. Cómo encajan uno en otro está en nuestra práctica de compliance.

Ningún sistema es seguro de forma absoluta ni deja de equivocarse por estar bien instrumentado. Lo que cambia es que el error deja de ser un misterio y pasa a ser un hallazgo con fecha, causa y responsable.

---

Qué hacer ahora

1. Elige el agente con más ejecuciones y responde por escrito: si mañana entrega una salida claramente errónea, ¿podrías reconstruir por qué sin volver a ejecutarlo? Si la respuesta es no, ahí está el trabajo.
2. Añade identificador de ejecución y versión de modelo a cada paso antes de tocar ninguna otra cosa.
3. Empieza a registrar la decisión humana como evento, con veredicto e instante. Es la métrica que nadie tiene y la que primero te van a pedir en una auditoría.
4. Congela un conjunto de referencia de casos representativos y ponlo a correr con periodicidad fija.
5. Revisa qué operaciones irreversibles están al alcance del agente. Si alguna lo está, el problema no es de observabilidad: es de diseño.

Si quieres una revisión de la instrumentación y de los puntos de aprobación de tus agentes, con el detalle de qué evidencia estás generando hoy y cuál te falta, escríbenos desde contacto.