Supervisar un agente de IA: trazas, registros y alertas

Supervisar un agente de IA en producción consiste en relacionar sus acciones, errores, tiempos y gastos con el resultado que realmente obtiene. Los registros recogen los eventos, las trazas reconstruyen los pasos de una tarea y las métricas activan alertas cuando el servicio se deteriora. Una supervisión útil también comprueba la calidad de los resultados y los efectos de las acciones, sin registrar datos sensibles de forma innecesaria.

Partir del resultado de negocio, no del panel

Un agente puede responder sin errores técnicos y, aun así, cumplir mal su cometido. Una llamada al modelo termina correctamente, una herramienta acepta la solicitud y la respuesta final anuncia un resultado que el sistema de negocio no confirma. Una supervisión centrada únicamente en la disponibilidad de las API dejaría pasar este fallo.

Defina, por tanto, qué significa completar una tarea con éxito antes de elegir los gráficos. En un agente que gestiona solicitudes de soporte, puede ser una propuesta registrada correctamente y validada conforme a las reglas establecidas. En un agente documental, será una respuesta respaldada por fuentes accesibles y pertinentes.

Distinga entre varios desenlaces: tarea completada con éxito, fallo técnico, rechazo previsto, transferencia a una persona, abandono y resultado indeterminado. Un rechazo que respeta los permisos no constituye necesariamente una avería. Del mismo modo, un mensaje final que afirma haber terminado no demuestra que la tarea haya tenido éxito.

La observabilidad de los LLM permite explicar estos resultados a partir de las operaciones registradas. Complementa la guía para evaluar un agente de IA, que detalla cómo preparar los conjuntos de pruebas y los criterios de calidad.

Determine también quién utiliza cada información. El equipo de operaciones necesita detectar las tareas bloqueadas; la persona responsable del negocio debe conocer los resultados incompletos; quien se ocupa de la seguridad debe poder localizar una acción sensible. Un único panel con todos los datos disponibles rara vez responde bien a necesidades tan distintas.

Combinar registros, trazas, métricas y auditoría

Estas señales responden a preguntas diferentes. Conservarlas en una misma plataforma puede simplificar las búsquedas, pero sus funciones siguen siendo distintas.

Señal	Qué representa	Utilidad principal	Limitación
Registro	Un evento con fecha y contexto	Examinar un error o un cambio de estado	La secuencia de eventos puede seguir siendo ambigua
Traza	Las operaciones vinculadas a una ejecución	Localizar el paso responsable de una demora o un fallo	Una instrumentación incompleta deja puntos ciegos
Métrica	Una medida agregada a lo largo del tiempo	Detectar desviaciones y comparar periodos	Oculta los detalles de los casos individuales
Registro de auditoría	Una acción sensible y el contexto de su autorización	Establecer quién podía actuar y qué efecto se comprobó	Exige controles de acceso e integridad adecuados

En una traza, una operación delimitada se denomina span. Cuenta, entre otros elementos, con un inicio, un final y vínculos con otras operaciones. La documentación sobre trazas explica este modelo y las relaciones entre operaciones.

Utilice un identificador de ejecución para pasar de una señal a otra. Una alerta debe permitir abrir trazas representativas y, después, los registros asociados, sin tener que buscar manualmente una conversación completa.

Separe, no obstante, el identificador de negocio del identificador técnico. Una misma solicitud puede pasar por varios intentos, reanudaciones o procesos diferidos. Confundirlos distorsionaría las estadísticas y dificultaría la búsqueda de una acción ejecutada varias veces.

Instrumentar la tarea completa y cada acción relevante

Empiece con una operación que abarque toda la tarea y añada después operaciones para las llamadas al modelo, las búsquedas documentales, las validaciones y cada llamada a herramientas. El objetivo es reconstruir el recorrido y sus dependencias, sin convertir cada función interna en un evento.

Para cada ejecución, prevea como mínimo:

los identificadores de tarea, intento y traza;
el entorno y la revisión del despliegue;
la revisión de las instrucciones y de la configuración;
el modelo solicitado y, si está disponible, el modelo utilizado realmente;
las marcas de tiempo, el estado final y el motivo de finalización;
el consumo comunicado y las referencias a los efectos en el sistema de negocio.

En el caso de una herramienta, distinga entre la solicitud de acción, la comprobación de permisos, el envío de la petición y el resultado comprobado. Una escritura aceptada por una API puede requerir todavía una verificación en el sistema de destino.

