Un agente de IA que atiende clientes: qué sale mal
Seis fallas que se repiten en producción, en el orden en que aparecen, y la peor de todas: la que no genera ningún error y parece que simplemente no escribió nadie.
Poner un agente de IA a hablar con clientes es de las cosas que mejor se demuestran y peor se estiman. La demo contesta impecable, el cliente se entusiasma, y los problemas aparecen dos semanas después de salir, cuando la gente real empieza a escribir cosas que nadie probó.
Estas son las fallas que se repiten. No son teóricas: son el patrón de lo que vemos en implementaciones reales, contado sin identificar a nadie — los casos son de cada cliente, el patrón es conocimiento.
La demo siempre funciona
Porque en la demo las preguntas las hace quien construyó el agente. Vienen bien escritas, en orden, sobre temas que están cubiertos, en un solo canal y sin nadie enojado del otro lado.
La producción es lo contrario: mensajes cortados, preguntas de tres cosas a la vez, gente que escribe el lunes por Instagram y el martes por WhatsApp, y un porcentaje constante de casos que el diseño no anticipó. La diferencia entre las dos situaciones no es de calidad del modelo: es de diseño del sistema alrededor.
Seis fallas, en el orden en que aparecen
| Falla | Como se ve desde afuera | Donde se arregla |
|---|---|---|
| No escala a humano | El cliente insiste y el agente repite | Reglas de derivacion por intencion, no por palabra clave |
| Pierde el hilo entre canales | Empezo en un canal y en otro lo tratan como desconocido | Identidad del contacto compartida entre canales |
| Duplica en el sistema de gestion | Dos reservas, dos fichas, dos presupuestos | Buscar antes de crear, y actualizar en vez de insertar |
| No deja rastro para el humano | Quien retoma no sabe que se dijo | La conversacion entera al CRM, no solo el resultado |
| Inventa una condicion comercial | Promete un precio, un plazo o una garantia | Catalogo cerrado de datos y prohibicion de completar huecos |
| Se cae y nadie se entera | Parece que esa semana no escribio nadie | Alerta de ausencia, no solo alerta de error |
1. No escala a humano. Casi siempre porque la derivación se programó por palabras clave: si el cliente escribe «hablar con una persona», deriva. Pero la gente enojada no escribe eso — repite la pregunta con menos paciencia. La señal de derivación útil es de intención y de contexto: dos intentos sin resolver, un tema fuera del alcance, o cualquier mención de un reclamo.
2. Pierde el hilo entre canales. La conversación existe por canal, pero la persona es una sola. Sin una identidad de contacto compartida, alguien que ya explicó su caso tiene que explicarlo otra vez, y esa es la interacción que hace que el cliente pida un humano — con razón.
3. Duplica en el sistema de gestión. Es la más cara de las seis porque ensucia datos que después usa todo el mundo. El patrón es siempre el mismo: el agente crea en vez de actualizar. Reagendar produce una reserva nueva en vez de mover la existente; un contacto que vuelve genera una ficha nueva. La regla que lo evita es aburrida: buscar antes de crear.
4. No deja rastro para el humano. El agente resuelve la mitad, deriva, y quien retoma recibe un ticket sin contexto. Para el cliente es peor que no haber tenido agente: ya contó su problema una vez.
5. Inventa una condición comercial. La falla más peligrosa, porque suena bien. Un precio que no existe, un plazo que nadie puede cumplir, una garantía que no se ofrece. No se arregla pidiéndole al modelo que no invente: se arregla dándole un catálogo cerrado de datos y prohibiéndole completar lo que falta. Si el dato no está, la respuesta correcta es derivar, no aproximar.
La peor: la falla que parece silencio
La sexta merece su propia sección porque es la única que puede durar semanas sin que nadie la note.
Cuando un agente se cae —vence un token, cambia una API, alguien desactiva una regla— no aparece un error en ningún lado. Aparece nada. Y «nada» se ve exactamente igual que «esta semana escribieron pocos». Para cuando alguien pregunta, ya pasaron consultas sin responder que no se pueden recuperar.
El agravante: varias integraciones de mensajería tienen ventanas de tiempo para responder. Pasado ese plazo, la respuesta ya no se puede mandar aunque el sistema vuelva. Lo que se perdió en el silencio no se recupera después.
Que tiene un agente bien construido
Nada de esto es sobre el modelo. Es sobre lo que lo rodea:
- Límites de acción explícitos. Qué puede consultar, qué puede escribir y qué no puede tocar. Las acciones de alto impacto no se habilitan sin controles.
- Fallback humano con reglas de derivación por intención, y alguien del otro lado.
- Prompts versionados o documentados. Si nadie sabe con qué instrucciones respondió, nadie puede auditar por qué respondió eso.
- Probado con casos normales y casos extremos. El caso extremo es el que define la calidad percibida, porque es el que la gente cuenta.
- Criterios aprobados por el cliente. Respuestas, límites y escalamiento. El agente representa su negocio, no el nuestro.
- Monitoreo de volumen, no solo de errores. Por la falla silenciosa.
Los cinco primeros son los que ya publicamos en nuestra Política de Seguridad. El sexto lo agregamos por experiencia.
Cuando no deberia ser un agente
- Cuando el volumen no lo justifica. Con pocas conversaciones por día, una persona contesta mejor y sale más barato.
- Cuando cada respuesta es una decisión comercial. Si el precio depende del caso, el agente califica y deriva; no cotiza.
- Cuando la información base no existe. Un agente no puede contestar lo que la empresa no tiene escrito en ningún lado. Escribirlo es el proyecto anterior.
- Cuando lo que se quiere arreglar es la demora. Si el problema es que nadie contesta en 48 horas, una alerta bien puesta lo resuelve por mucho menos. Eso es automatización clásica, no IA.
Preguntas frecuentes
- Un agente va a reemplazar a mi equipo de atencion? En nuestra experiencia cambia lo que hace el equipo mas que eliminarlo. El agente absorbe el volumen repetitivo; las personas quedan con las excepciones, que son justo los casos donde se juega el negocio. Planificar el reemplazo es como se termina sin ninguno de los dos.
- Hay que avisarle al cliente que habla con un bot? Buscamos que exista transparencia razonable sobre la naturaleza automatizada de la conversacion, sobre todo cuando puede afectar decisiones comerciales o expectativas de atencion. Mas alla del deber legal, la gente suele darse cuenta igual, y enterarse despues cuesta mas confianza que decirlo antes.
- Que pasa si el agente dice algo incorrecto? Comercialmente responde el negocio, por eso el cliente tiene que aprobar criterios, respuestas, limites y escalamiento antes de salir. Tecnicamente, para eso existen los limites de accion y el fallback humano.
- Cuanto tarda en funcionar bien? Mas de lo que sugiere la demo y menos que rehacerlo. La secuencia realista es salir acotado, mirar conversaciones reales durante unas semanas y ampliar solo donde los transcripts digan que es seguro.