Cómo funciona de verdad la IA de voz en tiempo real (STT → LLM → TTS, explicado)
Qué pasa entre el "hola" y la respuesta del agente, en lenguaje claro. Sin jerga, sin rodeos.
La IA de voz en tiempo real es un pipeline de tres etapas con dos piezas de orquestación a su alrededor. Entra el audio → el speech-to-text lo convierte en palabras → un LLM decide qué hacer → el text-to-speech convierte la respuesta de nuevo en audio. Envolviéndolo todo: la gestión de turnos (¿ha terminado de hablar quien llama?) y la gestión de las interrupciones (¿y si nos cortan?). Eso es todo.
Todo el pipeline tiene que terminar en menos de ~700 ms o deja de sentirse humano. Por encima de ese umbral, quienes llaman se sienten incómodos, se repiten y cuelgan. Por debajo, olvidan que están hablando con una IA. El stack de Retell funciona en torno a los 600 ms de extremo a extremo. Eso no es suerte. Es el resultado de que cada etapa transmite a la siguiente en streaming en lugar de esperar a que termine.
La mayor parte de la latencia se esconde donde no lo esperas. No en el STT, no en el TTS, sino en las decisiones de gestión de turnos y en el tiempo hasta el primer token del LLM. Si tu desarrollo se siente lento, esos son los dos primeros sitios donde mirar.
El streaming es el truco. El STT emite transcripciones parciales cada ~50 ms en lugar de esperar a una frase completa. El LLM transmite los tokens en streaming a medida que se generan. El TTS transmite fragmentos de audio antes de que exista la respuesta completa. Nada de esto funciona si alguna etapa espera a que la anterior "termine".
Los stacks de 2026 se parecen mucho a nivel arquitectónico. Lo que separa lo "de nivel de producción" de lo "de demo" es la calidad de la orquestación: ajuste del VAD, modelos de gestión de turnos, gestión de interrupciones, latencia de las llamadas a funciones. Ahí es donde va la inversión real en ingeniería.
Quita el marketing y un agente de voz es un pipeline. Entra el audio por el teléfono. El software lo convierte en texto. Un modelo de lenguaje lee ese texto, decide qué decir o qué hacer y genera una respuesta. Más software convierte la respuesta de nuevo en audio. El audio sale por el teléfono. Quien llama lo oye, dice algo y el bucle se vuelve a ejecutar. Eso es todo. Ese es el producto entero.
La razón por la que ese bucle tan simple tardó años en funcionar es que todo tiene que ocurrir en menos de un segundo. Cada parte del pipeline tiene que ser en streaming. Cada transición entre etapas tiene que ser casi instantánea. Dos etapas tienen que tomar decisiones estrictas en tiempo real: la gestión de turnos ("¿ha dejado ya de hablar quien llama?") y la gestión de interrupciones ("quien llama acaba de empezar a hablar por encima de mí, ¿qué hago?"). Falla en cualquiera de ellas y la conversación se viene abajo de una forma que quien llama nota al instante, aunque no sepa explicar por qué.
Este artículo es la versión sin marketing de cómo funciona de verdad un agente de voz en 2026. Recorreremos un único turno conversacional de extremo a extremo, veremos dónde se esconde la latencia, hablaremos de la orquestación que separa los stacks de producción de las demos y aclararemos algunos malentendidos habituales sobre lo que ocurre en realidad bajo el capó.
Si eres un PM que intenta entender qué están construyendo tus ingenieros, esto es para ti. Si eres un ingeniero que evalúa una plataforma frente a construirla por tu cuenta, también es para ti. En cualquier caso: al final sabrás qué pasa cada vez que alguien dice "hola" y una IA responde "hola".
Aquí va la versión de ascensor.
Un agente de voz son tres cosas en fila con dos cosas envolviéndolas. Las tres en fila: STT → LLM → TTS. El speech-to-text convierte el audio de quien llama en palabras. Un gran modelo de lenguaje lee esas palabras (además de tu prompt de sistema, la conversación hasta el momento y una descripción de las herramientas que el agente puede invocar) y decide si hablar o llamar a una función. El text-to-speech convierte la respuesta del modelo de nuevo en audio.
Las dos cosas que envuelven ese pipeline: la gestión de turnos y las interrupciones. La gestión de turnos es el sistema que decide cuándo quien llama ha terminado una idea para que el agente pueda responder, mucho más difícil de lo que parece, porque los humanos hacen pausas a media frase constantemente. La interrupción es el sistema que gestiona que quien llama corte al agente a media respuesta, también más difícil de lo que parece, porque tienes que detener el TTS al instante, descartar lo que el modelo estaba a punto de decir y empezar a escuchar de nuevo.
Por qué esto es difícil: cada etapa tiene que ser en streaming, y cada etapa tiene un presupuesto de latencia que no puedes reventar. Deja todo el bucle por debajo de ~700 ms y la conversación se siente humana. Pásate y deja de sentirse así. Ese es todo el trabajo.
Recorramos un turno conversacional de extremo a extremo. Quien llama dice "Hola, me gustaría reservar una limpieza para el martes que viene por la tarde" y 600 ms después el agente responde. Esto es todo lo que pasa en medio.
La llamada llega primero a tu capa de telefonía: un SIP trunk si usas tu operador existente, o un stream de WebRTC si usas un número de Retell. En cualquier caso, el audio de quien llama aparece como un flujo de pequeños paquetes, normalmente de 20 ms cada uno. Desde el momento en que quien llama empieza a hablar, esos paquetes fluyen hacia tu stack a la velocidad de la línea. El tiempo de ida y vuelta de la red es la primera pieza del presupuesto de latencia con la que no puedes hacer trampas: normalmente de 30 a 80 ms según la geografía y el operador, antes de que haya ocurrido ningún trabajo de IA.
El VAD es el modelo ligero que decide si el audio que entra es voz o silencio. Se ejecuta en cada fragmento entrante, en milisegundos. ¿Para qué molestarse? Por dos razones. Una: no quieres enviar silencio a tu STT, porque desperdicia cómputo y confunde la gestión de turnos. Dos: el VAD es la primera señal que usa la gestión de turnos para decidir cuándo ha dejado de hablar quien llama. Un mal VAD es uno de los asesinos silenciosos de la IA de voz. Ajústalo demasiado estricto y cortarás a quien llama a media palabra. Ajústalo demasiado laxo y el agente se sentirá lento. Los stacks de nivel de producción usan para esto una pequeña red neuronal entrenada específicamente con audio de llamadas telefónicas, no un umbral genérico de energía.
En cuanto el VAD dice "esto es voz", el audio se canaliza hacia un motor de STT en streaming. La palabra clave es streaming. El STT no espera a que quien llama termine. Emite transcripciones parciales cada ~50 ms, conjeturas incompletas que se van revisando a medida que llega más audio. Así, a los 200 ms la transcripción podría decir "Hola me gustaría reservar una". A los 400 ms, "Hola me gustaría reservar una limpieza para". A los 700 ms, la frase completa. El STT moderno también gestiona la diarización (quién habla, útil cuando hay más de una persona en la línea), la corrección provisional (revisar "dos" a "dos y media" cuando llega más contexto) y la robustez ante el ruido para quienes llaman con manos libres o en aeropuertos.
Si te preguntas dónde fallan en silencio la mayoría de los desarrollos caseros, este es uno de esos sitios. La precisión del reconocimiento está bien en 2026. La parte difícil es el streaming, las parciales y la detección de fin de enunciado, nada de lo cual obtienes de una API genérica de "transcribe este archivo de audio".
Este es el arte oscuro. La gestión de turnos es el modelo que decide cuándo quien llama ha terminado una idea, para que el agente pueda responder. No es solo "esperar 500 ms tras la última palabra". Los humanos hacen pausas a media frase, respiran, dicen "eh" mientras piensan. Un timeout ingenuo o los cortará ("Hola, me gustaría reservar—" "De acuerdo, ¿qué le gustaría reservar?") o se sentirá lento ("...para el martes que viene por la tarde." [silencio] [silencio] "Entendido, déjeme comprobarlo.").
La respuesta de producción de 2026 es un modelo de gestión de turnos neuronal, pequeño y rápido, que toma el flujo de audio, la transcripción parcial y el contexto de la conversación, y da una probabilidad de que quien llama haya terminado su turno. Se actualiza decenas de veces por segundo. Cuando la confianza cruza un umbral, comienza el turno del agente. El modelo de gestión de turnos de Retell gestiona los backchannels ("ajá", "claro"), las pausas de duda y la detección de fin de enunciado dentro de un presupuesto de respuesta de extremo a extremo de aproximadamente 600 ms. (Cómo funciona nuestra gestión de turnos.)
Si te llevas una sola cosa de este artículo: la mayor parte de la diferencia entre "se siente humano" y "se siente robótico" vive en esta etapa. En términos de presupuesto de latencia, la gestión de turnos se come de 150 a 300 ms de tu tiempo de respuesta total. En términos de calidad, es el factor más determinante de si quienes llaman respetan al agente.
Una vez terminado el turno de quien llama, se invoca al modelo de lenguaje con todo lo que necesita: tu prompt de sistema, la transcripción completa de la conversación, cualquier conocimiento recuperado de tu base de conocimiento y la lista de funciones disponibles. El modelo tiene dos opciones en cada turno: generar una respuesta hablada o llamar a una herramienta (concertar la cita, transferir la llamada, consultar el registro del cliente).
La métrica de latencia que importa aquí es el tiempo hasta el primer token (TTFT). No cuánto tarda la respuesta completa, sino cuánto tarda en empezar a transmitirse la primera palabra. Un buen LLM de 2026 alcanza un TTFT de 150 a 300 ms para un prompt típico de agente de voz. Una vez que los tokens empiezan a transmitirse, lo siguen haciendo a 50-100 por segundo, más rápido de lo que habla la mayoría de la gente. Así que la etapa de TTS empieza antes de que el modelo haya terminado de pensar. (Detalles de precios del nivel de LLM.)
Si el modelo decide llamar a una función en lugar de hablar, pagas una latencia distinta: el ida y vuelta a tu webhook (reservar la franja en Cal.com, escribir el lead en Salesforce). Para la mayoría de las funciones preconfiguradas, esto es rápido: cientos de milisegundos de un solo dígito. Para API de terceros lentas, puede ser más lento, y el agente suele decir algo como "un momento mientras lo compruebo" para rellenar el hueco. (Reservar, transferir, base de conocimiento.)
En cuanto el LLM emite los primeros tokens, el TTS arranca. Los agentes de voz modernos transmiten el audio de salida en fragmentos de 200-400 ms, de modo que quien llama oye la primera palabra antes de que se haya generado siquiera la respuesta completa. Este es el truco que hace que todo el pipeline se sienta rápido: cada etapa emite salida antes de que la etapa anterior termine.
El menú de voces de 2026 tiene tres niveles: las voces de la plataforma Retell y Cartesia para una voz rápida, natural y de baja latencia a 0,015 $/min; ElevenLabs para voces de marca de máxima fidelidad a 0,040 $/min; y una larga cola de clones de voz para casos de uso premium. El tiempo hasta el primer audio (TTFA) es la métrica a vigilar: los stacks de producción alcanzan los 100-200 ms. En pruebas a ciegas con voces predeterminadas, la mayoría de quienes llaman no las distinguen con fiabilidad de un humano. Lo que delata a la IA de voz en 2026 ya no es la voz. Es la sincronización.
El pipeline anterior funciona de maravilla hasta que quien llama hace lo que los humanos hacen de verdad: interrumpir. Empiezan a hablar por encima del agente. Quizá se dieron cuenta de que querían decir miércoles, no martes. Quizá están molestos. En cualquier caso, el agente tiene que dejar de hablar de inmediato, descartar el resto de su respuesta planeada y empezar a escuchar de nuevo, rápido.
Esto es la gestión de interrupciones, y es otro asesino silencioso de la IA de voz. Un desarrollo ingenuo sigue leyendo el resto del TTS mientras quien llama habla, la peor sensación en una llamada de teléfono. Un buen desarrollo corta el TTS dentro de un único fragmento de audio (menos de 100 ms), descarta lo que el LLM iba a decir y arranca un nuevo flujo de STT a partir del nuevo audio de quien llama. Puntos extra si el modelo sabe qué se dijo antes del corte para no repetirse.
Suma el presupuesto: red (50 ms) + VAD/gestión de turnos (200 ms) + TTFT del LLM (250 ms) + TTFA del TTS (100 ms) = unos 600 ms. Así es como un agente de voz se siente humano. Ninguno de esos números es mágico. Son simplemente el resultado de transmitir en streaming de forma agresiva y no esperar a nada que no haga falta.
Tres empresas que funcionan hoy sobre este mismo pipeline, dignas de estudiar.
Pine Park Health. Atención primaria para comunidades de viviendas para mayores. El juego del teléfono se les comía la agenda. Colocaron un agente de voz de Retell delante de su línea de programación, el mismo pipeline STT → LLM → TTS que el resto, solo que orquestado lo bastante bien como para que quienes llamaban no abandonaran. El NPS de programación subió un 38 %. Su personal clínico dejó de pasar medio día al teléfono.
SWTCH. Empresa de carga de vehículos eléctricos. Cuando un conductor se queda tirado en un cargador averiado, "le devolvemos la llamada mañana" no es una respuesta. Pusieron a Lucas, un agente de Retell, en la línea. Lucas contesta en segundos, guía a los conductores a través de soluciones urgentes y lo hace 24/7 sobre el mismo pipeline de siete etapas. Los costes de soporte cayeron más de un 50 %.
Medical Data Systems. Gestión de cobros. Regulada, sensible en el tono, implacable cuando las conversaciones se tuercen. Pusieron agentes de Retell en las llamadas entrantes y ahora gestionan el 100 % del volumen entrante con solo un 30 % de las llamadas transferidas a un humano, recaudando alrededor de 280.000 $ al mes. El pipeline es el mismo que acabamos de recorrer. La diferencia es la disciplina de orquestación y una larga cola de pequeñas decisiones sobre gestión de turnos, interrupciones y diseño del prompt. (Más historias de clientes aquí.)
El hilo común en los tres casos: ninguno intentó inventar el pipeline. Eligieron una plataforma que tenía la orquestación resuelta, centraron su trabajo en las partes que eran realmente propias de su negocio (el prompt, la base de conocimiento, los endpoints de funciones) y lanzaron.
Si no recuerdas nada más de este artículo, recuerda esto: el STT y el TTS no son donde se esconde la mayor parte de tu latencia. Son rápidos. Los dos sitios a los que va de verdad la latencia son la gestión de turnos y el tiempo hasta el primer token del LLM.
Aquí tienes un desglose típico del presupuesto de 2026 para un turno conversacional en un stack de producción:
Ida y vuelta de la red: 30-80 ms. Sobre todo geografía y tu operador SIP. Aquí no puedes hacer gran cosa.
Decisión de VAD + gestión de turnos: 150-300 ms. Esta es la mayor variable. Un mal modelo de gestión de turnos te costará más de 500 ms de latencia percibida sin aparecer nunca en un benchmark.
Transcripción final del STT: 50-100 ms tras el fin del habla. El streaming oculta la mayor parte de esto en la etapa anterior.
Tiempo hasta el primer token del LLM: 150-400 ms. Depende en gran medida de la elección del modelo y del tamaño del prompt.
Tiempo hasta el primer audio del TTS: 100-200 ms.
Llamada a función (si se invoca): 100-500 ms según la API.
Un stack de nivel de producción resuelve las partes de hablar-o-no-hablar de esto en unos 600 ms en total. Un stack mediocre se queda en 1,2-1,8 segundos. El stack mediocre se siente como hablar con un chatbot leyendo líneas. El bueno se siente como una persona.
Las dos grandes palancas si intentas optimizar: elige un LLM rápido con bajo TTFT (GPT 4.1, Claude 4.6 Sonnet y Gemini 3.0 Flash alcanzan todos los objetivos de producción), y usa un modelo de gestión de turnos entrenado con datos de conversación real, no un umbral de silencio fijo. (Por qué importa la latencia)
Vale la pena señalar algunas cosas.
"No son más que tres API pegadas." Lo son, hasta que intentas que se sienta en tiempo real. Entonces te das cuenta de que el pegado importa más que las API. La capa de orquestación (ajuste del VAD, modelo de gestión de turnos, coordinación del streaming, gestión de interrupciones, enrutamiento de las llamadas a funciones) es donde viven de verdad los stacks de nivel de producción. Puedes cambiar de proveedor de STT en un día. No puedes cambiar de orquestación sin reescribir medio sistema.
"LLM más grande = mejor agente de voz." En realidad no. Para la mayoría de los casos de uso de voz, un modelo rápido de gama media con un buen prompt supera a un buque insignia lento. El tiempo hasta el primer token importa más que la calidad pura del razonamiento, porque la percepción de quien llama está moldeada casi por completo por la latencia. Retell te deja cambiar de LLM con un desplegable precisamente porque la respuesta correcta depende del caso de uso: el razonamiento pesado se lleva Claude 4.6 Sonnet, el alto volumen barato se lleva GPT 5 nano, lo multilingüe se lleva Gemini 3.0 Flash, y el predeterminado es GPT 4.1.
"El streaming es un extra prescindible." Es toda la arquitectura. Sin streaming, esperas a que quien llama termine, luego esperas a que el STT termine, luego esperas a que el LLM termine, luego esperas a que el TTS termine, y has gastado más de 3 segundos antes de que un solo byte de audio salga de vuelta. La razón por la que los agentes de voz de 2026 se sienten humanos es que cada etapa empieza a emitir salida antes de que la etapa anterior termine.
"Necesitas un modelo entrenado a medida para que esto funcione en tu caso de uso." Casi siempre no. El stack de 2026 está diseñado para que el modelo se mantenga genérico y sean tu prompt + base de conocimiento + funciones los que hagan la personalización. Los modelos entrenados a medida son más lentos de iterar, más lentos en inferencia y quedan obsoletos en cuanto se lanza un nuevo modelo base. La mayoría de los equipos que "necesitaban un modelo a medida" en realidad necesitaban un mejor prompt y una mejor base de conocimiento.
"La voz es la parte más difícil." En realidad es ahora una de las más fáciles. Las voces de TTS predeterminadas son funcionalmente indistinguibles de un humano en pruebas a ciegas. Las partes más difíciles son la gestión de turnos y las interrupciones: las cosas que quienes llaman no notan conscientemente pero sienten sin duda.
La IA de voz en tiempo real es un pipeline de streaming: audio que entra → STT → LLM → TTS → audio que sale, con la gestión de turnos y las interrupciones envolviéndolo. Cada etapa emite salida antes de que la etapa anterior termine, todo el bucle se completa en menos de 700 ms, y la orquestación es lo que separa la producción de la demo. Esa es la arquitectura. No es magia. Son unos cuantos problemas de ingeniería concretos resueltos bien.
La mayoría de los operadores no necesitan construir esto por su cuenta. Necesitan entenderlo lo bastante bien como para saber qué están comprando, qué pedir y dónde fallará el desarrollo si eligen al proveedor equivocado. Si este artículo te ha llevado la mayor parte del camino, estás en buena forma.
Si quieres ver el pipeline en acción, el camino más rápido es construir algo sobre él. Crea una cuenta gratis en dashboard.retellai.com: las cuentas nuevas reciben 10 $ en créditos, unos 90 minutos de conversación. O solicita una demo y recorreremos la orquestación en el contexto de tu volumen de llamadas real. Y si prefieres oír la latencia por ti mismo, llama a nuestra línea de demo en vivo y habla con un agente que funciona sobre el pipeline anterior.
P: ¿Qué significa en realidad STT → LLM → TTS? R: Son las tres etapas centrales de un pipeline de IA de voz. El STT (speech-to-text) convierte el audio de quien llama en texto. El LLM (gran modelo de lenguaje) lee ese texto más tu prompt de sistema y decide qué decir o qué función llamar. El TTS (text-to-speech) convierte la respuesta de nuevo en audio. Envuélvelo con la gestión de turnos y las interrupciones y ese es el stack entero.
P: ¿Cómo de rápida tiene que ser la IA de voz en tiempo real? R: Por debajo de ~700 ms de tiempo de respuesta de extremo a extremo es el umbral en el que la conversación se siente humana. Por encima, quienes llaman empiezan a interrumpir, a repetirse y a colgar. Los stacks de producción como Retell funcionan en torno a los 600 ms.
P: ¿Adónde va la latencia en realidad? R: Sobre todo a la gestión de turnos y al tiempo hasta el primer token del LLM, no al STT ni al TTS. Un presupuesto típico: red 50 ms, VAD/gestión de turnos 200 ms, TTFT del LLM 250 ms, primer audio del TTS 100 ms. El STT se ejecuta en paralelo con el habla de quien llama, así que apenas añade nada por encima.
P: ¿Qué es el streaming y por qué importa? R: Cada etapa del pipeline emite salida antes de que la etapa anterior termine. El STT emite transcripciones parciales cada ~50 ms. El LLM transmite los tokens en streaming a medida que se generan. El TTS transmite el audio en fragmentos de 200-400 ms. Sin streaming, cada etapa espera a la anterior y gastas más de 3 segundos antes de que un solo byte de audio vuelva a quien llama.
P: ¿Qué es la gestión de turnos y por qué es difícil? R: La gestión de turnos es el sistema que decide cuándo quien llama ha terminado de hablar para que el agente pueda responder. Es difícil porque los humanos hacen pausas a media frase, respiran y dicen "eh" mientras piensan. Un timeout ingenuo corta a quien llama o se siente lento. La respuesta de 2026 es un pequeño modelo neuronal entrenado con audio conversacional real que actualiza una probabilidad decenas de veces por segundo.
P: ¿Qué es la gestión de interrupciones (barge-in)? R: Es lo que pasa cuando quien llama empieza a hablar por encima del agente. Un buen stack detiene el TTS en menos de 100 ms, descarta el resto de la respuesta planeada y arranca un nuevo flujo de STT a partir del nuevo audio de quien llama. Un mal stack sigue hablando: la peor sensación en una llamada de teléfono.
P: ¿Necesito construir el pipeline yo mismo? R: Casi nunca en 2026. La orquestación (VAD, gestión de turnos, interrupciones, coordinación del streaming, enrutamiento de las llamadas a funciones) es la parte en la que va la inversión seria en ingeniería. La mayoría de los equipos que intentan construirlo por su cuenta acaban con una versión más lenta y peor de lo que hay disponible de serie. Construye las partes que son propias de tu negocio: prompt, base de conocimiento, endpoints de funciones, workflows.
P: ¿Importa tanto la elección del LLM? R: Sí, pero sobre todo por el tiempo hasta el primer token, no por la calidad pura. Un modelo rápido de gama media con un buen prompt supera a un buque insignia lento para la mayoría de los casos de uso de voz. Retell te deja cambiar de LLM con un desplegable: GPT 4.1 es el predeterminado, Claude 4.6 Sonnet para mayor razonamiento, GPT 5 nano para volumen barato, Gemini 3.0 Flash para multilingüe. (Precios.)
P: ¿Cómo encaja la llamada a funciones en el pipeline? R: Cuando el LLM decide llamar a una función en lugar de hablar, la plataforma dispara un webhook HTTPS con argumentos estructurados que el modelo extrajo de la conversación y luego espera la respuesta. Ese ida y vuelta añade latencia: normalmente unos cientos de milisegundos para API rápidas, más para las lentas. Para esperas más largas, el agente suele decir "un momento mientras lo compruebo" para rellenar el hueco.
P: ¿Cuál es la diferencia entre la IA de voz y un IVR? R: Un IVR es un árbol de decisión fijo (pulse 1 para facturación). La IA de voz funciona sobre el pipeline anterior: habla abierta a la entrada, razonamiento del LLM en el medio, respuesta natural a la salida. Quienes llaman no navegan por menús. Simplemente hablan.
Descubre cuánto podría ahorrar tu empresa al pasar a agentes de voz impulsados por IA.
Total Human Agent Cost
AI Agent Cost
Estimated Savings
Un número de teléfono de demostración de Retell Clinic Office
Start building smarter conversations today.
.avif)
.avif)
