Cómo crear un agente de voz con IA en 2026: arquitectura y estructura técnica.

Un agente de voz basado en IA responde a las llamadas telefónicas, interpreta lo que el llamante desea a partir del lenguaje natural y ya sea responde o toma alguna acción, sin necesidad de un menú con opciones numeradas intermedias. Tres componentes colaboran para que esto sea posible: un modelo que transcribe el audio del llamante, un LLM que decide qué hacer con esa información y otro modelo que pronuncia la respuesta.

Las llamadas telefónicas no han desaparecido. Las empresas han orientado el soporte hacia chats y correos electrónicos, pero los clientes siguen marcando de todos modos. Un agente de voz llena ese vacío. No se trata de un chatbot al que se le ha añadido un altavoz; escucha, interpreta la intención a partir de la forma en que las personas hablan realmente y se comporta de manera similar a como lo haría una persona capacitada al otro lado de la línea.

Superar la fase de demostración implica elegir una arquitectura y un conjunto de tecnologías, además de reducir la latencia a menos de un segundo antes de que un llamante real lo utilice. Las secciones siguientes abordan todo eso.

La creación en ocho decisiones

Cada elección reduce las opciones para la siguiente.

1. Defina el flujo de trabajo de las llamadas. Decida qué tipos de llamadas manejará el agente, qué puede hacer y exactamente cuándo tomará el control otra persona.
2. Elija una arquitectura. En cascada, semicascada o conversión de voz a voz nativa. La elección determina el límite mínimo de latencia y el techo de costos.
3. Elija la solución de telefonía. Twilio, AWS Connect o WebRTC, según el canal y la región.
4. Agregue la conversión de voz a texto. Deepgram Nova-3 o AssemblyAI en modo de transmisión en tiempo real, con un vocabulario personalizado para términos del dominio cargado antes del inicio de operaciones.
5. Conecte el LLM y las herramientas. Configure las reglas de llamada a funciones y de escalada, y vincule el CRM o el sistema de reservas.
6. Agregue la conversión de texto a voz. Elija una voz, active la transmisión en tiempo real y procure que el primer audio tenga una duración inferior a 200 ms.
7. Pruebe la latencia y las interrupciones. Ejecute escenarios programados y de tipo adversarial, buscando que el tiempo total de respuesta sea inferior a un segundo.
8. Monitoreo después del lanzamiento. Observe la tasa de finalización, el control de situaciones, el CSAT y el tiempo de atención desde el primer día.

Por qué las empresas las están creando

El volumen de llamadas que antes justificaba un equipo de atención telefónica ya no cabe dentro de uno solo. Preguntas repetitivas, llamadas fuera del horario laboral, seguimientos por personas que no se presentan y recordatorios salientes llegan todos por el mismo canal, y contratar a más personas para cubrir todo esto impidió que la operación siguiera creciendo.

Los menús de respuesta de voz interactiva hacen que los llamantes cuelguen en cuanto se encuentran fuera de las opciones disponibles. Un agente de voz se comporta de manera diferente, ya que puede mantener una conversación real, hacer preguntas adicionales, dirigir casos complejos y ejecutar flujos de trabajo de llamadas repetitivos a gran escala. Las cifras de adopción indican lo mismo: las encuestas muestran que el uso de asistentes de voz entre los usuarios de móviles alcanza el 97%, el 89% de los clientes afirma preferir marcas que ofrecen soporte de IA de voz, y las empresas que la implementan informan costos operativos un 20 al 30% más bajos. Considere estos datos como cifras de encuestas del sector, no como garantías.

La presión suele manifestarse en cinco áreas donde los equipos humanos no pueden mantener el ritmo:

Volumen de llamadas entrantes repetitivas. En logística, se estima que del 50 al 70% de las llamadas entrantes son consultas del tipo “¿dónde está mi pedido?”. La misma pregunta, miles de veces al día, atendida por personas que podrían estar realizando trabajos más difíciles.

Llamadas fuera del horario de atención. Los pacientes intentan hacer reservas a medianoche y los solicitantes de préstamos llaman los domingos. Los clientes no programan sus consultas según el horario de apertura.

Faltas de asistencia sin solución. Las clínicas pierden aproximadamente el 20% de las citas debido a personas que no se presentan. Sin un seguimiento automatizado, la plaza permanece vacía y con ella los ingresos.

Trabajo manual de salida. Los recordatorios de renovación, el seguimiento de cuotas y las confirmaciones de entrega siguen todos el mismo guion. Pagar a personas para que lo lean en voz alta es caro e innecesario.

