Todos los tutoriales de "cómo crear un chatbot con IA" terminan igual: una demo que funciona en un entorno de pruebas, la captura de una conversación de prueba y una felicitación. Después intentas ponerlo al teléfono con clientes reales y todo se rompe.
Esta guía se salta el sandbox. Empieza donde terminan los tutoriales: en el momento en que tu bot tiene que atender a alguien que habla entre dientes, una pregunta que tu base de conocimiento no cubre, un sector sujeto a normativa y un equipo de agentes humanos que necesita un traspaso limpio cuando la IA llega a su límite.
El resultado es un agente de voz listo para producción, no un bot de juguete. Así se construye.
Por qué los tutoriales de "agentes de IA no-code" se desmoronan en producción
Las plataformas no-code son excelentes para aquello que fueron diseñadas: permitir que perfiles no técnicos pongan en marcha un chatbot rápidamente en casos de uso sencillos y de bajo riesgo. Un widget de texto en la página del centro de ayuda. Desvío de preguntas frecuentes para un puñado de dudas habituales. Un formulario de captación de leads con UX conversacional.
Fallan en producción por cinco motivos:
-
Dan por hecho que todo es texto. La voz es una modalidad completamente distinta. El barge-in (que la persona hable mientras el bot sigue hablando), el ruido acústico, los errores de ASR, los acentos regionales y los requisitos de latencia por debajo del segundo no existen en un constructor de chats no-code, porque esos constructores se diseñaron para el chat.
-
No saben fundamentar sus respuestas. El "grounding" significa que cada respuesta está anclada a tus datos reales: registros de cuenta, documentos de políticas, inventario en vivo. Las plantillas no-code se nutren de bases de conocimiento estáticas. Cuando un cliente llama por su cuenta, su pedido o su póliza concretos, el bot alucina o esquiva la pregunta.
-
No tienen modelo de escalado. Las llamadas reales escalan. Un bot no-code normalmente cuelga, envía un correo o deja a quien llama en una cola de espera, sin transmitir ningún contexto. La persona que atiende empieza de cero.
-
No sirven para sectores regulados. Los seguros, la sanidad y las finanzas tienen requisitos normativos (HIPAA, SOC 2, TCPA, leyes estatales de divulgación) que las plataformas no-code nunca se diseñaron para satisfacer. No puedes activar el cumplimiento de PCI desde un constructor de arrastrar y soltar.
-
No tienen un sistema de evaluación. ¿Cómo sabes que el bot ha empeorado después de actualizar la base de conocimiento? Las plataformas no-code no incluyen pruebas de regresión. Producción sí las exige.
El replanteamiento honesto: si tu caso de uso es desviar consultas de texto de bajo riesgo, el no-code te vale. Si toca la voz, datos regulados, consultas reales de cuentas o colas de agentes en vivo, necesitas una arquitectura de producción.
La anatomía real de un agente de voz en producción
Un agente de voz en producción es un pipeline, no un monolito. Cada etapa tiene su propio presupuesto de latencia, sus modos de fallo y sus compromisos de proveedor.
Preguntas frecuentes
¿Qué es lo primero que se rompe cuando un chatbot pasa a producción?
Gestionar las entradas que nadie guionizó: erratas, preguntas con varias partes y personas que responden a algo distinto de lo que se les preguntó. Los flujos de demo asumen usuarios cooperativos.
¿Necesito recuperación de información o puedo meterlo todo en el prompt?
La recuperación importa en cuanto el conjunto de respuestas cambia más a menudo de lo que te apetece desplegar. Un prompt funciona bien con conocimiento estable y mal con cualquier cosa que tenga número de versión.
¿Cómo debe transferir un chatbot la conversación a una persona?
Con la transcripción y la intención adjuntas. Un traspaso que reinicia la conversación es peor que no traspasar nada, porque el cliente ya ha tenido que explicarse dos veces.
