En el desarrollo de software, completar con éxito la integración continua (CI) y superar las evaluaciones internas son indicios clave de que una nueva versión está lista para producción. Sin embargo, cuando los sistemas incluyen agentes de inteligencia artificial (IA), estos indicadores tradicionales pueden no ser suficientes. Pese a pasar todas las pruebas, el usuario final puede seguir recibiendo respuestas erróneas o experimentando ralentizaciones inesperadas.
Este fenómeno revela una brecha crítica en la observabilidad de sistemas que incorporan funciones basadas en IA. Según el informe «State of SRE and Platform Engineering 2026» de Dynatrace, que encuestó a 919 líderes empresariales a nivel global, el 77 % de los equipos de ingeniería de plataformas integran algún nivel de observabilidad en sus servicios, pero solo el 40 % la aplica de manera completa en todos sus despliegues. Esta discrepancia, antes manejable con servicios deterministas, se transforma en un problema grave al incorporar agentes de IA, cuya naturaleza probabilística y operación silente dificulta la detección de fallos.
Los sistemas convencionales suelen fallar de manera ruidosa, mostrando errores 500, picos de latencia o fallos en dependencias externas visibles para los monitores. En cambio, los agentes de IA pueden operar sin errores aparentes: devuelven un código 200, pasan las comprobaciones de coherencia y, sin embargo, proporcionan información incorrecta al usuario. Detectar este tipo de fallo exige evidencia concreta del sistema en ejecución, más allá de los registros habituales de peticiones o tasas de error. 
Un ejemplo: un agente de soporte con problemas tras una actualización
Imaginemos una aplicación que soporta un agente de soporte automatizado para consultas sobre documentación técnica. Tras una actualización en la que se modificó la función de búsqueda documental, todas las pruebas en CI y evaluaciones previas superaron sin inconveniente. Sin embargo, tras la puesta en producción, los usuarios notaron respuestas más lentas y, en algunos casos, instrucciones desactualizadas relativas a versiones antiguas del producto.
Para identificar la causa, es esencial examinar una ejecución problemática comparándola con una previa a los cambios. Esto implica analizar la traza completa de la petición, incluyendo cada llamada hecha al modelo de IA y herramientas auxiliares, cómo se sucedieron y qué resultados retornaron. Esta observación se realiza mediante trazas distribuidas, que documentan cada paso y sincronizan la información entre servicios.
En el ejemplo simplificado, la traza mostró que el agente realizó tres búsquedas idénticas con el parámetro de versión del producto como nulo, lo que provocó que se recuperaran documentos antiguos (versiones 2024.1 y 2023.9) en lugar de los de la versión solicitada 2026.3. Estas múltiples consultas repetidas incrementaron la latencia y la cantidad de tokens procesados, afectando el rendimiento.
Desentrañando causas: reintentos legítimos o fallos en la gestión
Analizar el motivo de las consultas repetidas arroja datos reveladores. La traza muestra que las búsquedas no fueron solicitadas múltiples veces por el modelo, sino que el código encargado de ejecutar las herramientas y gestionar contextos probablemente generó los reintentos. Esto es distinto a una situación en la que el modelo pide explícitamente varias veces la misma herramienta, lo cual indicaría un problema en el prompt o en la descripción de la herramienta.
Pero no siempre que hay reintentos se trata de un error. Si el backend de búsqueda devuelve resultados vacíos o no relevantes, un mecanismo de reintentos puede ser apropiado para aumentar la fiabilidad. No obstante, el hecho de que el prompt contenga ahora la concatenación de los resultados de varios reintentos puede inflar demasiado la consulta, provocando mayores tiempos de respuesta. Antes de atribuir la lentitud a la actualización, conviene examinar también el comportamiento de los servicios downstream.
Fidelidad de la respuesta y problemas en la recuperación de información
La evaluación semántica mostró que el agente de IA generó respuestas fieles a los documentos recuperados, pero el cliente recibió ayudas referidas a versiones incorrectas del producto. Aquí el problema no es de generación, sino de recuperación: el filtro que debía limitar la búsqueda a la versión solicitada no se aplicó correctamente, de modo que los resultados incluidos documentos obsoletos y no relevantes para la consulta precisa.
Los evaluadores tradicionales de relevancia no detectan este tipo de error, pues comprueban si los documentos son pertinentes respecto a la consulta textual, pero no si son válidos para el contexto o versión solicitada. En este caso, la relevancia no coincide con la validez.
Por tanto, es fundamental validar que la recuperación de documentos respete siempre las condiciones preestablecidas. Esto puede comprobarse de manera determinista mediante pruebas unitarias que aseguren que la búsqueda solo incluye documentos con la versión requerida, sin implicar al modelo en esta comprobación.
def test_lookup_filters_to_requested_version(docs_fixture):
hits = search_docs(query="configure export", product_version="2026.3")
assert hits, "no hits for a version that has docs"
assert {h.product_version for h in hits} == {"2026.3"}Separar estas dos pruebas —la de recuperación y la de calidad de respuesta— permite identificar claramente qué parte falla. Además, para preservar el contexto necesario en las evaluaciones, conviene almacenar metadatos como la versión del prompt, el modelo usado, la configuración de recuperación y las versiones y IDs de los documentos consultados, todo vinculado con el identificador de traza de la ejecución.
Incluir fallos en el proceso de revisión de nuevas versiones
Una vez confirmadas las causas de los problemas, cada corrección debe ser verificada con pruebas específicas orientadas a la parte afectada del sistema. Por ejemplo, para el problema de consultas repetidas, se añade un test que reproduzca la situación sin eliminar los reintentos legítimos, evitando exigir un orden fijo en la ejecución de herramientas para permitir refactorizaciones válidas.
Respecto a la recuperación de versiones correctas, es importante incluir casos de prueba con la versión actual, versiones anteriores con soporte, documentación irrelevante e incluso situaciones sin respuesta soportada. Además, las evaluaciones de respuesta deben ejecutarse varias veces para capturar la variabilidad de salida inherente a los modelos generativos.
En entornos productivos, implementar muestreos automáticos de trazas e integrar un sistema de evaluación con un modelo que actúe como juez permite detectar regresiones de rendimiento o calidad en tiempo real. Los resultados deben almacenarse de forma vinculada a las trazas originales para una trazabilidad óptima, evitando modificar trazas finalizadas, conforme a las recomendaciones de OpenTelemetry.
Preparar la instrumentación para futuras investigaciones
Si no se sabe por dónde comenzar una investigación tras detectar un fallo, eso indica que la instrumentación actual es insuficiente. Para sistemas clásicos, disponer del camino de petición y tiempos de dependencias suele ser adecuado. Para sistemas con IA, es imprescindible añadir información sobre qué documentos se recuperaron, qué produjo el modelo y cómo se evaluó si la respuesta era la adecuada, disponiendo de evidencia suficiente para un análisis detallado.
En definitiva, lograr superar la brecha de observabilidad en sistemas con IA requiere nuevos enfoques en captura de datos, pruebas y evaluación, que vayan más allá de la infraestructura clásica y se adapten a las características propias de estas tecnologías emergentes.
Dynatrace será patrocinador del WeAreDevelopers World Congress Americas en San José (23-25 de septiembre de 2026). Invitan a los asistentes a traer preguntas concretas sobre la depuración de sistemas o características impulsadas por IA para trabajar conjuntamente en su resolución.