Aumentos repentinos que nadie puede manejar. Diez agentes atienden diez llamadas. Un agente de voz puede atender miles al mismo tiempo, sin colas ni música de espera.

Tres arquitecturas

La arquitectura determina la velocidad con la que responde el agente, el grado de control que mantiene su equipo, la facilidad para depurar y cuán predecibles son los costos a escala. Tres patrones de producción dominan, cada uno con diferentes compromisos en cuanto a latencia, control y costos, y una elección errónea puede resultar muy costosa de corregir.

1. La tubería en cascada

Tres modelos especializados se ejecutan en secuencia: el de conversión de voz a texto transforma el audio en texto, un LLM lee ese texto y escribe una respuesta, y el de conversión de texto a voz convierte la respuesta de vuelta en audio. El texto plano se transmite entre las etapas, y esa simplicidad es precisamente su ventaja principal. Es la arquitectura de producción más utilizada en 2026.

La latencia realista de extremo a extremo está entre 500 y 800 ms. No es la más rápida, pero permite una modularidad total. Puedes reemplazar Deepgram por AssemblyAI, ChatGPT por Claude o Cartesia por ElevenLabs sin tocar nada más. Cada componente genera registros, y cada capa puede medirse, ajustarse y reemplazarse por separado. Las implementaciones de alto volumen, con uso intensivo de telefonía y sensibles a la conformidad suelen funcionar de esta manera, no porque sea la más sofisticada, sino porque es la más controlable.

Una estructura en cascada se divide en estas partes, cada una reemplazable de forma independiente:

• Flujo de telefonía. Conéctate a través de Twilio o AWS Connect y transmite el audio entrante al reconocimiento de voz mediante SIP o WebRTC.
• Transcripción en tiempo real. Deepgram Nova-3 en modo de transmisión en tiempo real comienza a transcribir antes de que la persona que llama termine la oración.
• Orquestación de LLM. Entrega la transcripción a GPT-5 o Claude Sonnet con una instrucción que defina el alcance, el tono y las condiciones de escalada.
• Llamadas a funciones. Conecta el CRM, el sistema de reservas o la base de datos. El modelo las llama durante la conversación y espera el resultado.
• TTS en streaming. Envía la salida del modelo a Cartesia o ElevenLabs, de modo que la reproducción comience antes de que se genere la respuesta completa.
• Registro y reproducción. Captura transcripciones y audio en cada capa, para poder rastrear un fallo hasta un componente específico.
• Transferencia a un humano. Define qué intenciones y palabras clave activan una transferencia directa a un agente en vivo.

2. La cascada parcial

Aquí, el audio va directamente a un modelo multimodal que lo procesa de forma nativa, y solo la salida pasa por un modelo especializado de texto a voz. Ese cambio reduce la latencia a entre 300 y 500 ms, y permite lograr algo que el enfoque en cascada no puede hacer.

El modelo detecta a un llamante frustrado, percibe una entonación ascendente en una pregunta o identifica un cambio de idioma a mitad de una oración. No hay paso de transcripción entre el sonido y la comprensión del modelo. La salida sigue pasando por un modelo TTS especializado, por lo que la calidad de la voz permanece perfectamente controlable. Tanto ElevenLabs Agents como Gemini Live de Google siguen este patrón, y es la opción adecuada cuando la forma en que alguien dice algo es tan importante como lo que dice.

3. Texto a voz nativo

Un único modelo se encarga de todo: entrada de audio, salida de audio, sin texto intermedio ni límites entre componentes. La latencia baja a entre 200 y 300 ms. Por debajo de 300 ms, la conversación deja de parecerse a una interacción por software, lo cual es importante en cualquier situación en la que la vacilación socave la confianza.

No obstante, existen verdaderos compromisos. En llamadas largas, el costo aumenta porque el modelo vuelve a procesar cada token anterior de la conversación en cada turno, por lo que una llamada que parece costar 0,30 dólares por minuto puede llegar a costar 1,50 dólares en la práctica. También se pierde el control a nivel de componentes. Cuando algo sale mal, no se puede aislar la capa responsable, ya que no existen capas.

Hay otro límite más. Las llamadas telefónicas a través de la red pública transmiten audio a 8 kHz, lo que descarta gran parte de la riqueza que los modelos de audio nativos están diseñados para aprovechar, por lo que su ventaja sobre un sistema en cascada disminuye considerablemente.

¿Cuál elegir?

