Continuar conversaciones en el chatbot: sesiones, cambio de dispositivo y transferencia segura

Un visitante realiza tres preguntas en el chatbot de un sitio web, navega a la página de un producto y regresa más tarde. Una clienta comienza en su smartphone y desea continuar en la laptop. Finalmente, un agente humano toma el control en el servicio de soporte. En los tres casos, la expectativa es la misma: que la conversación continúe de forma fluida y coherente. Sin embargo, desde el punto de vista técnico y organizativo, se trata de tres tareas completamente distintas. Mezclarlas conlleva el riesgo de perder el contexto, exponer datos involuntariamente o mantener activa una sesión durante más tiempo del necesario.

«Continuar» no es lo mismo que «reconocer»

Para la planificación, resulta útil distinguir claramente tres niveles de continuidad:

1. Dentro de una misma visita: La conversación se mantiene mientras la persona navega entre páginas o cierra y vuelve a abrir la ventana del chat.
2. Al regresar más tarde: El mismo navegador recupera una conversación anterior dentro de un plazo determinado.
3. Entre diferentes dispositivos: Una persona continúa la conversación en otro navegador o dispositivo. Para ello, por lo general, se requiere una vinculación de cuenta confiable o un proceso de transferencia de corta duración iniciado deliberadamente.

El simple hecho de contar con un historial de conversación no demuestra la identidad del usuario. Por lo tanto, quien posea un ID de conversación o un enlace no debe acceder automáticamente a pedidos, datos contractuales o información personal. Esta es la misma frontera fundamental que se aplica al separar un chatbot público de un portal de clientes autenticado: el contexto puede aportar comodidad, pero no sustituye al inicio de sesión ni a la verificación de permisos.

La base técnica: referencia en el navegador, estado en el servidor

Una arquitectura sólida debe almacenar en el navegador únicamente una referencia aleatoria e idóneamente no descriptiva. El estado correspondiente de la conversación reside en el servidor y se verifica en cada solicitud en función de su validez, organización/inquilino, permisos y fecha de caducidad. Las recomendaciones de gestión de sesiones de OWASP aconsejan el uso de identificadores de sesión sin significado interno, difíciles de adivinar y con límites de tiempo controlados desde el servidor. Además, los identificadores de sesión nunca deben incluirse en las URL, ya que podrían divulgarse mediante el historial, registros, encabezados referrer o enlaces compartidos.

El almacenamiento web del navegador tiene diferentes alcances. Según la MDN Web Storage API, sessionStorage está vinculado a la pestaña y al origen, y suele finalizar al cerrar la pestaña. En cambio, localStorage se mantiene a través de las sesiones del navegador, pero sigue estando limitado a ese mismo perfil de navegador. Ninguno de los dos establece una identidad entre distintos dispositivos. Guardar transcripciones sensibles o tokens de acceso permanentes directamente en ellos aumenta significativamente el impacto en caso de acceso no autorizado a través de scripts o del propio dispositivo.

Qué datos debe contener el estado

Para ofrecer una continuación útil, el sistema a menudo necesita mucho menos que una transcripción completa. Un conjunto de datos de estado compacto y versionado puede ser suficiente:

• la solicitud actual y el objetivo confirmado,
• los hechos no sensibles ya aclarados,
• las preguntas pendientes y el siguiente paso lógico,
• las fuentes de conocimiento utilizadas o sus versiones,
• el estado de consentimiento, autenticación y transferencia (handoff),
• la marca de tiempo de la última actividad y la fecha de caducidad establecida.

De este modo, la conversación puede continuar de forma coherente sin necesidad de copiar indefinidamente cada mensaje anterior en el prompt activo. El historial completo puede conservarse por separado, de forma resumida o no conservarse en absoluto, dependiendo del propósito, las expectativas del usuario y las reglas definidas. Para los datos personales, los principios de limitación de la finalidad, minimización de datos y limitación del plazo de conservación establecidos en el Artículo 5 del RGPD son criterios de diseño fundamentales. Aunque esto no sustituye el asesoramiento legal individual, proporciona un requisito claro de producto: almacenar únicamente lo que sea estrictamente necesario para el fin especificado.

