Por qué la voz cambia cómo diseñamos sistemas de IA

Voice AI no es simplemente speech-to-text → LLM → text-to-speech. Esa secuencia describe una tubería de componentes, pero no el problema completo. Cuando una persona conversa con una máquina, el sistema debe decidir cuándo escuchar, cuándo responder, cuándo esperar, cuándo detenerse y cómo recuperarse si ambos hablan al mismo tiempo.

La diferencia fundamental es ésta: la voz es una interfaz temporal. En texto, el usuario controla explícitamente el límite de su mensaje al presionar “enviar”. En voz, ese límite debe inferirse continuamente a partir de audio, pausas, intención, contexto y comportamiento conversacional.

Por eso agregar voz a un sistema de IA no consiste en rodear un LLM con STT y TTS. Cambian la arquitectura, el modelo de estado, la observabilidad, la concurrencia y las expectativas del usuario.

1. Texto y voz no son la misma interfaz

Una interacción de texto suele tener una forma discreta:

Usuario escribe
        ↓
Usuario presiona SEND
        ↓
El sistema procesa
        ↓
El sistema responde

El botón send es un delimitador explícito. El sistema no necesita adivinar si el usuario todavía está redactando una frase o si una pausa significa que está pensando.

En voz, el flujo se parece más a esto:

flowchart LR
  A[Audio stream] --> B[Interpretación continua]
  B --> C[Detección de turno]
  C --> D[Procesamiento]
  D --> E[Respuesta en streaming]
  E --> F[Posible interrupción]
  F --> B

El sistema recibe un flujo continuo y debe inferir qué está ocurriendo. ¿La persona terminó? ¿Está haciendo una pausa? ¿Va a continuar? ¿Está reaccionando a la respuesta? ¿Quiere interrumpir?

La pregunta ya no es sólo qué mensaje recibió el modelo. También es qué evento acaba de ocurrir y qué debe hacer el runtime con él.

2. La voz convierte la interacción en un problema temporal

En una interfaz de voz no importa únicamente qué ocurre. También importa cuándo ocurre.

Un silencio de 300 milisegundos puede ser el final de una frase, una pausa para pensar o el espacio antes de una corrección. Una respuesta que inicia demasiado pronto puede cortar al usuario. Una respuesta que espera demasiado puede parecer rota aunque sea correcta.

Las conversaciones humanas contienen pausas, solapamientos, retroalimentación breve, hesitaciones e interrupciones. La expectativa de naturalidad nace de esa coordinación temporal, no sólo de la calidad semántica de las palabras.

Esto conecta directamente con la latencia como parte de la inteligencia: en voz, el tiempo hasta la primera señal útil y el tiempo hasta la respuesta completa son experiencias distintas.

3. VAD no es detección de fin de turno

Voice Activity Detection —VAD— responde una pregunta relativamente acotada: ¿hay actividad de voz en este segmento de audio?

Eso no equivale a responder: ¿terminó el usuario su turno?

Considera esta frase:

“Quiero reservar una mesa para…

…mañana a las ocho.”

El VAD puede detectar silencio entre ambas partes. Pero el silencio no demuestra que la persona terminó. Para decidir el final del turno, el sistema puede combinar actividad acústica, texto parcial, prosodia, duración de la pausa, estructura lingüística, contexto y señales del diálogo.

El trade-off es inevitable:

• Esperar menos: menor latencia, pero más respuestas prematuras.
• Esperar más: menos cortes, pero una conversación más lenta.

El endpointing no debe optimizarse como una métrica aislada. Depende del idioma, el ruido, el tipo de tarea, el dispositivo y el costo de equivocarse. En una búsqueda rápida quizá conviene responder pronto. En una operación crítica puede ser preferible confirmar.

Una aproximación conceptual del tiempo hasta la primera respuesta audible es:

\[T_{voice}=T_{endpoint}+T_{STT}+T_{TTFT}+T_{TTFA}\]