Comience con el enfoque en cascada si el despliegue implica telefonía, registro de cumplimiento o la necesidad de costos predecibles. La modularidad por sí sola lo justifica en la mayoría de los casos empresariales. Pase al enfoque semicascada cuando sea importante el audio de entrada, como cuando los llamantes cambian de idioma o se necesita detección del tono emocional, o en cualquier situación en la que la transcripción elimine señales que son necesarias. Elija el método de conversión voz a voz únicamente cuando las respuestas inferiores a 300 ms sean indispensables y el volumen de llamadas haga viable el cálculo económico por minuto. Esto abarca un conjunto reducido de casos; para la mayoría de los despliegues, el enfoque en cascada ofrece mejores resultados.

| Criteria                 | Cascaded Pipeline                         | Half-Cascade                            | Native Speech-to-Speech                    |
|--------------------------|-------------------------------------------|-----------------------------------------|--------------------------------------------|
| Latency                  | 500-800ms                                 | 300-500ms                               | 200-300ms                                  |
| Approx. Cost/min         | Low                                       | Medium                                  | High ($0.30 can reach $1.50)               |
| Modularity               | Full, swap any component independently    | Partial, TTS is swappable, input        | None, one model, no layers                 |
|                          |                                           | model is not                            |                                            |
| Emotion & Tone Detection | No, transcription strips it              | Yes, model hears audio natively         | Yes                                        |
| Compliance Logging       | Per-layer logs on every component         | Partial                                 | Not possible                               |
| PSTN Compatibility       | Strong                                    | Strong                                  | Weak, 8kHz audio narrows the               |
|                          |                                           |                                         | quality advantage                          |
| Best For                 | Telephony, compliance-sensitive,          | Multilingual callers, emotional         | Sub-300ms use cases with manageable        |
|                          | high-volume deployments                   | context, tone detection                 | call volume                                |
| Avoid When               | Latency is a hard requirement             | You need full component control         | Long calls, regulated industries,          |
|                          | under 500ms                               | or strict cost caps                     | unpredictable volume                       |

Las cinco capas

Sea cual sea la complejidad del agente, su estructura básica es idéntica: entra el sonido, sale una respuesta, y los pasos intermedios determinan cuán rápido, cuán preciso y cuán humano resulta el intercambio.

| Layer         | Role                    | Common Tools                  | Enterprise Consideration          |
|---------------|-------------------------|-------------------------------|-----------------------------------|
| Telephony     | Call routing            | Twilio, AWS Connect, SIP      | Region coverage, number portability |
| STT           | Speech transcription    | Deepgram, AssemblyAI, Whisper | Accents, noise, vocabulary        |
| LLM           | Reasoning and response  | GPT, Claude, Gemini, Llama    | Latency, compliance, tool use     |
| TTS           | Voice output            | ElevenLabs, Cartesia, PlayHT  | First-byte latency, brand voice   |
| Orchestration | Turn-taking and routing | Retell AI, Vapi, LiveKit      | Barge-in, handoff, monitoring     |

Los componentes, en orden:

1. Telefonía. La puerta de entrada. Una persona llama y esta capa captura el audio y lo envía por la cadena de procesamiento. Twilio, AWS Connect y WebRTC son las opciones más comunes.
2. Dictado a texto. Convierte lo que dice la persona que llama en texto. El ruido, los acentos y los términos especializados afectan la calidad, y cualquier error en esta etapa se refleja en todas las capas posteriores.
3. LLM. El cerebro. Lee la transcripción, determina la intención, elige una acción y escribe la respuesta. Cuando necesita datos externos, como el estado de un pedido o el saldo, llama a una herramienta y espera.
4. Texto a voz. Convierte la respuesta de vuelta en audio, y tanto la calidad de la voz como la rapidez de respuesta dependen de ella.
5. Integraciones. Conexiones con los sistemas reales: CRM, plataformas de reservas, bases de datos y procesadores de pagos. Sin ellas, el agente puede chatear pero no puede hacer nada más.

Cada transferencia de tarea añade latencia y cada componente puede fallar de forma independiente. Saber dónde se encuentra cada uno es lo que convierte una sesión de depuración de cinco horas en una de cinco minutos.

Capa 1: conversión de voz a texto

Todo lo que sigue depende de esta salida, por lo que los errores aquí se propagan por toda la cadena de procesamiento. El modelo recibe un flujo de audio, lo divide en fragmentos y predice la secuencia de palabras más probable a partir de patrones acústicos y probabilidades lingüísticas. La tecnología moderna de conversión de voz a texto es lo suficientemente rápida como para transcribir palabra por palabra mientras la persona sigue hablando.

