Cómo hacer load testing de un agente de voz para despliegue enterprise

La mayoría de las demos de agentes de voz ocurren con una persona llamando, una sala silenciosa y una conexión de red limpia. Producción no funciona así. Un lunes a las 9:00, tu agente puede estar gestionando trescientas llamadas simultáneas, la mitad desde redes móviles con pérdida de paquetes, algunas de clientes que interrumpen al agente a mitad de frase. El load testing es cómo descubres qué pasa antes de que lo descubran tus clientes.

Hacer load testing a un agente de voz significa simular volumen de llamadas, concurrencia y condiciones de red realistas para medir si la latencia, la precisión y la estabilidad aguantan bajo estrés de producción — no si el agente responde correctamente en una única llamada ideal. Es un ejercicio distinto al testing funcional, que comprueba si el agente da la respuesta correcta. El load testing comprueba si sigue dando la respuesta correcta, a la velocidad correcta, cuando otras mil llamadas están ocurriendo al mismo tiempo.

Por qué esto se salta

Los proyectos de agente de voz se suelen definir, construir y aprobar sobre demos funcionales: ¿el agente gestiona bien los veinte intents principales? Es un primer filtro razonable, y también es el único filtro por el que pasan la mayoría de los despliegues antes del go-live.

La brecha aparece tres semanas después del lanzamiento, no el primer día. Gartner estima que el 40% de los proyectos de IA agéntica se cancelarán antes de 2027, y cita como causa principal el comportamiento impredecible bajo condiciones operativas reales. Un agente de voz que gestionó 50 llamadas de prueba perfectamente puede degradarse de formas que nunca aparecen en una demo: la latencia sube hasta el punto en que los clientes cuelgan, la precisión del reconocimiento de voz cae con ruido de fondo real, o el sistema se cae directamente cuando el volumen de llamadas supera lo que nadie testeó.

Nada de esto requiere un bug. Sólo requiere el tipo de carga que una demo nunca simula.

Qué mide realmente un load test

Un load test de agente de voz debe producir números sobre cuatro cosas, y cada una corresponde a un modo de fallo real si sale mal.

Latencia de respuesta bajo concurrencia. ¿Cuánto tarda el agente en responder cuando es una de mil llamadas simultáneas, no la única? El número que importa es la latencia P95 — el tiempo de respuesta del 5% más lento de las interacciones, no la media. Una demo te enseña la media. Producción te castiga por el P95.

Precisión del reconocimiento de voz con ruido. El audio de un contact center no es limpio. Los clientes llaman desde coches, almacenes y salas ruidosas. El Word Error Rate hay que testearlo con ruido de fondo inyectado a niveles realistas, no contra una grabación limpia de estudio.

Gestión de barge-in y solapamiento. Los clientes reales interrumpen. Hablan por encima del agente, se corrigen a mitad de frase o empiezan a responder antes de que el agente termine la pregunta. Un load test tiene que medir cómo se comporta el sistema cuando el habla se solapa, no sólo cuando no se solapa.

Estabilidad bajo carga máxima sostenida. ¿Puede el sistema mantener mil llamadas concurrentes durante una hora sin degradarse, sin dropear llamadas y sin caer silenciosamente a una respuesta de fallback peor? Éste es el test que la mayoría de los equipos se saltan porque requiere infraestructura para simularlo, no sólo un script de test.

Cómo construir un load test: 6 pasos

1. Define tu escenario de pico antes de testear nada. Coge tu volumen real o proyectado de llamadas en la hora más ocupada del día más ocupado — no el volumen medio diario. Si aún no tienes histórico, usa el volumen que asume tu business case a escala, no el volumen con el que lanzas.

1. Simula llamadas concurrentes a ese pico, ni por encima ni por debajo. Testear a 100 llamadas cuando tu pico son 1.000 no te dice nada sobre el punto de fallo que importa. Herramientas construidas para esto — la propia metodología de auditoría de Lexic, por ejemplo, ejecuta tests sintéticos de estrés a niveles definidos de concurrencia como 1.000 llamadas simultáneas sobre un proveedor de telefonía como Telnyx — existen precisamente porque escribir un arnés de carga custom para voz es un proyecto de ingeniería no trivial en sí mismo.

1. Inyecta condiciones de ruido realistas, no audio limpio. Testea el Word Error Rate con ruido de fondo inyectado a un nivel que coincida con tu canal real — 75 dB es una proxy razonable de la planta de un contact center o de un cliente llamando desde un espacio público.

1. Testea el barge-in explícitamente, como escenario propio. Guiona llamadas de test donde el caller sintético interrumpe, habla por encima del agente o responde antes de que la pregunta termine. Mide la tasa de error de solapamiento por separado de la latencia con turnos limpios — son modos de fallo distintos con causas raíz distintas.

1. Mantén la carga durante un periodo sostenido, no un pico. Un test de spike de cinco minutos te dice si el sistema arranca bajo carga. Un test sostenido de una hora a concurrencia pico te dice si aguanta. La mayoría de los incidentes de producción ocurren en la segunda hora, no en el minuto cinco.

1. Puntúa el resultado contra un umbral pass/fail que fijaste antes del test, no después. Decide qué latencia P95, qué Word Error Rate y qué resultado de estabilidad es aceptable antes de ver los números. Testear sin un umbral pre-acordado convierte cada resultado en una negociación.

Load testing vs. auditoría: preguntas distintas, ambas necesarias

El load testing responde a una única pregunta: ¿rinde el agente bajo estrés simulado antes de salir a producción? Es necesario, y también es incompleto — porque una simulación, por muy realista que sea, sigue siendo una simulación.