Eliminar y exportar el historial del chatbot: Control seguro de los usuarios

El historial de un chatbot es práctico para los usuarios: pueden releer respuestas, continuar una conversación más tarde o pasar información al equipo de soporte. Sin embargo, ese mismo historial puede contener números de pedido, descripciones de problemas, datos de contacto u otra información sensible. Por ello, quienes almacenan conversaciones necesitan algo más que un discreto botón de «Historial». Los usuarios deben entender qué datos existen, cómo llevárselos, eliminarlos o revocar accesos futuros.

Esta guía muestra un modelo técnico y de producto aplicable a los chatbots de sitios web. Combina usabilidad, minimización de datos, verificación segura de identidad y estados del sistema comprensibles. Estos consejos no constituyen asesoramiento jurídico individual; las obligaciones concretas dependen, entre otros factores, de la finalidad, la base legal, la arquitectura del sistema y los datos afectados.

Cuatro funciones en lugar de un único botón de historial

«Gestionar historial» es demasiado impreciso. En la interfaz y en el backend deben separarse cuatro intenciones diferentes:

• Ver: Los usuarios leen las conversaciones guardadas, los archivos adjuntos y los metadatos reconocibles en una cronología comprensible.
• Exportar: Reciben una copia en un formato legible y, si es útil o legalmente requerido para el caso de uso, también en un formato estructurado legible por máquina.
• Eliminar: Borran conversaciones individuales o todo el historial asociado. La interfaz explica el alcance, los plazos y las posibles excepciones.
• Revocar acceso: Invalidan enlaces compartidos, dispositivos conocidos o tokens de reanudación, sin necesidad de eliminar inmediatamente todos los datos de contenido.

Esta separación evita confusiones peligrosas. «Cerrar sesión» no elimina los datos de la conversación. «Ocultar historial» no es una eliminación. Y un enlace caducado no significa automáticamente que los registros subyacentes hayan desaparecido. Como complemento, vale la pena consultar nuestra guía sobre cómo continuar conversaciones de chatbot de forma segura.

Empezar con un modelo de datos claro

Antes de que los equipos diseñen botones, deben inventariar los objetos almacenados. Una conversación a menudo no consta solo de mensajes. Se añaden identificadores de sesión, marcas de tiempo, referencias a archivos, eventos de seguridad, tickets de soporte, comentarios y registros técnicos. Cada objeto necesita un propósito documentado, un responsable, una regla de conservación y una ruta de eliminación.

El Reglamento General de Protección de Datos (RGPD) menciona en su artículo 5, entre otros, la minimización de datos y la limitación del plazo de conservación. El artículo 15 aborda el derecho de acceso, el artículo 17 el derecho de supresión con sus condiciones y excepciones, y el artículo 20 la portabilidad de los datos en sus respectivos ámbitos de aplicación. De esto no se deduce que cada interfaz de chatbot deba ofrecer funciones idénticas. Sin embargo, los equipos de producto deben construir los flujos de datos de manera que las solicitudes legítimas puedan procesarse de forma fiable.

Verificar adecuadamente la identidad antes de exportar o eliminar

Quien hace accesible un historial solo a través de un enlace adivinable o un identificador de sesión reutilizado se arriesga a filtraciones de datos. Al mismo tiempo, la verificación de identidad no debe exigir de forma generalizada más datos personales de los necesarios para la acción concreta. Las directrices finales 01/2022 del EDPB sobre el derecho de acceso tratan, entre otros temas, la identificación, el alcance y la entrega segura de copias. El artículo 12, apartado 6, del RGPD permite solicitar información adicional para confirmar la identidad si existen dudas razonables sobre la misma.

En la práctica, una gradación basada en el riesgo resulta muy eficaz. Mostrar un historial breve seudónimo en el mismo dispositivo puede requerir una sesión válida de corta duración. Una exportación completa, una eliminación irreversible o la revocación de todos los dispositivos justifica más bien una reautenticación. La guía actual del NIST sobre gestión de sesiones describe la reautenticación, los límites de tiempo y la terminación de sesiones como controles independientes. La fuerza concreta debe adaptarse al riesgo; las directrices del NIST para agencias federales de EE. UU. no son una exigencia legal genérica para todas las empresas.

