--- title: "Agentes de voz en tiempo real · Polargate" description: "Agentes de voz conversacional construidos sobre tu propio backend: verifican quién habla, leen datos reales de tu base de datos y escriben en los mismos sistemas…" url: https://polargate.ai/es/services/build/voice-agents locale: es publisher: POLARGATE S.L. --- - [Polargate](https://polargate.ai/es) - [Servicios](https://polargate.ai/es/services) - [Build](https://polargate.ai/es/services/build) - Agentes de voz en tiempo real Build // Agentes de voz que ejecutan, no que leen en alto una respuesta. # Agentes de voz en tiempo real Agentes de voz conversacional construidos sobre tu propio backend: verifican quién habla, leen datos reales de tu base de datos y escriben en los mismos sistemas que usa tu equipo. Nuestro agente hotelero maneja entre 11 y 12 herramientas de servidor contra las mismas funciones de base de datos que la app. Se publica como piloto: todavía sin línea telefónica viva, y por turnos, no full duplex. En corto Polargate construye agentes de voz que ejecutan, no que solo informan. El agente que corre en nuestro producto hotelero hace login del huésped por voz, lee la carta real del restaurante desde la base de datos, gestiona room service, crea, modifica y cancela reservas de restaurante y de spa, y abre un ticket clasificado en el mismo sistema que usa la app, con entre 11 y 12 herramientas de servidor cableadas contra las mismas funciones de base de datos. La identidad se verifica dentro de la llamada y el PIN nunca llega al proveedor de voz ni a los registros. El prompt de sistema se compila de forma determinista desde la configuración de cada propiedad y aguantó un red team adversarial, 0 vectores de 6 tras endurecerlo. Es un piloto y lo decimos: no hay número de teléfono vivo atendiendo a clientes reales, no hay consulta de disponibilidad ni de precios de habitación contra el PMS, y no hay full duplex. ## Qué es Un agente que atiende a tu cliente por voz y además ejecuta. Verifica quién habla, lee datos reales de tu base de datos y escribe en los mismos sistemas que ya usa tu equipo. Lo construimos, lo endurecemos y lo seguimos atendiendo después nosotros. Esta página está escrita como piloto, porque es lo que es. Lo que viene separa lo que ya funciona de lo que todavía no. ## Lo que ya hace nuestro agente El agente hotelero de nuestro propio producto hace login del huésped por voz, informa del hotel, lee la carta real de cada restaurante desde la base de datos, gestiona room service, crea, modifica y cancela reservas de restaurante y de spa, hace triaje de incidencias abriendo un ticket clasificado en el mismo sistema que usa la app, deja recados a recepción y transfiere a recepción cuando la propiedad lo activa. Son entre 11 y 12 herramientas de servidor cableadas contra las mismas funciones de base de datos que llama la app. No es una integración paralela, es la misma fuente de verdad. ### No se inventa nada La carta se lee de la base de datos. Si un restaurante no tiene carta cargada, el agente lo dice en vez de inventarla, y rechaza platos que no existen. Respeta los días de apertura y las ventanas de reserva reales, y cuando no puede reservar da el horario de verdad en lugar de un error genérico. Verificado en 18 de 18 escenarios hablados en una ronda de QA de julio de 2026 contra el agente en marcha de una propiedad de demostración, con evidencia de audio, transcripción, interfaz y base de datos. Una QA anterior del preview, en junio de 2026, salió con 21 de 24 pruebas perfectas y ningún fallo crítico. ### La identidad se verifica dentro de la llamada Habitación o nombre más un PIN, con hash y bloqueo por intentos, una sola vez por conversación. El PIN nunca llega al proveedor de voz ni a los registros. El identificador del tenant se resuelve siempre en servidor, nunca desde el modelo ni desde el payload. El mismo agente soporta dos modos de sesión: dentro de la app, ya autenticado por un vínculo de servidor, sin pedirle nada al huésped; y un modo de llamada con el flujo de verificación hablado completo. ### El prompt es ingeniería, no una caja de texto El prompt de sistema del agente piloto ronda los 31.000 caracteres y se compila desde la configuración de la propiedad con un compilador determinista, sin ningún modelo de lenguaje dentro. Antes de salir pasó por un red team adversarial de doce agentes: 4 de 6 vectores rompían el borrador y 0 de 6 pasaron tras endurecerlo. Una auditoría aparte repasó los esquemas de las herramientas y las dejó sanas, 12 de 12. ### Un agente por tenant, dado de alta solo Dado un hotel con voz activa, una función de borde crea su agente, compila su prompt desde la configuración de esa propiedad y le asigna las herramientas que permiten sus capacidades. Ese camino se probó de punta a punta en producción, con limpieza total después. El equipo del cliente edita nivel y capacidades desde la propia plataforma, y el backend de voz solo lee esa configuración por una función que falla cerrada y que no devuelve datos de huésped ni PIN. El aislamiento lo comprueba una máquina, no una persona: RLS en las tablas que llevan identificador de tenant y un guardián que descubre tenants y tablas en vez de enumerarlas, ejecutándose en integración continua. A agosto de 2026 vigila 81 tablas con identificador de hotel, y esa ejecución, entre dos hoteles reales, no encontró ninguna fuga cruzada. ## Lo que todavía no hace - No hay número de teléfono vivo atendiendo llamadas de clientes reales. La pata telefónica está diseñada, el número está pendiente de trámite regulatorio y no se ha validado ninguna llamada entrante real de un huésped. - No consulta disponibilidad ni precios de habitación contra el PMS. Esa capa no está abierta, y la herramienta de disponibilidad cubre solo restaurantes. - No hay full duplex. Las APIs disponibles hoy funcionan por turnos y ningún proveedor publica cifras oficiales de latencia extremo a extremo, así que no damos ninguna. Sí tenemos medida la latencia de síntesis al leer en alto una respuesta escrita, pero eso es texto a voz, no conversación, y mezclar las dos cifras sería deshonesto. - Todos los agentes que hemos construido hasta hoy son hoteleros. El mecanismo no es específico de hotel. La prueba en producción sí. ## Leer en alto una respuesta no es una conversación El texto a voz lee algo ya escrito. Un agente de voz escucha, decide y llama a herramientas contra tus datos. Son productos distintos, cuestan dinero distinto y no mezclamos sus cifras. ## El stack Motor conversacional de ElevenLabs para el agente, la voz y la transcripción, con el modelo de lenguaje dentro. Backend propio en Supabase, con funciones de borde y funciones de base de datos con privilegio controlado. Los secretos en un vault, nunca en el repositorio. La plataforma sobre la que corre este agente está en producción con huéspedes reales en dos hoteles, uno de ellos desde agosto de 2026. Esas cifras son de la plataforma, no del canal de voz, y no las presentamos como resultados de voz. Qué recibes - Herramientas de servidor cableadas contra las mismas funciones de base de datos que ya llama tu app o tu portal, para que la voz escriba en una única fuente de verdad - Identidad verificada dentro de la llamada, con hash y bloqueo por intentos, y el secreto sin llegar nunca al proveedor de voz ni a los registros - Prompt de sistema compilado desde tu configuración por un compilador determinista, sin ningún modelo de lenguaje dentro del compilador - Red team adversarial contra el prompt antes de salir, más auditoría de todos los esquemas de herramientas - Aislamiento por tenant con RLS y un guardián automático que descubre tablas en vez de enumerarlas, ejecutándose en integración continua - Alta autoservicio: una propiedad nueva recibe su agente, su prompt y sus herramientas en una sola operación - QA hablada contra el agente en marcha, guardando audio, transcripción, interfaz y base de datos como evidencia Formato Plazos El calendario lo marcan las acciones, no la voz. Cablear el motor de voz es la parte corta: cada cosa que el agente puede hacer es una herramienta de servidor contra tu base de datos, con sus reglas y sus pruebas. Un Discovery Sprint de alcance cerrado decide qué acciones entran en la primera versión antes de construir nada. Nuestro agente hotelero pasó rondas de QA hablada en junio y julio de 2026 antes de ponerlo delante de un huésped, y para el tuyo planteamos lo mismo. Si atender una línea telefónica real forma parte de lo que necesitas, dilo desde el principio: es la pata que no tenemos validada y arrastra su propio trámite regulatorio. Equipo Somos dos, y ninguno es comercial. Pedro Ciordia, fundador y CTO de Polargate, hace la arquitectura, las herramientas, la ingeniería del prompt y las revisiones; Andrés Ciordia, Chief AI Officer, lleva los agentes de voz. Sumamos especialistas de la red del estudio cuando el proyecto lo pide. La parte adversarial forma parte del método: al prompt y a los esquemas de herramientas se les ataca antes de que ningún cliente hable con el agente. Coste Se acota y se presupuesta en un Discovery Sprint de precio cerrado, desde 4.900 EUR, que termina con un precio cerrado para la construcción. Lo que mueve ese precio es el número de acciones que el agente tiene que ejecutar, no la voz. El consumo del proveedor de voz se factura aparte. La operación posterior va por Care, desde 850 EUR al mes. Stack - Supabase - PostgreSQL - Deno ## Pruebas Estevano ### Estevano: la app del huésped y la consola de staff que sostienen el día del hotel Estevano es el producto hotelero propio de Polargate: app del huésped, asistente de IA y consola de staff que convierten una petición en un ticket enrutado, con responsable y con reloj. Lleva meses en producción en Santo Domingo Bay, donde atendió unas 2.500 peticiones reales de huésped en cuatro meses con una mediana de resolución de dieciséis minutos. 2026 Ver el caso [Estevano: la app del huésped y la consola de staff que sostienen el día del hotel](https://polargate.ai/es/work/estevano-hotel-operations) FAQ ## Preguntas, respondidas ¿Un agente de voz puede atender nuestro teléfono? Todavía no, y preferimos decirlo aquí y no en la reunión de arranque. El agente tiene un modo de llamada con el flujo de verificación hablado completo, pero la pata telefónica está diseñada y no ejecutada: el número está pendiente de trámite regulatorio y no se ha validado ninguna llamada entrante real de un cliente. Lo que sí hemos probado es la voz dentro de la app, donde el huésped llega ya autenticado por un vínculo de servidor y no se le pide ni habitación ni PIN. Si lo que necesitas de verdad es una línea telefónica viva, eso es lo primero que hay que planificar, presupuestar y validar. ¿Cómo evitáis que se invente cosas? No dejándole responder de memoria. Los datos salen de tu base de datos por herramientas de servidor, así que la carta es la que está cargada, y si un restaurante no tiene carta el agente lo dice en vez de fabricarla. Rechaza lo que no existe y respeta días de apertura y ventanas de reserva reales. El prompt de sistema lo atacó un red team adversarial de doce agentes antes de salir: 4 de 6 vectores rompían el borrador y 0 de 6 pasaron tras endurecerlo. Una ronda de QA de julio de 2026 pasó 18 de 18 escenarios hablados contra el agente en marcha de una propiedad de demostración, guardando audio, transcripción, interfaz y base de datos como evidencia. Son resultados de pruebas fechadas, no una garantía permanente, y se repiten. ¿Esto solo sirve para hoteles? El mecanismo no es específico de hotel: un agente, un conjunto de herramientas de servidor contra tu base de datos, un prompt compilado desde tu configuración y aislamiento por tenant. Pero seamos claros con la prueba. Todos los agentes de voz que ha construido Polargate hasta hoy son hoteleros, y ahí es donde se hicieron las pruebas en producción. Si tu caso es de otro sector, eres el primero con nosotros, y el Discovery Sprint existe justo para valorar y acotar ese riesgo en lugar de disimularlo. ¿En qué se diferencia de un chatbot que habla? Un chatbot que habla lee en alto una respuesta ya escrita. Eso es texto a voz, e informa. Un agente de voz escucha, verifica quién habla, decide y llama a herramientas que cambian registros reales: un pedido, una reserva, un ticket en el mismo sistema en el que trabaja tu equipo. Son productos distintos y sus cifras no se trasladan, por eso no damos nuestra latencia de síntesis como si fuera latencia de conversación. Las APIs disponibles hoy funcionan además por turnos, no en full duplex, y ningún proveedor publica latencia oficial extremo a extremo, así que no prometemos una cifra que no podemos medir. ¿Están seguros nuestros datos si el proveedor de voz está en medio? El diseño da por hecho que el proveedor de voz es un tercero. La verificación ocurre dentro de la llamada y el PIN va con hash, con bloqueo por intentos, y nunca se envía al proveedor ni se escribe en los registros. El identificador del tenant se resuelve en nuestro servidor, nunca desde el modelo ni desde el payload, así que ningún prompt puede hablar hasta llegar a los datos de otro cliente. El endpoint de configuración falla cerrado y no devuelve datos de huésped. El aislamiento se impone con RLS y se comprueba en integración continua con un guardián que descubre tablas en vez de enumerarlas: a agosto de 2026 cubre 81 tablas con identificador de hotel, y esa ejecución, entre dos hoteles reales, no encontró ninguna fuga cruzada. Es una verificación fechada, no una propiedad permanente, y se vuelve a ejecutar en cada cambio. INITIATE ## Arranca el motor Cuéntanos qué estás construyendo en unas pocas preguntas cortas. Un ingeniero senior responde por escrito en 48 horas laborables con una primera lectura de alcance, plazos y precio. [Empieza tu proyecto](https://polargate.ai/es/start) · [Habla con nosotros](https://polargate.ai/es/start#static-brief-heading)