Los atributos de GenAI documentados por OpenTelemetry ofrecen un vocabulario para describir modelos, consumo y operaciones, entre otros aspectos. Compruebe que su instrumentación los admite antes de crear paneles que dependan de campos concretos.

Preste especial atención a los límites entre componentes: colas, procesos separados, subagentes y servicios remotos. Transmita el contexto de correlación mediante un mecanismo controlado. Una reanudación puede generar una nueva traza, pero debe mantener un vínculo explícito con la tarea inicial.

No intente deducir un razonamiento interno a partir de los comentarios que genera el modelo. Los elementos verificables son las entradas autorizadas, las llamadas, los resultados y los efectos observados.

Medir disponibilidad, tiempos, costos y calidad

Organice los indicadores en torno a las necesidades operativas: comprobar si el servicio acepta solicitudes, si las termina a tiempo, si los resultados son correctos y si los recursos consumidos siguen dentro del presupuesto.

En cuanto a los tiempos, distinga la espera antes del procesamiento, la duración de la ejecución y el tiempo hasta obtener un resultado utilizable. Una respuesta inicial rápida puede ocultar una espera larga hasta que se realiza la acción esperada. Examine también los casos más lentos: la media por sí sola puede ocultar un deterioro concentrado en determinadas tareas.

Para medir la fiabilidad, haga seguimiento de los fallos definitivos, los reintentos, las tareas sin estado final y las dependencias no disponibles. Calcule cada tasa con un denominador explícito. Las tareas recibidas, iniciadas y terminadas no representan el mismo conjunto.

Para calcular los costos, sume las llamadas de todos los intentos, los servicios facturados por uso y las evaluaciones automatizadas. Calcule un costo por tarea terminada y otro por tarea completada con éxito. Un proceso barato por llamada puede resultar costoso si acumula reintentos.

Por último, distinga entre una medición de calidad y una simple señal:

una validación de esquema confirma la estructura;
una comprobación de negocio confirma un estado esperado;
una valoración humana juzga el resultado según una rúbrica;
un modelo evaluador genera una estimación que puede contener errores.

Conserve el método y su revisión junto con cada evaluación. Un cambio en la rúbrica puede modificar las puntuaciones sin que haya cambiado el comportamiento del agente.

Crear alertas que lleven a una acción

Una alerta útil identifica un problema, su impacto, una persona responsable y un procedimiento de respuesta. Una notificación que solo informa de un aumento del consumo, sin precisar qué parte del servicio afecta, deja todo el diagnóstico en manos de quien la recibe.

Las buenas prácticas de alertas recomiendan dar prioridad a los síntomas que afectan a los usuarios y evitar notificaciones ante las que no se puede actuar. En un agente, esto implica vigilar las tareas sin terminar, los resultados inválidos y las desviaciones del gasto, además de las excepciones técnicas.

Situación	Señal que debe observarse	Respuesta prevista
Acumulación de solicitudes	Antigüedad de las tareas en espera y tiempo total	Examinar la capacidad y limitar la entrada de nuevas solicitudes
Bucle sin avances	Acciones repetidas y ausencia de cambios útiles	Detener la tarea y conservar los elementos de diagnóstico
Gasto anormal	Consumo acumulado y ritmo de gasto	Aplicar un límite o suspender la parte afectada del servicio
Acción sensible inesperada	Falta de autorización o efecto incompatible	Bloquear las escrituras afectadas y abrir un incidente
Deterioro de los resultados	Fallos de negocio y evaluaciones coincidentes	Examinar el último cambio y reducir el alcance del despliegue

Fije los umbrales según los compromisos del servicio, sus patrones habituales y el riesgo aceptable. Un mismo plazo no sirve para una conversación interactiva y para un procesamiento documental diferido.

Agrupe las alertas relacionadas con un mismo incidente. Establezca un periodo de confirmación para las fluctuaciones habituales y trate de inmediato los eventos que requieran una intervención.

La alerta no sustituye a un mecanismo de protección: el límite de gasto, el máximo de pasos y la autorización de escritura deben aplicarse durante la ejecución.

Elegir una plataforma según la información que falta

Una plataforma especializada facilita la lectura de los recorridos y su relación con las evaluaciones. Debe complementar la supervisión de los servidores, las colas y los servicios de negocio. El directorio de herramientas de IA permite situar estas soluciones entre los demás componentes de operación.

Las siguientes capacidades están documentadas en las fuentes oficiales consultadas para esta página. La tabla no establece una clasificación de rendimiento.