Tratar las conversaciones anónimas y autenticadas de forma diferente

Retorno anónimo en el mismo navegador

Para visitantes anónimos, la función «continuar conversación» debe mantenerse como una opción de conveniencia limitada. Se recomienda establecer un periodo de conservación corto, una opción de eliminación claramente visible y una explicación de que el historial solo se podrá recuperar desde ese mismo navegador. El chatbot no debe asumir, solo por el hecho de que el usuario regrese, que se trata de la misma persona física. Una vez transcurrido el plazo o perdida la referencia local, debe iniciarse una nueva sesión.

En la práctica, al regresar, el chatbot puede preguntar: «¿Desea continuar con su conversación sobre la selección de productos o prefiere comenzar de nuevo?». Esto es infinitamente mejor que activar silenciosamente el contexto anterior. En dispositivos compartidos, esta confirmación evita que la siguiente persona vea inmediatamente contenido confidencial o ajeno.

Cambio de dispositivo mediante inicio de sesión

La continuidad entre diferentes dispositivos debe estar vinculada a una cuenta verificada y a sus permisos actuales. Tras el inicio de sesión, el servidor solo cargará las conversaciones asociadas a esa cuenta y a la organización correcta. Al realizar acciones sensibles —como cambiar la dirección, consultar datos contractuales o realizar un pedido—, es aconsejable solicitar una nueva autenticación, incluso si el chat general continúa activo.

La guía actual NIST SP 800-63B sobre gestión de sesiones define una sesión como la vinculación entre una persona autenticada y un servicio a través de un secreto de sesión. Exige límites de tiempo tanto por inactividad como globales, así como la finalización de la sesión desde el lado del servidor. Para los equipos de producto, esto implica que estar «autenticado» no puede ser un estado ilimitado, y que un token de sesión o de cuenta caducado no debe reactivarse por la simple existencia de un historial de chat guardado.

Códigos de transferencia solo como un puente estrictamente limitado

Algunas aplicaciones permiten una transición anónima mediante un código de un solo uso o un código QR. En este caso, el código debe ser de corta duración, de un único uso y revocable. No debe contener transcripciones ni datos del cliente, sino únicamente una referencia aleatoria a un estado de conversación mínimo y autorizado. Una vez realizada la transferencia con éxito, la referencia anterior queda invalidada. El código actúa como un puente para el contexto, no como una prueba de identidad ni como una autorización para acceder a datos sensibles de la cuenta.

Las reglas de caducidad deben ser claras en la interfaz

Los límites de tiempo técnicos solo resuelven la mitad del problema. Los usuarios deben saber si su conversación se conservará y durante cuánto tiempo. Las directrices del NIST sobre Customer Experience destacan la importancia de ofrecer información clara sobre el fin de la sesión para evitar pérdidas de trabajo y prevenir que los usuarios recurran a prácticas inseguras.

Por ello, un buen concepto de caducidad responde directamente dentro del propio chat a las siguientes preguntas:

• ¿Se conserva la conversación después de cerrar la ventana?
• ¿Esto aplica únicamente a este navegador o también tras iniciar sesión en otros dispositivos?
• ¿Cuándo finaliza la sesión por inactividad y cuándo se elimina el historial guardado?
• ¿Qué partes puede eliminar o exportar el propio usuario?
• ¿Qué ocurre con un caso de soporte abierto una vez que la sesión caduca?

Antes de que finalice una sesión prevista, una notificación discreta puede ofrecer la opción de guardar la información pendiente o transferirla al equipo de soporte. Una vez caducada, la interfaz debe diferenciar claramente entre «sesión finalizada» e «historial eliminado». Lo primero afecta al acceso; lo segundo, a la conservación.

Human Handoff: transferir el contexto y visibilizar la responsabilidad

Al realizar la transición a un agente humano, un resumen estructurado y breve suele ser mucho más valioso que un historial extenso sin comentar. Este resumen debe detallar la consulta, los datos confirmados, los pasos ya sugeridos, las preguntas pendientes y las fuentes consultadas. El contenido sensible solo debe transferirse si es indispensable para resolver el caso de soporte y si ha sido autorizado para ello.

