RGPD en la atención al cliente con IA: contrato de encargo, transferencias, conservación y solicitudes de los interesados

Añadir un asistente de IA a tu stack de soporte no cambia ni una sola obligación del RGPD. Lo que cambia es dónde aparecen los datos personales. Un chat recoge lo que un formulario de contacto nunca recoge: números de pedido, direcciones, quejas sobre pagos, historias vitales enteras escritas a medianoche porque el cliente está molesto. Ese contenido se recupera, se resume, se envía a un modelo, se guarda como transcripción y se cuenta en tu analítica. Nada de ello es ilícito. Todo ello te toca justificarlo a ti.

1. Quién es quién, y qué ve cada parte

La mayoría de las discusiones sobre IA y RGPD se acortan en cuanto se nombran los roles en voz alta. Tú decides por qué y cómo se tratan los datos de tus clientes, así que eres el responsable. Tu plataforma de soporte los trata siguiendo tus instrucciones, así que es un encargado. El proveedor del modelo que hay detrás de las respuestas de la IA está por debajo, como subencargado. Tres partes trabajan sobre un mismo mensaje de chat, y solo una tiene relación con el cliente: tú.

Esa última fila pilla a mucha gente por sorpresa. Una plataforma de tienda o un canal de mensajería que conectas tú mismo es un servicio que tú has dirigido, no un subencargado contratado por tu proveedor, y nadie más lo va a incluir en tu registro de actividades de tratamiento.

2. La checklist del contrato de encargo

El artículo 28 del RGPD —consulta el texto del Reglamento (UE) 2016/679— establece lo que debe contener un contrato con un encargado. La mayoría de los contratos publicados lo cubren. La lectura útil no es si las cláusulas existen, sino si hay algo concreto debajo de ellas.

• Objeto, duración, naturaleza y finalidad, y las categorías de datos y de interesados. Si aquí es vago, el proveedor no ha averiguado qué datos tiene.
• Tratamiento solo según tus instrucciones documentadas, transferencias incluidas, más la obligación de avisar si una instrucción parece ilícita.
• Confidencialidad para todas las personas con acceso y medidas de seguridad descritas de forma concreta: cifrado en tránsito y en reposo, separación entre clientes, control de acceso, registro de auditoría, copia de seguridad y restauración.
• Una lista nominal de subencargados y un plazo de preaviso antes de añadir o sustituir uno, con derecho a oponerse.
• Asistencia con las solicitudes de los interesados y con los artículos 32 a 36: gestión de brechas, evaluaciones de impacto, consulta previa.
• Notificación de brechas sin dilación indebida, con un objetivo declarado y un contacto con nombre en lugar de la expresión del reglamento.
• Derechos de auditoría, y qué ofrece el proveedor en lugar de una auditoría presencial.
• Supresión o devolución al final del contrato, incluido qué pasa con las copias de seguridad y cuánto tarda.

Dos cosas que no son cláusulas importan igual. Cómo se te avisa de un cambio de subencargado: una lista de correo a la que tienes que acordarte de apuntarte es más débil que un plazo de preaviso contractual. Y si tu contenido de soporte entrena modelos generales, algo que debería ser una frase clara y no una deducción. La nuestra dice que no; las tablas de subencargados, el mecanismo de transferencia y el preaviso de 30 días para cambios están en el contrato de encargo y en la política de privacidad.

3. Transferencias: dónde están los datos y qué sale

«¿Está alojado en Europa?» son dos preguntas. ¿Dónde está el almacenamiento principal, y qué operaciones concretas salen del EEE? En nuestro caso, el alojamiento principal está en la UE, los datos de cada espacio de trabajo se guardan por separado de los de cualquier otro cliente y se cifran en tránsito y en reposo. Parte del tratamiento de IA pasa por subencargados fuera del EEE con las cláusulas contractuales tipo de la Comisión Europea y el anexo del Reino Unido, por escrito y donde puedes comprobarlo.

Lee a cualquier otro proveedor de la misma manera. Uno que responde «alojamiento en la UE» y se detiene ahí ha descrito su base de datos, no la llamada al modelo. Pregunta por escrito qué tratamiento sale del EEE, con qué mecanismo y si existe una configuración en la que no ocurra en absoluto.

4. Conservación: los datos de soporte que con más frecuencia no tienen dueño

Las transcripciones se acumulan porque nadie decidió que no lo hicieran. Son realmente útiles —revisión de calidad, huecos de contenido, el momento incómodo en que un cliente dice que se le prometió algo— y cada mes de transcripciones es también un mes de datos personales que tendrías que buscar, exportar y suprimir si te lo piden. La limitación del plazo de conservación no es una sugerencia.

• Fija un plazo por tipo de dato. Las conversaciones, los registros de decisiones de la IA y los datos de comercio conectados tienen vidas útiles distintas.
• Haz que la caducidad sea automática. Una política que depende de que alguien ejecute una limpieza no es una política.
• Sabe lo que cuesta la caducidad. Borrar las transcripciones del año pasado también elimina tu capacidad de volver a revisar una resolución antigua, así que decide primero qué conservas de forma agregada.
• Enmascara en lugar de conservar. Ocultar correos y teléfonos al cerrar mantiene un hilo útil para revisión y elimina la mayor parte de lo que lo hace sensible.
• Indica los plazos en tu aviso de privacidad con las mismas palabras con las que los configuraste.

En nuestro producto son ajustes del espacio de trabajo que controla un propietario o administrador: conservación de las conversaciones, un plazo distinto para los registros detallados de decisiones de la IA y un interruptor que enmascara los datos de contacto del cliente cuando se resuelve una conversación. Uses la herramienta que uses, responde el primer día a quién es el dueño de esas cifras: el valor por defecto en la mayoría de los stacks es «guardarlo todo, para siempre, sin querer».

