Para reconstruir una ejecución de un agente no basta con guardar su respuesta final: registra qué recibió, qué fuentes consultó, qué herramientas pidió y ejecutó, dónde intervino una persona, qué resultado produjo y qué falló. Las trazas conectan esos pasos en una secuencia atribuible a una versión del flujo; las pruebas previas, en cambio, examinan casos preparados antes del lanzamiento. Una no sustituye a la otra.
Una ejecución debe tener hilo y contexto
Empieza con un identificador único de ejecución, fechas y horas de inicio y fin, nombre y versión del agente o flujo, y un identificador de conversación solo si existe uno legítimo. Registra el evento que inició el proceso y una representación de la entrada que permita entenderla después. Puede ser el texto original si su conservación está justificada, o una referencia segura a ese contenido, con los campos relevantes y las transformaciones aplicadas.
HECHO: las convenciones de OpenTelemetry para agentes describen spans anidados para operaciones, contemplan nombre del agente, conversación y fuente de datos, y clasifican algunos campos con contenido de entrada como optativos. El documento aparece con estado “Development”; su historial registra cambios hasta el 30 de septiembre de 2026. OpenTelemetry, documento actualizado al 30 de septiembre de 2026, “Semantic Conventions for GenAI agent and framework spans”: https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/gen-ai-agent-spans.md ; historial: https://github.com/open-telemetry/semantic-conventions-genai/commits/main/docs/gen-ai/gen-ai-agent-spans.md.
INTERPRETACIÓN práctica: guarda lo necesario para reconstruir el caso, pero no conviertas la traza en una copia indiscriminada de datos personales, credenciales o instrucciones internas. Define quién puede consultarla, cuánto tiempo se conserva y cómo se ocultan valores sensibles. Una referencia a una fuente o registro suele ser más prudente que duplicar documentos completos. Las trazas ayudan a investigar; por sí solas no demuestran que la decisión haya sido correcta.
Fuentes, herramientas y aprobaciones
Por cada consulta de información, conserva el tipo de fuente, identificador o ruta estable, hora de consulta y versión o fecha del contenido cuando esté disponible. Si el flujo recupera documentos, guarda las referencias usadas y, si aporta al diagnóstico, cuáles fragmentos sustentaron la respuesta. Distingue entre una fuente consultada y una fuente que realmente influyó en el resultado. Si la información llegó de un sistema externo, anota su nombre y el estado de la respuesta.
En cada herramienta, registra el nombre, propósito, hora, parámetros relevantes, resultado y estado: solicitada, ejecutada, rechazada, agotada por tiempo o fallida. Incluye un identificador que conecte la petición con su respuesta y el error técnico en una categoría entendible, sin volcar secretos en el registro. La secuencia permite ver si el agente pidió una acción, si el sistema la ejecutó y qué información recibió de vuelta.
HECHO: la documentación oficial del SDK de OpenAI enumera trazas para generaciones del modelo, llamadas a funciones, transferencias entre agentes, guardrails y eventos personalizados. También explica que los spans de generación y función pueden contener entradas y salidas sensibles, y que el SDK permite desactivar su captura. OpenAI, documentación sin fecha (consultada el 3 de octubre de 2026), “Tracing”: https://openai.github.io/openai-agents-python/tracing/.
INTERPRETACIÓN práctica: registra las aprobaciones como eventos separados, con identificador de la acción pendiente, decisión (aprobada, rechazada o modificada), fecha y hora, rol o identidad autorizada, y versión del contenido que la persona revisó. Si la persona edita una propuesta, conserva la diferencia o una referencia a la versión aprobada. No deduzcas aprobación de que alguien abrió una pantalla. Este nivel de detalle permite distinguir una recomendación del agente de una decisión humana y de una acción ejecutada.
Resultado, errores y contexto de la falla
Al cerrar cada ejecución, guarda el resultado observable y el estado final: completada, incompleta, detenida, derivada a una persona o fallida. Relaciona el resultado con las acciones confirmadas, no solo con la respuesta escrita por el modelo. Si hubo error, registra componente afectado, clase de error, momento, reintentos y si el proceso se recuperó o quedó pendiente. También vale anotar límites de tiempo y cancelaciones. Evita calificar la respuesta como “correcta” si no hubo verificación; usa un campo distinto para la evaluación posterior.
HECHO: la convención de OpenTelemetry define `error.type` para operaciones que terminan con error y da ejemplos como timeout; incluye además identificadores de fuente de datos y entradas de mensajes como opt-in. Por tanto, propone vocabulario común, no obliga a conservar cada contenido ni cubre por sí sola cada evento propio del negocio. OpenTelemetry, actualización del 30 de septiembre de 2026, “Semantic Conventions for GenAI agent and framework spans”: https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/gen-ai-agent-spans.md.
INTERPRETACIÓN práctica: diseña el registro para responder preguntas concretas: ¿qué información tenía el agente?, ¿qué herramienta alteró el estado?, ¿quién autorizó ese paso?, ¿qué falló y qué quedó sin completar? Un esquema uniforme por ejecución facilita comparar eventos, pero no hace falta almacenar el razonamiento privado del modelo palabra por palabra. Prioriza hechos operativos que puedas verificar: entradas, referencias consultadas, llamadas, aprobaciones, resultados y errores.
La prueba antes del lanzamiento no es el monitoreo
Antes de habilitar un flujo, prueba ejemplos normales, datos incompletos, respuestas inesperadas de herramientas, permisos denegados y acciones que deben esperar aprobación. Guarda versión probada, conjunto de casos, resultado esperado, resultado observado y defectos corregidos. Así se compara el comportamiento frente a situaciones controladas y se decide si el alcance inicial es aceptable.
HECHO: NIST indica que los sistemas de IA deben probarse antes de su despliegue y periódicamente durante su operación. Su informe de marzo de 2026 explica que las evaluaciones previas suelen realizarse en entornos controlados, mientras el monitoreo posterior permite comprobar el comportamiento en situaciones reales, observar resultados imprevistos y detectar consecuencias inesperadas. NIST, 26 de enero de 2023, “Artificial Intelligence Risk Management Framework (AI RMF 1.0)”: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10 ; NIST, 6 de marzo de 2026, “Challenges to the monitoring of deployed AI systems”: https://www.nist.gov/publications/challenges-monitoring-deployed-ai-systems-center-ai-standards-and-innovation.
INTERPRETACIÓN práctica: conserva pruebas previas como evidencia de lo que se examinó, y las trazas de operación como historia de lo que realmente ocurrió. En producción, revisa tendencias de fallas, tareas detenidas, aprobaciones rechazadas y resultados que requirieron corrección; define quién analiza esas señales y qué cambio puede activar una revisión o pausa. El monitoreo no garantiza que se detecte todo, y una buena prueba no cubre cada variación real. NIST advierte, además, que las prácticas comunes de monitoreo todavía están en desarrollo.
Como ejemplo hipotético, una pyme de mantenimiento podría probar antes del lanzamiento un flujo que consulta un manual técnico y prepara una recomendación para revisión. Después, cada ejecución debería mostrar qué manual o versión consultó, qué dato aportó el técnico, qué propuso el agente, quién aprobó o rechazó la propuesta y si quedó alguna consulta sin resolver. No es una función que se atribuya a una plataforma disponible; ilustra qué información haría falta para reconstruir el recorrido.
Una acción concreta para empezar: elige un proceso acotado y redacta una hoja de registro con seis campos obligatorios —entrada, fuentes, herramientas, aprobaciones, resultado y error—; luego usa esa misma hoja para revisar un caso de prueba antes del lanzamiento y una ejecución real cuando exista. Para pensar dónde debe detenerse el flujo ante una decisión sensible, consulta también la guía de Jarvis sobre aprobación humana: https://www.jarvisrd.com.do/blog/aprobacion-humana-ia-no-decide-sola.