La forma en que un voicebot con IA procesa la voz determina si suena natural o si resulta lento e inconsistente. Existen actualmente dos arquitecturas en circulación entre constructores, y la elección entre ellas tiene consecuencias para la experiencia del llamador, la confiabilidad del sistema y lo que el bot puede extraer de una conversación. El enfoque más antiguo conecta tres componentes independientes uno tras otro, mientras que el método más nuevo procesa la conversación completa de una sola vez.

Esquema con tres componentes apilados en el lado izquierdo y un modelo de voz realtime en el lado derecho

El enfoque clásico: stitching

Cuando se construyeron los primeros voicebots, tenía sentido conectar tres componentes existentes. La voz entrante pasaba por un motor de voz a texto que la convertía en texto, después un modelo de lenguaje leía ese texto y formulaba una respuesta, y finalmente un motor de texto a voz convertía esa respuesta nuevamente en voz audible. Esta arquitectura se denomina “stitching” en el sector, porque conectas tres sistemas independientes en una cadena.

Durante un tiempo, esto proporcionaba resultados utilizables, y para equipos que no querían entrenar su propio modelo de voz era la única ruta práctica. Sin embargo, en la práctica emergen tres vulnerabilidades, porque cada eslabón puede fallar independientemente. El reconocimiento de voz puede malinterpretar una frase, el modelo de lenguaje puede dar una respuesta lenta o incorrecta, y la síntesis de voz puede fallar en el momento equivocado. Muchos equipos construyen un respaldo con un proveedor alternativo de TTS o LLM, para que el bot continúe funcionando si hay una interrupción. Eso resuelve el problema de la caída, pero los llamadores escuchan de repente una voz completamente diferente y se confunden sobre con quién están realmente hablando.

La segunda desventaja posiblemente sea aún más importante. Con stitching, el modelo de lenguaje solo ve una transcripción textual, por lo que no puede percibir el tono, el volumen, la duda o la emoción del llamador. Un cliente irritado y uno satisfecho suenan idénticos para el modelo una vez sus palabras están en papel, y eso perjudica la sensibilidad contextual que hace valioso un diálogo. Las señales sobre la edad aparente, la lengua materna o el estado de ánimo se pierden en la traducción al texto, mientras que precisamente esas señales suelen determinar cómo un empleado llevaría una conversación.

El nuevo enfoque: un modelo de voz realtime

Desde que OpenAI hizo disponible gpt-realtime-1.5 el 24 de febrero de 2026, existe una segunda manera de construir voicebots que funciona mejor en la mayoría de casos. En lugar de tres componentes independientes uno tras otro, un único modelo escucha y habla directamente, lo que elimina toda la capa intermedia de transcripción y síntesis. El modelo entiende las palabras, el tono y la emoción del llamador simultáneamente, para poder responder directamente a ellos en su respuesta. Lo fluida que funciona en la práctica se ve bien demostrado en un demo de Charlierguo.

Esto proporciona ventajas concretas en el uso diario. Solo hay un punto donde algo puede fallar en lugar de tres, lo que reduce significativamente la probabilidad de una caída. El tiempo de respuesta típicamente está por debajo de 400 milisegundos, por lo que la conversación fluye naturalmente sin la latencia que surge con stitching. El multilingüismo está integrado, lo que permite al mismo modelo cambiar sin esfuerzo entre español, inglés, alemán y otros idiomas sin que tengas que configurar ese cambio anticipadamente. Y como el modelo procesa audio en lugar de texto, reconoce a un cliente irritado por su voz y puede transferirlo directamente a un empleado sin necesidad de una palabra clave o escalada explícita.

Cuándo stitching sigue siendo la opción correcta

Permanece un nicho donde la arquitectura más antigua encaja mejor, y son situaciones en las que no es necesaria una conversación en vivo sino un análisis de una grabación posterior. Cuando un centro de llamadas quiere que las conversaciones se resuman, codifiquen o se analicen para cumplimiento después, no hay requisito de latencia y puedes elegir tranquilamente un modelo de lenguaje especializado. Piensa en un modelo de lenguaje médico que reconozca las abreviaturas y la jerga técnica de la sanidad, o un motor de voz a texto especialmente entrenado en un dialecto regional. La precisión en ese componente individual pesa más que la experiencia general de conversación en esos escenarios, porque no hay un llamador en la línea esperando una respuesta.

Nuestra recomendación

Para empresas que quieren que los voicebots manejen conversaciones en vivo, en prácticamente todos los casos recomendamos el enfoque realtime. La combinación de respuesta más rápida, menor sensibilidad a fallos, multilingüismo sin configuración y sensibilidad al tono crea una experiencia de llamada que los llamadores no perciben como robótica. Para análisis posteriores a la llamada y otros escenarios donde la precisión en un componente específico es decisiva, seguimos utilizando arquitecturas de stitching, porque ahí siguen ofreciendo el resultado más fuerte.

Nuestro equipo construye en ambas arquitecturas

CallFactory construye voicebots en ambas arquitecturas, dependiendo de lo que mejor se adapte a tu flujo de llamadas. Ya sea que quieras una solución completamente gestionada donde nuestro equipo configure todo de principio a fin, o prefieras un IVR dedicado ejecutándose en tu propia infraestructura, proporcionamos implementaciones conformes con RGPD disponibles 24 horas al día, siete días a la semana.

Ponte en contacto con nuestro equipo para discutir qué arquitectura se adapta a tus conversaciones, cómo funcionará la integración con tus sistemas existentes y dentro de qué plazo el voicebot puede estar en vivo. Así obtienes una estimación clara del tiempo de ejecución y la inversión, y puedes desde el día uno manejar llamadas entrantes y salientes con un voicebot que habla y escucha a un nivel que hace poco era inimaginable.