Agentes de voz para empresas

Una demo de voz puede impresionar en 30 segundos y fallar en la primera semana

La demostración suele ser impecable. El agente saluda, entiende una pregunta, responde con una voz natural y parece desenvolverse con una soltura que hace dos años habría resultado difícil de creer.

Después llega la llamada real.

El cliente habla desde el coche. Interrumpe. Da un apellido poco frecuente. Pide consultar un pedido. El ERP tarda cuatro segundos en responder. Cambia de tema. Después quiere hablar con una persona. La centralita tiene una cola distinta según el horario y, cuando la transferencia falla, hay que crear una devolución de llamada.

Ahí empieza el producto.

Un agente de voz para empresas no es simplemente una voz conectada a un modelo de inteligencia artificial. Es una pieza dentro de un proceso: recibe una llamada, interpreta lo suficiente para decidir qué hacer a continuación, consulta sistemas, ejecuta operaciones autorizadas, comprueba su resultado y sabe cuándo debe dejar paso a una persona.

La diferencia es importante porque muchas decisiones de compra se están tomando al revés: primero se elige una tecnología que conversa bien y después se intenta averiguar dónde encajarla. El enfoque que aplicamos en qué procesos merece la pena automatizar funciona también aquí: primero se analiza el proceso telefónico; después se decide qué tecnología necesita.

Qué es realmente un agente de voz para empresas

Un IVR tradicional —el menú de “pulse 1 para ventas, pulse 2 para soporte”— sigue un árbol predefinido. Un agente de voz moderno puede mantener una conversación más flexible, interpretar lenguaje natural y utilizar herramientas para consultar o modificar sistemas.

Pero eso no significa que deba improvisar.

La forma más útil de entenderlo es como una combinación de varias capas:

• Telefonía. El número, la centralita, las colas y el enrutamiento que hacen llegar la llamada.
• Conversación. La capa que escucha, interpreta el turno y genera una respuesta.
• Conocimiento. La información aprobada que puede utilizar para responder.
• Herramientas. Las conexiones con CRM, ERP, agenda, ticketing u otros sistemas.
• Políticas. Qué puede hacer, qué requiere identificación, qué necesita confirmación y qué debe escalar.
• Transferencia humana. Cómo pasa la llamada a una persona cuando corresponde.
• Observabilidad. Cómo sabemos qué ocurrió, cuánto tardó, qué falló y qué acciones se ejecutaron.

Esta es también la diferencia respecto a un agente de IA genérico: en voz, además de las decisiones y herramientas, aparecen problemas específicos de telefonía, audio, turnos, interrupciones y latencia que no existen igual en un flujo de texto.

Las siete pruebas antes de llamar “producción” a un agente de voz

Un sistema puede superar una prueba de conversación y suspender el resto. Para evaluar un agente de IA antes de darle más autonomía y comprobar si está preparado para atender llamadas reales, resulta más útil revisar siete áreas por separado.

Estas pruebas evitan una confusión frecuente: atribuir al “agente” cualquier fallo del circuito. Una llamada puede entenderse perfectamente y fracasar porque el CRM no responde. Puede funcionar la integración y fallar la transferencia. Puede acertar la intención y pedir datos que no necesitaba.

Si todos esos errores se agrupan bajo la etiqueta “la IA ha fallado”, no hay una ruta clara de mejora.

Qué llamadas merece la pena automatizar

La pregunta útil no es “¿qué puede decir un agente de voz?”. Hoy puede decir muchas cosas. La pregunta es qué llamadas pueden convertirse en un proceso controlable y verificable.

Suelen funcionar mejor como primeros casos de uso las preguntas frecuentes basadas en información aprobada, la captura estructurada de solicitudes, el alta de tickets, las confirmaciones sujetas a reglas, el seguimiento de estados verificables, la recuperación de llamadas perdidas, el overflow cuando el equipo está ocupado o la atención fuera de horario con un alcance limitado.

