IA para solicitudes del RGPD: qué automatizar en tu helpdesk y qué dejar en manos humanas

¿Qué cuenta como solicitud del RGPD en una cola de soporte?

Una solicitud del RGPD es cualquier mensaje en el que una persona pide ver, trasladar, corregir o eliminar los datos personales que conservas sobre ella. En una cola de soporte, casi nunca llega etiquetada.

El regulador británico es tajante en esto. Su guía para reconocer solicitudes dice que una persona puede hacer una solicitud de palabra o por escrito, también en redes sociales, a cualquier parte de tu organización, y no tiene que usar las palabras «solicitud de acceso» ni nombrar la ley. Solo tiene que quedar claro que quiere su información personal. La misma página dice que cualquier empleado puede recibir una solicitud válida y que debes identificar y gestionar cada una correctamente.

Ese es todo el argumento a favor de la IA aquí. Una regla de palabras clave sobre «RGPD» capta a los clientes que han leído una política de privacidad. Se le escapan los que escriben «¿qué tenéis realmente sobre mí?» o «cerrad mi cuenta y borrad todo» al final de una queja de facturación. Un agente de IA lee cada ticket como lo haría una persona, así que capta ambos.

Yo desarrollo las integraciones de helpdesk de eesel, y los tipos de solicitud siguientes son los que enseñaría primero a reconocer a un agente. Se corresponden con los derechos de los artículos 15 a 21 del RGPD.

La última fila parece trivial y es la que más equipos pasan por alto. Un «dadme de baja» tratado como un ticket normal recibe una respuesta amable y nada más. Tratado como una oposición, se comprueba en todas las herramientas de marketing. El etiquetado de tickets con IA que conoce la diferencia vale más que cualquier respuesta ingeniosa.

¿De cuánto tiempo dispones para responder a una solicitud del RGPD?

Tienes un mes natural desde el día en que recibes la solicitud, según el artículo 12 del RGPD. Puedes ampliarlo dos meses más si la solicitud es compleja o has recibido muchas, pero debes comunicárselo a la persona, con los motivos, dentro de ese primer mes.

La guía sobre cómo responder del regulador británico detalla las reglas de cómputo en las que la gente tropieza:

• El mes corre hasta la misma fecha del mes siguiente. Una solicitud del 14 de mayo vence al final del 14 de junio. Si la fecha no existe (31 de enero), usa el último día del mes siguiente.
• El reloj espera la identificación que pediste. Si tienes dudas reales sobre quién pregunta, el mes empieza cuando llega su identificación o la autorización de un tercero, no antes.
• Pedir aclaraciones detiene el reloj. Si pides aclaración el 15 de mayo y recibes la respuesta el 18 de mayo, sumas esos 4 días.
• Los fines de semana se desplazan hacia delante. Un plazo que cae en sábado pasa al final del siguiente día laborable.
• Se permite un objetivo interno de 28 días si tus sistemas necesitan un número fijo de días, y siempre queda dentro del mes.

Esa regla de la identificación es donde un agente de IA se gana el sueldo. Cuanto antes pidas confirmación, menos de tu mes gastas antes de que el reloj haya empezado siquiera, y el agente puede enviar esa petición en el primer minuto en lugar de cuando alguien abra la cola. Una salvedad honesta: estas reglas de cómputo son la interpretación del regulador británico, así que si estás en la UE consulta la guía de tu propio regulador sobre cuándo empieza el reloj. Pide la identificación el mismo día en que llega la solicitud y la diferencia nunca importará.

Introduce aquí las fechas de un ticket real para ver el plazo. Aplica las reglas de cómputo británicas anteriores.

Si tu helpdesk tiene un temporizador de SLA, esta es la fecha hasta la que debería contar. La mayoría lo tiene, y la guía de gestión de SLA explica cómo configurar uno por tipo de ticket.

¿Qué partes de una solicitud del RGPD puede gestionar la IA?

La IA puede gestionar todo lo que sea leer, clasificar, cronometrar y escribir. No debería gestionar nada que revele datos a alguien o los destruya.

Este es el reparto con el que empezaría con cualquier equipo:

Para la IA desde el primer día

1. Detectar. Leer cada ticket y comentario nuevo y marcar los que preguntan por datos personales, en cualquier idioma. Es el paso en el que falla una regla de palabras clave.
2. Etiquetar el tipo. Acceso, supresión, rectificación, portabilidad u oposición, escrito en un campo del ticket para poder generar informes.
3. Iniciar el reloj. Fijar la fecha de recepción y la de vencimiento en cuanto llega el ticket, no cuando una persona llega a él.
4. Redactar. El acuse de recibo, la petición de identificación, la nota de «necesitamos aclarar» y la confirmación final, todo a partir de plantillas que tu responsable de privacidad aprobó una vez.
5. Reunir. Consultar la cuenta, enumerar qué sistemas guardan datos de esta persona y señalar cualquier cosa que bloquee la eliminación, como un pedido abierto o una factura impagada.