Qué afecta la precisión. Cuatro factores degradan la conversión de voz a texto en entornos de producción: ruido de fondo, acentos marcados, vocabulario específico del dominio y mala calidad de audio. La red telefónica empeora aún más el problema, ya que su límite de 8 kHz elimina las frecuencias que ayudan a los modelos a distinguir palabras con sonidos similares.

Herramientas.

• Deepgram Nova-3 es la opción habitual para telefonía en tiempo real, ya que maneja líneas ruidosas, acentos y bajos bitrate sin muchos problemas.
• AssemblyAI Universal-Streaming funciona mejor cuando el audio es de buena calidad.
• gpt-4o-transcribe de OpenAI es preciso, pero la demora adicional se siente durante una conversación en vivo.
• Whisper es un modelo potente diseñado para tareas por lotes, por lo que no es adecuado para transmisiones en streaming.

Transmisión en tiempo real versus por lotes. El método por lotes espera a que quien llama termine antes de procesar, mientras que la transmisión en tiempo real transcribe a medida que llega el audio. Para los agentes de voz, la transmisión en tiempo real es la única opción viable.

Fallas en el vocabulario. Por defecto, la mayoría de los modelos de STT tienen dificultades con nombres de marcas, términos médicos y jerga sectorial. Las listas de palabras personalizadas, las indicaciones de pronunciación y el ajuste fino del modelo solucionan la mayor parte de estos problemas, por lo que debe reservarse tiempo para ello antes del lanzamiento en sectores como la salud, la logística o las finanzas.

Capa 2: el LLM

La capa de STT genera texto, y el modelo decide qué hacer con él. Lee la transcripción, identifica la solicitud, elige una acción y escribe una respuesta. En una llamada sencilla, eso significa responder a una pregunta. En una llamada compleja, implica utilizar una herramienta externa, esperar y integrar los datos en una respuesta natural, todo en el tiempo que tarda una persona en hacer una pausa entre oraciones.

Elegir un modelo. GPT-5 y Claude Sonnet son las opciones más fiables para la voz en 2026, ya que ambos gestionan bien el contexto, siguen las instrucciones al pie de la letra y mantienen las respuestas lo suficientemente cortas como para poderse pronunciar. Gemini 3 Flash merece ser considerado cuando la latencia es prioritaria. Llama y Mistral son adecuados para equipos que necesitan implementación local o un control de costos más estricto.

Indicaciones por voz versus indicaciones por chat. La voz tiene una limitación que el chat no tiene, que es la longitud. Un agente que lee un párrafo pierde al llamante. La indicación del sistema debe especificar el tono, la longitud de la respuesta, las condiciones de escalada y las palabras exactas que se deben usar cuando el agente no tiene respuesta.

Llamada a funciones. Cuando un cliente pregunta por un pedido, el agente consulta el sistema de pedidos o el CRM, espera el resultado y luego responde. Eso es lo que diferencia a un agente que solo habla de uno que también actúa. Hay un problema: las llamadas a funciones bloquean la transmisión en tiempo real, por lo que el diseño de la conversación debe tener en cuenta estas pausas.

Memoria. Existen dos tipos. La memoria de sesión abarca una sola llamada para que nadie tenga que repetir detalles, mientras que la memoria persistente se extiende más allá de las llamadas. Por lo general, los equipos implementan primero la memoria de sesión y añaden la funcionalidad de persistencia una vez que el proceso principal está establecido.

Capa 3: texto a voz

La impresión final del cliente proviene del sistema de texto a voz. Incluso una respuesta correcta, rápida y bien pensada pierde al cliente si suena robótica.

Qué hace que una voz suene natural. La prosodia, el ritmo y la velocidad de la primera letra. La prosodia es la melodía del habla, el movimiento de tono que indica al oyente si algo es una pregunta. El ritmo se refiere a las pausas en los lugares adecuados. Los modelos entrenados con grandes cantidades de habla real ahora lo hacen bien en ambos aspectos, y la salida robótica se ha vuelto mucho más rara que en 2025. La velocidad de la primera letra es el retraso antes de que quien llama escuche algo después de que comience la generación.

Herramientas.

