Lo que el RGPD exige realmente a una plataforma e-learning

El RGPD suele reducirse a un banner de cookies y un enlace a la política de privacidad. Para una plataforma de aprendizaje, esos son solo los bordes visibles de una obligación mucho mayor. El trabajo real está en qué datos se recogen, quién puede verlos, qué proveedores los reciben, cuánto tiempo permanecen y si la plataforma puede responder de verdad a una solicitud de acceso o borrado.

Este artículo explica qué cambia el RGPD en un producto e-learning: la relación entre responsable y encargado, la analítica, la IA, el alojamiento internacional y los derechos del alumno. Es una guía práctica, no asesoramiento jurídico. Confirma la base legal y las normas nacionales aplicables a tu organización.

Cuándo se aplica el RGPD a una plataforma de aprendizaje

El RGPD se aplica cuando una organización trata datos personales de personas del Espacio Económico Europeo. También puede alcanzar a una empresa de fuera de Europa cuando ofrece allí bienes o servicios o supervisa su comportamiento.

En una plataforma, los datos personales van mucho más allá del nombre y el correo. Matrículas, intentos de cuestionario, notas, respuestas, asistencia, mensajes de soporte, direcciones IP, identificadores de dispositivos, registros de actividad, necesidades de accesibilidad y comentarios de responsables pueden identificar o describir a alguien. Incluso los datos seudonimizados siguen siendo personales si pueden volver a conectarse con la persona.

La prueba no es dónde está constituida la empresa. Pregunta si la plataforma conserva datos sobre alumnos, docentes o empleados del EEE y por qué necesita cada campo. Si lo hace, el RGPD pertenece a la arquitectura y al contrato.

Responsable y encargado: quién toma las decisiones

La distinción contractual esencial separa al responsable del tratamiento, que decide por qué y cómo se tratan los datos, del encargado, que actúa siguiendo sus instrucciones.

En un LMS corporativo o universitario, el cliente suele ser responsable. Decide quién debe formarse, qué resultados importan y cuánto conservarlos. El proveedor suele ser encargado. La relación necesita un acuerdo del artículo 28 que defina objeto, duración, finalidad, tipos de datos, seguridad, eliminación, auditorías y subencargados.

«Suele» es importante. Un proveedor puede convertirse en responsable para sus propios fines. Si utiliza la actividad del alumno para publicidad, perfiles ajenos a la formación o el entrenamiento de un modelo general, ya no se limita a seguir instrucciones. Un contrato no puede llamarlo encargado si el producto se comporta como responsable.

Por eso la pregunta debe responderse función por función.

El consentimiento no es la respuesta predeterminada

Cada tratamiento necesita una base jurídica. El Comité Europeo de Protección de Datos enumera seis: consentimiento, contrato, obligación legal, intereses vitales, interés público e interés legítimo.

Los productos educativos recurren a menudo al consentimiento porque parece lo más seguro. No siempre lo es. Debe darse libremente y poder retirarse. Un empleado obligado a completar formación normativa o un estudiante que necesita la plataforma para cursar una asignatura quizá no tenga una elección real. Según el contexto y la legislación nacional, puede corresponder una obligación legal, una misión pública, un contrato u otra base válida.

La plataforma debe asociar finalidad y base a cada tratamiento importante, en lugar de usar una gran casilla de «acepto». Impartir un curso, registrar seguridad, hacer analítica opcional, marketing y entrenar IA son finalidades distintas.

Es la limitación de la finalidad convertida en producto. Los principios de la Comisión Europea exigen fines específicos, minimización, conservación limitada, exactitud, seguridad y responsabilidad.

Los derechos deben convertirse en funciones reales

Una plataforma que no puede localizar, exportar, corregir, limitar o borrar los datos de un alumno convierte cada solicitud en un proyecto manual de base de datos.

Dos detalles causan más problemas. Primero, la identidad debe ser coherente. Si un alumno existe con tres correos en el LMS, el vídeo, la analítica y soporte, una solicitud dejará datos atrás. Segundo, borrar es un flujo, no una consulta SQL. Copias de seguridad, certificados, informes, eventos y herramientas externas necesitan reglas expresas.

