Agentes de IA para atención al cliente

Un agente de soporte se vuelve significativamente diferente de un chatbot cuando puede combinar tres cosas: recuperación confiable, llamada de herramientas y límites de decisión explícitos. La recuperación mantiene las respuestas sobre políticas y productos basadas en contenido aprobado. La llamada a herramientas permite al sistema buscar un pedido, verificar el inventario, crear una nota interna o iniciar una solicitud de devolución a través de una API definida en lugar de fingir desde la memoria. Los límites de decisión le indican al agente cuándo responder, cuándo solicitar más pruebas de identidad, cuándo poner en cola una acción para su aprobación y cuándo detenerse.

OpenAI y Anthropic documentan patrones de herramientas/funciones para permitir que los modelos llamen a sistemas externos, pero el desafío de producción no es simplemente exponer una función. Cada herramienta necesita un esquema escrito con campos obligatorios, valores de enumeración, reglas de validación, comprobaciones de autorización y formas de devolución claras para que el orquestador pueda decidir qué sucedió. Una herramienta `create_return_request`, por ejemplo, debería requerir un cliente autenticado, una identificación de pedido, identificaciones de artículos de línea, un código de motivo y una clave de idempotencia. Debería devolver un estado como "creado", "ya_existe", "necesita_revisión" o "denegado", no un mensaje vago de éxito.

La capa de orquestación es el producto. Decide qué modelo se ejecuta, qué índice de recuperación se consulta, qué herramientas están disponibles para el cliente actual, cómo funcionan los reintentos, cuándo se requiere una cola de aprobación humana y qué se escribe en el registro de auditoría. Un agente de comercio electrónico útil debería poder explicar por qué eligió una herramienta y qué fuente o resultado de API respalda la respuesta del cliente.

Hay tres patrones arquitectónicos prácticos. Un diseño de agente único utiliza una ruta de orquestación de modelo para clasificación, recuperación, elección de herramientas y respuesta. Es más fácil de operar y funciona bien cuando el alcance del soporte es limitado. Un diseño de varios pasos o múltiples agentes separa la detección de intenciones, la recuperación, la ejecución del flujo de trabajo y la composición de la respuesta. Puede ser más fácil de depurar porque cada paso tiene un trabajo más pequeño, pero agrega latencia y más lugares para que el estado se desvíe.

Los sistemas de producción suelen añadir una puerta política alrededor del modelo. La puerta puede verificar el canal, el estado de autenticación del cliente, la propiedad del pedido, los permisos de la herramienta, el nivel de riesgo, la configuración regional y las reglas comerciales antes de que se le permita al modelo llamar a cualquier cosa que cambie de estado. Esto es importante porque la misma frase puede tener diferentes permisos según el contexto: "cancelar mi pedido" tiene un riesgo bajo antes del cumplimiento, un riesgo mayor después de la liberación del almacén y, a menudo, es imposible después de la recogida por parte del transportista.

Human-in-the-loop no es un recurso alternativo; es una elección de diseño. Úselo para reembolsos, cambios de dirección después de que haya comenzado el cumplimiento, acceso a cuentas, inquietudes sobre fraude, clientes de alto valor, cuentas mayoristas, lenguaje legal, cuestiones médicas o de seguridad y cualquier acción que no pueda revertirse fácilmente. La mejor arquitectura suele ser mixta: autónoma para trabajos fácticos de bajo riesgo, colas de aprobación para cambios financieros u operativos y toma de control humana inmediata para casos emocionales o ambiguos.

La gestión del contexto es donde muchas demostraciones fallan después del lanzamiento. Un modelo solo puede razonar sobre el contexto que se le brinda y soportar cambios de contexto a lo largo del tiempo: el cliente regresa días después, el pedido se envía, se emite un reembolso, un humano deja una nota interna o la misma persona envía mensajes desde WhatsApp en lugar del chat web. El agente necesita un estado persistente fuera del modelo.

Busque cuatro capacidades. En primer lugar, la resolución de identidad: el sistema debe relacionar a los clientes a través del correo electrónico, el teléfono, la sesión iniciada, el número de pedido y la identidad del canal sin exponer datos privados demasiado pronto. En segundo lugar, el diseño de la sesión: la plataforma debe almacenar una identificación de conversación duradera, una identificación de cliente, una identificación de canal, un estado de autenticación, referencias de pedidos activos y un estado de transferencia por separado del mensaje del modelo. En tercer lugar, resúmenes duraderos: las conversaciones pasadas deben comprimirse en registros precisos de números de pedidos, promesas hechas, acciones tomadas y problemas no resueltos. Cuarto, actualización de la fuente: los datos de políticas y pedidos en vivo deben volver a verificarse cuando la respuesta depende del estado actual.

La autenticación es parte del contexto, no una casilla de verificación separada. Una sesión web iniciada, un enlace firmado al servicio de asistencia técnica, una respuesta por correo electrónico y un número de teléfono de WhatsApp no ​​conllevan la misma seguridad. El agente debe exponer solo información de bajo riesgo hasta que tenga pruebas suficientes, y un resumen de una conversación obsoleta nunca debe anular la plataforma de comercio.

Un cliente envía un mensaje por WhatsApp: "Necesito devolver la chaqueta azul del pedido n.º 2204". Un agente de producción no debe saltar directamente a una etiqueta. Debe identificar al cliente, verificar que el pedido pertenece a esa persona, recuperar el pedido de Shopify o WooCommerce, verificar la política de cumplimiento y devoluciones, inspeccionar las reglas a nivel de artículo, como la venta final o las exclusiones de higiene, y determinar si la acción está permitida.

