Cómo crear tu propio agente IVR con IA

Un teléfono, una conversación y una tarea concreta. Conecta la telefonía con tus modelos de IA locales para construir un asistente que escuche, pida los datos que faltan y prepare una gestión con la confirmación del usuario.

Imagina llamar a un servicio de asistencia y explicar: «Quiero comunicar una incidencia con un equipo». El asistente te pregunta a qué elemento te refieres, acepta una corrección y resume los datos antes de continuar. La conversación se convierte en la entrada de una aplicación que puedes diseñar alrededor de tu propio servicio.

Un agente IVR con IA combina telefonía, reconocimiento de voz, interpretación del lenguaje y síntesis de audio. Puedes usar ese patrón para recoger solicitudes, consultar información autorizada o preparar el trabajo que después continuará una persona. La clave está en conectar esas piezas con un procedimiento claro.

En esta guía recorreremos esa construcción: elegir la primera tarea, conectar la llamada con los modelos, controlar las confirmaciones y medir la espera. Nos apoyamos en una implementación de laboratorio con Asterisk, Pi y Qwen, con un prompt para construir tu agente y gráficas que ayudan a decidir qué mejorar.

Partimos de modelos que ya funcionan en local. El objetivo es construir un prototipo que recoja y confirme una solicitud de prueba. A partir de ahí podrás diseñar la conexión con tu sistema de gestión. La guía explica la arquitectura y las reglas de aplicación; no entrega una centralita configurada ni un despliegue listo para producción.

1. Elige una tarea que tu agente pueda completar

Empieza describiendo qué debe conseguir una llamada. Para nuestro ejemplo, el resultado es una propuesta con la categoría, el elemento afectado y una descripción, confirmada por quien llama.

Este pequeño contrato te permite probar la lógica antes de conectar un teléfono. Introduce una petición por texto, comprueba qué campo falta y añade una corrección. Si ese recorrido no funciona, la voz añadirá más variables al diagnóstico.

Para pasar después a una consulta o una escritura real, define un adaptador con las operaciones exactas que necesita el agente. La autenticación, los permisos y la comprobación del resultado pertenecen a esa integración.

2. Organiza las piezas: telefonía, voz y lógica del agente

El diseño separa responsabilidades para poder comprobarlas por separado.

Estos modelos identifican la combinación utilizada en nuestras pruebas, no un requisito para tu agente. Puedes elegir otros modelos locales de ASR, lenguaje y TTS con interfaces compatibles; comprueba sus formatos de entrada, contratos de salida y capacidades antes de conectarlos. Las mediciones siguientes no acreditan el rendimiento de esas alternativas.

Los nombres identifican la configuración revisada; estos resultados no comparan modelos ni aíslan el rendimiento de sus pesos. Qwen documenta por separado sus familias de reconocimiento de voz y síntesis de voz. Pi aporta el entorno de ejecución del agente; el código de la aplicación establece sus restricciones.

Llamante → Asterisk → detección de voz → ASR → texto
                                                ↓
                                     Pi + modelo de lenguaje
                                                ↓
                                      intención y campos
                                                ↓
                                       máquina de estados
                                      ↙                  ↘
                               pedir / corregir     confirmar datos
                                      ↑                  ↓
                                      └── respuesta ← adaptador
                                             ↓
                             locución preparada o TTS → llamante

En este patrón de integración, Pi recibe el estado y la intervención, y devuelve una estructura acotada. No tiene herramientas generales de archivos, consola o navegación. El programa decide qué preguntar después y cuándo una operación está permitida.

Esto corrige una simplificación habitual: dar instrucciones al modelo no sustituye a implementar las condiciones del servicio. Una skill puede describir un procedimiento; la aplicación debe comprobar sus reglas. En este intérprete concreto, la carga automática de skills está deshabilitada y se usa una instrucción específica con una herramienta de salida estructurada.

3. Conecta la llamada con el ciclo de conversación