La minimización facilita todos los derechos. Lo que nunca recogiste no tendrás que protegerlo, explicarlo, exportarlo ni borrarlo.

Subencargados y transferencias internacionales

La mayoría de plataformas son una cadena de proveedores: alojamiento, correo, vídeo, analítica, errores, soporte, autenticación e IA. Cada servicio que recibe datos forma parte del mapa.

Un encargado necesita autorización escrita previa para nombrar subencargados. Una plataforma seria mantiene una lista actual, explica qué hace cada proveedor y dónde trata los datos, y avisa antes de añadir uno.

Transferir datos fuera del EEE requiere un mecanismo válido. Puede existir una decisión de adecuación. Si no, es habitual utilizar las cláusulas contractuales tipo de la Comisión Europea con la evaluación y garantías necesarias. Elegir un centro de datos europeo no resuelve nada si soporte, logs, copias o una API de IA siguen moviendo información.

La pregunta útil no es «¿están los servidores en Europa?», sino «muéstrame todos los países donde se puede almacenar o consultar la información, incluidos subencargados y soporte».

Analítica, IA y cuándo hace falta una EIPD

Un informe de finalización no tiene el mismo riesgo que perfilar a una persona, predecir su fracaso o cambiar automáticamente sus oportunidades. El RGPD se basa en el riesgo.

Una evaluación de impacto relativa a la protección de datos (EIPD) es obligatoria cuando el tratamiento puede crear un riesgo alto. La Comisión Europea señala la evaluación sistemática o elaboración de perfiles y el tratamiento a gran escala de datos sensibles. Debe hacerse antes y mantenerse viva.

Señales de alerta para un LMS:

• puntuar o clasificar mediante modelos opacos;
• predecir quién suspenderá, abandonará o recibirá una oportunidad;
• analizar comportamiento más allá de lo razonablemente esperado;
• tratar salud, discapacidad, biometría u otras categorías especiales;
• supervisar niños o empleados a escala;
• enviar trabajos a un modelo de IA externo.

La EIPD no legaliza automáticamente una función arriesgada. Obliga a describir finalidad, necesidad, flujo, riesgos y mitigaciones antes de lanzar. El resultado puede ser reducirla, mantener a una persona responsable o no construirla. Es la misma línea de lo que realmente ayuda de la IA en un LMS.

Lista práctica de construcción

Antes de comprar o lanzar, debes poder responder:

• ¿Qué datos conservamos y por qué necesitamos cada campo?
• ¿Quién es responsable y encargado para cada uso?
• ¿Qué base jurídica sostiene cada finalidad?
• ¿Podemos exportar, corregir, limitar y borrar los datos de una persona de extremo a extremo?
• ¿Qué subencargados reciben datos, en qué países y con qué mecanismo?
• ¿Qué plazos rigen cuentas, entregas, registros, informes y copias?
• ¿Qué roles ven notas, mensajes, comentarios o información de accesibilidad?
• ¿El perfilado, la IA, la vigilancia o los datos sensibles exigen una EIPD?
• ¿Podemos investigar una brecha y avisar rápidamente al responsable?

La última importa porque el responsable puede tener que avisar a la autoridad en 72 horas desde que conoce una brecha con riesgo. Un encargado que espera varios días consume el plazo del cliente.

El RGPD es arquitectura de datos, no un banner

Un banner registra una preferencia. No arregla la recogida excesiva, la conservación indefinida, las exportaciones sin control ni una cadena de proveedores desconocida.

Un buen trabajo de RGPD parece ordinario: menos campos, roles claros, acceso limitado, borrado predecible, proveedores documentados y flujos explicables. Por eso encaja junto a la seguridad de los datos estudiantiles y FERPA. Las leyes cambian, pero las capacidades técnicas son las mismas.

El momento más barato para decidirlo es antes de que base de datos, analítica y contratos se endurezcan alrededor de supuestos equivocados. La privacidad desde el diseño significa construir una plataforma capaz de cumplir las promesas que la organización está a punto de firmar.