• Cartesia Sonic es la líder en velocidad, ya que el primer audio llega antes que el de la mayoría de sus competidores.
• ElevenLabs es la opción más realista y permite clonar a partir de una muestra de audio corta.
• gpt-4o-mini-tts de OpenAI constituye una opción por defecto razonable si el resto del conjunto de herramientas ya es de OpenAI.
• PlayHT y Rime merecen una prueba cuando se necesita un acento o tono regional específico.

Clonación de voz. La mayoría de las plataformas clonan una voz a partir de una grabación breve, lo que permite a las empresas mantener una voz de marca consistente en cada llamada. Un hospital puede sonar tranquilo y clínico, mientras que una cadena de restaurantes de servicio rápido suena rápido y animado. Resuelva esto antes de ponerlo en producción.

TTS en streaming. El llamante debe escuchar la primera palabra mientras el modelo aún está escribiendo la última oración, lo que significa que el audio se emite antes de que la respuesta esté completa. Lo importante es la latencia del primer byte y no el tiempo total de generación. Manténgala por debajo de 200 ms en las llamadas en vivo.

Capa 4: telefonía y canales

Aquí es donde el mundo exterior se encuentra con la infraestructura. La forma en que el audio viaja desde el llamante hasta el modelo STT determina la calidad de la llamada, la latencia y el grado de control que usted tiene sobre la infraestructura.

Cómo se conectan las llamadas. La red telefónica tradicional, PSTN, limita la frecuencia de audio a 8 kHz, lo que afecta negativamente a todos los sistemas posteriores. SIP se utiliza para el tráfico VoIP y permite un control de enrutamiento más preciso. WebRTC funciona a través de Internet y ofrece mejor calidad de audio, por lo que es adecuado para su uso en navegadores y aplicaciones. Una distribución común es utilizar SIP para las llamadas entrantes y WebRTC para todo lo que se hace en la web.

Proveedores.

• Twilio es la opción segura por defecto gracias a su amplia cobertura, sus conexiones SIP fiables y sus buenos documentos de ayuda, aunque su costo aumenta con el volumen de uso.
• AWS Connect es adecuado para equipos que ya utilizan AWS.
• Vonage es una buena opción para implementaciones internacionales, especialmente en Europa y Oriente Medio.

Plataformas de orquestación. Retell AI, Vapi y LiveKit se sitúan en el medio, entre el operador y las opciones de STT, LLM y TTS que elijas. Ellas gestionan el enrutamiento de audio en tiempo real, el turno de habla, la detección de interrupciones y las transferencias. Para implementaciones telefónicas, Retell AI es la más madura; Vapi ofrece la mayor flexibilidad para pipelines personalizados, mientras que LiveKit funciona mejor con WebRTC.

Entrante y saliente. Un flujo entrante espera una llamada y responde a su llegada. Un flujo saliente realiza la llamada, verifica quién contestó y sigue una tarea predefinida como un recordatorio de pago o una confirmación de cita. El pipeline es el mismo en ambos casos; solo difieren el iniciador y el momento de inicio.

Capa 5: integraciones

Las integraciones son lo que permite al agente actuar y no solo hablar. Un modelo puede leer la intención y redactar una respuesta, pero sin conexión a sistemas reales no puede reservar un horario, buscar un pedido ni modificar un registro. Lo único que puede hacer es describir qué haría.

Qué se conecta. Típicamente cuatro categorías: CRM para buscar cuentas y contactos, herramientas de programación para reservas, sistemas de pedidos o logística para verificar el estado y procesadores de pagos para facturación. El agente de una clínica necesita el programa de programación, el agente de una tienda necesita la API de pedidos. Los sistemas varían, pero el ciclo es constante: el modelo hace una consulta durante la llamada, espera y utiliza la respuesta en su siguiente frase.

Cómo funciona la llamada. La llamada a funciones es lo que la impulsa, utilizando el mismo mecanismo descrito para la capa LLM. Cuando el modelo decide que necesita datos externos, emite una solicitud estructurada y se detiene. El resultado no fluye de vuelta por sí solo; su propio código debe capturarlo y añadirlo al historial de la conversación antes de que el modelo pueda utilizarlo. Sin ese paso, el agente se queda atascado en medio de la llamada, sin nada que decir.

Dónde falla. Dos aspectos causan la mayoría de los problemas. Una API lenta aumenta directamente el retraso, y quien llama no puede distinguir si el modelo está procesando información o si el CRM tardó 800 ms en responder. Una pausa sigue siendo una pausa. El otro problema es el manejo de fallos: cuando una búsqueda se agota el tiempo de espera, el agente necesita una respuesta preparada, no el silencio ni un bucle de frases repetidas.

