Observabilidad de los agentes de IA: una guía práctica para las huellas, métricas y revisiones

Observabilidad de los agentes de IAes la capacidad de reconstruir lo que un agente intentó, qué herramientas y datos usó, qué regresó cada paso, cuánto costó la ejecución y si el resultado final fue aceptable. Un panel que muestra sólo latencia y errores no es suficiente. El comportamiento de los agentes es variable, por lo que los equipos también necesitan rastros, evaluaciones, resultados comerciales y un camino de revisión para contenido sensible.

Investigación y transparencia: Esta guía reflejaTrabajo de observabilidad de agentes de OpenTelemetryConvenciones semánticas de OpenTelemetry, y el Marco de gestión de riesgos de la IA del NIST, revisado el 4 de septiembre de 2026. El modelo operativo siguiente es un marco editorial original, no un índice de rendimiento de Ottermind.

¿Qué observabilidad debe responder el agente

Un sistema útil debe responder a seis preguntas sin pedir a un ingeniero que reconstruya la carrera a partir de registros no relacionados:

1. ¿Qué objetivo, instrucciones, modelo y entradas comenzaron la carrera?
2. ¿Qué modelos de llamadas, extracciones, herramientas y aprobaciones se produjeron?
3. ¿Qué recibió y regresó cada paso?
4. ¿Dónde volvió a intentar, se detuvo, se ramificó o falló?
5. ¿El resultado cumplió un umbral de calidad específico de la tarea?
6. ¿Puede un revisor reproducir la evidencia sin exponer datos restringidos?

El seguimiento tradicional de las aplicaciones sigue siendo importante. La disponibilidad, la latencia y las tasas de error le indican si el servicio funciona. La observabilidad del agente agrega el contexto de nivel de tarea necesario para saber si el servicio hizo el trabajo correcto.

El modelo de observabilidad de cuatro capas

No desplome estas capas en una sola puntuación. Una carrera rápida puede producir un mal informe. Un informe fundamentado puede llegar demasiado tarde. Un producto aceptado puede exponer datos que nunca deberían haber entrado en pista.

Un esquema mínimo de eventos

Comience con un contrato de evento pequeño que cada agente y herramienta puede emitir:

{
  "run_id": "run_123",
  "step_id": "step_07",
  "parent_step_id": "step_03",
  "operation": "tool.call",
  "tool": "document_search",
  "started_at": "2026-09-04T09:00:00Z",
  "duration_ms": 842,
  "status": "ok",
  "input_classification": "confidential",
  "content_recorded": false,
  "tokens": 0,
  "cost_usd": 0,
  "evaluation_refs": ["eval_19"]
}

Las ejecuciones estables y los identificadores de los padres hacen que la secuencia sea reconstruible. Registran versiones para las instrucciones, modelos, herramientas y políticas para que una regresión pueda estar vinculada a un cambio. Mantenga las instrucciones y salidas en bruto opcionales: los metadatos suelen ser suficientes para el análisis operativo, mientras que la captura de contenido crea obligaciones de privacidad y retención.

Mantenga cuatro identificadores distintos

• workflow_idNombrar el producto o proceso comercial duradero.
• workflow_versionIdentifica la configuración probada de las instrucciones, herramientas, modelos y reglas.
• run_idconecta cada paso en una ejecución.
• thread_idenlaces relacionados se ejecutan en una conversación o tarea más larga.

No reutilice un ID de usuario como un hilo o ID de ejecución. Mantenga la identidad en un campo controlado por separado y utilice referencias pseudónimas cuando el análisis no requiera una identificación directa. Sólo adjunta el artefacto o el documento de identificación de los registros comerciales cuando la política lo permita.

Añadir versiones de implementación, entorno, experimento y conjunto de fuentes. Estas dimensiones responden a si un fracaso comenzó después de una liberación, afecta a una cohorte o depende de una colección de conocimientos obsoletos.

Metricas que revelan el comportamiento del agente

Seguir un conjunto compacto antes de agregar docenas de gráficos:

• tasas de finalización y abandono por tipo de tarea;
• la latencia media y de cola para la ejecución y cada herramienta;
• las tasas de fallas de las herramientas, retas y retrocesos;
• los pasos, los tokens y el coste por resultado aceptado;
• la base o la cobertura de citas cuando sea importante la evidencia;
• tiempo de corrección humana y razones de rechazo;
• bloqueo de políticas, solicitudes de aprobación y denegación de permisos.

Segmentar las métricas por versión del flujo de trabajo y tarea representativa. Los promedios agregados pueden ocultar que un tipo de documento o una integración de herramientas fallan repetidamente.

Sigue una carrera de meta a resultado

Consideremos que un agente de investigación se le pidió que preparara un informe de competencia de diez fuentes aprobadas. El documento final contiene el precio incorrecto para un competidor. Un rastro útil debe permitir al revisor retroceder a través de la carrera:

1. El registro de resultados muestra que el informe fue rechazado y etiqueta el error de fijación de precios.
2. El período de síntesis final identifica la línea de precios extraída que proporcionó la frase.
3. El lapso de recuperación muestra que un artículo de ayuda archivado se ubicó por encima de la página de precios actual.
4. Los metadatos de origen no muestran ningún campo de fecha efectiva ni ninguna regla que prefiera las páginas oficiales actuales.
5. La versión del flujo de trabajo muestra que un cambio reciente de recuperación eliminó un filtro de fecha.

La acción correctiva no es simplemente "usar un modelo mejor". Restablezca la regla de prioridad de origen, añada la ejecución rechazada a un conjunto de evaluación, prueba otras afirmaciones sensibles al tiempo y monitoree la recuperación de páginas archivadas. La observabilidad crea valor cuando conecta un defecto visible a un cambio que puede ser probado.

Sin un rastro vinculado, el equipo puede editar el precio único, retomar la tarea o modificar el aviso sin saber si el fallo de recuperación subyacente sigue existiendo.

El diseño abarca decisiones

Un rastro se vuelve ilegible cuando cada función auxiliar es un espacio y incompleto cuando toda la carrera es un espacio. Unidades de trabajo significativas de instrumentos:

• la toma de objetivos y la clasificación de las políticas;
• la creación de un plan o la selección de una ruta;
• cada invocación modelo;
• cada consulta de recuperación y conjunto de fuentes devueltas;
• cada llamada y resultado de las herramientas externas;
• estado o memoria de lectura y escritura;
• retroceder, retroceder y detener las decisiones;
• solicitudes y respuestas de aprobación por parte de los seres humanos;
• la creación y validación de artefactos;
• entrega final y resultado del usuario.

Utilice las relaciones padre-hijo para el trabajo anidado y los enlaces para tareas asincronas que comparten una causa pero no una pila de llamadas directas. Dar a cada período un nombre de operación estable. Coloque valores variables como el nombre de la herramienta, la versión del flujo de trabajo y la clase de documento en los atributos para que puedan ser filtrados sin crear miles de nombres métricos.

Registra el contexto suficiente, no el razonamiento oculto

El objetivo es capturar las entradas observables, las salidas, las decisiones y las transiciones de estado. No dependas de la cadena privada de pensamiento o de un razonamiento interno verbal. Un campo de ruta como selected_tool=document_search, más las alternativas permitidas y el resultado de la herramienta, es más útil y gobernable que una transcripción de razonamiento sin restricciones.

Para una decisión fallida, registre la política o evaluador que debería haberla regido, las pruebas disponibles en ese momento y la acción resultante. Esto admite el depuración sin convertir cada rastro en una narrativa sensible.

Construir evaluaciones a partir de modos de fallas reales

Las métricas genéricas como la fluidez y la utilidad rara vez son suficientes. Definir las dimensiones de evaluación del contrato de flujo de trabajo.

Para el informe de investigación, las dimensiones útiles podrían incluir:

Utilice tres etapas de evaluación:

1. **Regresión previa a la liberación:**casos fijos ejecutados antes de que una versión del flujo de trabajo se envíe.
2. **Muestreo de producción:**un porcentaje definido de las carreras reales recibe una revisión automática o humana.
3. **Promoción de los fracasos:**Las carreras rechazadas, corregidas o inusuales se convierten en casos de regresión etiquetados.