Para una persona

1. La identidad, cuando hay dudas. El regulador dice que seas razonable y proporcionado y uses comprobaciones que ya tienes, como una cuenta con sesión iniciada. Una solicitud desde el correo de la cuenta de un cliente conocido normalmente no necesita nada más. Una solicitud desde una dirección nueva que pide el historial de pedidos de otra persona necesita a una persona.
2. Aprobar la exportación. Alguien lee el archivo antes de que salga, porque los tickets de soporte están llenos de nombres de otras personas: el mensajero, el compañero en copia, la persona de la que se quejaron.
3. Aprobar la eliminación. Se trata en la siguiente sección, porque es la que sale mal.

Si ya tienes un traspaso a humanos para los reembolsos, este es el mismo patrón con una regla más estricta: la IA prepara, la persona pulsa el botón.

¿Por qué la IA no debería borrar datos de clientes por su cuenta?

Porque una eliminación no se puede deshacer y la ley suele exigir que conserves parte de los datos de todos modos.

La guía sobre el derecho de supresión del regulador británico lo dice desde el principio: el derecho no es absoluto y solo se aplica en determinadas circunstancias. Puedes rechazarlo, total o parcialmente, cuando necesites los datos para cumplir una obligación legal o para formular, ejercer o defender reclamaciones. En términos de soporte, es el cliente que quiere que se borre todo mientras hay un contracargo abierto, o cuyas facturas debes conservar por motivos fiscales.

Las propias herramientas de helpdesk se basan en el mismo supuesto. La redacción de tickets de Zendesk es irreversible. La eliminación de perfiles de Help Scout borra todas las conversaciones vinculadas sin posibilidad de deshacer. Delete forever de Freshdesk elimina los tickets y notas de un contacto, y su propia guía dice que las solicitudes de eliminación y exportación deben pasar por un administrador que compruebe que quien las solicita es auténtico.

También hay un orden. La guía del RGPD de Zendesk dice que hay que eliminar al usuario al final: primero limpia los datos personales de las conversaciones de los tickets, porque necesitas el perfil para encontrar esos tickets. Un agente que borra primero el perfil acaba de complicar el resto del trabajo.

Así que la regla que escribiría en las instrucciones de cualquier agente es corta: nunca ejecutes una eliminación, prepárala siempre. Redacta la lista de lo que hay que eliminar y de lo que hay que conservar, señala los motivos y entrégasela a una persona para que la apruebe.

¿Qué herramientas de RGPD tiene ya tu helpdesk?

Todos los helpdesks importantes pueden eliminar a un cliente. Se diferencian en la redacción, la ayuda de IA y el punto por el que entra la solicitud. Revisé el centro de ayuda de cada proveedor:

«No encontrado» significa que las páginas de ayuda del proveedor sobre el RGPD no lo describen, no que la función no pueda existir en otra parte del producto.

Zendesk es el único de los seis con IA integrada en el propio apartado del RGPD. Sus sugerencias de redacción resaltan los datos personales en naranja para que un agente pueda redactarlos de una sola pasada:

Sugerencias de redacción en un ticket de Zendesk, tal como se muestran en el centro de ayuda de Zendesk.

Esa función está en el complemento Advanced Data Privacy and Protection para Suite Enterprise y superiores, así que revisa tu plan de Zendesk antes de diseñar en torno a ella. Zendesk también señala que no funciona en tickets de agentes de IA.

La página de solicitudes de HubSpot es la que copiaría en otros helpdesks. Un formulario que pregunta «¿eliminar o exportar?» convierte un correo vago en una solicitud tipificada con una dirección verificada, que es exactamente la entrada que mejor gestiona un agente de IA. Si usas Freshdesk, trato su configuración del RGPD por separado. Los equipos de Gorgias tienen lo mismo en Gorgias y el RGPD.

Cómo configurar la IA para solicitudes del RGPD en tu helpdesk

Esta es la configuración que aplicaría en cualquier helpdesk, en este orden. Los pasos 1 a 3 merecen la pena en tu primera semana aunque nunca dejes que la IA toque nada más.

Paso 1: escribe la regla de detección con palabras sencillas

Dale al agente ejemplos de cómo es una solicitud, no una lista de palabras clave. «Qué datos tenéis sobre mí», «eliminad mi cuenta», «quitadme de todo», «quiero una copia de mi historial de pedidos», «dejad de usar mis datos», en cada idioma que admitas. Dile que una solicitud enterrada en una queja sigue contando, y que la solicitud de un abogado o de un familiar en nombre de alguien también es una solicitud.

