RGPD y consentimiento de cookies en una web Drupal

Hay un patrón que se repite cada vez que audito una web Drupal: el banner de cookies está perfecto sobre el papel, con su botón de aceptar y su texto bien redactado, pero Google Analytics, el píxel de Meta y un par de vídeos embebidos ya han disparado peticiones antes de que el usuario toque nada. El banner, en ese escenario, es decoración. Y la AEPD lleva años dejando claro que la decoración no cumple.

Vamos a poner orden en esto desde la doble perspectiva que exige el problema: la legal y la técnica. Porque en Drupal el cumplimiento del RGPD y las cookies no se resuelve instalando un módulo y dándole a guardar, sino entendiendo qué se carga, cuándo se carga y con qué permiso se carga.

El marco normativo que aplica en España

Lo primero es desmontar una confusión habitual. El consentimiento de cookies no se rige solo por el Reglamento General de Protección de Datos (RGPD, Reglamento UE 2016/679). La norma que regula específicamente el uso de dispositivos de almacenamiento en el equipo del usuario es el artículo 22.2 de la LSSI-CE (Ley 34/2002 de Servicios de la Sociedad de la Información y de Comercio Electrónico), que transpone la Directiva ePrivacy.

La articulación práctica es esta:

• La LSSI-CE dice cuándo necesitas consentimiento para instalar cookies y exenciones aplicables.
• El RGPD define qué requisitos debe cumplir ese consentimiento: libre, específico, informado e inequívoco, mediante una acción afirmativa.
• La Guía sobre el uso de las cookies de la AEPD, en su versión actualizada de 2023, traduce todo lo anterior a criterios operativos que los inspectores aplican de verdad.

Esa Guía de 2023 es el documento de referencia para cualquiera que monte una web orientada al público español. No es texto orientativo amable: cuando llega una reclamación, es la vara de medir.

Qué exige un banner de cookies que de verdad cumple

Un banner conforme no es una cuestión estética. Tiene que cumplir, a la vez, una lista de condiciones que conviene tener clavadas en la pared:

1. Informar antes de instalar nada. El usuario debe saber qué cookies hay, sus finalidades y quién las gestiona antes de que se instale ninguna cookie no exenta.
2. Granularidad por finalidades. No vale un sí o no global. El usuario tiene que poder aceptar la analítica y rechazar el marketing, por ejemplo. Cada finalidad, su interruptor.
3. Rechazar tan fácil como aceptar. Este es el criterio estrella de la AEPD desde 2023. Si tienes un botón "Aceptar todo" en primera capa, debes tener un "Rechazar todo" igual de visible y al mismo nivel. Nada de esconder el rechazo tras tres clics o detrás de un enlace gris diminuto.
4. Sin casillas premarcadas. El consentimiento por defecto es no consentimiento. Los conmutadores de finalidades no esenciales arrancan desactivados.
5. Nada de "cookie walls" sin alternativa. Negar el acceso al contenido a quien rechaza cookies solo es admisible si existe una alternativa real y equitativa de acceso (por ejemplo, una versión de pago sin tracking). Bloquear la web a secas no es consentimiento libre.
6. Permitir retirar el consentimiento. Tan fácil como se dio. Lo habitual es un enlace permanente en el pie o un icono flotante que reabre el panel de preferencias.

Si tu banner falla en cualquiera de estos puntos, el resto del montaje técnico da igual.

Cookies exentas y cookies no exentas

No todas las cookies requieren consentimiento, y aquí muchos sobreactúan pidiendo permiso para cosas que no lo necesitan. La LSSI-CE exime las cookies "técnicas o necesarias" estrictamente para prestar el servicio solicitado por el usuario.

Quedan exentas (no necesitan consentimiento previo):

• Cookies de sesión y autenticación de Drupal (SESS, SSESS).
• Carrito de la compra en un Drupal Commerce.
• Equilibrado de carga, balanceo o seguridad estrictamente funcional.
• En la práctica, y con matices, las de personalización de interfaz que el propio usuario solicita.

No exentas (consentimiento previo obligatorio):

• Analítica, incluida Google Analytics 4, aunque la trates como "anónima".
• Publicidad y remarketing: píxel de Meta, Google Ads, LinkedIn.
• Cookies de redes sociales y botones de compartir.
• Contenido embebido de terceros: YouTube, Vimeo, mapas, widgets.

El caso de la analítica es el que más discusiones genera. La AEPD admite una flexibilización para analítica propia y de bajo impacto, pero GA4 envía datos a Google, así que el criterio prudente en España es tratarla como no exenta y bloquearla hasta el consentimiento.