Mantenga las instrucciones de evaluación, los modelos de clasificación, las rubricas y los conjuntos de datos versionados. Cuando el juez cambie, no compares sus puntuaciones con una línea de base antigua como si la medición se mantuviera constante.

Definir los objetivos de servicio del flujo de trabajo

El tiempo de actividad de la aplicación no describe si un agente termina un trabajo útil. Añadir indicadores de servicio de nivel de tarea:

• porcentaje de carreras elegibles que produzcan un artefacto;
• porcentaje aceptado sin corrección material;
• el tiempo que transcurre desde la solicitud hasta el resultado listo para la revisión;
• porcentaje aumentado a la propiedad correcta;
• el coste máximo de un resultado aceptado;
• la citación o la cobertura de pruebas para trabajos respaldados por fuentes;
• tasa de finalización conforme a las políticas.

Crear objetivos por clase de flujo de trabajo. Un memorándum de investigación de cinco minutos y una respuesta de apoyo de diez segundos no deben compartir un objetivo de latencia. Excluir entradas inválidas sólo a través de una regla documentada, o los equipos pueden hacer que la fiabilidad se vea mejor reclasificando fallos difíciles.

Alerta sobre los síntomas que la gente puede actuar sobre

Evite llamar a alguien por cada puntuación de evaluación baja. Las alertas deben identificar una respuesta operativa limitada.

Utilice paneles de control para ver las tendencias, boletos para detectar defectos y páginas para incidentes urgentes. Si cada fluctuación de evaluación despierta a un operador, la fatiga de alerta ocultará el evento que realmente necesita intervención.

Elegir una estrategia de muestreo

La captura completa de metadatos puede ser lo suficientemente económica para cada ejecución, mientras que la retención completa de contenido y la evaluación basada en modelos no lo son. Combinar las reglas de muestreo:

• muestreo aleatorioestima la calidad normal sin seleccionar únicamente fallos dramáticos;
• muestreo de riesgorevisa más las operaciones derivadas de los flujos de trabajo consecuentes;
• muestreo de eventosconserva errores, bloqueos de políticas, costosos bucles y rechazos de los usuarios;
• muestreo de cambioaumenta la cobertura después de la liberación de un modelo, una solicitud, una extracción o una herramienta;
• muestreo de segmentosgarantizará la aparición de lenguajes raros, tipos de documentos, roles de usuarios y casos de borde;
• muestreo consistente en las huellasmantiene la carrera completa en varios pasos en lugar de las extensiones desconectadas.

Documenta el denominador. Si un panel muestra una tasa de aprobación del 95% de las carreras completadas con éxito, el trabajo abandonado y bloqueado ha desaparecido de la medición.

Revise la muestra para detectar puntos ciegos. Una regla que sólo mantiene carreras lentas o fallidas no puede estimar la calidad diaria, mientras que la simple muestreo aleatorio puede perder raros incidentes de alto impacto. Preservar los incidentes confirmados independientemente del muestreo rutinario en virtud de la política de registros correspondiente.

Conciliar la telemetría con la retroalimentación del usuario

Conecte el rechazo explícito, corrección, retoma, escalada, boleto de apoyo y señales de artefacto aceptadas a la carrera. No deduzcas satisfacción de que un usuario termine la conversación; puede que lo haya abandonado.

Crear razones estructuradas de retroalimentación como fuente equivocada, falta de requerimiento, información obsoleta, acción insegura, formato deficiente, demasiado lento o demasiado caro. Mantenga texto libre opcional para el contexto, pero evite que cada análisis dependa de la lectura manual.

Cuando la retroalimentación contradice un evaluador automatizado, inspeccione el caso. El usuario puede estar equivocado, el evaluador puede ser mal especificado, o el flujo de trabajo puede optimizar una rúbrica técnica que no coincide con el resultado real. Estos desacuerdos son valiosos casos de evaluación.

Hacer una revisión de incidentes de agentes

La revisión de los incidentes debe ser impecable y rastreable:

