Un agente de voz con IA mentía a los clientes y confundía a los llamantes: el desarrollador halló la causa fuera del prompt

Tres meses en producción bastaron para que el agente de voz con IA mintiera a un cliente sobre un administrador inexistente, hiciera pasar durante un mes una síntesis de voz corriente por una «voz clonada» y tomara a todos los llamantes por la misma persona. El desarrollador concluyó que el problema no eran los prompts, sino la arquitectura del código alrededor del modelo. Y todo ello sobre una pila tecnológica íntegramente rusa. El responsable de un agente de voz con IA para empresas documentó los tropiezos de tres meses en condiciones reales: el agente mentía, confundía a los clientes y falseaba la voz de un modo que nadie había previsto. La conclusión: la mayoría de los «comportamientos extraños» no son alucinaciones del modelo, sino agujeros arquitectónicos en el código que lo rodea. Se pueden arreglar, pero no con un prompt.

Procesado por IA desde Habr AI; editado por Hamidun News
Un agente de voz con IA mentía a los clientes y confundía a los llamantes: el desarrollador halló la causa fuera del prompt
Fuente: Habr AI. Collage: Hamidun News.
Escuchar artículo
Ficha técnica y cifras clave
ParámetroDatos
Fuente originalHabr AI ↗
Editor jefe
Dato clave #1El agente llamaba al nuevo cliente por el nombre del llamante anterior
Dato clave #2Recordaba detalles del pedido de otra persona y proponía «continuar con la tramitación»
Dato clave #3Confirmaba acuerdos inexistentes de sesiones pasadas

El desarrollador de un agente de voz con IA para empresas pasó tres meses en condiciones reales y documentó todos los tropiezos: el agente mentía, confundía a los clientes y falseaba la voz de una forma muy distinta a la prevista.

Los tres grandes fallos del agente

En sus primeros meses en producción, el agente de voz protagonizó varios incidentes.

Primer incidente: el agente le dijo a un cliente que «el administrador Alexéi» le devolvería la llamada en una hora. Ningún Alexéi existía. El agente generó el nombre a partir del contexto de llamadas anteriores, mezclando fragmentos de diálogos. El cliente esperó y presentó una queja.

El segundo error fue más grave: el agente empezó a tratar a todos los llamantes como si fueran la misma persona. La sesión no se reiniciaba entre llamadas, y la memoria del cliente anterior se filtraba a la siguiente conversación. Técnicamente, es el problema clásico del contexto compartido sin aislamiento explícito.

  • El agente llamaba al nuevo cliente por el nombre del llamante anterior
  • Recordaba detalles del pedido de otra persona y proponía «continuar con la tramitación»
  • Confirmaba acuerdos inexistentes de sesiones pasadas
  • Se disculpaba por un «retraso» que no se había producido, al confundir la llamada actual con la anterior

El tercer caso fue el que más tardó en detectarse. Durante un mes entero, el agente usó una síntesis TTS corriente mientras se presentaba ante los clientes como una «voz clonada». La clonación no se conectó por un error de configuración, pero no lanzó ninguna excepción: simplemente degradó en silencio a la síntesis estándar.

Por qué el prompt no lo arregla

La primera reacción intuitiva es añadir al prompt frases como «no inventes nombres», «no recuerdes a los llamantes anteriores», «comprueba siempre si existe un perfil de voz». El autor lo probó y explica por qué no funciona de forma sistemática.

Un modelo de lenguaje no distingue entre una prohibición del prompt y los datos del contexto de la sesión. Si el historial de una llamada anterior entra físicamente en la ventana de contexto, el modelo lo usa. Una instrucción no puede prohibir lo que ya está en la memoria.

«El prompt es una recomendación, no una barrera arquitectónica.

La barrera debe estar en el código.»

La solución consiste en aislar el estado a nivel de infraestructura: reinicio total del contexto entre llamadas, comprobación del perfil de voz antes de empezar la llamada (no durante ella) y validación explícita de cada dato antes de pronunciarlo.