Solución	Recorridos y trazas	Evaluación	Aspecto que debe comprobar para su uso
Langfuse	Observaciones anidadas, consumo y tiempos	Puntuaciones, conjuntos de datos y experimentos	Recopilación autorizada, alojamiento y organización de proyectos
LangSmith	Trazas de agentes y seguimiento en producción	Evaluaciones en línea y análisis de recorridos	Integraciones utilizadas y condiciones de despliegue
Arize Phoenix	Instrumentación basada en OpenTelemetry y OpenInference	Conjuntos de datos, evaluaciones y experimentos	Operación de la instancia y compatibilidad de la instrumentación

La documentación de Langfuse, la presentación oficial de LangSmith Observability y el repositorio oficial de Phoenix describen estas funciones. No demuestran que sean adecuadas para su carga de trabajo.

Compare las opciones con un recorrido representativo que incluya una rama paralela, una reanudación tras una interrupción, una llamada fallida y contenido oculto. Compruebe también la exportación de datos y la posibilidad de eliminar una ejecución.

El costo total incluye la ingesta, el almacenamiento, la retención de datos, las evaluaciones y la operación. Por tanto, el precio del plan básico no basta para comparar dos arquitecturas.

Limitar los datos recopilados y controlar su conservación

Una traza puede contener una solicitud privada, un documento recuperado, la respuesta de una herramienta o información de autenticación. Así se crea una copia adicional de datos que antes estaban repartidos entre varios servicios.

Defina una lista de campos permitidos. Recopile primero los metadatos necesarios para el diagnóstico y habilite la recopilación de contenido solo cuando exista una necesidad explícita. La referencia de un documento, su revisión y el resultado de una comprobación pueden bastar sin copiar todo su texto.

Aplique el filtrado antes de exportar. La documentación sobre el enmascaramiento de Langfuse describe esta posibilidad y aclara que el tratamiento aplicado por un exportador no limpia necesariamente los datos que envía otro.

Revise también las excepciones, los archivos adjuntos, los nombres de operaciones y los registros alternativos. Enmascarar un campo principal no protege una copia conservada en otro lugar.

Separe los accesos según el entorno y la responsabilidad. Defina plazos de conservación en función del uso: el diagnóstico habitual, la auditoría de acciones sensibles y los ejemplos destinados a evaluaciones no tienen necesariamente las mismas necesidades. Si aloja la plataforma en su propia infraestructura, estas decisiones quedan a su cargo.

La guía para proteger un agente de IA aborda los permisos y los secretos. El artículo sobre agentes de IA y datos personales completa este inventario de flujos.

Desplegar la supervisión en etapas verificables

Los requisitos previos son tanto organizativos como técnicos: una persona responsable del servicio, una definición del éxito, un entorno de pruebas y acceso controlado a los resultados de negocio. Sin estos elementos, recopilará datos sin poder resolver los incidentes con fundamento.

Defina los estados y los identificadores. Documente los desenlaces posibles, la diferencia entre tarea e intento y los vínculos esperados entre eventos.
Trace un recorrido completo. Incluya recepción, espera, llamadas, controles, efectos y estado final. Compruebe también qué ocurre durante una interrupción.
Añada las mediciones esenciales. El volumen, los tiempos, los desenlaces, los reintentos y el consumo deben poder vincularse con las ejecuciones de origen.
Aplique las reglas de recopilación. Utilice datos ficticios reconocibles para comprobar qué llega realmente a cada destino.
Active las alertas en pruebas. Simule una dependencia no disponible, una tarea bloqueada y un límite alcanzado. Verifique la recepción de la alerta y el procedimiento de respuesta.
Habilite el tráfico de forma gradual. Compare la parte del servicio desplegada con un recorrido de referencia y mantenga la posibilidad de volver al estado anterior.

Pruebe también el fallo del recolector. Una caída de la plataforma de observabilidad no debe bloquear accidentalmente todo el servicio. Para las acciones cuya auditoría sea obligatoria según su política, defina expresamente si siguen permitidas cuando falla el registro.

Mida la carga adicional de la recopilación: memoria, colas de exportación y latencia. El envío asíncrono reduce la dependencia entre componentes, pero la instrumentación sigue consumiendo recursos.

Aplicar muestreo sin perder los incidentes

Conservar todo el contenido de todas las ejecuciones aumenta el volumen almacenado y la exposición de los datos. El muestreo permite limitar las trazas detalladas, siempre que se tenga claro qué conclusiones se pueden seguir extrayendo.

