El pasado mes de diciembre, un importante minorista lanzó un nuevo agente de IA de atención al cliente. En cuestión de días, actores malintencionados lo habían manipulado para que hablara de temas que no tenían nada que ver con el comercio minorista, pero que tenían un increíble potencial de dañar la marca. La explicación del proveedor: las barreras de seguridad del agente se habían «configurado incorrectamente de forma inadvertida». La corrección llegó rápidamente.
Pero las implicaciones perduraron: una implementación de IA con abundantes recursos, construida sobre una destacada plataforma de agentes de IA, se había puesto en marcha sin ninguna forma sistemática de verificar que sus restricciones de comportamiento estuvieran funcionando realmente. La configuración incorrecta no se detectó en las pruebas ni en el control de calidad, y la marca se enteró al mismo tiempo que internet.
Si bien algunas de estas historias sobre el fallo de un agente de IA dan lugar a titulares memorables, también son casos atípicos. La realidad más común, aunque igual de perjudicial, es más silenciosa: agentes de IA que, con seguridad, dan a un cliente un plazo de devolución incorrecto, o uno que pasa por alto un requisito de cumplimiento en una o dos conversaciones. Estos fallos rara vez aparecen en las noticias, pero sí se reflejan en las puntuaciones de satisfacción del cliente (CSAT), en las tasas de escalamiento y en la pérdida de clientes.
Las empresas están implementando agentes de IA más rápido de lo que pueden validarlos de manera eficaz, y la brecha no se está cerrando. Históricamente, crear un programa de pruebas riguroso ha requerido tanto esfuerzo manual, criterio humano y mantenimiento continuo que la mayoría de los equipos se ven obligados a priorizar: cubrir los escenarios obvios, esperar lo mejor y parchear los problemas a medida que surgen en producción. Otros intentan acortar el trabajo con jueces LLM no validados, y terminan con programas de pruebas que parecen funcionar pero que en realidad no verifican que el agente esté listo para producción.
La incómoda verdad sobre las pruebas de agentes de IA es que muchos de estos programas están diseñados para el día del lanzamiento, en lugar de para las realidades de la producción cotidiana. Pueden ser lo suficientemente exhaustivos para superar una revisión interna, pero en muchos casos se erosionan a partir de ahí.
Dónde fallan las pruebas de agentes de IA
¿Por qué las pruebas, una parte tan fundamental de la implementación de agentes de IA, son tan difíciles de acertar a escala?
Cada paso de este proceso es extenso y requiere tiempo y cuidado. Un equipo debe definir cómo se ve lo «excelente» en términos precisos y verificables, configurar evaluadores que atraviesen el ruido y detecten los fallos reales, y crear una cobertura de pruebas que refleje cómo se comportan realmente los clientes. Cada actualización de modelo, revisión de prompt o nuevo flujo de trabajo reinicia el ciclo, poniendo a prueba hasta dónde pueden estirarse de forma realista los recursos.
Esto da como resultado un programa que puede parecer exhaustivo por fuera, pero que por dentro está plagado de agujeros.
Eso es lo que las mejoras de hoy en la suite de Pruebas Automatizadas de Cresta AI Agent están diseñadas para resolver, con cuatro nuevas capacidades, cada una dirigida a un punto donde los programas de pruebas históricamente han tenido dificultades para escalar o mantenerse a lo largo del tiempo.
Adherencia a los requisitos: la IA construye la base, los expertos la refinan
Los requisitos han residido típicamente en PRD, directrices de marca o listas de verificación de cumplimiento. Lo que rara vez producen es algo con lo que un evaluador LLM pueda realmente calificar.
AI Agent Testing 2.0 cambia eso al generar la lista inicial de requisitos directamente a partir de PRD, CSV o documentación existente, acelerando un proceso que de otro modo llevaría días, o incluso semanas para casos de uso complejos. Cresta ejecuta un diagnóstico de un solo clic que señala posibles problemas: lenguaje no verificable, criterios de múltiples parámetros que el LLM no puede calificar de forma fiable y requisitos que dependen de un contexto al que el agente no tiene acceso. Los expertos en la materia luego revisan, refinan y aprueban.
Cada requisito aprobado se convierte directamente en un evaluador LLM: una única fuente de verdad que se ejecuta tanto en las conversaciones de prueba como en el tráfico de producción.
La calidad de los evaluadores depende de la calidad de los propios requisitos. Cada requisito es binario: el agente hizo algo o no lo hizo. Un verdadero requisito tiene una condición clara de aprobación, una condición clara de fallo y es defendible en una auditoría:
- El agente debe verificar la identidad de quien llama antes de revelar los detalles 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 proporcionar asesoramiento financiero específico.
- El agente debe incluir un aviso de privacidad si la conversación abordó datos personales de salud.
Cada requisito también se etiqueta como imprescindible («must-have») o deseable («nice-to-have»), una distinción que cambia la forma en que las organizaciones priorizan los fallos. Una tasa de aprobación del 98 % parece sólida hasta que uno se da cuenta de que el 2 % de los fallos afectan todos a requisitos imprescindibles. Separar los bloqueadores imprescindibles de las mejoras deseables significa que el programa de pruebas revela aquello sobre lo que los equipos realmente necesitan 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, en que sigan funcionando de manera eficaz. Algunos se basan en evaluadores listos para usar que están destinados a medir aspectos como la empatía o la precisión en varios casos de uso, pero los evaluadores genéricos pasan por alto el matiz específico del dominio que determina si una respuesta es realmente correcta para un negocio determinado. Otros crean los suyos propios, pero carecen de retroalimentación sistemática sobre si el evaluador es demasiado estricto, demasiado indulgente o simplemente inconsistente. Un evaluador que falla no solo produce ruido; induce activamente a error. Los falsos positivos hacen perder tiempo persiguiendo problemas que no son reales. Los falsos negativos dejan pasar fallos reales sin que se detecten.
El enfoque de Cresta comienza con 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 luego otorga a cada evaluador basado en requisitos una puntuación de precisión mensurable. Los equipos seleccionan un grupo de requisitos para calibrar y una fuente de conversaciones, y luego revisan cómo el evaluador etiquetó una muestra y proporcionan retroalimentación donde el criterio de la IA no dio en el blanco. Cresta devuelve una puntuación F1 por requisito, una única métrica que equilibra si el evaluador está detectando lo que debería sin generar demasiadas falsas alarmas, de modo que los equipos sepan exactamente qué evaluadores son fiables y cuáles necesitan refinarse más.
En un cliente minorista, la calibración de evaluadores redujo en más de la mitad la tasa de fallos por falsas alarmas. El equipo dejó de investigar ruido y comenzó a investigar errores reales.
Este proceso no es solo diagnóstico, sino que también hace que la iteración sea mensurable. Después de refinar un requisito, los equipos pueden volver a ejecutar sobre el mismo conjunto de conversaciones etiquetadas y ver si la precisión mejoró, lo que convierte la calibración en un bucle de retroalimentación vivo, en lugar de una configuración única.
Una cobertura que refleja cómo se comportan realmente los clientes
Crear casos de prueba a mano a menudo significa que la cobertura refleja lo que el equipo tuvo la capacidad y los recursos para producir, no necesariamente cómo se comportan realmente los clientes. La mayor parte de la larga cola del comportamiento real de los clientes (los casos límite, las formulaciones inusuales, las vías inesperadas) queda sin probar.
AI Agent Testing 2.0 genera automáticamente casos de prueba a partir de cuatro fuentes, cada una fundamentada en señales reales:
- Violaciones de requisitos: Cuando una conversación de producción cerrada revela una brecha de requisitos, la IA aplica ingeniería inversa a un Synthetic Customer (una persona simulada, basada en datos de conversaciones con clientes) alineada con el escenario, y a un evaluador para validar exhaustivamente la corrección. Los equipos pueden ejecutar inmediatamente el nuevo caso de prueba para confirmar que la corrección se sostiene antes de que el agente avance.
- Retroalimentación 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 esa retroalimentación: nombre, descripción, comportamiento esperado y un evaluador alineado con los criterios específicos. Cada caso de prueba se puede rastrear hasta su retroalimentación de origen, lo que permite a los equipos hacer un seguimiento de lo que se detectó, lo que se corrigió y lo que 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 están fundamentadas en fuentes aprobadas. Las pruebas de un solo artículo evalúan si la respuesta del agente está respaldada por el artículo correcto, y las pruebas de varios artículos comprueban si el agente está sintetizando correctamente la información de dos o más artículos para consultas más complejas.
- Principales preguntas de los clientes a partir de conversaciones reales: Cresta extrae las preguntas más frecuentes de las conversaciones reales con clientes y las convierte en casos de prueba. Esto permite que la cobertura se extienda más allá de lo documentado en la base de conocimiento y capture el lenguaje real que los clientes utilizan para hacer preguntas.
Los casos de prueba se pueden combinar con Cresta Synthetic Customers, que generan personas derivadas de datos 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 realmente sus clientes, lo que 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 en que se califica reflejan la realidad. La cobertura crece a medida que el agente evoluciona, se acumula la retroalimentación de los revisores y se producen más conversaciones con el tiempo.
En una implementación de comercio electrónico, las pruebas de variación revelaron que el agente gestionaba correctamente las solicitudes de devolución estándar, pero fallaba con el planteamiento de una compra de regalo: «Quiero devolver esto, lo recibí como regalo». La formulación activó una vía lógica que la ruta feliz no había ejercitado. Se detectó sin conexión, antes de que ningún cliente lo viera.
Nuevos evaluadores LLM listos para usar: califique la respuesta según lo que está en juego, no solo según la respuesta
Incluso los equipos con evaluadores bien calibrados se topan con un modo de fallo específico: los criterios de calificación no coinciden con lo que el caso de uso realmente requiere. Un evaluador estricto aplicado a una respuesta abierta de preguntas frecuentes marca como fallos variaciones inofensivas de redacción, mientras que uno indulgente aplicado a un guion de cumplimiento deja pasar omisiones importantes. Las evaluaciones producen señal, pero no necesariamente la correcta.
AI Agent Testing 2.0 también amplía la biblioteca de Cresta de evaluadores LLM listos para usar y alineados con expertos, con tres opciones más precisas para calificar las respuestas de los agentes. Donde el evaluador Golden Response existente comprueba la equivalencia semántica, los nuevos evaluadores permiten a los equipos elegir el nivel de rigor adecuado para el caso de uso particular, en lugar de aplicar un único estándar de manera uniforme:
- Exhaustividad («Completeness») comprueba que el agente proporcionó todas las afirmaciones definidas en la respuesta aprobada, permitiéndose información adicional: adecuado para las preguntas frecuentes y las respuestas de soporte general.
- Precisión («Accuracy») comprueba que el agente proporcionó únicamente las afirmaciones definidas en la respuesta aprobada: adecuado para los flujos de trabajo guiados por SOP donde importa ceñirse al guion, como los guiones de resolución de problemas, el lenguaje de cumplimiento y los procesos guiados.
- Exhaustividad y precisión («Completeness & Accuracy») comprueba que el agente proporcionó todas las afirmaciones definidas y nada más. Esta es la opción más estricta, diseñada para salidas deterministas: plantillas, redacción regulada y casos de prueba donde se requiere un comportamiento exacto y cualquier desviación, ya sea por adición u omisión, se considera un fallo.
Juntos, los tres evaluadores ofrecen a los equipos una comprensión más clara de qué tipo de fallo ha ocurrido realmente, y un enfoque objetivo para calificar las respuestas de los agentes. Estos evaluadores son calibrados por expertos en la materia y validados en distintos casos de uso y sectores, lo que les permite ofrecer juicios fiables, lo adivinó, listos para usar.
El nuevo listón para una IA lista para producción
Afortunadamente, el contratiempo de ese importante minorista fue un caso límite. Pero los casos límite son exactamente lo que los programas de pruebas existen para detectar. Y con AI Agent Testing 2.0, ahora lo hacen.
Las pruebas rigurosas de agentes de IA no son solo una mitigación de riesgos; son una ventaja competitiva. Las organizaciones que pueden implementar con confianza, iterar rápidamente y demostrar el cumplimiento avanzarán más rápido y de forma más segura que las que todavía están priorizando sus programas de pruebas.
Ganar y mantener la confianza del cliente significa más que superar la revisión de lanzamiento. Significa requisitos que se sostienen en producción, evaluadores en los que puede confiar a lo largo del tiempo y una cobertura de pruebas que refleja cómo se comportan realmente 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. Escalan con su agente, de modo que cada conversación es una que puede respaldar: confianza en el lanzamiento, confianza a escala.
