Deep Dive · Voz IA

Cómo funciona la tecnología voice-to-voice: del audio al agente IA

4 de abril de 2026 · 9 min de lectura

Llevo los últimos tres años metido hasta las cejas en el desarrollo de la plataforma de voz IA de Baxilio. Y si hay algo que me ha cambiado completamente la perspectiva sobre cómo se construyen estos sistemas, es el salto de la arquitectura clásica STT→LLM→TTS al modelo voice-to-voice nativo. Voy a intentar explicar qué ha cambiado y por qué importa, sin perderme en abstracciones académicas.

El enfoque clásico: la cadena de tres eslabones

Hasta hace relativamente poco, cualquier sistema de voz con IA funcionaba así:

1. Speech-to-Text (STT): El audio del usuario se convierte en texto. Whisper de OpenAI, Deepgram, Google Speech-to-Text…
2. LLM (procesamiento): Ese texto se manda a un modelo de lenguaje que genera una respuesta en texto.
3. Text-to-Speech (TTS): La respuesta textual se convierte de nuevo en audio.

Funciona. Lo hemos usado. Pero tiene un problema fundamental: latencia acumulada.

Cada eslabón de la cadena añade tiempo. En nuestras primeras pruebas internas con esta arquitectura, medíamos tiempos end-to-end de entre 2 y 4 segundos desde que el usuario dejaba de hablar hasta que oía la respuesta. Dos segundos ya se sienten lentos en una conversación telefónica. Cuatro son inaceptables.

Además, al convertir audio a texto y luego texto a audio, pierdes información. La entonación, las pausas, los matices emocionales del hablante — todo eso se pierde en la transcripción y luego hay que «reinventarlo» en la síntesis.

El modelo voice-to-voice: audio entra, audio sale

Los modelos voice-to-voice nativos procesan directamente las representaciones de audio. En vez de convertir a texto como paso intermedio, trabajan con tokens de audio — representaciones comprimidas del sonido que conservan información tonal y prosódica.

La diferencia arquitectónica es profunda:

Y ese «hasta primer audio» es clave. Los modelos voice-to-voice generan audio en streaming, así que el usuario empieza a oír la respuesta antes de que esté completamente generada. Es como cuando hablas con una persona real: no esperas a que termine de pensar toda la frase para empezar a escucharla.

Cómo lo integramos en Baxilio

Cuando empezamos a construir la plataforma de voz IA, la primera decisión técnica fue cómo capturar y transmitir el audio. Teníamos dos opciones: usar el canal RTP directamente desde el SIP trunk o establecer un puente WebSocket.

Optamos por una arquitectura híbrida. El audio SIP/RTP llega a nuestro media server (basado en tecnología que hemos ido desarrollando sobre componentes de código abierto), se transcodifica si es necesario — la mayoría de operadores mandan G.711, nosotros trabajamos internamente con Opus a 16kHz para mejor calidad — y se envía al motor de voz IA a través de un canal WebSocket persistente.

La vuelta es simétrica: el audio generado por el modelo llega en streaming por el WebSocket, se transcodifica a G.711 y se inyecta en el stream RTP de vuelta al llamante. Todo esto tiene que pasar en tiempo real, con buffers mínimos, o la conversación se siente artificial.

El problema del turn-taking

Uno de los retos técnicos más interesantes que hemos tenido que resolver es el «turn-taking» — detectar cuándo el usuario ha dejado de hablar y espera respuesta. En una conversación humana esto lo hacemos sin pensar. En un sistema de voz IA, es sorprendentemente difícil.

Si cortas demasiado pronto, interrumpes al usuario. Si esperas demasiado, la conversación se siente lenta y robotizada. Durante el desarrollo de Baxilio probamos varios enfoques: detección de silencios simple (funcionaba mal con ruido de fondo), modelos de VAD (Voice Activity Detection) más sofisticados, y finalmente la capacidad nativa del propio modelo voice-to-voice para gestionar los turnos de conversación.

Los modelos nativos tienen una ventaja enorme aquí: como «escuchan» el audio directamente, pueden detectar patrones prosódicos que indican final de turno — una bajada de entonación, una pausa tras una pregunta, el ritmo de la frase. Es algo que un pipeline STT→LLM simplemente no puede hacer porque esa información se pierde en la transcripción.

Interrupciones: el gran test de naturalidad

Otro aspecto crucial: las interrupciones. En una conversación natural, si el agente está hablando y el usuario le interrumpe, tiene que parar inmediatamente y escuchar. Suena obvio, pero implementarlo bien requiere que el sistema esté escuchando constantemente el canal de entrada mientras genera audio de salida.

En nuestras pruebas piloto, este fue el factor que más comentaron los usuarios. «Es que parece que te escucha de verdad» era un comentario recurrente. Y es exactamente eso — el modelo voice-to-voice procesa entrada y salida de forma bidireccional, no secuencial.

¿Y el texto? ¿Dónde queda?

Buena pregunta. Aunque el procesamiento principal sea audio-a-audio, seguimos necesitando texto para varias cosas: transcripciones de las llamadas, logs para debugging, alimentar el sistema RAG con contexto de conversaciones previas, y cumplir con requerimientos legales de grabación.

Por eso mantenemos un pipeline de STT en paralelo, pero asíncrono. No está en el camino crítico de la conversación — el audio se transcribe «por detrás» sin afectar a la latencia de la interacción en vivo.

Lo que viene

Siendo honesto, estamos todavía en las fases tempranas de esta tecnología. Los modelos voice-to-voice actuales son impresionantes pero no perfectos. A veces «alucinan» sonidos, la gestión de idiomas diferentes en una misma conversación puede fallar, y hay margen de mejora en la expresividad emocional.

Pero la dirección es clara. La voz es la interfaz natural del ser humano, y por fin tenemos la tecnología para que las máquinas la procesen de forma nativa, sin el paso intermedio del texto. Para los que llevamos años trabajando en telefonía, es un momento fascinante.

Antonio Gutiérrez — Desarrollador e ingeniero informático en Baxilio