En cambio, una negociación compleja, una reclamación grave, una decisión de alto impacto con reglas difusas o un proceso que depende de un sistema interno inaccesible son candidatos mucho peores para una primera versión.

Una matriz mejor que “sí/no”

Una llamada de mucho volumen puede ser una mala candidata si la mitad de los casos son excepciones. Y una llamada de menor volumen puede justificar un proyecto si consume mucho tiempo, tiene un coste operativo alto y sus reglas están bien definidas.

La selección debería hacerse con una muestra real de llamadas, no con una lista de ideas creada en una reunión.

Cómo entra una llamada en un agente de voz

Sin entrar en una marca concreta, el recorrido técnico puede representarse así:

Algunos términos parecen más complejos de lo que son:

• PSTN. Es la red telefónica pública: la infraestructura tradicional por la que circulan muchas llamadas.
• SIP. Es un protocolo muy utilizado para establecer y enrutar llamadas sobre redes IP. Permite conectar centralitas y plataformas de comunicaciones sin asumir que hay que sustituir toda la telefonía existente.
• PBX o centralita. Es el sistema que distribuye las llamadas entre números, extensiones, colas o equipos.
• Streaming de audio. El audio se envía de manera continua mientras la conversación ocurre, en lugar de esperar a que termine para procesarlo.
• WebSocket y WebRTC. Son mecanismos utilizados en determinadas arquitecturas para mantener comunicación en tiempo real entre sistemas.

La documentación actual de OpenAI, por ejemplo, describe interfaces Realtime mediante WebRTC, WebSocket y SIP. Twilio documenta Media Streams para enviar y recibir audio de llamadas mediante WebSockets. Son ejemplos técnicos de que la infraestructura ya permite conversar en tiempo real; no implican que esas piezas, por sí solas, resuelvan el proceso empresarial.

Dos formas de construir la conversación: audio directo o cadena voz-texto-voz

Para un público no técnico, la diferencia puede explicarse sin entrar en modelos concretos.

Opción 1: speech-to-speech

Speech-to-speech significa, de forma sencilla, voz a voz. El sistema recibe audio y genera audio de forma directa dentro de un modelo preparado para interacción en tiempo real.

La ventaja conceptual es que hay menos saltos visibles entre escuchar y responder, lo que puede favorecer una conversación más fluida y preservar mejor elementos propios de la voz, como ritmo o entonación.

Pero no hay magia detrás: sigue necesitando políticas, herramientas, validaciones, permisos, registros y transferencia humana. Un modelo que habla de forma natural también puede ejecutar una acción incorrecta si la integración está mal diseñada.

Opción 2: STT → modelo → TTS

En esta arquitectura hay tres pasos explícitos:

• STT, speech-to-text. Convierte la voz del usuario en texto.
• Modelo. Interpreta ese texto, aplica contexto y decide qué responder o qué herramienta utilizar.
• TTS, text-to-speech. Convierte la respuesta escrita en voz.

Para entenderlo visualmente: es como si una persona escuchara la llamada y la transcribiera, otra decidiera la respuesta y una tercera la leyera en voz alta. En la práctica, todo sucede automáticamente y en muy poco tiempo.

Separar etapas puede facilitar determinados controles, elecciones de proveedor y observación de errores, aunque también introduce más componentes y potenciales puntos de latencia.

La parte difícil empieza cuando el agente tiene que tocar un sistema real

Responder “abrimos de 9 a 18” es relativamente sencillo si esa información está aprobada y actualizada. Consultar el estado de un pedido, crear un ticket, modificar una reserva o registrar un nuevo lead ya es otra cosa.

Ahí entran las herramientas: funciones o integraciones que permiten al agente pedir a una aplicación que realice una operación estructurada. En documentación técnica suele aparecer el término tool calling o function calling. La idea es importante: el modelo no debería imaginar el resultado; debe pedirlo al sistema que contiene la verdad.

Conviene separar tres categorías:

• Contenido estable. Horarios, ubicaciones, políticas generales, servicios o preguntas frecuentes. Puede proceder de una base de conocimiento controlada.
• Datos dinámicos. Estado de pedido, saldo, disponibilidad, ticket, reserva o incidencia. Deben consultarse en el sistema correspondiente.
• Acciones. Crear, modificar, cancelar, registrar, enviar o escalar. Deben ejecutarse mediante operaciones controladas.

Una base de conocimiento no sustituye al CRM. Y un documento que explica cómo se gestionan las devoluciones no confirma que una devolución concreta haya sido registrada.

La regla de confirmación

Supongamos que un cliente pide una devolución de llamada. El agente envía la orden al CRM y la respuesta tarda más de lo esperado.

Hay dos posibilidades muy diferentes:

1. La tarea se creó, pero la confirmación llegó tarde.
2. La tarea no se creó.

Si el agente interpreta un timeout como un fracaso y vuelve a ejecutar la operación sin control, puede crear dos tareas. Si interpreta el timeout como éxito, puede prometer una devolución que nunca se registró.

Por eso una acción debe pasar por una secuencia como esta:

Cuando la operación puede repetirse por reintentos, aparece otro concepto técnico: idempotencia. En lenguaje de negocio significa que repetir la misma petición no debería crear dos citas, dos tickets, dos pedidos o dos tareas.

Identidad y permisos: no toda llamada necesita saber quién eres

Uno de los errores más fáciles de introducir es pedir identificación demasiado pronto o, en el extremo contrario, revelar información porque el número entrante coincide con un contacto.

La identificación debería depender de la acción:

El número de teléfono ayuda a localizar un registro, pero no debería tratarse automáticamente como prueba inequívoca de identidad. Tampoco plantearía biometría de voz como solución por defecto: introduce otra categoría de tratamiento y una complejidad que solo tendría sentido después de analizar necesidad, proporcionalidad y marco aplicable.

La filosofía es la misma que en cualquier automatización bien diseñada: acceso mínimo para ejecutar la tarea y permisos distintos para leer y para escribir.

Latencia, interrupciones, nombres y ruido: lo que desaparece en una demo

La calidad de una llamada no depende solo de acertar la respuesta.

La latencia es el tiempo que pasa entre lo que hace el usuario y la respuesta del sistema. Si el silencio se alarga demasiado, la persona no sabe si el agente está pensando, si se ha cortado la llamada o si debe repetir. Y la latencia puede venir de varios sitios: audio, modelo, red o una herramienta externa que está consultando el ERP.

También hay que gestionar el turno. Una persona puede empezar a hablar antes de que el agente termine. Esta interrupción —a menudo llamada barge-in— debería detener o reajustar la respuesta, no obligar al usuario a esperar a que termine una locución.

Después están las situaciones que parecen triviales hasta que se convierten en datos de negocio:

• Un apellido poco común.
• Una dirección de correo que debe deletrearse.
• Una matrícula o referencia.
• Una fecha y una hora.
• Un número de pedido.
• Una cantidad económica.
• Una llamada desde manos libres con ruido.
• Una persona con un acento diferente al utilizado durante las pruebas.

En datos críticos conviene confirmar. “He entendido 17 de septiembre a las 16:30, ¿correcto?” es más útil que una falsa naturalidad que escriba silenciosamente una fecha equivocada.

No fijaría un número universal de milisegundos para decir que la latencia es “buena”. El criterio debe validarse con el flujo real: cuánto tarda en responder al inicio, cuánto después de usar herramientas y cómo reacciona el usuario en cada punto.

Transferir bien también es automatizar bien

Handoff humano es el traspaso de una interacción desde el agente automatizado a una persona. No es simplemente desviar una llamada a otra extensión. El valor está en que el humano reciba suficiente contexto para continuar desde donde se quedó la conversación.

Si un cliente lleva tres minutos explicando una incidencia y al transferir escucha “¿en qué puedo ayudarle?”, el sistema ha trasladado el audio, pero ha perdido el proceso.

Un handoff útil debería poder incluir:

• Motivo de la llamada.
• Identidad verificada o pendiente.
• Datos que ya se han recogido.
• Registro o expediente relacionado.
• Consultas o acciones intentadas y su resultado.
• Motivo de la transferencia.
• Resumen breve de la conversación.

No hace falta entregar una transcripción interminable al operador. Es más útil un paquete de contexto estructurado.

Tres salidas distintas

No todos los escalados necesitan el mismo mecanismo.

• Transferencia inmediata. El agente pasa la llamada en ese momento por petición expresa, riesgo, excepción o error crítico.
• Transferencia contextual. Recoge unos datos mínimos, prepara el contexto y deriva a una cola o persona.
• Callback o devolución de llamada. Si no hay una persona disponible, crea una tarea con prioridad, responsable y contexto para que el equipo devuelva la llamada.

Una tasa de transferencias baja no es necesariamente un éxito. También puede significar que el agente intenta resolver conversaciones que debería entregar a una persona.

Voz, transcripción y datos: guardar todo no es una estrategia

Una conversación telefónica puede producir varias capas de información: audio original, transcripción, resumen, entidades extraídas, IDs, resultados de herramientas y acciones.

No son lo mismo y no tienen por qué conservarse juntas.

La AEPD ha recordado en 2026 que, con carácter general, la voz puede constituir un dato personal cuando permite identificar o hacer identificable a una persona. Su análisis sobre transcripción con IA también pone el foco en responsabilidades, transparencia, derechos y conservación.

Por eso el diseño debería responder antes de desplegar:

• ¿Hace falta almacenar el audio completo?
• ¿La transcripción es temporal o persistente?
• ¿Puede conservarse únicamente un resumen estructurado?
• ¿Basta con registrar IDs, estado final y acciones ejecutadas?
• ¿Quién puede acceder a cada capa?
• ¿Durante cuánto tiempo?
• ¿Qué proveedores procesan esos datos y para qué?

Grabar por defecto porque la tecnología lo permite es una mala regla de diseño. En muchos casos, para operar un flujo puede ser suficiente conservar el resultado estructurado y la trazabilidad de la acción.

Informar de que se interactúa con IA

El Reglamento Europeo de Inteligencia Artificial establece en su artículo 50 obligaciones de transparencia para sistemas destinados a interactuar directamente con personas: el sistema debe diseñarse de forma que la persona sea informada de que está interactuando con una IA, salvo cuando resulte evidente atendiendo al contexto.

Para una empresa, la aplicación práctica no debería convertirse en una locución jurídica de cuarenta segundos. Un aviso breve y claro al inicio de la interacción puede cumplir una función mucho mejor de transparencia, sin perjuicio de la información adicional que corresponda sobre tratamiento de datos, grabación u otras cuestiones.

Una advertencia sobre llamadas comerciales salientes

Automatizar una llamada comercial no elimina las reglas que ya existían para llamar. En España existen restricciones específicas sobre comunicaciones comerciales telefónicas no solicitadas y la AEPD distingue además las llamadas automáticas sin intervención humana.

Antes de desplegar campañas salientes hay que revisar finalidad, base aplicable, oposición, listas de exclusión y el tipo concreto de automatización. Este artículo no pretende sustituir ese análisis jurídico.

Qué pasa cuando algo falla

Una arquitectura de producción se diferencia de una demo, entre otras cosas, porque diseña los fallos antes de que ocurran.

Algunos son obvios: la llamada se corta. Otros son más peligrosos porque parecen éxitos.

La regla más importante vuelve a aparecer aquí: no comunicar “hecho” si el sistema no ha confirmado la acción.

Y la segunda es igual de relevante: cada fallo debe tener una salida definida. Reintento, transferencia, devolución, cola, mensaje honesto o cierre controlado. “Que el agente improvise” no es una política de resiliencia.

Qué medir para saber si funciona de verdad

Un cuadro de mando útil debería permitir bajar desde el resultado general hasta el motivo concreto.