Impacto del usuario y las carreras afectadas:
Tiempo de detección y señal:
Flujo de trabajo, respuesta rápida, modelo, herramienta y versiones de políticas:
El comportamiento esperado:
Secuencia observada:
Fuente, estado o permiso involucrado:
Por qué las evaluaciones existentes no lo han alcanzado:
Contención inmediata:
Cambios correctivos y propietario:
Los casos de regresión se añaden:
Seguimiento de los cambios:
Fecha de seguimiento:

Separar el error de desencadenamiento de los contribuyentes sistémicos. Un modelo puede emitir un argumento inválido, pero el contrato de herramientas también puede aceptarlo, el bucle de retoma puede repetirlo y la evaluación puede ignorar los resultados de la herramienta. Sólo arreglar el primer fallo visible deja el sistema frágil.

Desarrollar observabilidad en cuatro etapas

Etapa 1: Reconstruir una sola carrera

Instrumento un flujo de trabajo limitado de extremo a extremo. Confirme que un ingeniero y un revisor de dominio pueden explicar de forma independiente una carrera fallida desde el rastro.

Etapa 2: Conecta la calidad

Anexar validaciones deterministas, etiquetas de revisores y resultados aceptados o rechazados. Construir un pequeño conjunto de regresión de fallos observados.

Etapa 3: Operar en volumen de producción

Definir muestras, retención, redacción, tablas de control y alertas que se pueden actuar. Medir el coste de la telemetría y verificar que el seguimiento no expone datos restringidos.

Etapa 4: Mejorar sistemáticamente

Utilice grupos de fallos para priorizar los cambios, comparar versiones en conjuntos de datos fijos y confirmar el efecto en la producción. Revise las métricas obsoletas y elimine la telemetría que ya no impulsa una decisión.

Template de revisión semanal

Flujo de trabajo y versión:
Resultados esperados para el usuario:
Las carreras representativas exitosas:
Las ejecuciones de los representantes fallidas o corregidas:
Modo de falla máxima:
Cambios desde la revisión anterior:
La latencia y el cambio de costes:
El cambio de evaluación:
Incidentes de privacidad o de permiso:
Un experimento para la próxima semana:
Propietario y fecha de revisión:

Las fallas de muestras, no sólo promedios. Revise al menos una carrera limpia, una cara, un resultado rechazado y una que requirió intervención humana. Ese conjunto expone el comportamiento que un panel de estado verde no tiene.

Fronteras de privacidad y seguridad

Los datos de observabilidad pueden contener instrucciones, nombres de archivos, pasajes recuperados, argumentos de herramientas, credenciales, datos personales y decisiones comerciales. Clasifica como datos de producción. Redireccionar los secretos antes de la exportación, separar el contenido de los metadatos, restringir el acceso, definir la retención y registrar quién inspeccionó rastros sensibles.

Crear al menos tres modos de captura. Un modo de metadatos registrará el tiempo, el estado, las versiones, las clasificaciones y los hashes. Un modo editado retiene contenido limitado después de filtrar automáticamente. El modo de diagnóstico restringido captura el contenido aprobado durante un corto período con acceso designado. El flujo de trabajo, no un desarrollador individual, debe seleccionar el modo de clasificación de datos.

La redacción de pruebas antes de que la telemetría salga del proceso. Un ajuste de backend no puede proteger un secreto que ya se transmitió. También compruebe los datos derivados: los títulos de documentos, los argumentos de herramientas, las incorporaciones, los mensajes de error y las explicaciones del evaluador pueden revelar contenido sensible incluso cuando se elimina el prompt principal.

Una lista de verificación de vencimiento

[ ] Cada ejecución de producción tiene flujo de trabajo estable y identificadores de versiones.
[ ] Los pasos de modelo, recuperación, herramienta, estado, aprobación y artefacto están conectados.
[ ] La captura de contenido sensible sigue una regla documentada de clasificación.
[ ] Los resultados aceptados, corregidos, rechazados y abandonados se unen a los rastros.
[ ] Las evaluaciones reflejan el contrato de tareas y son versionadas.
[ ] Las ejecuciones de producción fallidas pueden ser promovidas en conjuntos de datos de regresión.
[ ] Las alertas tienen un propietario y una respuesta definida.
[ ] Se han probado la retención, el acceso, la exportación y la eliminación.
[ ] El coste incluye el almacenamiento y la evaluación de telemetría, no sólo los tokens de modelo.
[ ] Un revisor de dominio puede reconstruir un resultado sin ayuda de ingeniería.

