Lo que trabajar en Mango y Zara me enseno sobre agentes de IA para atencion al cliente

Antes de construir asistentes conversacionales con LLMs, WhatsApp, webhooks o llamadas telefonicas, trabaje como retail assistant en Mango durante 2024 y en Zara durante 2025. A primera vista, esas experiencias pueden parecer separadas de mi trabajo actual en IA y automatizacion. Para mi, estan muy conectadas.

Trabajar de cara al publico ensena algo que no aparece en una documentacion tecnica: el cliente no quiere hablar con una tecnologia impresionante. Quiere resolver su problema de forma rapida, clara y sin tener que repetirlo.

Esa idea guia ahora mi forma de construir agentes de IA para atencion al cliente dentro de NexaVision AI y otros proyectos de automatizacion.

Respuesta directa: que hace fiable a un agente de IA de atencion al cliente

Un agente de IA fiable no es el que responde a mas preguntas. Es el que entiende la intencion, consulta datos reales, aplica reglas explicitas, reconoce sus limites y escala a una persona cuando no puede garantizar una respuesta correcta.

En la practica necesita cinco capas:

1. contexto suficiente para entender la conversacion,
2. herramientas conectadas a sistemas reales,
3. guardrails y validaciones antes de actuar,
4. trazabilidad para revisar que ha ocurrido,
5. escalado humano con todo el contexto disponible.

El modelo de lenguaje es una parte importante, pero no es el sistema completo.

Primera leccion del retail: el cliente expresa problemas, no intenciones estructuradas

En una tienda, una persona rara vez formula una solicitud como si estuviera rellenando un formulario. Puede decir que busca "algo parecido a esto", que necesita un regalo pero no sabe la talla o que quiere devolver una prenda sin conocer el procedimiento exacto.

En canales digitales ocurre lo mismo:

Quiero cambiar lo que pedi ayer.

Ese mensaje no indica por si solo que producto es, si el pedido admite cambios, cual es el canal adecuado o si la persona realmente quiere una devolucion. Un agente debe detectar la intencion probable, pero tambien pedir la informacion minima necesaria antes de actuar.

Por eso separo dos responsabilidades:

• el LLM interpreta lenguaje ambiguo, resume y mantiene una conversacion natural;
• las reglas y herramientas verifican datos antes de ejecutar una operacion.

Esta separacion reduce respuestas inventadas y evita que una frase convincente se convierta en una accion incorrecta.

Segunda leccion: una buena respuesta no siempre resuelve el problema

En atencion al cliente, ser amable no basta. Si una persona pregunta por el estado de un pedido, una respuesta bien redactada que no consulta el pedido sigue siendo inutil.

Un agente util debe poder conectar la conversacion con herramientas. Dependiendo del caso, podria:

• consultar el estado de un pedido,
• buscar disponibilidad o stock,
• recuperar condiciones de devolucion,
• crear o modificar una reserva,
• registrar una incidencia,
• actualizar un CRM,
• transferir la conversacion a una persona.

He aplicado este enfoque en sistemas como un agente de atencion al cliente conectado a Gmail y un asistente de reservas por WhatsApp. En ambos casos, la respuesta conversacional solo es la capa visible. Debajo hay APIs, webhooks, historial, validaciones y acciones verificables.

Tercera leccion: saber cuando pedir ayuda es una capacidad, no un fallo

En retail hay situaciones sencillas y situaciones donde hace falta una persona con criterio: excepciones, clientes frustrados, informacion contradictoria o solicitudes que pueden tener impacto economico.

Un agente de IA deberia funcionar igual. El escalado humano no debe aparecer como ultimo recurso improvisado; debe formar parte de la arquitectura.

Definiria condiciones de escalado cuando:

• la intencion no alcanza un nivel suficiente de confianza,
• faltan datos despues de varios intentos,
• el usuario solicita hablar con una persona,
• existe riesgo economico, legal o de privacidad,
• las herramientas devuelven informacion contradictoria,
• el tono indica frustracion o una situacion sensible,
• la operacion esta fuera de las reglas permitidas.

La transferencia tambien debe incluir contexto. Obligar al cliente a repetir toda la conversacion despues de escalar destruye buena parte del valor de la automatizacion. El equipo humano deberia recibir un resumen, los datos recopilados, las acciones intentadas y el motivo del escalado.

Cuarta leccion: el tono importa, pero la precision importa mas

Cada marca tiene una forma de comunicarse. Un asistente debe respetar idioma, tono, vocabulario y nivel de detalle. Sin embargo, alinear respuestas con una marca no consiste solo en escribir un prompt que diga "se amable".

Los guardrails deben definir:

• que puede y no puede prometer el agente,
• que fuentes puede utilizar,
• que operaciones requieren confirmacion,
• que datos personales necesita realmente,
• como debe responder cuando no conoce una respuesta,
• cuando debe dejar de automatizar y escalar.

Para mantener consistencia, prefiero separar instrucciones de marca, reglas operativas y contexto especifico de cada conversacion. Esto permite modificar el tono sin alterar las restricciones del sistema.

Quinta leccion: la velocidad solo aporta valor si reduce friccion

Una ventaja clara de los agentes conversacionales es poder atender solicitudes frecuentes de forma inmediata. Pero responder rapido no ayuda si el usuario entra en un bucle, recibe informacion generica o debe corregir continuamente al sistema.

La metrica no deberia ser solamente el numero de conversaciones automatizadas. Tambien mediria:

• porcentaje de solicitudes resueltas correctamente,
• tiempo hasta la resolucion,
• numero de mensajes necesarios,
• porcentaje y motivo de escalados,
• operaciones fallidas o revertidas,
• satisfaccion despues de la conversacion,
• frecuencia con la que el cliente debe repetir informacion,
• coste por conversacion resuelta.

Un agente que escala un caso complejo correctamente puede ser mejor que uno que intenta automatizarlo todo y termina generando un problema mayor.

Arquitectura que utilizaria para un agente conversacional fiable

Aunque cada empresa necesita integraciones distintas, suelo pensar en una arquitectura por capas:

1. Entrada multicanal

La conversacion puede llegar desde una web, WhatsApp, email, una app o telefono. La primera capa normaliza el mensaje, identifica el canal y conserva los metadatos necesarios.

2. Contexto y memoria

El agente recupera el historial relevante, idioma, preferencias y datos autorizados. La memoria no debe ser infinita ni guardar informacion sin criterio: tiene que ser util, limitada y respetuosa con la privacidad.

3. Interpretacion e intencion

El LLM clasifica la solicitud, extrae campos y decide que informacion falta. En esta fase puede proponer una accion, pero todavia no deberia ejecutarla.

4. Politicas, guardrails y validacion

Las reglas deterministas comprueban permisos, campos obligatorios, limites y condiciones del negocio. Esta capa decide si la accion es valida, si necesita confirmacion o si debe escalarse.

5. Herramientas y acciones

APIs, bases de datos, calendarios, CRMs o sistemas internos ejecutan la operacion. Las acciones importantes deben ser idempotentes cuando sea posible para evitar duplicados si un workflow se reintenta.

6. Observabilidad y evaluacion

Cada ejecucion debe dejar registros utiles: intencion detectada, herramienta utilizada, resultado, latencia, errores y razon de escalado. Esos datos permiten encontrar fallos y construir evaluaciones repetibles.

7. Respuesta o escalado humano

El agente comunica el resultado real, no el resultado que esperaba obtener. Si no puede resolver, transfiere el caso con contexto.

Como evaluaria el agente antes de ponerlo delante de clientes

No probaria un agente solamente conversando con el de forma manual. Crearia un conjunto de casos que represente situaciones normales, ambiguas y adversas:

• preguntas frecuentes bien formuladas,
• mensajes incompletos,
• cambios de idioma,
• instrucciones contradictorias,
• solicitudes fuera de politica,
• intentos de obtener datos no autorizados,
• errores de API,
• clientes que cambian de intencion,
• conversaciones que deben escalarse.

Para cada caso definiria el resultado esperado: responder, preguntar, utilizar una herramienta, rechazar una accion o escalar. Despues mediria exactitud de intencion, seleccion de herramientas, cumplimiento de politicas y calidad de la respuesta final.

Tambien mantendria una revision humana de muestras reales. Las evaluaciones automaticas ayudan a detectar regresiones, pero el lenguaje y la experiencia del cliente necesitan criterio humano.

Lo que aporto al construir estos sistemas

Mi experiencia en Mango y Zara no me convierte por si sola en ingeniero de IA. Mi experiencia tecnica tampoco sustituye entender a la persona que esta al otro lado.

La combinacion de ambas me ayuda a pensar en el sistema completo:

• que necesita realmente el cliente,
• que informacion tiene disponible el agente,
• que acciones puede ejecutar de forma segura,
• que debe comprobar antes de responder,
• cuando una persona debe tomar el control.

Despues de trabajar en retail y construir mas de 30 workflows de IA y automatizacion, mi conclusion es sencilla: la mejor automatizacion de atencion al cliente no intenta parecer humana; intenta ser util, fiable y honesta sobre sus limites.

Si quieres hablar sobre agentes conversacionales, automatizacion o integraciones con LLMs, puedes contactarme desde mi pagina de contacto o conectar conmigo en LinkedIn.