Diseñando flujos seguros de autenticación de identidad de llamantes para agentes de voz

Voice agents are rapidly evolving from simple FAQ responders to action-taking systems that modify accounts, process transactions, and access sensitive customer data. This shift introduces a critical challenge: How do you verify caller identity in a conversational AI system where traditional visual authentication methods don't exist?

Cuando un agente de voz puede actualizar suscripciones, consultar saldos o iniciar reembolsos, debe autenticar a quien llama con el mismo rigor que un centro de atención humano, pero usando solo la voz. A diferencia de los agentes humanos, que siguen políticas de empresa, los agentes IA necesitan una autenticación determinista basada en herramientas, sin depender del criterio de un LLM.

En este artículo te mostramos patrones de autenticación probados, basados en nuestra experiencia como Forward Deployed Engineers en despliegues empresariales. Verás cinco enfoques clave, desde autenticación por sesión para widgets integrados hasta métodos específicos de telefonía y verificación por OTP, y te explicamos cómo implementar cada uno usando control determinista de flujos en la plataforma de ElevenLabs.

Lo más importante: verás por qué la autenticación no puede dejarse a la interpretación conversacional. Debe diseñarse con subagentes aislados, verificación basada en herramientas y rutas condicionales en el flujo de trabajo, asegurando que solo usuarios autenticados acceden a operaciones sensibles.

Base arquitectónica para una autenticación determinista

Para garantizar que solo usuarios autenticados acceden a información de cuentas, recomendamos un entorno y acceso estrictamente segmentados mediante los workflows de ElevenLabs. La autenticación debe implementarse siempre con una llamada a herramienta que devuelva un resultado booleano de éxito o fallo, configurada como herramienta de despacho en el constructor de workflows de ElevenLabs.

Al vincular la condición de transferencia directamente al resultado de la herramienta, el subagente con acceso a datos de cuenta solo es accesible tras una autenticación exitosa y permanece completamente aislado de usuarios no autenticados. Así, la autenticación es determinista, no depende de la decisión de un LLM, y se evita cualquier avance en el flujo sin identidad verificada.

Como alternativa, puedes usar expresiones de transferencia como método fiable. Estas expresiones hacen referencia a variables dinámicas que se actualizan con los resultados de las herramientas.

Ejemplo de implementación

Verifica al usuario en Salesforce (llamada a herramienta). Si es correcto, recupera los datos de transacciones del cliente en Salesforce (otra llamada a herramienta) y luego transfiere al usuario a un subagente encargado de usar estos datos para comunicarse con el cliente y realizar otras acciones si hace falta.

Métodos de autenticación de identidad de usuario

Estos métodos de autenticación no están soportados de forma nativa en la plataforma de ElevenLabs. Puedes implementarlos mediante herramientas en el servidor que se integren con tu CRM o backend/base de datos, donde se almacena la información de autenticación.

Autenticación de la aplicación anfitriona

Para agentes de voz integrados en una web, la aplicación anfitriona puede pasar datos de sesión del usuario (como estado de inicio de sesión, ID de cuenta o tokens de sesión) mediante variables dinámicas al iniciar el agente/widget. Estas variables se inyectan automáticamente en las llamadas a herramientas usando las mismas variables dinámicas, permitiendo que el agente recupere datos personalizados de sistemas integrados sin requerir autenticación adicional.

Esto permite un flujo de soporte sin interrupciones, ya que el usuario ya fue verificado por la aplicación anfitriona. Puedes configurarlo de forma personalizada o usar el widget de ElevenLabs, donde pasas variables en tiempo real mediante la configuración del widget (por ejemplo, <elevenlabs-convai dynamic-variables='{"user_id": "123", "account_tier": "premium"}'>).

Documentation on Dynamic Variables:

• https://www.11labs.ru/docs/agents-platform/customization/personalization/dynamic-variables#pass-variables-at-runtime 

Autenticación basada en conocimiento (KBA)

El agente de voz pide al usuario datos de autenticación como número de cuenta, código postal, fecha de nacimiento o respuestas de seguridad. Una herramienta en el servidor (webhook o cliente) verifica estos valores en tu base de datos (por ejemplo, CRM o almacén de identidades). La herramienta devuelve un resultado de éxito/fallo que incluye un estado booleano (is_error) y un texto descriptivo. Puedes implementarlo con control determinista de flujos: tras solicitar la información, configura un despacho de herramienta y usa transferencias condicionales en el workflow que ramifican según el estado de éxito/fallo, dirigiendo a usuarios autenticados a nodos “privilegiados” del agente.

Este enfoque admite preguntas de seguridad estáticas y verificación dinámica del tipo "fuera de cartera", dependiendo de tus requisitos de riesgo de fraude.

Documentación sobre herramientas:

• https://www.11labs.ru/docs/agents-platform/customization/tools/server-tools 
• https://www.11labs.ru/docs/agents-platform/customization/agent-workflows#dispatch-tool-node 

Variables dinámicas del sistema (solo telefonía)

En conversaciones telefónicas (vía Twilio o SIP trunk), tu agente accede automáticamente a variables del sistema específicas de telefonía, como system__caller_id (el número de teléfono de quien llama). Esta variable se rellena automáticamente al iniciar la conversación y puedes usarla de dos formas: 1) En prompts/mensajes: Haz referencia usando doble llave, por ejemplo {{system__caller_id}}, y se sustituirá por el valor real; 2) En parámetros de herramientas: Configura los parámetros para usar estas variables, permitiendo autenticación silenciosa sin mencionarlas en el prompt.

Por ejemplo, puedes configurar una herramienta para pasar automáticamente el caller ID a tu ruta de consulta en el CRM, permitiendo que el agente verifique en silencio si el número entrante coincide con el registrado para la autenticación del usuario. En vez de una llamada a herramienta, la autenticación también puede configurarse como un webhook de inicio de conversación que se ejecuta antes de que empiece la conversación.

Nota de seguridad: Como quien llama puede usar números distintos a los registrados, o los números almacenados pueden estar accesibles para personas no autorizadas, la autenticación basada en caller ID debe requerir consentimiento previo del cliente o combinarse con otros métodos (por ejemplo, preguntas de conocimiento).

Documentación sobre variables dinámicas del sistema y webhook de inicio:

• https://www.11labs.ru/docs/agents-platform/customization/personalization/dynamic-variables#system-dynamic-variables 
• https://www.11labs.ru/docs/agents-platform/customization/personalization/twilio-personalization 

Autenticación avanzada por preguntas de seguridad/conocimiento

El agente puede autenticar al usuario haciendo varias preguntas de seguridad y solo da acceso si responde correctamente un número predefinido. El agente puede seleccionar preguntas aleatorias de una lista (por ejemplo, fecha de nacimiento, código postal, nombre de mascota) y validar las respuestas mediante una llamada a herramienta a tu base de datos.

La herramienta de autenticación devuelve una respuesta JSON con el número de aciertos actual. Usando asignaciones de herramienta, este contador se extrae y almacena/actualiza automáticamente en una variable dinámica (por ejemplo, auth_success_count). Tras cada verificación exitosa, la variable aumenta.

Cuando se alcanza el número requerido de verificaciones (por ejemplo, 3), una condición de expresión en el workflow comprueba el valor de la variable dinámica y pasa a un nodo de subagente privilegiado. La expresión usa operadores de comparación (por ejemplo, auth_success_count >= 3) para controlar el acceso de forma determinista según el estado de autenticación.

Documentación aquí: https://www.11labs.ru/docs/agents-platform/customization/agent-workflows#edges-and-flow-control 

Código de un solo uso

Este método universal consiste en enviar un código de un solo uso al dispositivo del usuario por SMS o email. El usuario debe comunicar el código al agente para verificarlo y obtener acceso.

Flujo de implementación:

1. Generación de código: El agente inicia el proceso con una llamada a herramienta en el servidor a una ruta dedicada. Esto genera un código seguro de un solo uso y lo envía al usuario por el canal elegido (SMS o email).
2. Solicitud al usuario: El agente pide al usuario que indique el código recibido. En modo voz, el usuario dice el código en voz alta y se captura mediante speech-to-text.
3. Verificación del código: El agente envía el código proporcionado por el usuario a un servicio de verificación en el backend mediante una segunda llamada a herramienta. El backend comprueba que el código coincide, no ha caducado y no se ha usado antes.
4. Rutas del workflow: El agente gestiona el resultado según la verificación: Éxito: Si el código es correcto, el usuario pasa a la parte posterior a la autenticación mediante una condición de éxito. Fallo: Si el código es incorrecto, el agente puede pedir que lo introduzca de nuevo o iniciar un procedimiento alternativo (por ejemplo, enviar un nuevo código).

Consideraciones de seguridad: Debes limitar los intentos para evitar ataques de fuerza bruta, los códigos deben caducar rápido (3-5 minutos) y controlar el número de reintentos. En interacciones por voz, considera prompts de confirmación para asegurar la precisión del speech-to-text al capturar códigos.

Conclusión

Estos métodos de autenticación son bloques flexibles para construir tu solución, no recetas cerradas. Elige según tu perfil de riesgo, requisitos normativos y experiencia de usuario que buscas. Un bot de atención al cliente necesita una seguridad distinta a la de un asistente bancario que gestiona transacciones. La flexibilidad de la plataforma te permite adaptar tu estrategia de seguridad a medida que cambian las amenazas y crecen los requisitos, siempre equilibrando protección y experiencia de usuario.