La respuesta corta
Observar un agente de IA no consiste solo en comprobar si responde. Una operación puede terminar sin error, consumir pocos recursos y aun así dar una respuesta equivocada, utilizar una herramienta indebida o saltarse una regla de negocio. Antes de producción, el equipo necesita relacionar tres planos: salud técnica, comportamiento del agente y resultado útil para el proceso.
AWS anunció CloudWatch Omni el 22 de septiembre de 2026 como un entorno de observabilidad para aplicaciones y cargas con agentes. Su documentación separa trazas, sesiones, evaluaciones, experimentos y monitorización en producción. OpenTelemetry define convenciones para registrar operaciones de IA generativa y NIST sitúa la monitorización y la evaluación a lo largo del ciclo de vida. La lección transferible no es comprar una herramienta concreta: es diseñar evidencias que permitan detectar, explicar y corregir una regresión.
Separa funcionamiento, comportamiento y resultado
Las métricas operativas responden si el servicio está disponible y cuánto tarda. Las trazas muestran qué pasos ejecutó. Las evaluaciones preguntan si el comportamiento fue aceptable. Ninguna capa sustituye a las otras: una latencia correcta no demuestra calidad, y una puntuación de calidad no explica por sí sola qué llamada o herramienta provocó el fallo.
La documentación de AWS reúne volumen, errores, latencia y uso de tokens con trazas y resultados de evaluación. OpenTelemetry describe atributos y spans para invocaciones de modelos y herramientas. NIST recomienda observar el funcionamiento y el comportamiento en producción, además de documentar métricas y cambios. Juntas, estas fuentes respaldan una revisión que vaya desde la infraestructura hasta la decisión de negocio.
- Salud técnica: disponibilidad, errores, latencia, reintentos y consumo.
- Comportamiento: pasos, herramientas, datos recuperados, bucles y rutas de escalado.
- Calidad: corrección, relevancia, formato, cumplimiento de reglas y uso adecuado de fuentes.
- Resultado de negocio: tarea completada, revisión necesaria, excepción creada y efecto sobre el proceso.
Diseña una traza que permita reconstruir el caso
Una traza útil representa una ejecución completa y la divide en pasos relacionados. AWS y OpenTelemetry usan este patrón para distinguir, entre otras operaciones, la llamada al modelo, la recuperación de información y la ejecución de herramientas. Para una empresa, la finalidad no es coleccionar registros: es poder responder qué recibió el agente, qué intentó, qué sistema consultó, qué acción pidió y qué devolvió cada paso.
No todo debe registrarse como contenido completo. Conviene conservar identificadores, versiones, tiempos, resultados y decisiones de control, y capturar prompts, documentos o parámetros solo cuando exista una necesidad clara y una base de acceso adecuada. La traza debe servir para investigar sin convertirse en una copia indiscriminada de datos empresariales.
- Identificador de ejecución y, cuando proceda, de sesión.
- Versión del agente, prompt, modelo, herramientas y reglas aplicadas.
- Spans para recuperación, llamadas al modelo y acciones externas.
- Estado, duración, consumo y error de cada paso.
- Resultado final, evaluación, escalado humano y efecto confirmado en el sistema de destino.
Evalúa con casos conocidos antes de puntuar tráfico real
Una evaluación automática solo es útil si su criterio distingue ejemplos buenos y malos del proceso real. La documentación de AWS recomienda comprobar evaluadores con trazas conocidas y advierte que un criterio general puede aprobar una respuesta que no sirve para un dominio concreto. NIST plantea pruebas, evaluación, verificación y validación como trabajo continuo, no como una comprobación única antes del lanzamiento.
Empieza con reglas deterministas cuando el resultado pueda comprobarse sin otro modelo: formato válido, campos obligatorios, identificadores existentes, importes dentro de límite o prohibición de una herramienta. Reserva el modelo juez para criterios que realmente requieren interpretación y revisa una muestra humana. La puntuación del evaluador también puede equivocarse y debe medirse contra decisiones de referencia.
- Conjunto pequeño de casos normales, límites, excepciones y fallos conocidos.
- Un criterio por evaluador, con definición visible de aprobado y suspendido.
- Reglas deterministas para comprobaciones estructuradas o de negocio.
- Muestra revisada por una persona para estimar errores del propio evaluador.
- Comparación antes y después de cambiar modelo, prompt, herramienta o fuente de datos.
Protege la telemetría desde el punto de captura
Los registros de un agente pueden incluir mensajes, documentos recuperados, argumentos de herramientas y resultados. OpenTelemetry marca varios de estos atributos como potencialmente sensibles. AWS indica que la telemetría puede contener datos personales o confidenciales y que no todo se elimina automáticamente; también explica que un evaluador basado en un modelo puede enviar el contenido de la traza al modelo juez configurado.
Por eso la privacidad no debe añadirse después de habilitar el registro. El equipo tiene que decidir qué campos nunca salen de la aplicación, cuáles se redactan, quién puede consultar trazas, cuánto tiempo se conservan y qué contenido puede recibir un evaluador. Filtrar en origen reduce capacidad de depuración, pero es la frontera adecuada cuando un dato no debe exportarse.
- Inventario de campos antes de activar la captura de contenido.
- Redacción o exclusión de secretos, datos personales y documentos completos.
- Acceso separado para operación, seguridad, desarrollo y propietarios del proceso.
- Retención mínima compatible con investigación y obligaciones aplicables.
- Revisión específica del proveedor y la ubicación del modelo usado como juez.
Convierte fallos reales en pruebas de regresión
Cuando una ejecución falla, conservar solo una captura impide comprobar la corrección. Es más útil transformar el caso depurado en una prueba versionada: entrada saneada, contexto necesario, resultado esperado y reglas que no deben romperse. AWS permite convertir trazas en casos de un conjunto de evaluación y comparar ejecuciones; el marco de NIST respalda la evaluación continua cuando cambian el sistema o su contexto.
El conjunto no debe almacenar datos reales sin necesidad. Puede anonimizarse, reducirse al mínimo que reproduce el fallo y conservar un enlace controlado a la investigación original. Después, cada cambio relevante compite contra esos casos para demostrar que corrige el problema sin reabrir otros.
- Clasifica el fallo: datos, recuperación, razonamiento, herramienta, permiso o sistema externo.
- Reduce la traza al caso mínimo que todavía reproduce el comportamiento.
- Sanea el contenido antes de añadirlo al conjunto de pruebas.
- Define el resultado esperado y la señal de parada.
- Ejecuta la regresión antes de ampliar tráfico o permisos.
Fija alertas y criterios de parada antes de escalar
No existe un umbral universal para declarar fiable un agente. El equipo debe fijarlo según el daño posible, la frecuencia, la reversibilidad y la capacidad de revisión. Una caída de calidad, un aumento de bucles, una llamada prohibida o una pérdida de trazabilidad pueden justificar detener la automatización aunque la infraestructura siga disponible.
Las alertas deben conducir a una acción definida. Si nadie sabe quién investiga, cómo limita el agente o cómo vuelve a la versión anterior, el panel solo describe el problema. Conviene asociar cada señal a un responsable, un plazo, una ruta de escalado y una medida reversible.
- Errores técnicos y latencia fuera del nivel acordado.
- Descenso de evaluaciones en casos críticos o aumento de respuestas inconclusas.
- Uso de una herramienta, dato o parámetro fuera del alcance aprobado.
- Sesiones con bucles, reintentos o consumo anómalos.
- Trazas incompletas que impiden reconstruir una acción relevante.
Un piloto de diez días
Esta propuesta de AUTOINTELLIA empieza con una tarea repetible y reversible. Durante la primera mitad, el equipo instrumenta el flujo y observa ejecuciones de prueba sin conceder nuevas acciones. Define la traza mínima, prepara casos conocidos y comprueba que los datos sensibles no aparecen en la telemetría.
Durante la segunda mitad, ejecuta el agente con un grupo pequeño, revisa fallos y convierte algunos en regresiones. El cierre no pregunta solo si el agente respondió bien: decide qué señales se vigilan, quién puede investigarlas, qué cambio requiere repetir las pruebas y qué condición detiene el uso.
- Días 1 y 2: tarea, riesgo, propietario y resultado verificable.
- Días 3 y 4: instrumentación, esquema de traza y protección de datos.
- Día 5: casos buenos, malos y de frontera con resultado esperado.
- Días 6 a 8: ejecución limitada, revisión y clasificación de fallos.
- Días 9 y 10: regresiones, alertas, criterio de parada y decisión de continuidad.
Checklist antes de pasar a producción
La observabilidad aporta valor cuando une una acción concreta con evidencia suficiente para explicarla y corregirla. Un panel lleno de métricas no compensa una traza incompleta, un evaluador sin referencia o un registro que expone información innecesaria.
AUTOINTELLIA puede ayudar a convertir el agente y su proceso en un piloto medible: definir señales, instrumentar límites, preparar evaluaciones y diseñar una respuesta operativa antes de ampliar permisos o usuarios.
- Cada ejecución relevante tiene una traza reconstruible y vinculada a su versión.
- Las métricas técnicas se revisan junto con calidad y resultado de negocio.
- Los evaluadores distinguen casos conocidos y se contrastan con revisión humana.
- La telemetría excluye o redacta datos que no deben exportarse.
- Los fallos útiles se convierten en regresiones saneadas y versionadas.
- Cada alerta tiene responsable, acción y procedimiento de reversión.
- El equipo conoce la condición que pausa el agente aunque el servicio siga respondiendo.