TTFT es el tiempo hasta el primer token del modelo. TTFA es el tiempo hasta el primer audio reproducible. En un sistema real estas etapas pueden solaparse, así que la suma representa un camino secuencial simplificado, no una ley universal.

4. Arquitectura básica de Voice AI

Una arquitectura mínima necesita más piezas que una cadena lineal:

flowchart TD
  A[Micrófono] --> B[Audio stream]
  B --> C[VAD]
  C --> D[Streaming STT]
  D --> E[Detección de turno]
  E --> F[Agent Runtime]
  F --> G[LLM / Tools]
  G --> H[Streaming TTS]
  H --> I[Audio output]
  F --- J[Estado]
  F --- K[Cancelación]
  F --- L[Observabilidad]

VAD, STT, turn detection, runtime y TTS tienen responsabilidades diferentes. Colapsarlas detrás de una única función puede ser cómodo al inicio, pero dificulta entender dónde se introdujo una demora, qué se canceló o por qué se respondió antes de tiempo.

5. Streaming cambia el diseño

El pipeline más simple espera a que cada etapa termine:

audio completo
        ↓
transcripción completa
        ↓
respuesta completa
        ↓
audio completo
        ↓
reproducción

Ese diseño acumula latencia. En una arquitectura de streaming, las etapas pueden solaparse:

• STT entrega resultados parciales.
• El runtime identifica cuándo existe suficiente señal para procesar.
• El LLM genera tokens o fragmentos.
• TTS sintetiza unidades reproducibles.
• El cliente empieza a hablar antes de recibir la respuesta completa.

El objetivo no es hacer streaming por moda. Es mover el primer evento útil hacia la izquierda. La respuesta final puede tardar lo mismo, pero el usuario deja de experimentar un silencio sin explicación.

El solapamiento exige contratos claros: qué resultados parciales son provisionales, qué fragmentos pueden invalidarse, cuándo un texto es estable y cómo se propaga una cancelación. Streaming no elimina la complejidad; la vuelve concurrente.

6. Barge-in: cuando el usuario interrumpe

Barge-in es permitir que el usuario interrumpa mientras el sistema está hablando.

IA: “Encontré cinco opciones de restaurantes…”
Usuario: “Sólo quiero italianos.”

La respuesta correcta del sistema no es terminar de reproducir el audio anterior y después procesar la nueva frase. Debe detectar la voz, detener la salida, actualizar el estado y decidir qué hacer con la generación y las herramientas que siguen activas.

sequenceDiagram
  participant U as Usuario
  participant R as Runtime
  participant T as TTS / Output
  participant M as Modelo o Tool
  U->>R: Nueva voz detectada
  R->>T: Detener reproducción y limpiar buffer
  R->>M: Cancelar o invalidar ejecución
  R->>R: Registrar interrupción y actualizar estado
  R->>R: Procesar nuevo turno

Una interrupción introduce concurrencia, cancelación, ciclo de vida de streams e identidad de ejecución. El audio viejo no debe llegar después del nuevo. Una respuesta cancelada no debe marcarse como completada. Un resultado tardío de una tool no debe sobrescribir el estado de una conversación que ya cambió.

7. Cancelar no es una sola operación

Una interrupción puede ocurrir mientras:

• TTS reproduce audio.
• El LLM continúa generando.
• Una tool consulta una API externa.
• Un workflow ejecuta efectos secundarios.

Por eso conviene distinguir:

• Cancelar output: detener audio y descartar chunks pendientes.
• Cancelar inference: detener generación si el proveedor lo permite.
• Cancelar tool execution: cerrar una solicitud o marcarla como obsoleta.
• Cancelar task: cambiar el ciclo de vida de la operación completa.

No siempre es posible detener una operación externa. Una transferencia bancaria, una reserva o una consulta ya enviada pueden continuar aunque el usuario interrumpa la respuesta. En esos casos, el runtime necesita execution IDs, versiones de turno, idempotency keys y tokens de cancelación donde sean soportados.

8. Estado conversacional explícito