Paso 2: etiqueta el tipo y fija las fechas

Haz que el agente escriba el tipo de solicitud en un campo del ticket y fije la fecha de recepción. Después deja que el SLA de tu helpdesk se encargue del cronometraje. Generar informes sobre ese campo es como sabrás si recibes cinco de estas al mes o cincuenta, algo que trata la guía de informes de soporte con IA.

smava usa exactamente este esquema en finanzas reguladas. Un agente de eesel se activa con cada nuevo ticket y comentario, etiqueta el idioma, elige una categoría de un documento de correspondencias que escribió el equipo y la escribe en dos campos de Zendesk. No toca nada más. De unos 27.000 tickets en un mes, categorizó unos 14.600, y solo unos 1.100 se marcaron como aptos para una respuesta automática. En una cola regulada, la mayor parte del valor está en clasificar.

Paso 3: redacta el acuse de recibo y la petición de identificación

Escribe las plantillas una vez con tu responsable de privacidad: el acuse de recibo con la fecha de vencimiento, el mensaje de «confirma que eres tú», la nota de aclaración y el aviso de ampliación. El agente las rellena. Si la solicitud llegó por redes sociales, haz que pida un canal privado, ya que el regulador señala que las redes sociales no son una forma segura de enviarle a alguien sus datos.

Paso 4: exige aprobación para toda acción irreversible

Este es el paso que hace seguro todo lo demás. En eesel, cada acción que puede realizar un agente se configura para ejecutarse sola, preguntar primero o quedar desactivada, por agente. La documentación de acciones y aprobaciones recomienda empezar supervisado, con las respuestas y todo lo irreversible bajo aprobación.

Ajustes por acción en eesel: una marca se ejecuta sola, una mano espera a una persona, una cruz está desactivada.

Para los tickets del RGPD, dejaría que el etiquetado y las notas internas se ejecuten solos, pondría las respuestas públicas bajo aprobación y mantendría cualquier acción de eliminación o exportación de datos desactivada o bajo aprobación. También puedes retener un caso aunque una acción esté activada: una instrucción como «pregunta antes de responder a cualquier cosa sobre eliminar datos» hace que el agente se detenga solo en ese caso. Mi artículo sobre flujos de aprobación trata el patrón para otros tipos de ticket.

Paso 5: deriva a un responsable con nombre

Cada tipo de solicitud debe llegar a una persona, no a un buzón de grupo. Normalmente es tu responsable de privacidad o protección de datos para supresión y acceso, y operaciones de soporte para rectificación y bajas. Un agente de IA puede derivar por etiqueta al instante; no puede arreglar una regla de derivación que no lleva a ninguna parte. Si estás decidiendo quién es ese responsable, el artículo sobre los roles de trabajo en soporte ofrece un modelo.

Paso 6: conserva el registro

Necesitarás demostrar qué ocurrió si un regulador o el cliente lo pregunta. El helpdesk conserva el historial del ticket, y la herramienta de IA debería llevar su propio registro de cada acción. En eesel, cada ejecución aparece en la vista de Actividad con su estado de aprobación:

La vista de Actividad en eesel, filtrable por acciones aprobadas, rechazadas y pendientes.

Paso 7: pruébalo con tus tickets pasados del RGPD

Antes de ponerlo en marcha, ejecuta el agente con las solicitudes que ya has gestionado. ¿Detectó todas, incluidas las escondidas en quejas? ¿Etiquetó «dadme de baja» como una oposición en lugar de una pregunta general? Una simulación con tickets pasados lo responde en una tarde, y es la forma más barata de encontrar la solicitud que tu regla habría pasado por alto.

¿Forma tu herramienta de IA parte de la solicitud del RGPD?

Sí, y este es el paso que casi todas las guías omiten. Si tu agente de IA aprendió de tickets anteriores, el cliente que pide ser olvidado puede seguir en el historial de tickets almacenado y en el índice de búsqueda de la herramienta de IA después de que lo hayas eliminado del helpdesk.

Hay dos formas de afrontarlo. La primera es mantener los datos personales fuera del índice de la IA desde el principio. La redacción de PII de eesel pasa los tickets anteriores por un detector antes de almacenar o indexar nada, y enmascara 15 categorías, entre ellas nombres, correos, teléfonos, direcciones, IBAN y documentos de identidad nacionales. El agente sigue aprendiendo cómo responde tu equipo; simplemente nunca almacena quién preguntó. Es opcional por integración, se aplica a los tickets anteriores sincronizados desde tu helpdesk y no cubre los tickets indexados antes de activarla, así que actívala antes de la primera sincronización. La segunda es poner al proveedor de IA en tu lista de eliminación y confirmar cuánto tiempo conservan los datos sus copias de seguridad. El Trust Center de eesel indica que las copias de seguridad cifradas caducan en 35 días.

