Un Moodle almacena, para cada alumno, mucho más que un nombre y un correo: calificaciones, historial de actividad, comunicaciones con tutores, y en formación bonificada, datos que además hay que conservar durante años por obligación normativa. Todo eso son datos personales sujetos al RGPD y a la LOPD, con obligaciones concretas que van más allá de tener “una casilla de aceptar cookies”.
En esta guía vas a ver qué exige realmente la normativa de protección de datos a una plataforma Moodle, y qué herramientas trae ya integradas para cumplirlo, muchas veces sin configurar.
Qué datos personales gestiona realmente un Moodle
- Datos identificativos: nombre, DNI, correo, en algunos casos número de afiliación a la Seguridad Social (formación bonificada).
- Datos de actividad: tiempos de conexión, progreso, calificaciones, resultados de evaluación.
- Comunicaciones: mensajes de foro, mensajería interna, sesiones de videoconferencia grabadas.
- Datos técnicos: dirección IP de acceso, dispositivo y navegador usado, en los logs del sistema.
Todo este conjunto está sujeto a las mismas obligaciones de protección de datos que cualquier otro sistema que gestione información personal, sin excepciones por tratarse de un entorno educativo.
Principios clave del RGPD aplicados a Moodle
Minimización de datos
Solo se debe recoger la información estrictamente necesaria para la finalidad del curso. Campos de perfil de usuario opcionales que no aportan valor real a la formación deberían revisarse y, si no son necesarios, desactivarse.
Base legal y consentimiento
El tratamiento de datos de los alumnos necesita una base legal clara, en formación bonificada, suele derivarse de la relación laboral y la normativa de formación profesional, pero cualquier tratamiento adicional (por ejemplo, comunicaciones comerciales) necesita su propio consentimiento explícito, independiente del necesario para impartir el curso.
Derecho de acceso, rectificación y supresión
Los alumnos tienen derecho a solicitar qué datos se tienen sobre ellos, corregir información incorrecta, y solicitar su eliminación cuando no exista una obligación legal de conservarla (como el periodo de retención documental de FUNDAE, que prevalece mientras esté vigente).
Limitación del plazo de conservación
Los datos no deben conservarse indefinidamente “por si acaso”. En formación bonificada, el plazo de conservación viene marcado por la obligación de 4 años que exige FUNDAE; fuera de ese contexto, cada centro debe definir y documentar sus propios plazos de retención razonables.
Seguridad y confidencialidad
El RGPD obliga a proteger los datos con medidas técnicas proporcionadas: cifrado en tránsito (HTTPS), control de accesos por roles, copias de seguridad y registro de actividad. Esto conecta directamente con la configuración de seguridad de la plataforma; lo tratamos aparte en el checklist de hardening de Moodle.
La API de Privacidad: cómo sabe Moodle qué datos tiene
Antes de tocar ninguna pantalla conviene entender la pieza que sostiene todo el subsistema. Desde Moodle 3.5, el núcleo incluye la API de Privacidad: cada plugin instalado (fórum, cuestionario, tarea, un plugin de videoconferencia de terceros, etc.) está obligado a declarar qué datos personales almacena, dónde y con qué finalidad. Esa declaración se hace en el código del propio plugin mediante un “proveedor de privacidad”.
La consecuencia práctica es importante: cuando un alumno pide “todos mis datos”, Moodle no busca a ciegas en la base de datos, sino que recorre esas declaraciones plugin a plugin y compone el resultado. Por eso un plugin mal programado o muy antiguo puede quedar fuera de una exportación o de un borrado sin avisar. El menú Site administration > Development > Privacy > Plugin privacy registry lista qué plugins declaran datos y cuáles aparecen como “no implementado”: ese es el primer sitio donde mirar si sospechas que un módulo se escapa del subsistema.
Herramientas nativas de Moodle para cumplir el RGPD
Todo el bloque vive bajo Site administration > Users > Privacy and policies. No es una única casilla: son cuatro herramientas que resuelven obligaciones distintas y que casi nunca vienen activadas de fábrica.
Registro de políticas y consentimiento
En Privacy settings, cambia el manejador de política del sitio a la herramienta de políticas (tool_policy) para activar el gestor completo. A partir de ahí, en Manage policies puedes crear varios documentos (política del sitio, política de privacidad, política de terceros, política propia) cada uno con su público (todos, usuarios autenticados, invitados) y, sobre todo, con versionado. Cuando publicas una versión nueva de la política de privacidad, Moodle obliga a cada usuario a volver a aceptarla en su siguiente acceso, y registra la aceptación con fecha y versión. Eso es lo que convierte “el usuario aceptó” en una evidencia auditable, no en una afirmación.
El gestor contempla también a menores: si el sitio marca que hay usuarios menores de edad, el consentimiento lo otorga el padre, madre o tutor, y queda registrado como tal. Un aviso de cookies suelto no cubre nada de esto.
Solicitudes de datos (acceso y supresión)
En Data requests se centralizan las peticiones del interesado. Hay dos tipos: exportar todos los datos de un usuario o eliminarlos. El propio alumno puede abrir la solicitud desde su perfil, o un administrador hacerlo en su nombre. Cada solicitud pasa por un flujo de aprobación: la revisa el Delegado de Protección de Datos (Data Protection Officer), un rol que se asigna en Privacy settings y que por defecto recae en los administradores del sitio. El gotcha habitual: si nadie tiene el rol de DPO asignado o el correo de contacto está vacío, las solicitudes se quedan encoladas sin que nadie las vea.
Registro de datos y plazos de retención
El Data registry es la pieza que casi todo el mundo ignora. Aquí defines dos cosas: categorías de datos (qué tipo de información) y finalidades (purposes), y a cada finalidad le asignas una base legal y un plazo de retención. Después aplicas esas finalidades por nivel de contexto siguiendo la jerarquía de Moodle: sistema → categoría de curso → curso → módulo de actividad → usuario. Un curso de formación bonificada puede llevar una finalidad con retención de 4 años, mientras que un curso interno sin obligación legal lleva una retención mucho más corta.
Borrado de contextos caducados
Definir la retención no borra nada por sí solo. Cuando vence el plazo de una finalidad, ese contexto pasa a estado caducado (expired context) y aparece como candidato a eliminación. La limpieza real la ejecuta una tarea programada del cron (“Delete expired contexts”). Si el cron de Moodle no corre (error clásico en instalaciones descuidadas) los plazos de retención quedan sobre el papel pero los datos siguen ahí indefinidamente. Conviene revisar en Site administration > Server > Scheduled tasks que esa tarea esté activa y ejecutándose.
Los derechos del interesado y cómo se ejercen en Moodle
El RGPD reconoce una serie de derechos al titular de los datos. Esta es la correspondencia práctica con lo que ofrece la plataforma:
| Derecho | Base RGPD | Cómo se ejerce en Moodle |
|---|---|---|
| Acceso | Art. 15 | Solicitud de exportación en Data requests; Moodle compone un archivo con todos sus datos por área |
| Rectificación | Art. 16 | El propio usuario edita su perfil; los datos de actividad los corrige el administrador en el módulo correspondiente |
| Supresión (“derecho al olvido”) | Art. 17 | Solicitud de borrado en Data requests, condicionada a que no exista obligación legal de conservar (FUNDAE) |
| Portabilidad | Art. 20 | La exportación entrega los datos en formato legible y estructurado, reutilizable en otro sistema |
| Limitación y oposición | Art. 18 y 21 | Suspensión de la cuenta y retirada del consentimiento en las políticas no obligatorias |
El derecho al que hay que prestar más atención es el de supresión, porque es donde choca con la conservación documental de la formación bonificada (lo vemos más abajo).
El encargado del tratamiento: quién aloja tu Moodle
Un punto que se olvida a menudo: si tu Moodle está en un hosting externo, ese proveedor es encargado del tratamiento de los datos de tus alumnos. El RGPD exige un contrato de encargo de tratamiento por escrito (artículo 28) que fije qué hace el proveedor con esos datos, dónde están alojados (relevante si el servidor está fuera de la UE), qué medidas de seguridad aplica y qué pasa al terminar el servicio. Alojar un Moodle con datos de alumnos en un proveedor sin ese contrato firmado es un incumplimiento en sí mismo, por muy bien configuradas que estén las herramientas nativas. Es una de las primeras cosas que revisamos cuando entra un Moodle a mantenimiento.
Cookies y aviso legal
Las herramientas de privacidad de Moodle cubren los datos dentro de la plataforma, pero no eximen de las dos capas informativas de la propia web: el aviso legal / política de privacidad accesible desde el pie de página, y el consentimiento de cookies. Moodle instala cookies técnicas propias (la de sesión MoodleSession y la de idioma), que son de funcionamiento y no requieren consentimiento; el consentimiento entra en juego cuando añades analítica, píxeles o vídeos incrustados de terceros. El error frecuente es copiar un banner de cookies genérico que no refleja lo que la plataforma realmente instala. La política de privacidad publicada como documento en el gestor de políticas debe ser coherente con lo que declara ese aviso.
Errores comunes en el cumplimiento del RGPD en Moodle
- No haber activado ni revisado nunca las herramientas de privacidad nativas, dejando esta responsabilidad sin gestionar formalmente.
- Recoger campos de perfil innecesarios por defecto, sin revisar si realmente son necesarios para el curso.
- No tener un plazo de retención definido, conservando datos indefinidamente sin justificación documentada.
- No informar con claridad a los alumnos sobre qué datos se recogen y con qué finalidad, más allá de un aviso genérico de cookies.
- Purgar datos antes de cumplir el plazo de conservación exigido en formación bonificada, entrando en conflicto con la obligación de conservar evidencia documental de FUNDAE durante 4 años.
El equilibrio entre RGPD y las obligaciones de FUNDAE
Aquí aparece una tensión que conviene resolver con claridad: el RGPD exige no conservar datos más tiempo del necesario, mientras que FUNDAE exige conservar la documentación de formación bonificada durante un mínimo de 4 años. La solución no es un conflicto real, sino una cuestión de base legal: la obligación normativa de FUNDAE es, en sí misma, la justificación legal para conservar esos datos durante ese periodo específico, sin que esto contradiga los principios del RGPD, siempre que, pasado ese plazo, los datos se eliminen o se anonimicen si ya no hay ninguna obligación legal que justifique seguir conservándolos.
En la práctica, esto se traduce directamente en cómo configuras el Data registry: creas una finalidad “Formación bonificada” con base legal “obligación legal” y retención de 4 años, y la aplicas al contexto de esos cursos. Así el sistema no marcará esos datos como caducados antes de tiempo, y cuando el plazo venza los tratará como candidatos a borrado de forma automática. Si además necesitas que la trazabilidad de la actividad del alumno aguante una inspección durante ese periodo, revisa Moodle y FUNDAE, donde detallamos qué evidencia hay que conservar y por qué.
Preguntas frecuentes
¿Un Moodle de un centro educativo pequeño también está sujeto al RGPD? Sí, el tamaño del centro no exime del cumplimiento; cualquier tratamiento de datos personales de alumnos está sujeto a las mismas obligaciones.
¿Necesito el consentimiento explícito de cada alumno para usar Moodle? Depende de la base legal aplicable: en formación bonificada, suele derivarse de la relación contractual o laboral, pero cualquier tratamiento adicional no imprescindible sí puede requerir consentimiento explícito independiente.
¿Moodle tiene herramientas propias para gestionar solicitudes de acceso o eliminación de datos? Sí, bajo Site administration > Users > Privacy and policies, Moodle incluye un panel específico para gestionar este tipo de solicitudes de forma formal.
¿Puedo eliminar los datos de un alumno de formación bonificada antes de los 4 años exigidos por FUNDAE? No, mientras esté vigente la obligación de conservación documental de FUNDAE, esta prevalece sobre una solicitud de eliminación anticipada por parte del alumno.
¿Qué pasa si nunca he configurado las herramientas de privacidad de Moodle? Es un punto de riesgo de cumplimiento normativo que conviene resolver cuanto antes, ya que estas herramientas cubren buena parte de las obligaciones básicas de RGPD de forma nativa, sin necesidad de desarrollo adicional.
¿Los logs de conexión también son datos personales sujetos al RGPD? Sí, cualquier dato que permita identificar o vincular actividad a una persona concreta, incluidas direcciones IP y tiempos de conexión, está sujeto a las mismas obligaciones de protección de datos.
¿Necesito un registro de actividades de tratamiento para mi Moodle? Sí, es una obligación general del RGPD para muchos responsables de tratamiento, y los informes de contexto de datos nativos de Moodle facilitan construir esa documentación por área del sitio.
¿Quién es el responsable y quién el encargado del tratamiento? El centro o empresa que decide para qué se usan los datos de los alumnos es el responsable; el proveedor que aloja la plataforma es el encargado. El RGPD exige un contrato de encargo de tratamiento por escrito entre ambos, incluso si el proveedor es un hosting compartido.
¿Un plugin de terceros que instalé puede dejar datos fuera de una exportación o un borrado? Sí. Solo los datos que un plugin declara a través de la API de Privacidad entran en las solicitudes de datos. Un plugin antiguo o mal mantenido que no implemente esa declaración puede almacenar datos personales que Moodle no exportará ni borrará. Puedes comprobar el estado de cada plugin en el registro de privacidad de plugins.
¿Basta con activar el banner de cookies para cumplir el RGPD en Moodle? No, ni de lejos. El banner de cookies cubre una parte mínima. Las obligaciones de fondo, base legal, consentimiento de políticas versionado, derechos del interesado, plazos de retención, contrato con el encargado, se gestionan en el subsistema de privacidad de la plataforma y en la documentación legal, no en un aviso de cookies.
¿Se borran solos los datos cuando vence el plazo de retención? Solo si el cron de Moodle está corriendo y la tarea “Delete expired contexts” está activa. El plazo por sí mismo marca los datos como caducados, pero la eliminación efectiva la ejecuta una tarea programada. Sin cron, los datos permanecen indefinidamente pese a estar configurada la retención.
Conclusión
El RGPD y la LOPD no son un trámite legal ajeno a la configuración técnica de Moodle, la propia plataforma incluye herramientas pensadas específicamente para cumplir buena parte de estas obligaciones, aunque en la práctica rara vez se activan y revisan con la atención que merecen. La clave está en tratar la privacidad como una configuración activa, no como un documento firmado una vez y olvidado.
Si prefieres que alguien revise y configure esto por ti, en Avantys lo incluimos en la auditoría de cumplimiento de cada Moodle que gestionamos. Puedes pedirla gratis en Moodle Gestionado.
Artículos relacionados
- Mantenimiento y hosting Moodle: guía completa
- Trazabilidad en Moodle para formación bonificada
- Roles y permisos en Moodle: evitar accesos indebidos
- Checklist de hardening de Moodle
¿Y si tu Moodle lo lleváramos nosotros?
Actualizaciones, backups verificados, rendimiento y trazabilidad FUNDAE, gestionado de forma continua por una persona que responde. Auditoría gratuita de tu plataforma actual.