Con la lógica básica definida, el siguiente paso es llevarla a una llamada. En la arquitectura revisada, Asterisk se ocupa de la telefonía y la aplicación intercambia audio mediante un canal WebSocket. El recorrido de integración es el siguiente:

1. Abre una sesión por llamada. Guarda en ella los campos, el estado y la revisión actual. Cada llamante necesita su propio contexto.

2. Espera a que el audio esté disponible. La entrada de la llamada y la conexión de medios son eventos distintos. Reproduce el saludo cuando el canal pueda recibirlo.

3. Detecta una intervención y transcríbela. El detector de actividad de voz delimita el audio que se envía al ASR. Entrega el texto reconocido al intérprete junto con la pregunta y el estado actuales.

4. Convierte el resultado en una transición. Pi devuelve intención y campos; la máquina de estados decide si pedir información, corregirla o solicitar confirmación.

5. Reproduce la respuesta y vuelve a escuchar. Usa una locución preparada para las preguntas fijas y TTS para el contenido variable. Al colgar, cancela los trabajos y temporizadores pendientes.

Para depurar este circuito, verifica cada conexión con una entrada conocida: primero audio a texto, después texto a campos y finalmente texto a voz. Cuando las tres etapas funcionen, intégralas con el gestor de llamadas. Los tiempos de cada etapa te ayudarán a localizar una espera sin atribuírsela automáticamente al modelo de lenguaje.

4. Diseña un diálogo que admita correcciones

Este ejemplo es ficticio y ajeno al caso de uso del que proceden las métricas. Los equipos A y B solo ilustran el diseño; no reproducen una llamada ni representan una organización, sector o ubicación.

Asistente: Soy un asistente automático. ¿Qué problema quiere comunicar?

Persona: Quiero comunicar una incidencia con un equipo.

Asistente: ¿Qué equipo está afectado?

Persona: El equipo de ejemplo A. No responde al encenderlo.

Asistente: Voy a preparar una incidencia: el equipo de ejemplo A no responde al encenderlo. ¿Es correcto?

Persona: No, me refiero al equipo de ejemplo B.

Asistente: Corrijo el elemento afectado al equipo de ejemplo B. ¿Confirma estos datos?

Persona: Sí, correcto.

Asistente: La solicitud de prueba está preparada. No se ha enviado al sistema de gestión.

La corrección debe invalidar la confirmación anterior. Un «sí» solo sirve para el resumen vigente; tampoco debe interpretarse el silencio como consentimiento. Si falta un dato obligatorio, la aplicación vuelve a preguntarlo.

Una integración que sí cree registros necesitará comprobar el resultado del backend antes de anunciar el alta y emitir una referencia devuelta por ese sistema. Nuestro ensayo de preparación no demuestra esa escritura: mantener esta distinción evita convertir una buena conversación en una promesa falsa.

En la consulta ocurre algo parecido. El sistema explica lo que devuelve la lectura autorizada. El modelo no debería completar una fecha de resolución ausente ni conceder acceso basándose únicamente en que una persona conoce una referencia.

5. Copia este prompt para crear tu propio agente

Si ya tienes el reconocimiento de voz, el modelo de lenguaje y la síntesis de voz funcionando en local, puedes pedir a un LLM de programación que construya la aplicación que los conecta. El encargo debe definir el diálogo, el estado de cada llamada y las condiciones para actuar.

Completa los campos entre corchetes con la información de tus servicios y pega el siguiente prompt en tu asistente de programación. No incluyas contraseñas ni datos de personas. Si desconoces algún campo, déjalo pendiente para que el asistente lo aclare antes de implementar esa conexión.

Actúa como ingeniero de software especializado en agentes de voz.
Construye el código de un agente IVR para mi proyecto. Quiero una
aplicación funcional y comprobable, no solo una explicación.

