Red team de la demo de un agente de soporte de IA antes del lanzamiento

La demo responde con cortesía. Un cliente real pregunta lo mismo en otro idioma, con una errata, una amenaza de reembolso y un caso límite de política. Ahí es donde el agente gana confianza o la pierde.

Una demo muestra la mejor paráfrasis; tu trabajo es encontrar la peor y conservar el marco que la detectó.

• Mantén aproximadamente el 25% de los casos prelanzamiento como adversariales o críticos; una suite prelanzamiento con esa proporción expuso cada problema que valía la pena corregir antes del lanzamiento.
• Revalida la misma intención a través de paráfrasis e idiomas.
• Repite cada caso de seguridad hasta que el resultado sea estable.
• Construye un conjunto de 50 a 100 casos a partir del trabajo existente y añade cada incidente de producción como caso de regresión permanente.
• Reporta las correcciones verificadas por separado de los incidentes contenedos.

Empieza con la peor paráfrasis, no con la demo

Construye el primer lote a partir de los casos que más temes: paráfrasis hostiles, revalidaciones multilingües, ejecuciones repetidas y casos límite de política. Responder a la versión pulida no basta. Debe sobrevivir a la versión que un cliente cansado envía a altas horas de la noche.

Escribe cada caso como una entrada, un comportamiento esperado y un modo de fallo. Si no puedes decir qué debe hacer el agente, el caso no es testeable.

Una demo que pasa es una señal limitada; un conjunto de red team debería revelar los fallos que no querrías descubrir en una conversación con un cliente.

Construye un conjunto de evaluación que se comporte como trabajo real

Extrae casos del trabajo existente, no de la imaginación. Incluye la solicitud de reembolso, el seguimiento airado, la pregunta llena de erratas, el mensaje en otro idioma y el caso que incomodó a tu equipo de soporte. Evalúa agentes con escenarios realistas en lugar de idealizados.

Agrupa los casos por intención, no por redacción. Las intenciones de reembolso pueden llegar como pregunta, exigencia, queja o medio frase. El agente debe reconocer la intención y elegir la acción segura.

Si estás probando el producto de agente de IA avanzada de Zendesk, pruébalo donde realmente funcionará: canales de mensajería y correo electrónico, más una Chat API para integraciones personalizadas.

Un conjunto está listo solo cuando incluye los casos incómodos que tu equipo de soporte ya conoce.

Ejecuta el agente hasta que deje de tener suerte

La función Test Run de Macha te permite procesar un ticket, correo o documento real de Zendesk a través del agente configurado en un sandbox prelanzamiento.

Observa la ruta completa, incluidas las llamadas a herramientas, las transferencias y la respuesta final. Respuestas finales limpias pueden ocultar un paso roto. Quieres ver al agente hacer el trabajo, no solo decir lo correcto.

La simulación Test Run de Macha consume créditos por cada acción de IA, con costos que van de 0,5 a 9 según el modelo y GPT-5.4 Mini configurado en 1 por defecto.

Ejecuta cada caso repetidamente. Un agente puede tener suerte en una ejecución y fallar en la siguiente. Una ejecución se justifica cuando el mismo caso produce el mismo fallo, o el mismo paso, en las repeticiones.

Evalúa la salida contra el comportamiento esperado, no contra el tono. Las respuestas incorrectas pero corteses siguen siendo fallos. Las respuestas correctas pero directas pueden ser aceptables.

Detenerse tras un paso es la trampa. Vuelve a ejecutar el caso tras un cambio de prompt, un cambio de modelo o una nueva política. Añade la versión rota al conjunto de regresión cuando se rompa.

Mide correcciones verificadas, no daños contenedos

Tras el lanzamiento, separa las correcciones verificadas de los incidentes contenedos. Un incidente contenido significa que el agente hizo algo malo y detuviste el daño. Una corrección verificada significa que la misma entrada ya no produce el fallo. Son puntuaciones diferentes.

Reporta la diferencia. La contención protege al cliente en el momento. La verificación protege al siguiente cliente del mismo error.

Mantén vivo el conjunto de regresión. La próxima versión no puede reintroducir en silencio un fallo corregido si ese fallo sigue en el conjunto de pruebas.

Rastrea los casos corregidos, los que siguen fallando y los que solo parecen corregidos porque se estrechó el prompt. La medición gana confianza cuando un incidente corregido se mantiene corregido y un incidente nuevo se convierte en una nueva prueba.

Cuando llegue el próximo incidente, ya tendrás el caso, el comportamiento esperado y la prueba de regresión esperándolo.