El esquema de la herramienta debe hacer explícitas esas comprobaciones. Un flujo seguro podría llamar a `lookup_customer`, `lookup_order`, `check_return_eligibility` y luego `create_return_request`. Cada llamada debe recibir entradas escritas, utilizar credenciales con privilegios mínimos y devolver resultados legibles por máquina que el orquestador pueda evaluar. La herramienta de acción debe incluir una clave de idempotencia derivada de la conversación, el pedido, la línea de pedido y la acción solicitada para que los mensajes repetidos o los reintentos de webhook no creen etiquetas duplicadas, tickets duplicados ni reembolsos duplicados.

Si el pedido es elegible, el agente puede crear una solicitud de devolución, generar o solicitar una etiqueta a través del sistema de devoluciones o envío, agregar una nota interna e informar al cliente qué sucede a continuación. Si el pedido está fuera de la política, es parcialmente reembolsado, ya devuelto, bajo revisión de fraude o falta verificación de identidad, debe escalarse con un resumen conciso. Cada acción de escritura debe dejar un registro de auditoría con el mensaje del usuario, las entradas de la herramienta, el resultado de la herramienta, la fuente de la política y la respuesta final del cliente.

Las demostraciones muestran el camino feliz. Evalúe estas dimensiones para encontrar los modos de falla. Uno: confiabilidad de las llamadas a herramientas. ¿Con qué frecuencia el agente selecciona la función incorrecta? ¿Cómo se recupera cuando falla una llamada API? Pruebe con solicitudes ambiguas, como un número de pedido faltante o una descripción vaga del producto. Dos: calidad de la recuperación del conocimiento. ¿El agente recupera la sección de póliza correcta cuando se superponen varios documentos? Si su página de devoluciones dice 30 días y la página de un producto dice 14 días para artículos en oferta, ¿el agente resuelve o saca a la luz el conflicto? Tres: tasa de alucinaciones. Haga preguntas con premisas deliberadamente falsas ("Pedí un producto que no vendes"). ¿El agente fabrica una orden o dice que no la encuentra? Cuarto: inteligencia de escalada. ¿El agente escala cuando debería o persiste con respuestas incorrectas? Pruebe con lenguaje de cliente frustrado.

Cinco: coherencia de múltiples turnos. Haga una pregunta, cambie el tema, vuelva a la pregunta original y verifique que el agente conserve el estado correcto de la sesión sin exponer datos privados. Seis: autenticación y autorización. Pruebe escenarios de inicio de sesión, cierre de sesión, correo electrónico, WhatsApp y teléfono compartido. Siete: idempotencia de acción. Repita la misma solicitud de cancelación o devolución y confirme que solo se crea un flujo de trabajo. Ocho: manejo de idioma y configuración regional. Realice pruebas en los idiomas que utilizan sus clientes, incluidas conversaciones en varios idiomas. Nueve: modos de falla de integración de plataforma. ¿Qué sucede cuando la API de administración de Shopify devuelve un error de límite de tasa 429? ¿Qué sucede cuando no se puede acceder a la API REST de WooCommerce? ¿El agente le dice al cliente que hay un retraso o falla silenciosamente?

Diez: observabilidad y evaluaciones. Debería poder ver cada paso del modelo, fuente recuperada, llamada a función, entrada de herramienta, salida de herramienta, decisión de permiso, reintento, escalamiento y respuesta final. Ejecute un conjunto de evaluación fuera de línea de tickets históricos antes del lanzamiento, luego realice un seguimiento de las métricas de producción por intención: tasa de resolución correcta, intentos de acciones inseguras, prevención de acciones duplicadas, exposición de pedidos incorrectos, precisión de escalamiento, contacto repetido, CSAT y tasa de anulación humana. Si la plataforma no puede mostrar esta evidencia, no podrá depurarla ni gobernarla.

Implementar en fases. Comience con flujos de trabajo de solo lectura: recuperación de políticas, búsqueda de pedidos, estado de envío y preguntas sobre productos. Antes de que los clientes lo vean, ejecute evaluaciones provisionales y fuera de línea con conversaciones históricas, casos extremos iniciados, fallas de API simuladas, mensajes duplicados, identidades débiles, políticas obsoletas y conflictos de políticas. Revise diariamente las primeras conversaciones con los clientes y corrija la fuente de conocimiento, el esquema de herramientas o la regla de orquestación cuando la respuesta sea incorrecta. Agregue la ejecución de acciones solo después de que el agente haya demostrado que identifica a los clientes correctamente y escala los casos extremos.

La preparación del equipo es tan importante como la calidad del modelo. Los líderes de soporte necesitan un ciclo de revisión semanal para detectar malas respuestas, artículos faltantes, llamadas fallidas a herramientas, intentos de acciones inseguras, bloqueos de acciones duplicadas y motivos de escalada. Los agentes necesitan capacitación sobre cómo hacerse cargo de los resúmenes de IA y cómo marcar los resultados para que se pueda evaluar el sistema. Ingeniería u operaciones necesitan propiedad para las credenciales de API, reglas de sesión/autenticación, claves de idempotencia, reintentos de webhook, registros, cambios de políticas, cambios de campaña y excepciones de cumplimiento. Sin ese ritmo operativo, la IA se alejará lentamente de cómo funciona realmente la tienda.