Por qué la mayoría de proyectos de agentes de voz se atascan justo antes de lanzar

Hace unas semanas me llegó un mensaje de un responsable de operaciones de una empresa de servicios financieros en Madrid. Llevaban cuatro meses desarrollando su agente de voz con IA —plataforma de conversación propia, voz generativa, modelo ajustado a su sector— y estaban en el punto en que querían lanzar. El mensaje decía, textualmente: —"Ya lo tenemos listo. El equipo técnico dice que el sistema puede gestionar miles de llamadas simultáneas. ¿Qué necesitamos de vuestra parte?"

Me detuve antes de responder.

No porque la pregunta fuera difícil. Sino porque era la quinta vez ese mes que recibía la misma pregunta formulada de la misma forma. Y porque la respuesta siempre empieza por desmontar algo que el equipo técnico ha dado por hecho sin comprobarlo.

El sistema que habían construido sí podía gestionar cientos de sesiones de audio simultáneas. El modelo procesaba texto. El motor de voz generaba audio. La lógica de conversación funcionaba sin problemas. En un entorno de pruebas, el agente respondía, gestionaba objeciones, cualificaba leads con precisión. Todo perfecto.

El problema es que ninguna de esas sesiones estaba llegando a un teléfono real.

La confusión de base que frena a casi todos los proyectos

Esto es lo que cuesta más entender cuando se trabaja con agentes de voz: la IA y la telefonía son dos mundos que no se comunican solos. La IA vive en la nube, escala en servidores, no tiene límites físicos obvios. La telefonía tiene reglas, límites regulatorios y sistemas de protección que llevan décadas en funcionamiento. Cuando las dos se juntan sin la infraestructura correcta entre medias, el resultado es siempre el mismo: el agente habla, pero no llega a ningún sitio.

Cuando un agente de IA "llama", lo que hace técnicamente es abrir una sesión WebRTC: un canal de audio entre el sistema y el modelo de lenguaje. Esa sesión puede escalar hasta donde llegue el servidor. No hay un operador de por medio, no hay red pública, no hay ningún número de destino real al otro lado.

Para que ese audio llegue a un teléfono —al móvil de un cliente, al fijo de una empresa, a cualquier número del mundo— hace falta cruzar una frontera: la PSTN, la red telefónica pública. Y ese cruce no lo gestiona la plataforma de IA. Lo gestiona el operador de telecomunicaciones.

Una sesión WebRTC no es una llamada telefónica. Esta distinción, que debería ser obvia, es el origen del 90% de los problemas que veo en proyectos de agentes de voz cuando llegan a la fase de escalado.

Los tres límites que la IA no ve

Cuando una llamada tiene que llegar a un número de teléfono real, entran en juego tres elementos que tienen límites físicos y regulatorios. No son configuraciones de software que se pueden ajustar desde la plataforma de IA. Son la realidad de cómo funciona la telefonía desde hace décadas.

El SIP trunk. Es la conexión que une la infraestructura de voz IP con la red telefónica pública. El punto de entrada y salida de todas las llamadas. No es infinito: tiene una capacidad máxima de llamadas simultáneas definida en el momento de contratarlo con el operador. No escala automáticamente. No lo controla la plataforma de IA. Si el trunk tiene capacidad para 30 llamadas simultáneas, la llamada número 31 no pasa. No se degrada. No se pone en espera indefinida. Simplemente no pasa.

Los canales salientes. Son la concurrencia real en telefonía. 30 canales significa que pueden estar activas 30 llamadas al mismo tiempo. Cuando el sistema de IA intenta abrir más llamadas de las que permiten los canales disponibles, las adicionales se rechazan directamente. El límite es duro, sin matices:

• 30 canales → hasta 30 llamadas simultáneas activas
• 60 canales → hasta 60 llamadas simultáneas activas
• 120 canales → hasta 120 llamadas simultáneas activas

Esta es la definición real de concurrencia en telefonía. No es una abstracción. Es un número concreto acordado con el operador.