El punto donde fallan casi todas las webs: el bloqueo previo

Aquí está el meollo técnico y la causa número uno de incumplimientos reales. La normativa no pide que muestres un banner; pide que no instales cookies no exentas hasta que el usuario consienta. Son cosas distintas.

En Drupal, los scripts de terceros suelen entrar por varias vías y todas hay que controlarlas:

• Snippets pegados en bloques HTML o en la configuración del tema.
• Módulos como Google Tag Manager o el integrador de GA4 que imprimen su <script> en hook_page_attachments.
• Vídeos de YouTube embebidos directamente en campos de texto con formato completo.
• Etiquetas inyectadas vía Google Tag Manager, que es una caja negra donde puede dispararse casi cualquier cosa.

El bloqueo previo consiste en impedir que esos scripts se ejecuten hasta tener el consentimiento de su categoría. La técnica estándar es no servir el <script src> activo, sino marcarlo con un tipo neutralizado (por ejemplo type="text/plain") y un atributo de categoría, de modo que el gestor de consentimiento solo lo "active" cuando corresponda. Si tu implementación se limita a tapar visualmente la pantalla con un banner mientras las peticiones ya salen, no estás cumpliendo, por muy bonito que sea el aviso.

Un consejo de campo: después de configurar todo, abre la pestaña de red del navegador en una sesión limpia y mira qué peticiones salen antes de tocar el banner. Si ves google-analytics.com, connect.facebook.net o youtube.com ahí, tienes trabajo pendiente.

Módulos de Drupal para implementarlo

Drupal no trae gestión de consentimiento en el núcleo, así que la elección de módulo condiciona cuánto sufres. Estas son las opciones que de verdad uso.

EU Cookie Compliance

El veterano del ecosistema. Muy configurable, con soporte para categorías, segunda capa de detalle y multilingüe nativo, lo que viene de perlas para webs en castellano y otras lenguas del Estado.

• A favor: maduro, traducido, integrado con el sistema de bloques y permisos de Drupal, control fino de textos.
• En contra: el bloqueo previo de scripts no es automático ni cómodo. Requiere configurar manualmente qué scripts pertenecen a cada categoría, y es fácil dejar agujeros. Su UX por defecto puede quedarse corta frente al criterio de "rechazar tan fácil como aceptar" si no la ajustas.

Klaro!

La opción más sólida hoy en términos técnicos para el bloqueo previo. Klaro está construido precisamente alrededor de la idea de gestionar y bloquear servicios de terceros, y el módulo de Drupal expone esa configuración como "apps" o servicios.

• A favor: bloqueo previo real y bien pensado, gestión por servicio, panel de preferencias claro, encaja con el criterio AEPD de granularidad.
• En contra: curva de configuración más exigente, hay que mapear cada servicio con cuidado y revisar que el styling case con tu tema.

Integración con CMP externas (Cookiebot, Complianz)

Para proyectos grandes o con departamento legal exigente, conectar Drupal con una Consent Management Platform como Cookiebot tiene sentido.

• A favor: escaneo automático de cookies, registro de consentimiento gestionado por el proveedor, actualizaciones de cumplimiento mantenidas por terceros, informes listos para auditoría.
• En contra: coste recurrente, dependencia de un tercero que a su vez carga su propio script, y hay que verificar que su modo de bloqueo previo esté bien activado (algunos arrancan en modo solo-aviso por defecto).

Mi recomendación general: para la mayoría de proyectos en español, Klaro! si quieres control técnico y bloqueo previo serio; EU Cookie Compliance si priorizas el multilingüe y vas a dedicar tiempo a mapear scripts; una CMP externa cuando el cliente necesita reportes formales y prefiere externalizar el mantenimiento normativo.

Registrar y documentar el consentimiento

El RGPD funciona bajo el principio de responsabilidad proactiva: no basta con cumplir, hay que poder demostrarlo. Si un usuario reclama, tienes que enseñar prueba de su consentimiento.

Una prueba de consentimiento útil registra, como mínimo:

• Marca temporal del consentimiento.
• Finalidades aceptadas y rechazadas.
• Versión del banner y de la política de cookies vigente en ese momento.
• Identificador anonimizado o referencia que permita vincular el registro sin guardar de más.