Para widgets públicos y áreas de clientes autenticados, el límite debe permanecer visible. Nuestra publicación sobre identidad y acceso a datos en el portal de clientes muestra por qué un chat público no debería convertirse silenciosamente en un canal de datos de la cuenta.

Una exportación debe ser comprensible y completamente explicable

Una buena exportación no es un volcado en bruto de la base de datos. Comienza con un resumen: período de creación, conversaciones incluidas, archivos adjuntos, zona horaria utilizada y versión del formato. A continuación vienen los contenidos en un orden claro. El formato JSON puede tener sentido para un procesamiento posterior estructurado; HTML o PDF es más fácil de leer para la mayoría de las personas. Debe evaluarse para cada caso concreto si y en qué medida se exige legalmente un formato portable.

Si el sistema genera la exportación de forma asíncrona, la interfaz necesita un estado claro: «en preparación», «listo hasta…», «caducado» o «fallido». El enlace de descarga debe ser de corta duración, no adivinable y revocable tras su uso. Los secretos como los prompts internos, las claves de acceso o los datos de otras personas no pertenecen al paquete. Antes de la entrega, un filtro del lado del servidor debe verificar si las relaciones con casos de soporte, conversaciones compartidas o contenidos de terceros requieren un tratamiento especial.

La eliminación como máquina de estados en lugar de una promesa inmediata

Un botón con el mensaje «Todo eliminado» es problemático si el índice de búsqueda, el almacenamiento de analítica, el sistema de soporte o las copias de seguridad siguen conteniendo copias. Es mejor utilizar una pequeña máquina de estados que refleje el proceso real.

Estados de eliminación lógicos

1. Solicitado: La identidad y el alcance deseado están confirmados.
2. Bloqueado: El historial ya no es accesible para el uso normal; los tokens de reanudación y de uso compartido quedan invalidados.
3. En proceso: Se están procesando el almacenamiento primario, el índice de búsqueda, el almacenamiento de archivos y los destinos de analítica e integración.
4. Completado: Los sistemas activos previstos se han limpiado; las copias de seguridad restantes están sujetas a la rotación de backups documentada o a una excepción justificada.
5. Parcialmente bloqueado: Un sistema no se pudo limpiar o los datos deben conservarse por el momento. El caso se escala de forma transparente.

No olvidar los datos dependientes

Los mensajes pueden hacer referencia a archivos, embeddings, índices de búsqueda, evaluaciones de calidad, registros de CRM o tickets de soporte. Por ello, la solicitud de eliminación necesita un ID de solicitud estable y pasos de trabajo idempotentes: una nueva ejecución no debe generar nuevas copias ni revertir pasos ya completados. Para los datos de medición, se debe decidir desde la fase de diseño si se pueden conservar métricas agregadas que ya no se puedan asociar a un usuario. Hay más información al respecto en el artículo sobre analítica de chatbots de IA con minimización de datos.

La revocación protege especialmente en dispositivos compartidos

En hoteles, salas de ventas, talleres o hogares familiares, las personas cambian con frecuencia en el mismo dispositivo. Por eso, «Revocar acceso» debe ser capaz de hacer algo más que borrar una cookie localmente. En el lado del servidor, los tokens de sesión conocidos, los enlaces compartidos y, si procede, las vinculaciones de dispositivos deben quedar invalidados. La interfaz debe diferenciar entre «este dispositivo», «todos los dispositivos» y «todos los enlaces compartidos».

Tras la revocación, el botón de retroceso no debe mostrar un historial sensible desde la caché. Las vistas previas en notificaciones, la autocompletación del navegador y los datos locales fuera de línea entran dentro de la revisión. Al mismo tiempo, el usuario debe recibir una confirmación clara de qué accesos se han finalizado y si los datos de la conversación se siguen almacenando. Así se evita confundir la revocación con la eliminación.

Diseñar una confirmación de eliminación accesible y tolerante a errores

Una acción irreversible requiere una confirmación tranquila y comprensible. La explicación de la WCAG 2.2 para el criterio de conformidad 3.3.4 se refiere explícitamente a la modificación o eliminación de datos controlables por el usuario. Se prevé al menos una opción para revertir, revisar o confirmar. Qué variante es la idónea dependerá del producto.