El CPS (calls per second). Es la velocidad a la que se pueden iniciar llamadas nuevas, medida en llamadas por segundo. Es el segundo gran limitador, completamente independiente del número de canales disponibles. Un sistema puede tener 100 canales libres y aun así no poder lanzar 100 llamadas de golpe si el CPS configurado es 5. Los agentes de IA sin control de CPS pueden disparar este valor a 50 o 100 en cuestión de segundos, porque el sistema es automático y nadie le pone freno.

Esto es lo que generan los distintos niveles de CPS desde el punto de vista del operador:

• 2–3 CPS: tráfico bajo o pruebas. Normal, sin alarmas.
• 5 CPS: campañas estándar. Aceptable con buena configuración.
• 10+ CPS: campañas grandes. Requiere whitelist y coordinación previa con el carrier.
• +20 CPS: riesgo alto. Posible bloqueo o throttling automático.

Qué pasa cuando el tráfico no se controla

Los carriers y operadores tienen sistemas automáticos que detectan patrones de tráfico anómalos. No analizan solo el volumen: analizan la forma del tráfico, su regularidad, la duración de las llamadas, la tasa de contestación, el comportamiento del CLI de origen.

Los agentes de voz con IA son especialmente susceptibles a activar estas detecciones si no se configuran correctamente. El motivo es simple: el sistema es automático y puede lanzar llamadas muy rápido sin ningún tipo de control humano.

Un flujo de tráfico sano tiene esta pinta: 3 CPS, 3 CPS, 3 CPS, 3 CPS. Regular, predecible, coherente con el comportamiento de un sistema bien configurado.

Un sistema de IA sin control genera esto: 0 CPS, 0 CPS, 0 CPS, 50 CPS, 0 CPS, 0 CPS. Picos violentos seguidos de silencios. Es exactamente el patrón que los sistemas antifraude están diseñados para detectar y cortar. No porque las llamadas sean fraudulentas, sino porque ese patrón es idéntico al de un ataque de spam masivo.

Hay otros patrones que también activan alarmas. Cuando miles de llamadas salen con el mismo número de origen CLI en poco tiempo, los operadores lo interpretan como robocalling. Cuando hay muchas llamadas de 1 o 2 segundos —porque el usuario cuelga en cuanto oye que es un sistema automático— los sistemas lo identifican como escaneo de números o spam. Cuando la tasa de llamadas rechazadas es muy alta durante los primeros minutos, se aplican filtros automáticos que afectan a toda la numeración.

Las consecuencias son inmediatas y dolorosas: rutas bloqueadas, errores SIP 403 o 503, llamadas que no se completan, y en los casos más graves el CLI marcado como sospechoso por los operadores. Recuperar un número en esa situación puede llevar semanas. He visto empresas perder campañas completas —y la numeración que habían construido durante meses— por esto.

Las cuatro preguntas que hay que responder antes de lanzar

Antes de activar cualquier campaña outbound con agentes de voz, hay cuatro preguntas que permiten detectar el 90% de los problemas antes de que ocurran:

• ¿A qué CPS vais a lanzar las llamadas? Esta es la pregunta más reveladora. Si el equipo técnico no sabe responder, normalmente significa que no tienen control de tráfico configurado. El agente llama cuando quiere, a la velocidad que quiere.
• ¿Cuál es la duración media esperada de cada llamada? Junto con el CPS, permite calcular la concurrencia estimada. Un sistema que lanza a 5 CPS con llamadas de 4 minutos de media genera aproximadamente 20 llamadas simultáneas. Si los canales disponibles son 15, habrá llamadas rechazadas desde el primer día.
• ¿Cuántos canales tienes disponibles? Si la concurrencia estimada supera los canales disponibles, el sistema empieza a perder llamadas desde el primer segundo. Y si no hay monitorización, nadie lo nota hasta que los números no cuadran al final de la semana.
• ¿Tienes pacing configurado entre la IA y el SIP trunk? Si la respuesta es no, el sistema puede generar picos de CPS que activen las protecciones de los carriers, independientemente de cuántos canales tenga disponibles.

Cuando hago estas cuatro preguntas y el equipo técnico puede responder todas con números concretos, sé que el proyecto está bien estructurado. Cuando no pueden responder la primera, normalmente tampoco saben las otras tres.