La voz hace visible un problema que también existe en agentes de texto: el sistema necesita estado. Como expliqué en Los agentes de IA necesitan estado, el historial no sustituye a una representación operacional.

Un runtime de voz puede tener estados como idle, listening, processing, speaking, waiting_for_tool, interrupted o cancelled. No son los únicos posibles ni tienen que ser idénticos en todos los productos.

stateDiagram-v2
  [*] --> IDLE
  IDLE --> LISTENING: audio iniciado
  LISTENING --> PROCESSING: turno detectado
  PROCESSING --> SPEAKING: primer audio listo
  PROCESSING --> WAITING_FOR_TOOL: tool iniciada
  WAITING_FOR_TOOL --> SPEAKING: tool completada
  SPEAKING --> LISTENING: respuesta terminada
  SPEAKING --> INTERRUPTED: voz detectada
  INTERRUPTED --> LISTENING: output cancelado
  INTERRUPTED --> PROCESSING: nuevo turno listo

Explicitar estado ayuda a depurar, actualizar la UI, aplicar cancelación y validar eventos. También permite distinguir “estoy esperando una tool” de “el sistema dejó de funcionar”.

9. Una máquina de estados pequeña en TypeScript

La máquina no necesita convertirse en un framework. Incluso un reducer pequeño puede hacer visibles las transiciones importantes:

type VoiceState =
  | "idle"
  | "listening"
  | "processing"
  | "speaking"
  | "interrupted";

type VoiceEvent =
  | { type: "audio.started" }
  | { type: "turn.completed" }
  | { type: "response.started" }
  | { type: "user.interrupted" }
  | { type: "response.cancelled" };

function transition(state: VoiceState, event: VoiceEvent): VoiceState {
  switch (event.type) {
    case "audio.started":
      return state === "idle" ? "listening" : state;
    case "turn.completed":
      return state === "listening" ? "processing" : state;
    case "response.started":
      return state === "processing" ? "speaking" : state;
    case "user.interrupted":
      return state === "speaking" ? "interrupted" : state;
    case "response.cancelled":
      return state === "interrupted" ? "listening" : state;
    default:
      return state;
  }
}

let state: VoiceState = "idle";
state = transition(state, { type: "audio.started" });
state = transition(state, { type: "turn.completed" });
state = transition(state, { type: "response.started" });
state = transition(state, { type: "user.interrupted" });
state = transition(state, { type: "response.cancelled" });

Un producto real necesitará más datos —turn ID, execution ID, timestamps, buffers y errores—, pero la idea central permanece: los eventos cambian el estado; no cualquier callback puede modificarlo arbitrariamente.

10. De mensajes a eventos

Una conversación de texto suele modelarse como mensajes. En voz conviene pensar también en eventos:

audio.started
speech.detected
speech.partial
speech.final
turn.completed
response.started
audio.output.started
user.interrupted
response.cancelled
tool.started
tool.completed

Una arquitectura orientada a eventos puede ser útil porque permite que transporte, UI, audio, runtime y observabilidad reaccionen a la misma secuencia temporal. No es obligatoria. Lo importante es que los eventos tengan semántica, orden, correlación y reglas de deduplicación.

voiceRuntime.on("speech.final", async (event) => {
  await stateStore.append(event.turnId, event);
  await agent.process({
    turnId: event.turnId,
    text: event.text,
    signal: event.signal,
  });
});

voiceRuntime.on("user.interrupted", async (event) => {
  await audioOutput.stop(event.turnId);
  await agent.cancel({ executionId: event.executionId });
  await stateStore.append(event.turnId, {
    type: "response.cancelled",
    reason: "barge-in",
  });
});

voiceRuntime.on("tool.completed", async (event) => {
  await stateStore.append(event.turnId, event);
  await agent.resume(event.turnId);
});

El ejemplo separa tres responsabilidades: registrar el evento, cancelar lo que corresponde y reanudar el proceso cuando una tool termina. En producción también habría que manejar concurrencia, errores, orden y autorización.