PUNTO DE PARTIDA
Ya tengo tres servicios de modelos funcionando en local:
- ASR: [URL, modelo, protocolo, formato de audio y respuesta].
- LLM: [URL, modelo, protocolo y soporte de salida estructurada].
- TTS: [URL, modelo, voz, formato de respuesta y frecuencia de audio].
Los nombres de las variables de entorno para autenticarlos son:
[nombres de variables, sin introducir sus valores secretos].
No instales, descargues, entrenes ni pongas en marcha modelos.
Consume directamente los servicios existentes. No añadas capas de
intermediación ni diseñes infraestructura o despliegues.

MI AGENTE
- Tarea: [qué debe poder completar el agente].
- Idioma de la conversación: [idioma].
- Campos obligatorios: [campos y reglas de validación].
- Acciones permitidas: [lista cerrada de operaciones].
- Salida de ayuda: [qué ofrecer si la tarea no se puede completar].
Si necesito un punto de partida, usa una incidencia genérica con
categoría, elemento afectado y descripción. Los datos de prueba deben
ser ficticios, sin organizaciones, sectores ni ubicaciones reales.

ENTORNO DEL PROYECTO
Respeta el lenguaje y las convenciones del repositorio existente.
Si parto de cero, usa Node.js y TypeScript. Usa Pi como intérprete
restringido si es compatible con mi endpoint LLM. Comprueba esa
compatibilidad y no inventes soporte de funciones o métodos del SDK.
Si falta información indispensable sobre alguna API, pídeme su
contrato o una respuesta de muestra sin datos sensibles. Avanza
mientras tanto con los módulos que no dependan de esa información.

LÓGICA DEL AGENTE
1. Separa sesión, máquina de estados, interpretación, voz y acciones.
   Cada llamada debe tener sus propios campos, historial acotado,
   temporizadores y tareas pendientes.
2. El LLM solo devuelve intención, campos y una propuesta de
   interpretación. Valida su salida contra un esquema. No le des
   herramientas generales de consola, archivos o peticiones de red.
3. La aplicación decide el siguiente paso: recoger información,
   pedir aclaración, presentar el resumen, confirmar o cancelar.
   Pregunta solo lo que falta. No inventes valores ni completes
   datos dudosos por suposición.
4. Vincula la confirmación explícita a la revisión exacta del resumen
   que ha escuchado el usuario. Una corrección invalida esa
   confirmación y exige presentar de nuevo el resumen. El silencio
   y una confirmación antigua nunca autorizan una operación.
5. Empieza con un adaptador simulado: devuelve una propuesta e indica
   que no se ha enviado. Define una interfaz para incorporar después
   acciones reales con validación, autorización e idempotencia.
   No conectes servicios de negocio reales sin su contrato.
6. Solo comunica éxito cuando la operación correspondiente lo haya
   confirmado. Ante un resultado incierto, informa de la incertidumbre
   y evita repetir automáticamente una escritura.

CICLO DE VOZ Y TELEFONÍA
- Conecta audio de entrada, detección de intervención, ASR,
  interpretación, máquina de estados y respuesta por TTS.
- Normaliza el audio según los formatos realmente admitidos por mis
  servicios; no supongas un códec ni una frecuencia sin comprobarlos.
- Delimita el final de una intervención tanto al recibir silencio
  como ante ausencia de bloques de audio.
- Cuando el usuario interrumpa, detén el audio pendiente, cancela el
  procesamiento cuando sea posible y descarta resultados obsoletos.
- Reutiliza las locuciones fijas; no almacenes respuestas con datos
  del usuario como parte de un catálogo compartido.
- Añade límites configurables de espera, aclaraciones y duración.
  Al terminar, libera la sesión y cancela todas sus tareas.
- Prepara un adaptador para una instalación de Asterisk ya disponible:
  [contrato de conexión y nombres de variables de configuración].
  Espera a que el canal de audio esté listo antes del saludo.
  Si esa conexión no está disponible, conserva un transporte simulado
  y señala que la telefonía real sigue pendiente de verificar.
- Si hay una opción de atención humana configurada, distingue intento
  de transferencia, respuesta y conexión de audio. No inventes destinos
  ni marques una transferencia como completada solo por iniciarla.