Cuando exista telemetría suficiente, también puede calcularse coste por llamada o por intención. Pero ese dato solo tiene sentido si se compara con el resultado obtenido, no como una cifra aislada de consumo.

Cómo lanzaría un piloto

No empezaría automatizando todo el teléfono de la empresa.

1. Medir llamadas reales. Si no hay datos fiables, analizar varias semanas de motivos, duración, horarios y transferencias.
2. Elegir entre tres y cinco intenciones. Utilizar la matriz de volumen, repetibilidad, estructura, integrabilidad, riesgo y excepciones.
3. Limitar el alcance. Una cola, un número, una sede, un horario o un tipo concreto de llamada.
4. Conectar primero en lectura cuando sea razonable. Verificar que el agente consulta correctamente antes de permitir escrituras.
5. Diseñar el handoff desde el primer día. No añadirlo después como parche.
6. Probar casos normales, ambiguos y adversos. Ruido, interrupciones, nombres, sistemas lentos, caídas y peticiones fuera de política.
7. Clasificar los fallos. Separar telefonía, conversación, conocimiento, herramientas, permisos y transferencia.
8. Activar escrituras de forma gradual. Con confirmaciones, prevención de duplicados y capacidad de reversión.
9. Ampliar solo cuando los fallos críticos estén controlados.

Cuánto cuesta un agente de voz: la voz es solo una de las variables

No existe un precio universal por “poner un agente de voz” porque dos proyectos pueden compartir modelo y diferir por completo en complejidad.

El coste depende, entre otras cosas, de:

• Minutos de conversación y simultaneidad.
• Telefonía, numeración y centralita existente.
• Arquitectura de voz elegida.
• Número de herramientas e integraciones.
• Complejidad de identidad y permisos.
• Base de conocimiento y frecuencia de actualización.
• Transferencias, colas y horarios.
• Política de audio, transcripción y conservación.
• Observabilidad y soporte.
• Entornos de prueba y producción.
• Número de intenciones y excepciones.
• Requisitos de resiliencia y disponibilidad.

Por eso dos agentes que “atienden llamadas” pueden tener costes de proyecto muy distintos. El desarrollo importante no está necesariamente en conseguir una voz agradable, sino en integrar la operación sin crear errores nuevos.

Es el mismo principio que explicamos al analizar cuánto cuesta automatizar un proceso empresarial: el presupuesto depende sobre todo de complejidad, sistemas, excepciones, riesgo y mantenimiento.

Lo que no automatizaría en una primera versión

Empezar pequeño no es una limitación del proyecto. Es una forma de obtener información real sin ampliar el radio de error.

• Todas las llamadas de la empresa al mismo tiempo.
• Procesos cuyo resultado no pueda verificarse.
• Acciones irreversibles o de alto impacto sin controles.
• Negociaciones complejas como primer caso de uso.
• Reclamaciones graves sin protocolo de escalado.
• Llamadas salientes comerciales masivas sin revisión previa de las reglas aplicables.
• Identificación biométrica por voz por defecto.
• Grabación completa simplemente porque esté disponible.
• Integraciones de escritura sin haber probado antes lecturas, permisos, errores y duplicados.
• Un despliegue sin salida humana o fallback operativo.

Un buen piloto no intenta demostrar que la IA puede hacerlo todo. Intenta descubrir qué parte del proceso puede asumir de manera fiable y qué condiciones hacen falta para ampliar después.

La pregunta no es si puede mantener una conversación

La conversación ya no es la parte sorprendente.

La pregunta relevante para una empresa es si el agente puede hacerse cargo de una parte concreta del proceso sin crear una nueva caja negra: si consulta el dato correcto, si ejecuta la acción permitida, si confirma lo que realmente ocurrió, si sabe detenerse y si una persona puede continuar cuando entra en escena.

Cuando esas condiciones se cumplen, la voz deja de ser una demo y se convierte en infraestructura operativa.

Y cuando no se cumplen, una voz muy natural solo consigue que el fallo suene mejor.