Esa ventana de 35 días es normal, y la guía de supresión del regulador la acepta: los datos pueden permanecer en una copia de seguridad hasta que se sobrescriban, siempre que queden fuera de uso y seas claro con la persona sobre lo que ocurrirá.

El resto de la revisión del proveedor es la misma que harías con cualquier proveedor de IA para soporte:

• Un contrato de encargado del tratamiento. El de eesel cubre el RGPD, con cláusulas contractuales tipo para las transferencias internacionales.
• Una lista publicada de subencargados. En el Trust Center, incluidos los proveedores de modelos de IA.
• Sin entrenar con tus datos. eesel no entrena ni ajusta modelos con datos de clientes.
• Dónde residen los datos. La residencia de datos en la UE o en EE. UU. figura en cada plan de eesel, también en el gratuito.

Una carencia que conviene nombrar con claridad: la auditoría SOC 2 Tipo II de eesel está en curso, con el periodo de observación del 1 de octubre al 31 de diciembre de 2026 y el informe previsto para 2027. Si tu departamento de compras necesita el informe hoy mismo, es una limitación real. Mi guía de revisión de seguridad explica qué pedir en su lugar.

Equipos de la UE llevan tiempo usando eesel con estos requisitos. Simployer, una empresa nórdica de software de cumplimiento de RR. HH., lo expresó así en su caso de éxito:

"We needed a turnkey solution for Confluence that met our GDPR requirements and could serve different teams through dedicated Slack bots. eesel AI delivered exactly that, with EU data residency included."

Flemming Ottosen, Development Director, Simployer

Errores comunes con la IA y las solicitudes del RGPD

Estos son los que vigilaría durante el primer mes:

• Dejar que el agente responda «hecho» antes de que esté hecho. Un correo de confirmación es una afirmación de hecho. Haz que el agente lo redacte y solo se envíe cuando la eliminación o la exportación estén aprobadas y completadas.
• Responder a una solicitud de acceso con la transcripción de un chat. Una solicitud de acceso abarca todos los sistemas, no solo el hilo del ticket. El trabajo del agente es enumerar los sistemas; una persona certifica que la lista está completa.
• Enviar la exportación a quien la pida. Una solicitud desde una dirección de correo nueva que pide los datos de un cliente existente es el movimiento clásico de ingeniería social. Es justo entonces cuando se aplica la comprobación de identidad del regulador.
• Olvidar las demás herramientas. Gorgias dice claramente que eliminar un cliente no afecta a Shopify ni a Klaviyo. Tu lista de comprobación necesita todas las herramientas, incluida la de IA.
• Tratar «darse de baja» como charla trivial. Es una oposición al tratamiento. Etiquétala, derívala y confirma que la baja llegó.

Si quieres una segunda opinión sobre dónde falla un despliegue como este, el artículo sobre el calendario de implementación trata con más detalle el control del lanzamiento.

Prueba eesel para solicitudes del RGPD en tu helpdesk

eesel se incorpora a tu helpdesk como un compañero de IA para soporte. Para las solicitudes del RGPD, eso significa que lee cada ticket nuevo, reconoce una solicitud de datos con cualquier formulación o idioma, etiqueta el tipo, redacta el acuse de recibo y la petición de identificación a partir de tus plantillas y retiene cada respuesta o acción que elijas para que la apruebe una persona. Funciona en Zendesk y en los demás helpdesks de la tabla anterior. En Freshdesk, la integración con Freshdesk funciona igual.

Una acción configurada para preguntar primero en eesel: la respuesta redactada espera hasta que alguien la apruebe.

Las aprobaciones llegan donde ya trabaja tu equipo: el panel, un hilo de Slack o un enlace en la nota del helpdesk. Los equipos que llevan el trabajo de privacidad desde una terminal pueden listar y aprobar las acciones retenidas con la CLI de eesel (eesel approvals), que también pueden manejar agentes de programación como Claude Code.

Las reglas son texto plano que escribes tú. Swiftreg, un distribuidor británico de matrículas, ejecuta un agente de eesel en Zendesk que se refiere a los vendedores particulares solo como «el vendedor» o «el propietario actual», nunca por su nombre, porque eso es lo que dicen sus instrucciones. En Dokument 24, en Dinamarca, el agente etiqueta unos 430 tickets al mes por producto y deja unos 670 borradores de respuesta en danés como notas internas para que los envíe el equipo. Esa es la forma que usaría para las solicitudes del RGPD: el agente clasifica y redacta, las personas deciden.

Los planes empiezan gratis con 100 créditos, y un ticket del RGPD cuesta el mismo 1 crédito que cualquier otro. Prueba eesel con tu propia cola o lee antes más historias de clientes.