ENTREGA Y COMPROBACIÓN
Entrega módulos claros, archivos completos, configuración mediante
variables de entorno sin secretos y un README para ejecutar el agente
contra mis servicios locales. Implementa primero el flujo por texto,
después voz y finalmente el adaptador telefónico.

Incluye pruebas de campos incompletos, correcciones, confirmación
obsoleta, silencio, interrupciones, fallo de un modelo, resultado
incierto de una acción y aislamiento entre sesiones.

Mide por separado ASR, interpretación, acción y TTS. Cuando exista
una llamada real, mide también desde el final de la intervención hasta
el primer audio de la respuesta útil. No confundas generar audio con
haberlo reproducido ni registres grabaciones, transcripciones,
credenciales o datos personales en los logs por defecto.

Ejecuta las comprobaciones que permita el entorno y explica cuáles
has realizado. Distingue servicios simulados de modelos locales reales
y de telefonía real. No inventes latencias, éxitos ni pruebas superadas.

El prompt encarga la construcción del agente: los modelos ya existen y se conectan mediante sus interfaces. Puedes adaptar la tarea y sus campos sin cambiar los principios de confirmación, aislamiento y control de acciones. El código generado necesitará revisión y pruebas con tus servicios antes de atender llamadas.

6. Haz que el agente sepa escuchar, esperar e interrumpirse

1. Preparar las locuciones que nunca cambian

Saludos, menús y preguntas fijas pueden generarse antes de recibir llamadas. El patrón de referencia carga un catálogo de locuciones fijas y comprueba su correspondencia con el texto y su integridad. Las respuestas con datos variables siguen otro recorrido.

Así se elimina la necesidad de generar esos mensajes fijos durante la llamada. Es una propiedad del diseño; no afirmamos un ahorro medido en segundos porque este ensayo no contiene una comparación A/B del saludo. Los audios con datos de personas no deben incorporarse a ese catálogo compartido.

2. Detectar también el silencio que no llega

Esperar únicamente a recibir muestras de audio silencioso puede dejar un turno abierto si el transporte deja de enviar paquetes durante la pausa. El detector revisado combina el análisis de muestras con un temporizador ante ausencia de nuevos bloques.

El principio reutilizable es sencillo: probar una pausa con bloques de silencio y otra con ausencia de bloques. Ambas deben tener una salida definida.

3. Cancelar el trabajo obsoleto cuando alguien interrumpe

La interrupción, o barge-in, no consiste solo en bajar el volumen. Hay que vaciar audio pendiente, cancelar procesamiento cuando sea posible y descartar resultados de una intervención que ya ha sido sustituida.

El controlador WebSocket de Asterisk documenta el comando FLUSH_MEDIA para descartar audio encolado. La aplicación necesita, además, identificar qué generación de trabajo sigue vigente. Documentación de Asterisk.

Por ejemplo, si la persona corrige el identificador de un elemento mientras se genera la respuesta anterior, esa respuesta no debería reaparecer al terminar la inferencia. Un contador de revisión y señales de cancelación permiten implementar esa regla.

4. Hacer explícitas las alternativas de ayuda

El flujo conserva opciones por teclado y una petición de atención humana. Agotar aclaraciones ofrece ayuda; no debe confundirse con haber transferido la llamada.

En una integración telefónica, marcar el destino solo acredita un intento. El éxito requiere verificar respuesta y conexión del audio. Este ensayo en memoria no valida una transferencia humana y no la contamos como resultado conseguido.

5. Distinguir informar de esperar y responder más rápido

Una locución breve de espera puede ayudar a que la persona sepa que la llamada sigue activa. Las preguntas preparadas reducen dependencias de inferencia. Ninguna de estas decisiones borra el tiempo que tarda la respuesta variable.

Separar el primer aviso audible de la primera respuesta útil evita optimizar una cifra que no representa lo que necesita quien llama.

7. Mide la respuesta y mejora con datos

Cuando el recorrido funcione, registra lo que tarda cada etapa y comprueba los datos que conserva. Las siguientes mediciones de nuestro laboratorio muestran cómo convertir esas pruebas en decisiones de mejora para tu agente.