EU Cookie Compliance puede guardar registros de consentimiento, las CMP externas lo hacen de serie, y con Klaro suele hacer falta apoyarse en un registro propio. Cuidado con un matiz fino: el propio sistema de prueba de consentimiento no debería convertirse en un tratamiento desproporcionado de datos. Guarda lo justo para demostrar el consentimiento, no un perfil del usuario.

Minimización en formularios: el frente olvidado

Las cookies se llevan toda la atención, pero el RGPD aplica a todo tratamiento de datos personales, y en Drupal eso significa los formularios. Webform es la herramienta estándar, y ahí hay que aplicar el principio de minimización del artículo 5.1.c del RGPD: pide solo los datos que necesitas para la finalidad concreta.

En la práctica, para cada formulario Webform conviene:

• Eliminar campos "por si acaso". Si no necesitas el teléfono para responder un email, no lo pidas.
• Definir y mostrar la base jurídica del tratamiento. En un formulario de contacto suele ser interés legítimo o ejecución de medidas precontractuales; en una suscripción a newsletter es consentimiento, y ahí sí hace falta una casilla específica, sin premarcar, con enlace a la política de privacidad.
• Separar consentimientos: un check para "responder a tu consulta" y otro distinto para "recibir comunicaciones comerciales". Empaquetarlos en una sola casilla vicia el consentimiento.
• Configurar la retención: no guardes envíos de Webform indefinidamente. Drupal permite purgar envíos antiguos de forma programada.

Política de privacidad, de cookies e información en capas

La AEPD impulsa el modelo de información por capas, y encaja muy bien con Drupal:

• Primera capa: el propio banner. Información esencial y resumida, con los botones de aceptar, rechazar y configurar.
• Segunda capa: el panel de preferencias detallado, con la lista de finalidades y servicios.
• Capa completa: la página de política de cookies, con el inventario detallado (nombre, titular, finalidad, duración) y la política de privacidad, donde detallas responsable del tratamiento, bases jurídicas, plazos de conservación, destinatarios y derechos.

En Drupal estas páginas se montan como nodos o páginas básicas, y el enlace a la política de cookies debe estar accesible siempre, también desde el propio banner.

Derechos de los usuarios y la figura del DPO

La política de privacidad tiene que explicar cómo ejercer los derechos ARSOPL: acceso, rectificación, supresión, oposición, portabilidad y limitación del tratamiento. En una web Drupal con cuentas de usuario, conviene además ofrecer mecanismos prácticos: exportación de datos del perfil y un procedimiento claro de baja y borrado de cuenta que arrastre los datos asociados.

Sobre el Delegado de Protección de Datos (DPO): no toda web lo necesita. Es obligatorio cuando hay tratamiento a gran escala de categorías especiales de datos, observación sistemática a gran escala o ciertos organismos públicos. Una pyme con un formulario de contacto normalmente no está obligada, pero si lo tienes designado, sus datos de contacto deben figurar en la política de privacidad.

Pasos concretos de configuración en Drupal

Para aterrizar todo lo anterior, este es el orden de trabajo que sigo:

1. Inventaría las cookies y scripts reales del sitio. Recorre tema, bloques HTML, módulos de analítica/marketing y campos con embebidos. Lo que no conoces no lo puedes bloquear.
2. Clasifica cada cookie como exenta o no exenta y asígnale una finalidad.
3. Instala y configura el módulo de consentimiento (Klaro o EU Cookie Compliance) con categorías que reflejen tus finalidades reales.
4. Activa el bloqueo previo de cada script no exento y verifica con la pestaña de red que nada no exento se dispara antes del consentimiento.
5. Ajusta el banner para cumplir el criterio de simetría: aceptar y rechazar al mismo nivel, sin casillas premarcadas, con enlace permanente para revocar.
6. Activa el registro de consentimiento y comprueba qué datos guarda.
7. Revisa los Webform: minimiza campos, define bases jurídicas, separa consentimientos y configura la retención.
8. Publica las páginas de política de cookies y de privacidad, y enlázalas desde el banner y el pie.
9. Reaudita tras cada cambio importante: un módulo nuevo o un script de campaña pueden romper el cumplimiento sin avisar.

Cómo dejar tu Drupal en regla

El cumplimiento del RGPD y las cookies en Drupal vive en los detalles: el script que se cuela antes de tiempo, el botón de rechazar que cuesta encontrar, el Webform que pide de más. Son fáciles de pasar por alto y caros de ignorar cuando llega una reclamación. Si quieres que alguien revise tu instalación con ojo técnico y criterio AEPD actualizado, contacta con nuestro equipo Drupal y lo dejamos cerrado de principio a fin.