Autenticación. Las credenciales suelen ser claves API o tokens OAuth con permisos de solo lectura o acceso de escritura limitado. Para verificar el estado de un pedido solo se necesita lectura. Reprogramar citas requiere acceso de escritura a un calendario, lo que aumenta la complejidad en el manejo de errores, ya que una llamada errónea puede modificar un registro en tiempo real.

Reducir la latencia

Tres estrategias son clave: transmitir tanto el STT como el TTS de forma continua en lugar de esperar a que se generen los resultados completos, almacenar en caché las respuestas a preguntas frecuentes y mantener todos los componentes en la misma región. Juntas, permiten reducir la latencia percibida en aproximadamente un 40%, con el objetivo de lograr un tiempo total inferior a un segundo.

Origen de la demora

Cada componente agrega su propio tiempo de procesamiento. La transcripción en tiempo real de voz a texto añade entre 50 y 150 ms, la inferencia de modelos de lenguaje grande suma entre 200 y 500 ms según el modelo y la longitud del prompt, y el primer byte de la síntesis de voz a texto requiere otros 100 a 200 ms, sin olvidar el tiempo adicional que implica la transmisión por red en cada etapa. Un flujo de trabajo que solo sea promedio en cada capa tarda cerca de 1,5 segundos antes de cualquier optimización. Las llamadas a funciones empeoran la situación, ya que la inferencia se detiene por completo hasta que la herramienta devuelve el resultado, lo que añade entre 300 y 800 ms.

Qué hacer al respecto

La transmisión en tiempo real es la solución más efectiva. Ejecute la transcripción en modo streaming para que comience antes de que quien habla termine, y utilice la síntesis de voz en tiempo real para que el audio se reproduzca antes de que la respuesta esté completamente escrita. Solo estos dos cambios ya generan una mejora del 40%.

El caché también ayuda. Si la mayoría de los usuarios hacen las mismas tres preguntas, genere previamente esas respuestas y sígalas proporcionándolas al instante. Además, mantenga los componentes geográficamente juntos. Separar la conversión de voz a texto en EE. UU. Este de un modelo de lenguaje grande en Europa Occidental implica un retraso de 80 a 120 ms por transacción debido al tráfico de red.

Para lograr el menor retraso posible, la conversión nativa de voz a voz reduce el tiempo total de procesamiento a entre 200 y 300 ms. Las diferencias en costos son significativas, pero las ventajas son cruciales cuando el ritmo de la conversación es esencial.

Interrupción durante la reproducción

La detección de interrupciones escucha el audio del usuario mientras se reproduce la síntesis de voz, interrumpe la respuesta a mitad de frase y redirige inmediatamente la comunicación. Tanto Retell AI como Vapi lo soportan de forma nativa. Ajuste el umbral de audio para que el ruido de fondo no genere interrupciones falsas.

Dónde implementarlo

La elección del entorno de despliegue afecta el costo, el cumplimiento normativo, la latencia y el grado de control que se tiene sobre la infraestructura, y es más importante de lo que la mayoría de los equipos se dan cuenta hasta que ya están en producción.

Nube es la opción por defecto. AWS, Azure y GCP ofrecen servicios gestionados para cada componente del pipeline, con una configuración rápida, escalado automático y sin necesidad de hardware. El precio que se paga es que los datos salen de su entorno, lo cual es relevante en industrias reguladas.

En las instalaciones propias significa que el audio, las transcripciones y los registros de los clientes nunca salen de sus propios servidores. Los sectores de la salud, las finanzas y cualquier país con normas de residencia de datos suelen requerir precisamente esto. Herramientas de código abierto como Whisper y modelos LLM autohospedados hacen que sea posible lograrlo sin tener que reconstruir cada capa del sistema.

Despliegue híbrido: divide la cadena de procesamiento según el nivel de sensibilidad de cada parte. La telefonía y la conversión de voz a texto permanecen en las instalaciones locales para que el audio en bruto no salga nunca, la inferencia de LLM se realiza en la nube gestionada y la conversión de texto a voz se ejecuta donde el retraso es menor. Las empresas suelen elegirlo porque los revisores de cumplimiento pueden aprobar por separado el manejo de datos en cada capa.

Conformidad

• En el sector sanitario de EE. UU., HIPAA implica acuerdos firmados con cada proveedor, audio encriptado en reposo y registros de acceso.
• GDPR aplica a toda cadena de procesamiento que involucre a residentes de la UE, con notificaciones claras de consentimiento para las llamadas grabadas.
• Las normas de residencia de datos en los EAU, Arabia Saudita y Alemania limitan dónde pueden almacenarse los datos de las conversaciones, por lo que es necesario verificar cada proveedor en relación con ellas antes del lanzamiento.