Qué probamos y qué quedó fuera

Alcance de las gráficas. Son 12 intervenciones de un llamante sintético, repartidas en dos guiones, evaluadas el 17 de septiembre de 2026. Los modelos son reales; el transporte telefónico y la persistencia del ensayo se sustituyen en memoria. No son doce llamadas de personas ni una prueba de carga.

El evaluador usa el gestor de llamadas, la detección de voz, el cliente de reconocimiento y el intérprete del proyecto. Alimenta el audio sintético en bloques PCM de 20 milisegundos. Conserva modelos e integración de consulta reales, pero reemplaza el transporte telefónico y el guardado del ensayo por implementaciones en memoria.

Los dos guiones contienen cuatro y ocho intervenciones, respectivamente. La muestra revisada tiene 13 segmentos de reconocimiento: 12 completados y uno cancelado al ser sustituido. Las gráficas de tiempos incluyen los 12 completados; el cancelado queda declarado y excluido. En el turno dividido, mostramos el segmento completado, no el tiempo total de todos los intentos.

Medimos desde el cliente cuánto tarda la petición de ASR y cuánto tarda la interpretación de Pi. Estas duraciones pueden incluir transporte, colas y procesamiento del servicio. No son tiempo GPU puro ni la espera completa desde que una persona deja de hablar hasta que escucha la respuesta.

No tenemos en esta muestra una medición integral de TTS, primer audio audible, jitter, pérdida de paquetes, consumo energético, coste por llamada o concurrencia. Tampoco hay un conjunto de personas con distintos acentos. Esas métricas no se sustituyen por estimaciones.

Los informes de esta ejecución no incluyen una captura suficiente del hardware, la carga y la configuración efectiva del servidor. Por eso no atribuimos estas cifras a una GPU concreta ni a un límite de contexto, y no las presentamos como una comparación de hardware.

Dónde se acumula la espera

Figura 1. Mediciones del cliente por etapa. Barras independientes, sin sumar una latencia total. Muestra secuencial y pequeña; un segmento completado por turno.

El reconocimiento presenta la mediana más alta, aunque en algunos turnos la interpretación también pesa mucho. El siguiente trabajo de optimización debería medir ambos recorridos por separado: duración del audio, espera en cola, procesamiento, longitud de la petición y generación.

No publicamos un p95 como si caracterizara un servicio: con doce observaciones de dos guiones, podría calcularse un percentil, pero sería muy débil como señal operativa. La distribución completa, la mediana y el rango describen mejor lo que realmente vimos.

Tampoco presentamos una mejora porcentual frente al ensayo inicial. Durante la revisión se ajustó el tratamiento de segmentos y la verificación del audio. Ese cambio impide tratar las dos ejecuciones como una comparación controlada de velocidad.

El factor de tiempo real ayuda a interpretar el ASR

El factor de tiempo real, o RTF, divide el tiempo de reconocimiento entre la duración del audio que se envió:

RTF = tiempo de la petición ASR / duración del segmento de audio

Un RTF de 1 significa que la petición tarda tanto como el segmento. Es una referencia de cálculo; por sí sola no determina si una conversación completa resulta fluida.

Figura 2. El RTF mediano de las doce peticiones completadas es 3,37. Los segmentos enviados duran entre 1,22 y 4,98 segundos. Se usa la duración de la entrada real al ASR, no la del montaje de la conversación.

En todos los puntos, reconocer el segmento llevó más tiempo que su duración. Eso permite identificar una prioridad de investigación en este recorrido concreto. No demuestra que el modelo tenga ese rendimiento en cualquier servidor, ni permite deducir cuántas llamadas simultáneas soporta la GPU.

Comprueba por separado el diálogo y el reconocimiento

Figura 3. Controles por turno. Son criterios diferentes sobre la misma muestra, no porcentajes independientes de fiabilidad en producción.