11. Tools, progreso y silencio

La voz vuelve más visible la latencia de las herramientas. Si el usuario pregunta “¿cuánto cuesta el vuelo?” y la API tarda cuatro segundos, un silencio completo se percibe como una falla.

Algunas estrategias son:

• confirmar que la solicitud fue recibida;
• mostrar o decir un estado de progreso;
• ejecutar operaciones independientes en paralelo;
• usar una respuesta parcial cuando ya existe información confiable;
• mover trabajo no crítico a segundo plano.

“Déjame revisarlo” puede ser útil, pero los fillers artificiales no deben convertirse en una máscara para una arquitectura lenta. El feedback debe comunicar algo verdadero y no interrumpir el ritmo más de lo necesario.

12. Full-duplex y turn-taking

En un sistema half-duplex, escuchar y hablar son fases separadas. Es más sencillo, pero impide interrupciones naturales. En un sistema full-duplex, el sistema puede escuchar mientras produce audio.

Full-duplex permite una experiencia más flexible, pero introduce eco, detección de la propia voz, falsos barge-ins, concurrencia y administración de recursos. No basta con abrir dos streams: hay que distinguir audio del usuario, audio generado y señales ambientales.

Además, una conversación no es necesariamente:

user message
assistant message
user message
assistant message

Puede contener overlap, backchannel, pausas, dudas y correcciones. Por eso “mensaje” es una abstracción útil, pero insuficiente para diseñar todo el runtime. La unidad operacional puede ser un turno, un evento o una secuencia de audio parcialmente interpretada.

13. La interfaz también necesita estado

La UI puede mostrar Listening, Thinking, Speaking o Working. No es decoración: reduce incertidumbre y ayuda al usuario a entender qué puede hacer a continuación.

La voz también puede combinarse con texto, imagen, pantalla o wearable. Una pregunta como “¿qué es esto?” puede comenzar con voz mientras el usuario comparte una imagen. La respuesta necesita contexto multimodal, no sólo transcripción.

El dispositivo importa. En unas gafas puede ser apropiada una respuesta breve hablada. En un escritorio puede tener sentido una explicación larga acompañada de un artefacto visual. Un sistema voice-first necesita ser consciente del dispositivo, el canal y el contexto de uso.

14. Privacidad y observabilidad

Voice AI introduce decisiones específicas de privacidad:

• ¿cuándo se activa el micrófono?
• ¿se conserva el audio original?
• ¿se conserva la transcripción?
• ¿qué ocurre con las palabras capturadas antes del wake word?
• ¿qué datos se procesan en el dispositivo y cuáles salen a un servicio externo?

La arquitectura debe definir qué se captura, qué se guarda, durante cuánto tiempo y quién puede acceder. La retención por defecto no debería ser una decisión accidental del proveedor.

La observabilidad también debe ser más granular que una métrica de HTTP:

session_id
turn_id
speech_detected_at
end_of_turn_at
stt_first_partial_at
llm_ttft
 tts_ttfa
time_to_first_audio
interrupt_response_time
tool_latency
outcome

Estas métricas permiten separar problemas que de otro modo aparecen como “la voz está lenta”. T_end_of_turn mide cuánto espera el sistema antes de cerrar el turno. T_first_audio mide cuándo empieza la respuesta audible. T_interrupt mide cuánto tarda en detenerse después de detectar una interrupción. RTF —real-time factor— compara el tiempo de procesamiento con la duración del audio procesado; su interpretación depende de la etapa y del sistema.

15. Fallos y recuperación

Voice AI tiene caminos de fallo que deben diseñarse como parte de la UX:

• STT entiende mal una palabra.
• La red se desconecta durante la respuesta.
• TTS falla después de que el LLM ya generó texto.
• Una tool tarda demasiado.
• Se detecta un falso barge-in.
• Un evento llega duplicado o fuera de orden.

Una recuperación puede pedir confirmación: “Creo que te escuché decir X. ¿Es correcto?”. También puede degradar a texto, reintentar una etapa, continuar con una respuesta breve o informar que una herramienta sigue trabajando.

