MAQ Módulo 2 — Políticas del sitio: más allá del checkbox de aceptación
Este post cierra la serie del Módulo 2 del MAQ. Puedes leer el anterior aquí: MAQ Módulo 2 — Privacidad
El último subapartado del módulo de Implementación es Políticas del sitio. Y si el de Privacidad me generó incomodidad, este me ha generado algo diferente: reconocer que durante años he tratado las políticas de sitio como un trámite y no como lo que son.
La mayoría de las instalaciones de Moodle que he visto tienen, en el mejor de los casos, una URL genérica apuntando a un PDF de política de privacidad que nadie ha leído. En el peor, el campo vacío desde la instalación inicial.
El gestor de políticas predeterminado vs tool_policy
Moodle ofrece dos formas de gestionar políticas. El gestor predeterminado del núcleo es simple: una URL para usuarios autenticados y otra para invitados. Punto. Funciona para organizaciones pequeñas o para las que genuinamente no están sujetas a normativas de protección de datos — que son pocas.
El gestor tool_policy es otra cosa. Permite crear múltiples políticas independientes, especificar si son obligatorias u opcionales, versionar los cambios, y ver exactamente quién ha aceptado qué y cuándo. Eso no es burocracia — es la única forma de demostrar cumplimiento si alguien te lo exige.
El módulo lo dice con claridad: si tienes alguna duda de si el RGPD o normativa similar te aplica, usa tool_policy. Yo lo formularía de otra forma: si tienes usuarios reales en producción, usa tool_policy.
Las políticas que debería tener cualquier instalación
El módulo establece un mínimo razonable: política general de uso del sitio, política de cookies y política de privacidad. Son el suelo, no el techo.
Lo que me parece más relevante de cara a 2026 es lo que añade como “muy recomendable”: una política de IA. Y tiene toda la razón.
Llevamos dos años con la IA generativa instalada en el flujo de trabajo de estudiantes y docentes, y la mayoría de las organizaciones educativas no tienen una posición oficial documentada sobre su uso. No digo que la IA sea un problema — digo que la ausencia de política sí lo es. Sin una política clara, no hay forma de gestionar los casos límite, y los casos límite existen y seguirán existiendo.
El caso de Parlick High y la política de IA
El módulo incluye un caso de estudio sobre un instituto inglés que detectó un aumento preocupante del uso de IA en los trabajos de los alumnos. La solución no fue solo técnica — fue organizacional: formación al profesorado, charla con un ponente externo, colaboración entre dirección y legal para redactar una política, y finalmente el administrador de Moodle la añadió como política obligatoria en tool_policy.
Lo que me llama la atención de este caso es el orden. La política no la redactó el administrador. No la impuso unilateralmente. Fue el resultado de un proceso que involucró a varias personas con diferentes perspectivas.
El administrador de Moodle fue el último eslabón, no el primero. Eso es exactamente como debería ser.
Obligatoria u opcional: una decisión con consecuencias reales
La distinción entre política obligatoria y opcional en tool_policy tiene implicaciones que no son evidentes a primera vista.
Una política obligatoria significa que el usuario no puede acceder al sitio sin aceptarla. Es la forma más fuerte de obtener consentimiento, pero también la más costosa en términos de experiencia de usuario — especialmente si hay cambios frecuentes que obligan a volver a aceptar.
Una política opcional tiene una lógica diferente: al no aceptarla, el usuario está implícitamente denegando ese permiso específico. El ejemplo del módulo es clarificador — una política de uso de imágenes en materiales promocionales como opcional significa que quien no la acepta está diciendo que no autoriza el uso de su imagen. Eso es gestión de consentimiento granular, no un checkbox genérico.
La versión menor que no obliga a re-aceptar
Un detalle técnico que me parece valioso y que poca gente conoce: cuando editas una política activa en tool_policy, puedes marcarla como “revisión menor”. Si solo corregiste una errata o actualizaste un enlace, los usuarios no tienen que volver a aceptarla.
Si los cambios son sustanciales — nueva cláusula, cambio de responsable de datos, modificación de periodos de retención — deja esa casilla sin marcar. Los usuarios tendrán que aceptar la nueva versión. Guarda registro de por qué consideraste que el cambio era sustancial. Esa documentación puede ser relevante si alguien cuestiona el proceso.
Cerrando el Módulo 2
Este subapartado cierra el módulo de Implementación del MAQ. Y mirando atrás los cuatro subapartados — Instalación, Seguridad, Privacidad y Políticas del sitio — hay un hilo conductor claro.
Ninguno de ellos trata solo de configuración técnica. Todos implican decisiones organizacionales que el administrador no debería tomar en solitario. El MAQ no te pide que sepas hacer todo — te pide que sepas qué preguntas hacer, a quién preguntárselas y cómo documentar las respuestas.
Eso, en mi experiencia, es lo que realmente separa a un administrador de Moodle de un técnico que sabe instalar Moodle.
Esta serie sobre el Módulo 2 del MAQ está completa. Puedes leer todos los posts desde el principio: MAQ Módulo 2: Implementación — primeras impresiones