Escalabilidad

Las implementaciones en la nube se escalan horizontalmente, mientras que las configuraciones locales requieren planificación de capacidad antes de los picos conocidos. Pruebe con un volumen de tres a cinco veces superior al pico esperado antes de ponerlo en producción.

Monitoreo

Hay cuatro aspectos que merecen atención constante: las tasas de finalización y transferencia de llamadas, la latencia a nivel de componentes en STT, LLM y TTS, las llamadas a herramientas que fallan, y las intenciones no manejadas junto con las transcripciones guardadas para reproducirlas.

Si la tasa de transferencia aumenta bruscamente, significa que hay algún problema en el diseño de la conversación. Si el tiempo de respuesta del LLM sigue aumentando, sospeche que el prompt es demasiado largo o que una llamada a herramienta está atascada esperando. LangSmith se encarga de la observabilidad del LLM, mientras que Datadog o Grafana cubren la infraestructura.

Pruebas y evaluación

La mayoría de los fallos pueden detectarse antes del lanzamiento si se prueban los elementos adecuados.

1. Comience con escenarios programados en sus 20 a 30 flujos de llamadas principales.
2. Pasemos a las pruebas adversarias: interrumpa al agente, dele información incompleta y haga preguntas fuera de su ámbito de acción.
3. Esté atento a los fallos importantes, que son respuestas incorrectas seguras, transferencias que nunca se activan y llamadas a herramientas que dejan la línea en silencio.
4. Utilice herramientas como Hamming o el conjunto de evaluación de Vapi para simular cientos de escenarios de forma programática.

Hay cuatro métricas que son las más importantes: la tasa de finalización de tareas, la tasa de contención, el CSAT y el tiempo promedio de manejo. Regístrelas todas desde el primer día. Los componentes que funcionan bien con 10 llamadas simultáneas a menudo fallan con 100, de ahí la prueba de carga de tres a cinco veces esa cantidad. Después del lanzamiento, revise las transcripciones cada semana y úsalas para perfeccionar los prompts, reforzar las definiciones de funciones y mejorar los mecanismos de respaldo. Los agentes que mejoran más rápido cuentan con una rutina estructurada de revisión.

Diez lecciones de implementaciones reales

Los desarrolladores novatos en el área de la voz suelen comenzar con una creencia: elegir un buen modelo, redactar una instrucción clara y lanzar la aplicación. Seis semanas después, se encuentran lidiando con llamadas interrumpidas y picos de latencia, perplejos al ver que los agentes exponen hechos inventados con total confianza. Estas son las lecciones que los equipos aprenden a la fuerza.

1. El transporte es más importante que la elección del modelo. Sustituir WebSockets por UDP puede ser más útil que cambiar el modelo LLM. La mayoría de los modelos funcionan bien con una instrucción adecuada, mientras que la latencia e la infraestructura no responden en absoluto a las instrucciones dadas.
2. Un agente, una tarea. Para varias tareas distintas, utilice varios agentes que puedan comunicarse entre sí. Un único agente encargado de todo coopera mal.
3. Las llamadas a funciones interrumpen la transmisión en tiempo real. Nada se transmite hasta que finaliza la llamada a la herramienta. Diseñe el flujo de la conversación teniendo en cuenta esa interrupción y no en contra de ella.
4. Las ventanas de contexto largas engañan. Llenar un prompt al máximo es una apuesta que generalmente pierde, porque cuanto más contexto haya, más tiende el modelo a desviarse en los extremos. Proporcione solo lo necesario.
5. RAG aporta potencia pero también requiere mantenimiento. Ofrece un pipeline de datos del cual ahora es usted el dueño, que debe actualizarse constantemente, por lo que debe sopesar honestamente ese costo.
6. Las APIs en tiempo real superan a los sistemas de recuperación estática para datos en tiempo real. Si la actualidad es importante, consultar la fuente directamente es mejor que utilizar una capa de recuperación basada en una captura de ayer.
7. Los resultados de las herramientas necesitan un nuevo prompt. El modelo no ve el resultado de una herramienta hasta que este se agrega al historial y se envía de vuelta. Si se olvida de esto, el agente responderá sin base alguna.
8. Los prompts son parte de la arquitectura. Pruébelos e iteréelos de la misma manera que lo haría con el código, ya que contienen la lógica central del agente.
9. El audio y las transcripciones difieren. Lo que escuchó la persona que llamó y lo que se registró no siempre coinciden, por lo que el control de calidad no puede basarse únicamente en la precisión de las transcripciones.
10. La infraestructura de voz no es la misma que la de texto. Las lecciones aprendidas con el texto no son aplicables aquí. La voz presenta perfiles de latencia, comportamientos de conexión y modos de fallo distintos, por lo que hay que empezar de cero.

