"Soluciones de Pago Avanzadas" lanzó asistente de voz con IA para llamadas en piloto sin equipo de ML

La empresa "Soluciones de Pago Avanzadas" contó cómo lanzó un asistente de IA por voz para llamadas en piloto sin su propio equipo de ML. En seis meses, 12 desarrolladores backend construyeron un sistema que en tiempo real sugiere al gerente cómo responder al cliente y se ajusta a un retardo de alrededor de dos segundos.

Cómo se construyó el MVP

Dentro de la empresa el proyecto recibió el nombre "Apuntador". Su tarea es escuchar una conversación ya transcrita, entender qué producto se está discutiendo, notar objeciones del cliente e inmediatamente mostrar al gerente una sugerencia de texto. La pila final se ensambló en Python, FastAPI y PostgreSQL, mientras que clasificadores BERT y Qwen 8B local se encargaban de la clasificación y generación.

Para el negocio esto es una forma de reducir la carga en los mentores y llevar a los nuevos empleados a KPI más rápido, especialmente cuando el ecosistema tiene más de 35 productos y el gerente necesita mantener demasiados escenarios en mente. La restricción clave era estricta: el sistema tiene solo 1,5–2 segundos para responder, de lo contrario la sugerencia pierde sentido justo en medio de un diálogo en vivo.

El equipo llegó a un prototipo funcional rápidamente. En las primeras tres semanas los desarrolladores tomaron transcripciones de texto de las llamadas, entrenaron dos clasificadores BERT en aproximadamente 1.500 diálogos, armaron bases de conocimiento simples con scripts y conectaron todo a través de prompts con un modelo GPT en la nube. La interfaz se hizo en un día usando Django. Tal prueba de concepto funcionaba lentamente, con un retardo de 10–15 segundos, pero fue suficiente para defender la idea ante el negocio y obtener el visto bueno para el MVP. Luego comenzó el trabajo real de ingeniería para reducir retardos, estabilización e integraciones.

Por qué todo se simplificó

Al principio el equipo, como frecuentemente ocurre en proyectos de IA, diseñó un sistema demasiado ambicioso: su propio pipeline de audio, varios clasificadores complejos, fine-tuning de un modelo de lenguaje grande, una base de datos vectorial e incluso un bucle de autoaprendizaje. Pero bastante rápido quedó claro que tal camino alargaría el lanzamiento a 12–18 meses e incrementaría drásticamente la probabilidad de fracaso. En lugar de intentar construir la arquitectura "perfecta" los desarrolladores comenzaron sistemáticamente a eliminar todo aquello sin lo que se podía prescindir en el primer lanzamiento.

"No luchamos contra problemas, rediseñamos el sistema para que esos

problemas no surgieran en él."

• Rechazaron fine-tuning en favor de RAG para evitar gastar meses en anotación y reducir el riesgo de alucinaciones.
• No escribieron su propia transcripción y tomaron segmentos de texto listos de Voximplant.
• Simplificaron el clasificador de objeciones: en lugar de 15+ clases dejaron un esquema binario "tiene objeción / sin objeción".
• No tiraron de una pesada base de datos vectorial para unos pocos megabytes de datos y cargaron archivos JSON estructurados directamente en memoria.
• Se alejaron de APIs en la nube a Qwen 8B local en un servidor GPU para encajar en el retardo y no enviar datos sensibles fuera del perímetro.

Este conjunto de compromisos resultó ser clave. Los modelos en la nube daban una respuesta en 7–20 segundos, y Qwen 32B aunque respondía mejor igual no pasaba la prueba de tiempo. Una Qwen 8B más compacta resultó ser suficientemente buena para sugerencias al gerente y estabilizó la latencia alrededor de dos segundos. Paralelamente el despliegue local cerró cuestiones de seguridad: las transcripciones de llamadas no necesitan ser enviadas a servicios externos, lo que significa que no tuvieron que construir una capa separada de enmascaramiento de datos personales y pagar por ello con retardos adicionales.

Qué mostró el piloto

El problema más subestimado resultó ser no los modelos sino los datos. El equipo tomó 200 llamadas, las dividió entre 12 participantes y rápidamente chocó contra la pared de la anotación manual: para clasificar correctamente objeciones no es suficiente destacar una frase, necesitas entender el contexto de la conversación y la lógica de ventas. Como resultado los desarrolladores reconstruyeron la propia definición del problema. En lugar de intentar "enseñar a la IA a pensar como un experto" se enfocaron en un objetivo más estrecho: notar a tiempo cuándo el gerente necesita ayuda, y entonces traer el script necesario y generar una sugerencia.

Al final del piloto el sistema logró un retardo promedio de alrededor de dos segundos, solo en 2–3% de los casos subiendo a tres. La clasificación de servicios dio una precisión superior al 70%, y el reconocimiento de voz — del 92% dependiendo de la calidad de la conexión. El equipo escribe que el piloto ya dio un efecto cualitativo: aparecieron las primeras señales sobre conveniencia, reducción de carga en los mentores y utilidad general para los operadores. Pero aún no hay conclusiones estadísticamente significativas sobre conversión y KPI — para eso el producto necesita escalado e integración perfecta directamente en el CRM.

Qué significa esto

Este caso demuestra bien que un producto de IA interno no siempre requiere un equipo de ML listo desde cero. Si una empresa tiene ingenieros backend fuertes, dolor de negocio claro y acceso a los procesos, un MVP puede ensamblarse más rápido a través de simplificación estricta de la arquitectura y rechazo de componentes "inteligentes" innecesarios. La conclusión principal aquí no está en la elección de un modelo específico sino en disciplina: primero resolver el problema de negocio, luego verificar restricciones de velocidad y seguridad, y solo después complicar la pila.