Diez de las doce intervenciones quedaron dentro del umbral de error de palabras del evaluador: WER igual o inferior al 20 %. Once conservaron los términos críticos previstos en el guion. En los doce turnos se superaron las comprobaciones de campos interpretados, estado del diálogo, contenido de respuesta, confirmación y validez técnica del audio.

La WER compara la transcripción con el texto de referencia contando sustituciones, omisiones e inserciones. En esta evaluación se normalizan mayúsculas, acentos y algunas expresiones numéricas. Por eso estos resultados no deben compararse directamente con un benchmark que aplique otra normalización o use otro corpus.

Un turno puede fallar la coincidencia de texto y aun así conservar suficiente información contextual para llegar al estado esperado. Eso explica la diferencia entre completar el recorrido y superar todos sus criterios; no convierte el fallo de reconocimiento en irrelevante. Un identificador o una referencia mal transcrita puede requerir repetición aunque el resto del diálogo parezca correcto.

La voz de salida también pasó por una retranscripción automática. Tras la revisión del verificador, las respuestas de los doce turnos quedaron dentro del umbral establecido. El ASR utilizado para comprobarlas pertenece al mismo sistema de reconocimiento: no es una escucha humana independiente ni certifica la pronunciación exacta de cada nombre propio.

Los informes mantienen el resultado global estricto como fallido en ambos escenarios. Un evaluador de lenguaje que encuentre razonable el diálogo no debe borrar ese resultado. Cada señal responde a una pregunta distinta.

8. Valida el recorrido antes de abrirlo al público

Para reproducir el método en otro proyecto, empezaría por un procedimiento acotado, con campos obligatorios, acciones permitidas y resultados verificables. Después escribiría guiones que incluyan confirmación, corrección, silencio, interrupción, cancelación y fallo de backend.

1. Versionar el ensayo. Fijar código, modelos, parámetros, audio y normalización. Registrar la configuración efectiva del servidor, no solo la deseada.

2. Medir etapas independientes. Anotar inicio y fin de ASR, interpretación, adaptador, TTS y reproducción. Registrar también cancelaciones y errores.

3. Mantener los fallos. Excluir una petición cancelada de la distribución de peticiones completadas es válido si se declara. Borrarla de la contabilidad no lo es.

4. Comprobar datos y acciones. Contrastar campos, confirmación vigente, operación ejecutada y respuesta comunicada. Guardar una propuesta no es crear una solicitud real.

5. Pasar a telefonía real. Repetir con personas, ruido y red SIP/RTP, midiendo desde el final de la voz hasta el primer audio de la respuesta útil.

6. Aumentar la carga gradualmente. Medir distribuciones, errores y colas bajo concurrencia, con límites definidos antes de la prueba. Compartir modelos no autoriza a compartir estado entre llamadas.

Las gráficas muestran tiempos, duración de audio y comprobaciones de calidad del ensayo. No incluyen grabaciones, textos reconocidos, direcciones, referencias de registros, identificadores de sesión ni infraestructura interna.

Tu primer agente: una tarea útil y un siguiente paso claro

El patrón encaja como hipótesis de producto en tareas repetibles: preparar incidencias genéricas, consultar estados autorizados o recoger información antes de hablar con una persona. El atractivo comercial está en completar esos pasos con menos fricción; esta muestra todavía no cuantifica ahorro de personal, satisfacción ni reducción de abandonos.

Para un equipo que evalúa construirlo o comprarlo, pediría tres demostraciones: una corrección que invalide la confirmación anterior, un fallo que no anuncie un éxito inexistente y una medición completa de espera bajo la carga prevista.

Tu primera versión puede empezar con una sola tarea: recoger los datos, permitir una corrección y devolver una propuesta confirmada. Después podrás incorporar una lectura autorizada, conectar una operación real y probar el recorrido telefónico completo. Cada etapa añade una capacidad que puedes verificar antes de ampliar el servicio.

¿Qué tarea le darías a tu primer agente telefónico: recoger solicitudes, consultar estados o preparar la atención de una persona?