Costo

Realizarlo internamente cuesta aproximadamente 8,500 dólares para el prototipo más sencillo, cantidad que varía según el volumen y las funciones, y 100,000 dólares o más para un sistema de nivel empresarial, además de tres a seis meses de trabajo de ingeniería antes de que algo esté listo para su uso. Eso sin contar con los trabajos de cumplimiento ni con los gastos operativos anuales del 15 al 20% que suelen surgir tras la implementación en producción.

| Tier                              | Upfront Cost | Timeline    | Key Features                                               |
|-----------------------------------|--------------|-------------|------------------------------------------------------------|
| MVP/Proof of Concept              | $8K-$30K     | 4-10 weeks  | Basic voice flows, single integrations, RAG memory         |
| Mid-Tier (CRM/multi-intent)       | $25K-$150K   | 2-6 months  | Contextual reasoning, telephony (Twilio), analytics        |
| Enterprise (autonomous, compliant)| $150K-$300K+ | 4-12 months | Multi-agent orchestration, multilingual, deep ERP/CRM,     |
|                                   |              |             | HITL governance                                            |

El equipo por sí solo, que incluye ingenieros de IA, desarrolladores de backend, especialistas en DevOps y QA, cuesta 150,000 dólares o más al año, y ese equipo dedica su tiempo a la infraestructura en lugar del negocio principal.

La arquitectura mínimamente viable

Primero deben existir seis componentes, antes que nada más:

• Entrada de audio. Twilio o WebRTC transporta la voz del llamante al sistema.
• Transcripción en tiempo real. Deepgram Nova-3 transcribe mientras el llamante sigue hablando.
• Un modelo con una instrucción breve. GPT-5 o Claude Sonnet, manteniendo la instrucción del sistema por debajo de 500 tokens, ya que instrucciones más largas ralentizan las respuestas.
• Reproducción en tiempo real. Cartesia o ElevenLabs comienza a reproducir antes de que se escriba toda la respuesta.
• Registro. Guardar las transcripciones y el audio de cada capa desde el primer día.
• Plan de respaldo y transferencia. Establezca una regla de transferencia para los casos que el agente no pueda resolver.

Preguntas frecuentes

¿Es posible mantener los datos del cliente alejados de terceros? Sí, mediante hosting local o híbrido. Mantenga la telefonía y la conversión de voz a texto en su propia infraestructura para que el audio en bruto permanezca protegido, y permita que la inferencia del LLM se ejecute en la nube gestionada si la normativa lo aprueba en cada capa.

¿Puede la IA de voz manejar llamadas y SMS en la misma aplicación? Sí. Tanto la capa de telefonía como la capa de orquestación del LLM funcionan en todos los canales, por lo que la cadena de procesamiento que atiende una llamada telefónica puede enrutar una conversación por SMS a través del mismo modelo y lógica de llamadas a funciones.

¿Cómo se corrigen la mala entonación y el ritmo? La prosodia y el ritmo provienen del modelo de TTS y no del guion. Tanto Cartesia como ElevenLabs gestionan bien los cambios naturales de tono de forma predeterminada. Si el habla sigue sonando plano, la solución suele ser un modelo de voz diferente, no un prompt distinto.

¿Cómo se puede añadir inteligencia artificial de voz a un sistema telefónico existente sin cambiar los números? Transfiera el número a un tronco SIP a través del proveedor de telefonía y, a continuación, dirija el audio entrante desde ese tronco hacia la capa de STT. Los llamantes marcarán el mismo número de siempre; solo cambiará la ruta detrás de él.

¿Cómo evitar el encadenamiento al proveedor? Utilice la arquitectura en cascada. Cada componente funciona de forma independiente, por lo que Deepgram puede ser reemplazado por AssemblyAI o Cartesia por ElevenLabs sin necesidad de reconstruir el resto. Tanto la arquitectura de media cascada como la conversión de voz a voz nativa renuncian a esa flexibilidad a cambio de una menor latencia.