El pasado diciembre, una gran empresa de retail lanzó un nuevo agente de IA de atención al cliente. En pocos días, actores malintencionados lo manipularon para que hablara de temas ajenos al retail, con un potencial enorme de dañar la marca. La explicación del proveedor: las barreras de protección del agente se habían «configurado mal de forma involuntaria». La corrección llegó rápido.
Pero las implicaciones se quedaron: un despliegue de IA con muchos recursos, construido sobre una plataforma de agentes de IA destacada, salió a producción sin ninguna forma sistemática de verificar que sus restricciones de comportamiento funcionaran. El fallo de configuración no se detectó ni en las pruebas ni en QA. La marca se enteró a la vez que internet.
Algunas de estas historias de fallos de agentes de IA dan titulares memorables, pero son casos atípicos. La realidad más habitual es más silenciosa, aunque igual de dañina: agentes de IA que dan al cliente un plazo de devolución equivocado con total seguridad, o que pasan por alto un requisito de compliance en una o dos conversaciones. Estos fallos rara vez llegan a las noticias, pero sí se reflejan en la satisfacción del cliente (CSAT), en las tasas de escalado y en la pérdida de clientes.
Las empresas despliegan agentes de IA más rápido de lo que pueden validarlos, y la brecha no se cierra. Crear un programa de pruebas riguroso siempre ha exigido mucho trabajo manual, criterio humano y mantenimiento continuo. Por eso la mayoría de los equipos se ven obligados a priorizar: cubren los escenarios evidentes, esperan que todo vaya bien y parchean los problemas cuando aparecen en producción. Otros intentan atajar con jueces LLM sin validar. El resultado son programas de pruebas que aparentan funcionar, pero que no comprueban si el agente está listo para producción.
La verdad incómoda sobre las pruebas de agentes de IA es que muchos programas se diseñan para el día del lanzamiento, no para el día a día de producción. Pueden ser lo bastante exhaustivos para superar una revisión interna, pero a partir de ahí suelen degradarse.
Dónde fallan las pruebas de agentes de IA
¿Por qué las pruebas, una parte tan crítica del despliegue de agentes de IA, son tan difíciles de hacer bien a escala?
Cada paso del proceso es largo y exige tiempo y cuidado. El equipo debe definir qué significa «excelente» en términos precisos y verificables. Debe configurar evaluadores que filtren el ruido y detecten los fallos reales. Y debe crear una cobertura de pruebas que refleje cómo se comportan los clientes. Cada actualización de modelo, revisión de prompt o nuevo workflow reinicia el ciclo y tensa los recursos disponibles.
El resultado es un programa que por fuera parece completo, pero que por dentro está lleno de agujeros.
Eso es lo que resuelven las mejoras que presentamos hoy en la suite Automated Testing de Cresta AI Agent. Son cuatro capacidades nuevas. Cada una aborda un punto donde los programas de pruebas han tenido problemas para crecer o mantenerse con el tiempo.
Adherencia a los requisitos: la IA construye la base y los expertos la refinan
Los requisitos suelen vivir en PRD, guías de marca o listas de comprobación de compliance. Rara vez producen algo que un evaluador LLM pueda calificar.
AI Agent Testing 2.0 lo cambia: genera la lista inicial de requisitos a partir de PRD, CSV o documentación existente. Así acelera un proceso que llevaría días, o incluso semanas en casos de uso complejos. Cresta ejecuta un diagnóstico de un clic que señala posibles problemas: lenguaje no verificable, criterios con varios parámetros que el LLM no puede calificar de forma fiable y requisitos que dependen de un contexto al que el agente no accede. Después, los expertos de dominio revisan, refinan y aprueban.
Cada requisito aprobado se convierte en un evaluador LLM: una única fuente de verdad que se aplica tanto a las conversaciones de prueba como al tráfico de producción.
La calidad de los evaluadores depende de la calidad de los requisitos. Cada requisito es binario: el agente hizo algo o no lo hizo. Un buen requisito tiene una condición de aprobado clara, una condición de fallo clara y resiste una auditoría:
- El agente debe verificar la identidad de quien llama antes de revelar datos de la cuenta.
- El agente debe ofrecer una transferencia a un especialista si el usuario plantea una disputa de facturación.
- El agente debe abstenerse de dar asesoramiento financiero concreto.
- El agente debe incluir un aviso de privacidad si la conversación trata datos personales de salud.
Cada requisito se etiqueta además como imprescindible o deseable, una distinción que cambia la forma de priorizar los fallos. Una tasa de aprobado del 98 % parece sólida hasta que se descubre que ese 2 % de fallos afecta a requisitos imprescindibles. Separar los bloqueantes imprescindibles de las mejoras deseables hace que el programa de pruebas revele aquello sobre lo que los equipos realmente deben actuar, no solo lo que ocurrió.
Evaluadores en los que puede confiar y que puede medir
Muchos programas de pruebas configuran los evaluadores LLM-como-juez una sola vez y confían, o esperan, que sigan funcionando bien. Algunos recurren a evaluadores listos para usar, pensados para medir cosas como la empatía o la precisión en varios casos de uso. Pero los evaluadores genéricos pasan por alto el matiz de dominio que determina si una respuesta es correcta para un negocio concreto. Otros construyen los suyos, pero no reciben feedback sistemático sobre si el evaluador es demasiado estricto, demasiado indulgente o simplemente inconsistente. Un evaluador que falla no solo genera ruido: induce a error. Los falsos positivos hacen perder tiempo persiguiendo problemas inexistentes. Los falsos negativos dejan pasar fallos reales.
El enfoque de Cresta parte de una base híbrida: combina evaluadores LLM para juicios matizados y dependientes del contexto con evaluadores deterministas para criterios que se pueden comprobar con precisión. La calibración de evaluadores asigna después una puntuación de precisión medible a cada evaluador basado en requisitos. Los equipos eligen un grupo de requisitos que calibrar y una fuente de conversaciones. Luego revisan cómo etiquetó el evaluador una muestra y aportan feedback donde el criterio de la IA no acertó. Cresta devuelve una puntuación F1 por requisito. Esa métrica única equilibra si el evaluador detecta lo que debe sin generar demasiadas falsas alarmas, de modo que los equipos sepan qué evaluadores son fiables y cuáles hay que refinar.
En un cliente de retail, la calibración de evaluadores redujo a menos de la mitad la tasa de fallos por falsa alarma. El equipo dejó de investigar ruido y empezó a investigar errores reales.
Este proceso no es solo diagnóstico: también hace medible la iteración. Tras refinar un requisito, los equipos pueden volver a ejecutarlo sobre el mismo conjunto de conversaciones etiquetadas y ver si la precisión mejora. Así la calibración se convierte en un bucle de feedback vivo, no en una configuración única.
Una cobertura que refleja cómo se comportan realmente los clientes
Crear casos de prueba a mano suele significar que la cobertura refleja lo que el equipo tuvo capacidad y recursos para producir, no cómo se comportan los clientes. La larga cola del comportamiento real —los casos límite, las formulaciones inusuales, las vías inesperadas— se queda sin probar.
AI Agent Testing 2.0 genera casos de prueba automáticamente a partir de cuatro fuentes, todas basadas en señal real:
- Incumplimientos de requisitos: Cuando una conversación de producción cerrada revela una carencia en los requisitos, la IA construye por ingeniería inversa un Synthetic Customer (una persona simulada, basada en datos de conversaciones con clientes) alineado con el escenario, y un evaluador que valida la corrección a fondo. Los equipos pueden ejecutar el nuevo caso de prueba de inmediato y confirmar que la corrección se sostiene antes de que el agente avance.
- Feedback sobre conversaciones de producción: Cuando un revisor marca una conversación, Cresta puede generar automáticamente un caso de prueba completo a partir de ese feedback: nombre, descripción, comportamiento esperado y un evaluador alineado con los criterios concretos. Cada caso de prueba se puede rastrear hasta el feedback de origen, lo que permite seguir qué se detectó, qué se corrigió y qué se ha validado.
- Artículos de la base de conocimiento: Los equipos pueden convertir el contenido de la base de conocimiento en casos de prueba que verifican que las respuestas del agente se apoyan en fuentes aprobadas. Las pruebas de un solo artículo evalúan si la respuesta del agente está respaldada por el artículo correcto. Las pruebas de varios artículos comprueban si el agente sintetiza bien la información de dos o más artículos en consultas complejas.
- Principales preguntas de los clientes en conversaciones reales: Cresta extrae las preguntas más frecuentes de las conversaciones reales con clientes y las convierte en casos de prueba. Así la cobertura va más allá de lo documentado en la base de conocimiento y recoge el lenguaje que los clientes usan de verdad.
Los casos de prueba se pueden combinar con Cresta Synthetic Customers, que generan personas a partir de datos reales de conversaciones con clientes. En lugar de simular cómo podrían comportarse los clientes, reflejan cómo se comportan los suyos. Eso hace que las pruebas de simulación sean más representativas y los resultados más significativos. Tanto lo que se prueba como la forma de calificarlo reflejan la realidad. La cobertura crece a medida que el agente evoluciona, se acumula el feedback de los revisores y se producen más conversaciones.
En un despliegue de e-commerce, las pruebas de variación revelaron que el agente gestionaba bien las devoluciones estándar, pero fallaba cuando se planteaban como regalo: «Quiero devolver esto, me lo regalaron». Esa formulación activó una vía lógica que el camino feliz no había recorrido. Se detectó sin conexión, antes de que ningún cliente lo viera.
Nuevos evaluadores LLM listos para usar: califique según lo que está en juego, no solo según la respuesta
Incluso los equipos con evaluadores bien calibrados chocan con un fallo concreto: los criterios de calificación no encajan con lo que el caso de uso exige. Un evaluador estricto aplicado a una respuesta abierta de FAQ marca como fallo variaciones inofensivas de redacción. Uno indulgente aplicado a un guion de compliance deja pasar omisiones importantes. Las evaluaciones dan señal, pero no siempre la correcta.
AI Agent Testing 2.0 amplía además la biblioteca de Cresta de evaluadores LLM listos para usar y alineados con expertos, con tres opciones más precisas para calificar las respuestas del agente. El evaluador Golden Response ya existente comprueba la equivalencia semántica. Los nuevos permiten elegir el nivel de exigencia adecuado a cada caso de uso, en lugar de aplicar un único estándar a todo:
- Completeness comprueba que el agente ha aportado todas las afirmaciones definidas en la respuesta aprobada, admitiendo información adicional: encaja con las FAQ y con las respuestas de soporte general.
- Accuracy comprueba que el agente ha aportado únicamente las afirmaciones definidas en la respuesta aprobada: encaja con los workflows guiados por SOP donde importa ceñirse al guion, como guiones de resolución de incidencias, lenguaje de compliance y procesos guiados.
- Completeness & Accuracy comprueba que el agente ha aportado todas las afirmaciones definidas y nada más. Es la opción más estricta, pensada para salidas deterministas: plantillas, redacción regulada y casos de prueba donde se exige un comportamiento exacto y cualquier desviación, por adición u omisión, se considera un fallo.
Juntos, los tres evaluadores dan a los equipos una idea más clara del tipo de fallo que se ha producido y un método objetivo para calificar las respuestas del agente. Están calibrados por expertos de dominio y validados en distintos casos de uso y sectores, de modo que ofrecen juicios fiables, lo ha adivinado, listos para usar.
El nuevo listón para una IA lista para producción
Por suerte, el traspié de aquella gran empresa de retail fue un caso límite. Pero los casos límite son justo lo que los programas de pruebas existen para detectar. Y con AI Agent Testing 2.0, ahora lo hacen.
Probar los agentes de IA con rigor no es solo mitigar riesgos: es una ventaja competitiva. Las organizaciones que despliegan con confianza, iteran rápido y demuestran compliance avanzarán más deprisa y con más seguridad que las que aún priorizan a duras penas sus programas de pruebas.
Ganar y mantener la confianza del cliente es más que superar la revisión de lanzamiento. Significa requisitos que aguantan en producción, evaluadores fiables a lo largo del tiempo y una cobertura de pruebas que refleja cómo se comportan los clientes, no cómo el equipo imaginó que lo harían.
Con AI Agent Testing 2.0, las pruebas rigurosas no se detienen en el lanzamiento. Crecen con su agente, de modo que puede respaldar cada conversación: confianza en el lanzamiento, confianza a escala.