La pila rusa y sus peculiaridades

El autor trabaja íntegramente con herramientas nacionales: un LLM ruso, un proveedor ruso de TTS y telefonía a través de un operador local. Esto impone limitaciones específicas.

La documentación de varias de estas herramientas es incompleta o va por detrás de la API. Por eso el error de clonación de voz pasó inadvertido: si faltaba el perfil de voz, el proveedor no devolvía ningún error. Entregaba sin avisar la síntesis estándar con código 200. La sustitución solo podía detectarse analizando el audio de salida o comprobando de forma explícita los metadatos de la respuesta.

Lecciones prácticas de tres meses de experiencia:

  • Comprueba que existen todos los recursos (voz, perfil, sesión) antes de iniciar la operación, no durante ella
  • Registra no solo los errores, sino también las respuestas «correctas»: la degradación silenciosa es más peligrosa que un fallo evidente
  • Aísla el estado del agente entre sesiones en el código, no en el prompt
  • Prueba la salida de audio, no solo el registro de texto: una síntesis y un clon suenan distinto

Qué significa esto

Los agentes de voz con IA fallan en producción de otra manera que los chatbots: los errores se dicen en voz alta, el cliente los oye en tiempo real y no puede releerlos ni ignorarlos. Eso hace crítica la pulcritud arquitectónica.

La mayoría del «comportamiento extraño» de un agente de voz no son alucinaciones del modelo, sino agujeros arquitectónicos en el código que lo rodea. Se puede arreglar. Pero no con un prompt.

Preguntas frecuentes sobre la noticia

¿Qué se sabe sobre Los tres grandes fallos del agente?

En sus primeros meses en producción, el agente de voz protagonizó varios incidentes. Primer incidente: el agente le dijo a un cliente que «el administrador Alexéi» le devolvería la llamada en una hora. Ningún Alexéi existía. El agente generó el nombre a partir del contexto de llamadas anteriores, mezclando fragmentos de diálogos. El cliente esperó y presentó una queja. El segundo error fue más grave: el agente empezó a tratar a todos los llamantes como si fueran la misma persona. La sesión no se reiniciaba entre llamadas, y la memoria del cliente anterior se filtraba a la s

¿Qué se sabe sobre Por qué el prompt no lo arregla?

La primera reacción intuitiva es añadir al prompt frases como «no inventes nombres», «no recuerdes a los llamantes anteriores», «comprueba siempre si existe un perfil de voz». El autor lo probó y explica por qué no funciona de forma sistemática. Un modelo de lenguaje no distingue entre una prohibición del prompt y los datos del contexto de la sesión. Si el historial de una llamada anterior entra físicamente en la ventana de contexto, el modelo lo usa. Una instrucción no puede prohibir lo que ya está en la memoria. «El prompt es una recomendación, no una barrera arquitectóni

¿Qué se sabe sobre La pila rusa y sus peculiaridades?

El autor trabaja íntegramente con herramientas nacionales: un LLM ruso, un proveedor ruso de TTS y telefonía a través de un operador local. Esto impone limitaciones específicas. La documentación de varias de estas herramientas es incompleta o va por detrás de la API. Por eso el error de clonación de voz pasó inadvertido: si faltaba el perfil de voz, el proveedor no devolvía ningún error. Entregaba sin avisar la síntesis estándar con código 200. La sustitución solo podía detectarse analizando el audio de salida o comprobando de forma explícita los metadatos de la respuesta.

ZK
Zhemal Khamidun — CPO de Alpina Digital, product manager de AlpinaGPT. Crea productos de IA desde 2019. Hamidun News es un proyecto personal que creció hasta ser un agregador en producción con más de 6.000 lectores.
✦ Unified AI Workspace · Nomad

Test Frontier LLMs & Autonomous Agents in One Workspace

Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.

Try Nomad AI →Launch Nomad Agent
¿Qué te parece?
Cargando comentarios…