La pieza que conecta la IA con la red telefónica

En netelip somos operadores VoIP con más de 20 años gestionando tráfico de voz real. El SIP trunk, los canales, el CPS, las relaciones con los carriers —eso es exactamente lo que hacemos. No es un producto nuevo. Es lo que llevamos haciendo desde antes de que existieran los agentes de IA.

Cuando un agente de voz —ya sea con Retell AI, LiveKit, Gemini Live, ElevenLabs, Ultravox, Vocals o cualquier otra plataforma que hable SIP— necesita llamar a teléfonos reales, el SIP Trunk de netelip es la capa que conecta ese agente con la red telefónica pública. Y esa conexión incluye:

• Números virtuales como CLI. El número que ve el cliente en pantalla cuando le llama el agente. Puede ser de Madrid, de Barcelona, de México DF, de cualquiera de los 58 países donde tenemos numeración. El CLI importa: un número local incrementa significativamente la tasa de contestación frente a un número desconocido o internacional.
• Control de canales y CPS configurado correctamente desde el inicio. No según lo que quiere lanzar el agente de IA, sino según lo que la red puede absorber de forma sostenida sin activar alarmas. Siempre se empieza de forma conservadora: 30 canales, CPS de 3. Se observa el comportamiento. Se escala cuando los datos confirman que la infraestructura aguanta.
• Escalado progresivo acompañado. El proceso de aumentar la capacidad —de 30 a 60 canales, de 60 a 120, de 120 a más— no es solo una operación técnica. Requiere conocer cómo responde el tráfico a cada incremento, qué métricas vigilar, cuándo es seguro subir y cuándo hay que estabilizar primero. Llevamos décadas haciendo esto con call centers y plataformas de contact center. Ahora lo hacemos también con agentes de IA.
• Documentación de integración completa. En el Centro de Ayuda de netelip tenemos guías paso a paso para conectar el SIP trunk con las principales plataformas de agentes de voz. No es un proceso que requiera semanas de desarrollo. El equipo de Madrid que mencionaba al principio tardó tres días desde que recibió las credenciales hasta la primera llamada real.

El agente de IA sabe conversar. Nosotros sabemos llamar. Son dos capas diferentes, y las dos son necesarias.

Lo que el equipo de Madrid entendió esa semana

Respondí al mensaje con esto: —"El sistema que tenéis funciona. Pero ahora mismo está hablando consigo mismo. Para que llame de verdad, necesitáis un SIP trunk con los canales y el CPS correctamente configurados. Eso no lo hace la plataforma de IA: lo hace el operador."

Su siguiente pregunta fue: —"¿Cuántos canales necesitamos para 3.500 llamadas al mes?"

Y esa respuesta es más sorprendente de lo que parece. Para 3.500 llamadas al mes, distribuidas en jornadas de 8 horas con una duración media de 4 minutos por llamada, el cálculo de tráfico da aproximadamente 1,5 Erlang —la unidad estándar en telecomunicaciones para medir volumen de tráfico. Con ese volumen, técnicamente bastan 5 canales.

Empezamos con 30, porque es la práctica correcta. Da margen para picos de tráfico, reintentos, días de mayor actividad, y campañas paralelas si las necesitan. Dimensionar al mínimo es el camino más corto hacia los problemas.

Esa primera semana hicieron 1.260 llamadas reales —número de Madrid como CLI, clientes de toda España— sin ningún bloqueo, sin ninguna alerta de carrier, sin perder ninguna ruta.

El agente de IA era exactamente el mismo que habían construido en cuatro meses. Lo único que cambió fue que por fin tenía donde llegar.

En el próximo artículo explico qué pasa exactamente cuando una campaña de agentes de voz escala sin control de tráfico. Cómo funciona el cálculo Erlang en la práctica, qué patrones activan el bloqueo automático de los carriers, y qué métricas —el ASR y el ACD— son las que revelan de verdad si una campaña está funcionando o está a punto de bloquearse.

Consulta nuestras guías de integración del SIP Trunk de netelip con las principales plataformas de agentes de voz en el Centro de Ayuda.