Confiabilidad no significa ocultar todos los fallos. En una interfaz temporal, confiabilidad también significa que el usuario entienda qué ocurrió y qué puede hacer después.

16. Arquitectura de referencia

Esta arquitectura no es universal, pero muestra las responsabilidades que normalmente aparecen:

flowchart TD
  A[Cliente / Dispositivo] --> B[Audio Transport]
  B --> C[Realtime Voice Runtime]
  C --- D[VAD]
  C --- E[Turn Detection]
  C --- F[Streaming STT]
  C --- G[Conversation State]
  C --- H[Agent Runtime]
  H --- I[Context]
  H --- J[Memory]
  H --- K[Model]
  H --- L[Tools]
  C --- M[Streaming TTS]
  C --- N[Cancellation]
  C --- O[Observability]
  M --> A

La separación permite que voz, texto y otras superficies compartan estado, herramientas y memoria sin convertirse en asistentes independientes. Al explorar interfaces multimodales y voice-first como Nexa, estos límites resultan prácticos: la superficie cambia, pero la continuidad del sistema puede mantenerse.

¿Debe la IA sonar humana?

Naturalidad no significa imitar perfectamente a una persona. Las pausas, el tono, la velocidad y las confirmaciones son decisiones de producto. Un sistema puede ser claro y agradable sin fingir emociones ni ocultar que es una máquina.

La pregunta útil no es “¿cómo hacemos que parezca humano?”, sino “¿qué señales necesita el usuario para coordinarse con el sistema?”. A veces una pausa breve ayuda. A veces una confirmación explícita es mejor. A veces el sonido de que el sistema está procesando reduce más incertidumbre que una frase artificial.

Mi perspectiva actual

La voz no hace que una IA sea automáticamente más inteligente. Pero cambia radicalmente cómo experimentamos esa inteligencia.

Con texto pensamos principalmente en mensajes. Con voz empezamos a pensar en streams, eventos, timing, estado, interrupciones y presencia.

Ésa es la razón por la que Voice AI no puede reducirse a STT + LLM + TTS. La tubería de modelos es sólo una parte. El sistema completo debe detectar turnos, manejar silencios, producir respuestas incrementales, cancelar trabajo, coordinar tools, preservar estado, comunicar progreso y recuperarse de errores.

La voz no sólo cambia cómo el usuario habla con la IA. Cambia cómo debemos diseñar la IA completa.

Referencias

1. Charles F. Hockett, The Problem of Universals in Language, 1966. Incluye propiedades de la comunicación hablada relevantes para la coordinación conversacional.
2. Harvey Sacks, Emanuel A. Schegloff y Gail Jefferson, A Simplest Systematics for the Organization of Turn-Taking for Conversation, Language, 1974.
3. Steven E. Levinson, Turn-taking in Human Communication: Origins and Implications for Language Processing, Annual Review of Linguistics, 2016.
4. Johan Heldner y Mattias Edlund, Pauses, gaps and overlaps in conversations, Speech Communication, 2010.
5. Google Cloud, Voice activity events. Documentación técnica sobre eventos de actividad de voz.
6. Google Cloud, Streaming recognition. Reconocimiento de audio con resultados parciales.
7. WebRTC Working Group, WebRTC 1.0, W3C. Comunicación de audio y medios en tiempo real.
8. OpenAI, Realtime API documentation. Referencia técnica sobre sesiones realtime, eventos y cancelación.
9. Amazon Web Services, Timeouts, retries, and backoff with jitter. Diseño de timeouts y recuperación en sistemas distribuidos.
10. Jeffrey Dean y Luiz André Barroso, The Tail at Scale, Communications of the ACM, 2013. Impacto de la latencia de cola en sistemas interactivos.

Los diagramas Mermaid se incluyen como bloques de código para conservar la estructura del artículo. Si el tema de Ghost no los renderiza automáticamente, deben transformarse en SVG antes de una publicación final.