Para un modelo de amenaza más amplio, utilice el Lista de verificación de seguridad de agentes de IA Para los límites de los componentes y los contratos de orquestación, véase el Guía de arquitectura de agentes de IA

Las preguntas frecuentes

¿Cuál es la diferencia entre el monitoreo de agentes de IA y la observabilidad?

Los informes de monitoreo de señales conocidas como fallos, latencia y costo. La observabilidad proporciona suficiente evidencia conectada para investigar el comportamiento que no predijo, incluyendo opciones de herramientas, retemplazos, contexto, evaluaciones y correcciones humanas.

¿Deberíamos almacenar cada respuesta y solicitud?

No. Almacenar el mínimo de datos necesarios para los fines operativos y de auditoría. Preferir metadatos y hashes cuando sea posible, redactar secretos, limitar la captura de contenido por clasificación de tareas y establecer un período de retención.

¿Con qué métrica debería comenzar un nuevo equipo?

Comience con la tasa de finalización y el tiempo de corrección aceptados para un flujo de trabajo limitado. Añadir costos, latencia y métricas de modo de falla alrededor de ese resultado.

¿La observabilidad reemplaza la evaluación fuera de línea?

No. Pruebas de evaluación fuera de línea de casos conocidos antes de su liberación. La observabilidad de la producción muestra cómo se comportan las entradas, herramientas y usuarios reales después de la liberación. Los equipos confiables usan ambos.

¿Cuánto tráfico de producción debe ser tomado en muestra?

No hay porcentaje universal. Recoger metadatos de bajo riesgo en términos generales, luego elegir el contenido y la muestreo de evaluación en función del volumen, el riesgo, el costo y la frecuencia de fallas. Siempre retenga incidentes confirmados bajo la política aprobada.

¿Cuánto tiempo debe conservarse el rastro?

Los conservarán solo mientras lo requiera el propósito de depuración, evaluación, auditoría o contrato. Utilice períodos más cortos para el contenido en bruto, períodos más largos para las métricas agregadas y retenciones documentadas para incidentes confirmados.

¿Quién debería revisar las huellas del agente?

Los ingenieros revisan las fallas de ejecución e integración; los propietarios de dominios revisan la calidad de la tarea; los equipos de seguridad y privacidad revisan los incidentes relevantes. El acceso basado en el papel debe evitar la navegación amplia de contenidos sensibles.

¿Puede la observabilidad mejorar las instrucciones por sí sola?

Proporciona pruebas, no una solución automática. Utilice grupos de fallas para proponer un cambio, probarlo en casos versionados y confirmar que las ganancias no crean regresiones en otros lugares.

¿Cuál es el primer tablero de control?

Para un flujo de trabajo, muestre las ejecuciones elegibles, la finalización aceptada, las razones de rechazo, el tiempo de corrección, la latencia, el costo, la escalación y la versión actual del flujo de trabajo. Enlazar cada agregado a las carreras inspectables.

¿Es suficiente la retroalimentación de los usuarios para medir la calidad?

No. La retroalimentación es valiosa pero incompleta y auto-selectable. Combínalo con validaciones de tareas, muestreo representativo, revisión de dominio y resultados observados.

¿Deberían mantenerse siempre las carreras fallidas?

Mantener las pruebas necesarias para investigar y cumplir con las políticas, pero seguir aplicando reglas de minimización de datos, acceso y retención. Una falla no justifica automáticamente el almacenamiento indefinido de contenido sensible.

Usa Ottermind para ejecutar un flujo de trabajo delimitado y respaldado por fuentes, revisar el artefacto resultante y registrar las correcciones que formarán tu primer conjunto de evaluación.