El usuario debe ver claramente que un agente humano está tomando el control, qué información se está compartiendo y si habrá un nuevo tiempo de espera. Al mismo tiempo, la IA debe saber si, tras la transferencia, debe permanecer en silencio, limitarse a brindar apoyo organizativo o si podrá retomar el control más adelante. Los desencadenantes y reglas de escalación específicos se explican en detalle en el artículo sobre el Human Handoff en chatbots para sitios web.

Implementación en seis pasos

1. Especificar los escenarios de uso: Definir por separado la navegación por el sitio, el retorno posterior, el cambio de dispositivo y la transferencia a un agente humano.
2. Definir niveles de confianza: Establesca qué contenidos están disponibles de forma anónima, cuáles requieren vinculación con la cuenta y cuáles exigen una reautenticación.
3. Minimizar el estado: Diseñar un estado de reanudación (resume-state) estructurado que incluya el objetivo, los hechos confirmados, los puntos pendientes y el tiempo de caducidad.
4. Hacer cumplir el ciclo de vida: Probar en el servidor los límites de inactividad, los límites absolutos, la eliminación, la revocación y el cierre de sesión.
5. Diseñar las transferencias: Hacer visible la confirmación del usuario, el resumen para el equipo de soporte, el estado de espera y la asignación de responsabilidades.
6. Medir el éxito sin almacenar texto completo: Registrar eventos como «continuación ofrecida», «aceptada», «caducada», «cambio de dispositivo completado» y «handoff exitoso». Para conocer cómo lograrlo minimizando datos, consulte la guía sobre analítica para chatbots de IA.

Matriz de pruebas para escritorio, móvil y casos límite reales

Antes del lanzamiento, no solo debe funcionar la ruta ideal. Una pequeña matriz de pruebas permite identificar y corregir los errores más habituales:

• Navegación dentro del mismo sitio web con la ventana de chat abierta y cerrada,
• Retorno en el mismo navegador antes y después del límite de inactividad,
• Retorno en una ventana de navegación privada o tras borrar los datos locales del navegador,
• Cambio de dispositivo antes y después de iniciar sesión, así como tras cerrar sesión,
• Cambio de cuenta en un dispositivo compartido,
• Código de transferencia caducado, ya utilizado o revocado,
• Conversación eliminada, cuenta bloqueada o permisos de organización modificados,
• Continuación de la conversación tras una actualización de la base de conocimientos,
• Handoff con y sin un resumen expresamente autorizado,
• Títulos largos, idiomas con diferente longitud de texto y anchos de pantalla móviles sin desbordamiento horizontal.

En cada caso, la verificación debe incluir no solo la respuesta visible en la interfaz, sino también las solicitudes de red, la invalidación de la sesión, los registros de errores y los eventos analíticos. El chatbot puede explicar amablemente que un contexto ya no está disponible, pero jamás debe intentar reconstruirlo a partir de datos de usuarios similares ni asignarlo a una nueva persona.

Conclusión: la continuidad es una transferencia controlada

Ofrecer una buena experiencia de continuación no significa guardar todo para siempre. Significa trasladar el contexto adecuado y mínimo a lo largo de un trayecto claramente delimitado. El mismo navegador, un segundo dispositivo autenticado y un canal de soporte humano requieren reglas de confianza y caducidad diferentes. Al mantener separados el estado de la conversación, la identidad y los permisos, se logra una gran comodidad sin arriesgar divulgaciones silenciosas de datos.

Integrar estas reglas desde las primeras fases del diseño de la Conversational UX ayuda a reducir los abandonos de sesión y hace que las transferencias al equipo de soporte sean mucho más comprensibles. Las características de ChatReact ofrecen una visión general de los módulos disponibles para chatbots en sitios web; la configuración específica de sesiones y protección de datos debe planificarse y probarse posteriormente según las necesidades de cada proyecto.

Fuentes

• NIST SP 800-63B: Session Management
• NIST SP 800-63C: Customer Experience
• OWASP Session Management Cheat Sheet
• MDN: Web Storage API
• EUR-Lex: Reglamento General de Protección de Datos, Artículo 5