Los buenos diálogos mencionan concretamente «3 conversaciones y 2 archivos adjuntos» en lugar de solo «datos». La acción primaria y la destructiva se diferencian visualmente, son accesibles mediante el teclado y no se explican únicamente mediante el color. Tras el envío, una área de estado accesible informa de que la solicitud ha sido aceptada. Una papelera de reciclaje con un plazo de recuperación limitado puede mitigar errores de manejo, pero no debe contradecir en secreto una eliminación inmediata prometida.

Traspaso a soporte sin copia en la sombra

Cuando una conversación se transfiere a un agente humano, a menudo se crea un ticket de soporte independiente. Este objeto puede tener una finalidad distinta, otros roles de acceso y una regla de conservación diferente. La configuración del historial en el chatbot no debe eliminar dicho ticket de forma invisible ni ignorarlo silenciosamente. Antes de la transferencia, la interfaz debe explicar qué contenidos se van a traspasar. En caso de una solicitud posterior, el sistema debe localizar la vinculación y tratar el caso según las reglas aplicables.

Si una eliminación automática falla o la identidad y el alcance no están claros, el proceso necesita un canal humano seguro. El artículo sobre Human Handoff en el soporte de sitios web describe paquetes de contexto y reglas de escalado para este fin. Solo se debe transferir lo que el empleado responsable realmente necesite.

Lista de verificación de implementación para equipos de producto y soporte

1. Inventariar todos los objetos de datos y ubicaciones de almacenamiento de una conversación.
2. Modelar la visualización, exportación, eliminación y revocación como permisos separados.
3. Reautenticar según el riesgo para acciones sensibles.
4. Estructurar los paquetes de exportación de forma comprensible y establecer tiempos de caducidad seguros.
5. Hacer que los pasos de eliminación sean idempotentes y rastreables con un ID de solicitud.
6. Incluir el índice de búsqueda, archivos, analítica, integraciones, cachés y casos de soporte.
7. Probar los diálogos de confirmación y los mensajes de estado con teclado y lector de pantalla.
8. Simular dispositivos compartidos, enlaces caducados y dispositivos perdidos.
9. Escalar de forma visible los errores parciales sin copiar contenido sensible en los registros.
10. Revisar periódicamente las reglas de conservación y eliminación con el área de protección de datos y los departamentos correspondientes.

Las pruebas más importantes antes del lanzamiento

Los casos de prueba no deben cubrir solo el flujo ideal. Compruebe las solicitudes de eliminación paralelas, un inicio de sesión que expira durante la exportación, enlaces ya revocados, nuevos mensajes durante una eliminación en curso y la caída de un sistema conectado. Controle también si una exportación contiene mensajes de terceros procedentes de cuentas compartidas y si se puede acceder a un archivo eliminado a través de una URL antigua.

Para cada acción debe haber un resultado esperado en la interfaz, la API y el almacenamiento. Una buena prueba de aceptación no termina con un mensaje de éxito en verde. A continuación, verifica los almacenes de datos relevantes, los tokens y las URL públicas. Los registros de eventos deben demostrar que se ejecutó un paso, sin volver a almacenar el contenido de la conversación eliminada.

Conclusión: El control del usuario es una propiedad de extremo a extremo

Un chatbot de confianza no solo hace que el historial sea localizable. Separa la visualización, exportación, eliminación y revocación, verifica adecuadamente las acciones sensibles y muestra el estado real del procesamiento. Lo decisivo es la combinación de una UX clara con un modelo de datos que conozca todos los sistemas dependientes.

Quienes integran estas funciones desde una fase temprana en la arquitectura, los procesos de soporte y las pruebas reducen los casos excepcionales manuales y evitan falsas promesas. Durante la planificación, compruebe también qué funciones de ChatReact se adaptan a su sitio web y a su proceso de soporte. Comience con un inventario de datos y una sola prueba de extremo a extremo: exportar el historial, revocar los accesos, activar la eliminación y comprobar el resultado en todos los sistemas involucrados.

Fuentes y referencias adicionales

• EUR-Lex: Reglamento (UE) 2016/679, especialmente los artículos 5, 12, 15, 17 y 20.
• EDPB: Directrices 01/2022 sobre los derechos de los interesados – Derecho de acceso, Versión 2.1.
• NIST SP 800-63B: Gestión de sesiones.
• W3C: Comprensión del criterio de conformidad 3.3.4 de las WCAG 2.2.