5. Minimización de datos, donde realmente ocurre

En un producto de chat, la minimización son cuatro decisiones sobre lo que se le permite necesitar al asistente.

1. No pidas lo que no vas a usar. Cada campo previo al chat son datos que ahora tienes. Un nombre y un correo resuelven la mayoría de los tickets; una fecha de nacimiento casi nunca.
2. Verifica comparando, no revelando. Vincula la consulta de un pedido a la dirección de correo desde la que chatea el cliente y devuelve un «no encontrado» neutro si no coincide, para que un número de pedido adivinado nunca confirme que existe el pedido de otra persona.
3. Mantén el asistente en solo lectura sobre las fichas de clientes. Una IA que lee un pedido es un riesgo distinto de una que puede modificarlo; los reembolsos y las modificaciones de pedidos van a una cola para que una persona los apruebe.
4. Sabe lo que el widget deja en el navegador. El nuestro guarda un identificador de sesión en el almacenamiento local para que un cliente que vuelve vea su propio hilo: un dato para tu aviso de cookies y una pregunta justa para cualquier proveedor.

La comparación de identidad es la que se convierte en incidente cuando se omite, y es donde la Ley de IA y el RGPD se encuentran en el mismo widget. La parte del aviso se trata en el artículo sobre el aviso de chatbot de la Ley de IA de la UE.

6. Solicitudes de acceso y supresión, de principio a fin

Una solicitud de acceso debe responderse sin dilación indebida y en el plazo de un mes desde su recepción, prorrogable dos meses más en solicitudes complejas o numerosas si se lo comunicas a la persona dentro del primer mes. Parece generoso, hasta que lo intentas en cuatro canales y encuentras al mismo cliente tres veces.

1. Encuentra todas las identidades. Una persona puede existir como visitante del widget, como dirección de correo, como número de WhatsApp y como ID de cliente en la tienda. Decide de antemano qué identificador usas para cruzarlas; el correo suele ser el único compartido.
2. Incluye los datos derivados. Etiquetas, puntuaciones de sentimiento, registros de decisiones de la IA, filas de analítica y datos de pedidos replicados son todos datos personales de esa persona.
3. Verifica primero al solicitante. Una solicitud de acceso respondida a la persona equivocada es una brecha disfrazada de cumplimiento.
4. Decide qué significa «suprimir» en tu stack. Borrar filas a menudo rompe la integridad financiera y analítica, así que muchos sistemas anonimizan de forma irreversible: eliminan todos los campos identificativos y conservan la carcasa vacía. Eso es defendible según el artículo 17 siempre que el resultado no pueda volver a vincularse y puedas explicarlo.
5. Sigue los datos hasta los índices y las copias de seguridad. Los índices vectoriales, las cachés, una exportación en la carpeta de descargas de alguien y las copias de seguridad cifradas sobreviven a la fila. Las copias de seguridad normalmente se dejan para que la rotación las sobrescriba; dilo, e indica el plazo.
6. Registra la solicitud, la verificación, el alcance y la fecha de finalización. Un año después, esa es tu única prueba.

De ahí salen dos preguntas para el proveedor. ¿Puedes exportar y suprimir a una persona tú mismo, o cada solicitud se convierte en un ticket con el proveedor? ¿Y hay contenido de clientes incrustado en algún sitio al que no llega la supresión? Nuestra vía para particulares está en la página de supresión de datos, y los administradores del espacio de trabajo pueden exportar y suprimir a un único cliente desde los ajustes de cumplimiento sin pedírnoslo.

7. ¿Necesita un chatbot de soporte una EIPD?

Normalmente no, por sí solo. Una evaluación de impacto es obligatoria cuando es probable que el tratamiento entrañe un alto riesgo para los derechos y libertades de las personas: observación sistemática a gran escala, categorías especiales de datos a gran escala, decisiones automatizadas con efectos jurídicos o igualmente significativos. Un chatbot que responde preguntas documentadas y traspasa a una persona no suele superar ese umbral, y un breve análisis previo documentado es el resultado adecuado. Eso cambia a medida que añades cosas: puntuaciones que enrutan a las personas de forma distinta, datos de salud o financieros que llegan de forma habitual, un asistente que decide derechos en lugar de describirlos, grabación de llamadas. Consulta la lista obligatoria de tu propia autoridad de control antes de concluir que quedas fuera: esas listas son nacionales y no son idénticas.

El correo que puedes enviar a un proveedor

Todo lo anterior se resume en ocho preguntas. Envíalas antes de una prueba y no después de que se atasque el proceso de compra: las respuestas suelen llegar rápido, y la lentitud también es un dato.

• ¿Dónde está el almacenamiento principal de datos, y qué tratamiento sale del EEE y con qué mecanismo de transferencia?
• ¿Qué subencargados tratan hoy los datos personales de nuestros clientes, y con cuánto preaviso nos enteramos de que esa lista cambia?
• ¿Se usa alguna vez nuestro contenido de soporte para entrenar modelos generales, y eso es contractual o un ajuste?
• ¿Qué plazos de conservación podemos configurar por tipo de dato, y la caducidad es automática?
• ¿Cómo verifica el asistente a un cliente antes de revelar datos de pedidos o de la cuenta?
• ¿Podemos exportar y suprimir nosotros mismos todo lo relativo a una persona, en todos los canales, y qué deja tras de sí la supresión?
• ¿Cuál es vuestro objetivo de notificación de brechas, y quién es el contacto con nombre?
• ¿Qué certificaciones y auditorías tenéis hoy, y qué está en la hoja de ruta?