Puede seleccionar una parte de las ejecuciones habituales y aplicar una política distinta a los errores o a los recorridos sensibles. Sin embargo, seleccionar según el resultado final exige conservar temporalmente suficiente información para tomar esa decisión.

No calcule la tasa global de fallos a partir de un conjunto en el que haya incluido deliberadamente más errores. Utilice contadores que cubran toda la actividad para las métricas generales y las trazas seleccionadas para explicar los casos concretos.

La propia supervisión debe dejar pruebas de que funciona. Haga seguimiento de los rechazos durante la ingesta, los fallos de exportación, los datos descartados y los retrasos de llegada. Una disminución de las trazas puede indicar menos tráfico o un fallo en la recopilación.

Por último, impida que el muestreo habitual elimine eventos de auditoría que su política exige conservar. Las trazas de diagnóstico y las pruebas de acciones sensibles necesitan reglas distintas.

Problemas frecuentes y respuesta a incidentes

Las llamadas aparecen sin relación entre sí. Busque una pérdida de contexto a la salida de una cola o de un proceso. Compruebe también que las tareas paralelas no reutilizan un contexto que ya no corresponde.

Los datos de consumo están incompletos. Distinga entre un valor no disponible y un consumo nulo. Examine los reintentos, las interrupciones de la transmisión y las llamadas realizadas fuera de la instrumentación principal.

El panel indica que la tarea tuvo éxito, pero la acción no aparece. Sustituya el estado basado en el texto final por una comprobación del estado de destino. Conserve por separado lo que afirma el agente y el resultado comprobado.

Las trazas aparecen duplicadas. Varias capas pueden instrumentar la misma llamada. Identifique qué componente crea cada operación antes de sumar duraciones o consumo.

Durante un incidente, empiece por limitar los efectos: suspenda las escrituras afectadas, detenga los bucles o redirija las solicitudes. Después, preserve las trazas útiles y las revisiones de configuración.

Construya una cronología que relacione solicitud, autorización, acción y estado final. No vuelva a ejecutar directamente una traza que pueda enviar un mensaje o modificar un registro. Tras corregir el problema, convierta el caso en una prueba de regresión sin datos sensibles y compruebe también si la alerta habría permitido detectarlo.

Lista de comprobación antes de pasar a producción

El éxito de la tarea se verifica en el sistema de negocio.
Cada intento está vinculado a su tarea y a sus operaciones.
Los reintentos, las esperas y las interrupciones siguen siendo visibles.
Los costos desconocidos se distinguen de los costos nulos.
El contenido sensible se filtra antes de cada exportación.
Las alertas identifican a una persona responsable y una acción.
Los límites y las paradas funcionan sin depender de las notificaciones.
Se han probado el fallo de recopilación y la vuelta al estado anterior.
Los incidentes útiles se incorporan a las pruebas de regresión.

Páginas relacionadas

Preguntas frecuentes

¿Qué diferencia hay entre la supervisión y la observabilidad de un agente de IA?

La supervisión comprueba condiciones previstas, como una tarea bloqueada o un presupuesto superado. La observabilidad también aporta los elementos necesarios para investigar comportamientos inesperados. Ambas se complementan en la operación diaria.

¿Es necesario registrar todos los prompts en producción?

No. Puede empezar por los metadatos, las duraciones, los estados y el consumo, y después permitir una recopilación selectiva de contenidos con los datos sensibles eliminados. La decisión depende de los datos tratados y de las necesidades de diagnóstico.

¿Se puede supervisar un agente sin una plataforma especializada?

Sí, mediante registros estructurados, métricas y trazas en su infraestructura actual. Una plataforma especializada facilita sobre todo la lectura de los intercambios con el modelo y su relación con las evaluaciones. Compruebe primero qué información le falta realmente.

¿Una traza permite reproducir exactamente una ejecución?

Documenta las operaciones registradas, pero no garantiza una reproducción idéntica. El modelo, los datos consultados y el estado de los servicios externos pueden haber cambiado. Por eso, volver a ejecutar una acción de escritura exige un entorno aislado y la neutralización de sus efectos externos.

¿Cómo se mide la calidad de un agente después del despliegue?

Combine comprobaciones de los resultados de negocio, revisión humana de ejecuciones seleccionadas y evaluaciones automatizadas. Mantenga una categoría de resultado indeterminado cuando falten pruebas. Toda puntuación automática debe ir acompañada de su método y sus limitaciones.

Supervisar un agente de IA en producción: registros, trazas, alertas y herramientas de observabilidad