Agentes de IA en WhatsApp: cuándo pasar a una persona
Cómo transferir una conversación con contexto, responsable y próxima acción, sin dejar al cliente entre el agente de IA y el equipo.
Un cliente pide una excepción, el agente no puede autorizarla y la conversación queda esperando sin responsable. La transferencia de un agente de IA a una persona en WhatsApp debe resolver ese cambio de manos: qué se entrega, quién recibe y cómo continúa el caso sin pedir toda la historia otra vez.
El objetivo no es que la IA sostenga cualquier conversación. Es que opere dentro de sus tareas y límites, y que el equipo intervenga cuando hace falta criterio. Esta guía propone decisiones de diseño para una empresa que atiende, vende o coordina servicios por WhatsApp; no describe funciones garantizadas por cualquier herramienta.
¿Qué es la transferencia de un agente de IA a una persona?
La transferencia de un agente de IA a una persona es el cambio de responsabilidad sobre una conversación cuando la atención necesita intervención humana. En WhatsApp, debe incluir el motivo del traslado, el contexto relevante y una próxima acción. Enviar una notificación no basta: alguien debe poder recibir y continuar el caso.
También se conoce como transferencia humana o handoff. La diferencia entre una transferencia útil y un botón de contacto está en lo que sucede después: la conversación debe entrar en una cola visible, conservar un estado y permitir que una persona asuma la atención.
Conviene separar el mensaje al cliente del cambio operativo. Decir «te paso con el equipo» no demuestra que exista un caso asignado. Durante una prueba, comprueba ambas cosas: qué ve el cliente y qué encuentra quien recibe.
¿Cuándo debe el agente pasar la conversación a una persona?
Define la transferencia cuando el cliente la solicita, faltan fuentes para responder, una consulta exige una excepción o la acción supera los permisos del agente. Las reglas deben acordarse con quien opera el proceso. No conviene dejar al modelo decidir por sí solo si puede negociar, aprobar cambios o comprometer a la empresa.
Una matriz de decisión ayuda a convertir esos límites en pruebas concretas. Este ejemplo es una propuesta de diseño, no una política aplicable sin revisión a cualquier negocio:
| Situación | Qué puede hacer el agente | Qué requiere una persona |
|---|---|---|
| Consulta documentada | Responder desde una fuente aprobada | Resolver una contradicción entre fuentes |
| Solicitud de excepción | Registrar el pedido y su motivo | Aprobar o rechazar según sus atribuciones |
| Error al consultar un sistema | Informar que no pudo verificar | Revisar el registro o la integración |
| Cliente solicita atención humana | Preparar el contexto y transferir | Continuar la conversación |
| Acción fuera de permisos | Detener la ejecución | Validar y ejecutar si corresponde |
Evita usar una aparente seguridad al escribir como prueba de que el agente conoce la respuesta. Para consultas operativas, exige una fuente disponible y una tarea autorizada. Si no puede comprobar el estado de una solicitud, debe explicarlo, no completar el vacío con una respuesta probable.
¿Qué contexto debe recibir quien continúa la atención?
Entrega un resumen de la solicitud, los datos necesarios para atenderla, las consultas realizadas, las acciones confirmadas y el motivo de transferencia. Separa hechos verificados de información que todavía debe revisarse. La persona debe entender qué falta sin releer todo el historial, pero conservar acceso a los mensajes relevantes cuando necesite comprobar un detalle.
Una ficha de transferencia puede incluir:
- Solicitud: qué quiere resolver el cliente.
- Estado comprobado: qué dato devolvió el sistema consultado.
- Acciones realizadas: qué quedó registrado y qué no se ejecutó.
- Motivo: qué regla detuvo la atención automática.
- Pendiente: qué necesita decidir o verificar el equipo.
- Destino: área o responsable que debe recibir el caso.
Recoge solo la información necesaria para esa tarea. No copies documentos completos ni datos sensibles en un resumen por comodidad. Define quién puede consultar la ficha y evita mezclar información de personas distintas.
En un escenario hipotético, un cliente solicita cambiar una reserva. El resumen debería distinguir «el cliente pide el cambio» de «el cambio quedó confirmado». Si la consulta falló, registra el fallo; no presentes una intención como una operación completada.
¿Cómo evitas que el agente y la persona respondan a la vez?
Diseña un estado de conversación que indique quién tiene la responsabilidad de responder. Al solicitar intervención humana, la atención automática debe respetar ese estado y no seguir negociando o ejecutando acciones por su cuenta. La devolución al agente también necesita una regla explícita, no una suposición basada en que el equipo dejó de escribir.
Una secuencia de diseño que puedes probar con tu equipo es:
- El agente detecta una condición de transferencia.
- El sistema prepara la ficha y registra la solicitud de atención.
- La conversación queda en una cola con destino definido.
- Una persona asume el caso y continúa desde el contexto recibido.
- El equipo resuelve, deja un pendiente o devuelve la atención al agente según una regla acordada.
Prueba también qué ocurre si entra otro mensaje durante el traslado o si dos personas intentan asumir el caso. El sistema debe conservar una responsabilidad clara. Un CRM para WhatsApp para equipos debe evaluarse por ese recorrido, no solo por mostrar conversaciones en una pantalla compartida.
¿Qué le dices al cliente si no hay nadie disponible?
Explica que el caso requiere revisión humana y comunica el estado real de la solicitud. Si solo quedó pendiente para el equipo, dilo así; no afirmes que una persona ya está conectada. El mensaje debe distinguir entre recibir una solicitud, asignarla y empezar a atenderla, sin prometer disponibilidad que el sistema no puede comprobar.
Una formulación ilustrativa sería: «Este cambio requiere revisión del equipo. Dejé registrada tu solicitud con el contexto de la conversación. La atención humana está pendiente». Ajusta el texto al funcionamiento real y a los canales disponibles en tu empresa.
Fuera del horario de atención humana, define quién revisa la cola al retomar la operación y cómo identifica los casos pendientes. No resuelvas esa falta de organización permitiendo que el agente apruebe excepciones para las que no tiene autorización.
¿Qué permisos deben mantenerse al transferir el caso?
Mantén separados los permisos del agente, los del sistema de asignación y los de cada persona del equipo. Transferir una conversación no autoriza automáticamente una devolución, un cambio contractual o una modificación de datos. La acción final debe validar quién puede ejecutarla y registrar qué ocurrió, incluso si la solicitud llegó mediante un resumen generado por IA.
OWASP recomienda limitar funciones y permisos y exigir aprobación humana para acciones de alto impacto en su guía sobre agencia excesiva. Esa recomendación respalda un principio concreto: una instrucción conversacional no reemplaza los controles de autorización de la herramienta que ejecuta la acción.
Cuando evalúes agentes de IA, pide que se pruebe una acción no permitida. El resultado esperado debe ser una negativa o un paso a revisión, no una ejecución seguida de una explicación. Incluye mensajes que intenten cambiar las reglas y solicitudes ambiguas que requieran confirmar la identidad o el alcance antes de actuar.
Cómo lo resolvemos en LemaBot
En LemaBot construimos software a medida y agentes de IA para empresas en Latinoamérica. Partimos del proceso de quienes atienden hoy: definimos tareas, límites, fuentes y paso a una persona. Después conectamos los sistemas necesarios y seguimos operando con el cliente, revisando conversaciones y corrigiendo lo que necesita mejorar.
En MyL Auto Check construimos un CRM e inbox de WhatsApp con campañas, automatizaciones, pipeline y agente de atención con paso a una persona. Está en operación. Ese es el alcance documentado del caso: no atribuimos cifras de ahorro ni una arquitectura interna que no esté publicada.
Para otro proyecto, el diagnóstico debe precisar quién recibe cada tipo de solicitud y qué herramientas necesita. La bandeja y CRM de WhatsApp forman parte de ese recorrido cuando la operación requiere compartir atención y seguimiento. No proponemos reemplazar tus sistemas por defecto; primero identificamos dónde debe vivir cada responsabilidad.
¿Cómo compruebas que la transferencia funciona antes de operar?
Prueba el recorrido completo con consultas habituales, excepciones, fallos de conexión y ausencia de atención humana. Revisa lo que recibe el cliente y lo que encuentra el equipo. Una transferencia funciona cuando conserva el contexto necesario, deja un responsable o una cola visible y evita acciones no autorizadas durante el cambio de atención.
No te quedes con la demostración de un caso exitoso. Pide comprobar que el agente no confirma operaciones fallidas, que la ficha distingue datos pendientes y que el equipo puede cerrar el caso sin perder su historial. Revisa también cómo se retoma una conversación que llegó mientras se atendía otra solicitud.
Después de publicar, registra motivos de transferencia, casos sin responsable, correcciones a los resúmenes y reaperturas. Usa esos registros para decidir si falta una fuente, una regla, una integración o capacidad de atención humana. Una menor cantidad de transferencias no demuestra, por sí sola, una mejor atención.
Preguntas frecuentes
Estas preguntas resumen decisiones que conviene resolver con el equipo antes de conectar la atención automática con la humana. Las respuestas son criterios de diseño: deben adaptarse a tus políticas, fuentes y responsabilidades. La prueba decisiva sigue siendo recorrer un caso completo y comprobar qué ocurre cuando algo no sale como se esperaba.
¿El cliente puede pedir hablar con una persona?
Incluye esa solicitud entre las condiciones de transferencia. El agente no debería obligarlo a repetir preguntas automáticas para intentar resolver algo que ya pidió revisar con el equipo.
¿Es suficiente enviar una alerta al equipo?
No si la alerta no deja un caso visible y una responsabilidad definida. Comprueba quién recibe, cómo asume la atención y dónde queda registrado el pendiente si no puede resolverlo.
¿Qué ocurre si el agente no encuentra una respuesta?
Debe reconocer el límite y evitar inventar información. Según el proceso, puede pedir una aclaración pertinente o transferir con el motivo y los datos ya recopilados.
¿Puede el agente volver a atender después de la intervención?
Sí, si existe una regla explícita para devolverle la conversación. El equipo debe dejar claro qué quedó resuelto y qué tareas siguen autorizadas; no conviene reactivarlo solo por inactividad.
¿Cómo empiezo a revisar el proceso de mi empresa?
Elige una conversación que haya necesitado intervención y recorre qué información faltó, quién decidió y dónde quedó el resultado. Para identificar ese primer proceso, habla con Leda en lemabot.com y agenda un diagnóstico sin costo, o escríbenos por WhatsApp al +1 854 900 1298.
