Cumplimiento del RGPD en sitios web: lo que realmente hay que construir

La mayoría de los consejos sobre RGPD que circulan están escritos para juristas o para quien va a comprar un generador de políticas. Muy poco está escrito para la persona que tiene que abrir un editor y cambiar algo.

Esta guía es del segundo tipo. Recorre lo que el Reglamento General de Protección de Datos exige a un sitio web y a los sistemas que hay detrás, expresado como cosas que se construyen, se configuran o se borran. Llevamos haciendo este trabajo para empresas que operan en la UE desde que el reglamento se aplicó en 2018, y el patrón de lo que sale mal apenas ha cambiado.

Un apunte previo: el RGPD no se volvió más fácil porque llegaran normas nuevas. Se volvió más importante, porque casi todo en la ola actual de reglas digitales europeas da por supuesto que tus datos personales ya están en orden.

Empieza con un inventario honesto de datos

Casi todos los proyectos de RGPD fallidos que hemos heredado fallaron en el mismo punto. El equipo escribió la política primero y descubrió los datos después.

Antes que nada, mapea qué datos personales recoge realmente tu sitio. No lo que dice la especificación de producto. Lo que hay en la base de datos, los registros, la plataforma de analítica, el CRM, la herramienta de soporte, la pila de automatización de marketing, el rastreador de errores, los logs del CDN y los scripts de terceros de la página.

En la práctica eso significa:

Peinar el esquema. Cada columna que pueda identificar a una persona, sola o combinada con otra.
Leer la pestaña de red en una carga real. Cada petición saliente a un dominio que no controlas es una transferencia potencial de datos personales, porque una dirección IP más un user agent son datos personales.
Revisar qué captura tu rastreador de errores. Las trazas contienen habitualmente direcciones de correo, tokens y cuerpos de petición.
Revisar la retención de logs. Registros de acceso con IP conservados indefinidamente son uno de los hallazgos más comunes y de los más fáciles de arreglar.

Anótalo como registro de actividades de tratamiento. El artículo 30 lo exige de todos modos para la mayoría de las organizaciones, y la versión útil para desarrolladores es una tabla con sistema, datos, finalidad, base jurídica, plazo de conservación y destinatarios.

Elige una base jurídica por finalidad, no por sistema

El artículo 6 ofrece seis bases jurídicas. El error más frecuente es elegir una para todo el producto.

Casi con seguridad tienes varias finalidades funcionando a la vez. Cumplir un pedido es contrato. Las comprobaciones antifraude suelen ser interés legítimo u obligación legal. Conservar facturas durante el plazo legal es obligación legal. El correo de marketing es consentimiento en la mayoría de los Estados miembros. La analítica no esencial es consentimiento, por las reglas de ePrivacy sobre el acceso a equipos terminales y no por el RGPD en sí.

La consecuencia práctica es que tu modelo de datos debe saber a qué finalidad sirve cada registro. Si no puedes separar el perfil de marketing del registro de pedido, no puedes atender una oposición de marketing sin romper el historial de pedidos. Esa separación es una decisión de esquema, y es dolorosa de adaptar después.

El consentimiento tiene que ser real y quedar registrado

Si te apoyas en el consentimiento, tiene que ser libre, específico, informado e inequívoco, y tienes que poder demostrarlo después.

En concreto:

Nada no esencial se dispara antes de que el usuario actúe. Eso incluye el script de analítica, el píxel publicitario, el widget de chat, la fuente cargada desde un CDN de terceros y el script de pruebas A/B.
Rechazar debe ser tan fácil como aceptar. Misma capa, mismo peso visual, mismo número de clics. Los reguladores tratan cualquier otra cosa como patrón oscuro, y han sido consistentes en ello.
El consentimiento es por finalidad. Un único interruptor que cubra «analítica y marketing y personalización» no es específico.
La retirada es tan fácil como la concesión. Un enlace permanente o un botón flotante, no un correo a soporte.
Guarda la prueba: marca de tiempo, la cadena de consentimiento o el estado de cada categoría, la versión del banner y el texto que se mostró al usuario. Sin la versión no puedes defender un consentimiento de hace dos años.

Aquí la ejecución no es teórica. En septiembre de 2025 la autoridad francesa multó el mismo día a Google con 325 millones de euros y a Shein con 150 millones por prácticas de cookies. Ambos casos giraron sobre mecánica y no sobre el texto de la política: cookies depositadas antes de cualquier interacción, y botones de rechazo que no rechazaban de verdad.

Las reglas también están en movimiento. La propuesta Digital Omnibus trasladaría el consentimiento sobre equipos terminales al propio RGPD y haría vinculantes las señales del navegador. Cubrimos qué cambiaría en el consentimiento de cookies tras el Digital Omnibus.

Construye pronto la maquinaria de derechos de los interesados

Los artículos 15 a 22 dan a las personas derecho de acceso, rectificación, supresión, limitación, portabilidad y oposición. Tienes un mes para responder, ampliable a tres en casos complejos.

Los equipos tienden a gestionar las primeras solicitudes a mano, lo cual funciona hasta que deja de hacerlo. Lo que conviene tener antes de que llegue el volumen:

Un resolutor que encuentre a una persona en todos los sistemas. Dada una dirección de correo, devolver todo: la cuenta, los pedidos, los tickets de soporte, el perfil de marketing, el identificador analítico, los logs. Si un humano tiene que recordar que existe una plataforma de reseñas de terceros con datos, alguien acabará olvidándolo.

Una ruta de borrado que respete las obligaciones de conservación. La supresión no es absoluta. Las facturas suelen tener que sobrevivir por motivos fiscales. Lo que necesitas es borrado lógico con borrado físico por finalidad, para eliminar el perfil de marketing manteniendo el asiento contable, y para que ese asiento caduque a su vez en plazo.

Una exportación portable. Estructurada, de uso común, legible por máquina. JSON vale. Un PDF de una página HTML renderizada no.

Un indicador de oposición que lea todo el sistema. Oponerse a la elaboración de perfiles tiene que detener realmente la elaboración de perfiles, incluido el proceso por lotes que corre a las tres de la mañana y no comprueba el indicador.

La conservación es un trabajo, no una línea de política

La limitación del plazo de conservación es el principio que más incumplen sistemas por lo demás bien construidos, porque borrar exige que alguien escriba y programe una tarea que nadie pide.

Da a cada categoría de datos una vida definida y luego impleméntala. Logs de acceso, sesiones, carritos abandonados, altas sin verificar, tickets cerrados, copias antiguas y datos analíticos en bruto necesitan una caducidad. Las copias de seguridad merecen atención especial: si tu proceso de restauración resucita datos borrados, tu supresión está incompleta, y la respuesta habitual es una rotación documentada con antigüedad máxima más una reaplicación de los borrados tras cualquier restauración.

Transferencias, subencargados y dónde corre realmente tu stack

Las transferencias fuera del EEE necesitan un mecanismo jurídico, normalmente el Marco de Privacidad de Datos UE-EE. UU. para destinatarios estadounidenses certificados, o cláusulas contractuales tipo más una evaluación de impacto de la transferencia en otros casos.

El ángulo de ingeniería es más simple que el jurídico: saber dónde están físicamente tus datos. Eso significa la región de nube de cada servicio, la ubicación de tus copias, la región de tu base gestionada, la configuración de los nodos del CDN y, sobre todo, el modelo de soporte de cada herramienta SaaS que usas. Un proveedor alojado en Fráncfort cuyo equipo de soporte accede a producción desde fuera del EEE sigue siendo una transferencia.

Recomendamos en general mantener los datos personales en regiones de la UE cuando no haya una razón sólida en contra. Elimina toda una categoría de discusión, y la diferencia de coste suele ser ruido.

Mantén una lista de subencargados y tenla al día. El artículo 28 exige un contrato escrito con cada uno, y esa lista es también lo que te pedirán tus clientes en la diligencia debida.

Seguridad por defecto, expresada como configuración

El artículo 32 pide medidas técnicas y organizativas apropiadas. Es deliberadamente vago, pero la base para un sitio web en 2026 no es negociable:

TLS en todas partes, HSTS activado, sin contenido mixto.
Contraseñas con hash mediante una función moderna intensiva en memoria, y autenticación multifactor disponible para cuentas con datos personales.
Cifrado en reposo para bases de datos y copias.
Acceso a datos personales de producción limitado por rol y registrado, con revisiones que ocurren de verdad.
Seudonimización donde sea posible: hashear el identificador en la analítica y mantener la tabla de correspondencia separada y con acceso restringido.
Una restauración probada, no solo una copia.

La protección de datos desde el diseño y por defecto del artículo 25 significa que la opción más protectora es la que obtienes sin hacer nada. Casilla de boletín sin marcar. Visibilidad de perfil privada. Campos opcionales opcionales.

La notificación de brechas necesita un manual

Setenta y dos horas desde el conocimiento hasta notificar a la autoridad de control no es mucho, sobre todo si la brecha se descubre un viernes por la tarde. Ten en cuenta que la propuesta Digital Omnibus lo llevaría a noventa y seis horas, aunque todavía no es derecho.

Prepara de antemano: quién declara un incidente, quién evalúa si hay datos personales afectados, quién contacta con el regulador, qué contiene la notificación y cómo informas a los afectados si el riesgo es alto. Escríbelo como un manual con roles nombrados y ensáyalo una vez. La primera vez que se use no debería ser la primera vez que se lee.

La superficie del propio sitio

Parte del RGPD es visible en la página, y merece la pena cuidar esos detalles porque son los que la gente denuncia.

Tu aviso de privacidad debe indicar la identidad y el contacto del responsable, las finalidades y bases jurídicas, los destinatarios y categorías de destinatarios, los mecanismos de transferencia, los plazos de conservación, la lista completa de derechos incluido el de reclamar ante una autoridad de control, y si hay decisiones automatizadas. Escríbelo en un lenguaje que una persona normal pueda seguir. Los avisos por capas, con una versión corta que enlace al detalle, funcionan mejor que un muro de texto.

Los formularios deberían recoger solo lo necesario. Cada campo es una justificación que quizá tengas que dar. Si la casilla de consentimiento de marketing va en el mismo envío que el pedido, debe estar desmarcada por separado y redactada por separado.

Los contenidos incrustados de terceros son el fallo silencioso. YouTube en modo de privacidad mejorada, mapas tras un marcador de carga por clic, fuentes autoalojadas en lugar de traídas de un CDN de terceros. Cada uno de estos cambios es pequeño y elimina un hallazgo.

Lo que vemos fallar más a menudo

Tras suficientes auditorías, aparece siempre la misma lista corta:

Analítica que carga antes del consentimiento, normalmente porque un gestor de etiquetas lo configuró marketing y nunca lo revisó ingeniería.
Botones de rechazo que disparan consentimiento igualmente por el comportamiento por defecto de un script de terceros.
Ninguna tarea de retención, en ninguna tabla.
Supresión que se olvida de copias, logs y CRM.
Un aviso de privacidad que describe un flujo de datos que cambió hace dieciocho meses.
Listas de subencargados que se quedan en los tres proveedores obvios.
Registros de consentimiento sin la versión del texto que se mostró.

Ninguno es un problema difícil. Es simplemente trabajo que nadie ha asignado.

Pedir ayuda

Si quieres un segundo par de ojos sobre un sitio existente, hacemos auditorías técnicas de RGPD que producen un backlog priorizado en lugar de un informe: qué arreglar, en qué orden, con una estimación por punto. Si estás construyendo algo nuevo, es bastante más barato acertar con el modelo de datos y la arquitectura de consentimiento desde el principio.

También cubrimos la superficie más amplia de cumplimiento europeo, incluida la accesibilidad y la entrada al mercado europeo. Escríbenos a office@c9group.dev.

Construimos software. No damos asesoramiento jurídico, y la interpretación de cualquier requisito concreto corresponde a tus abogados. Lo que podemos hacer es asegurar que el sistema hace lo que tus abogados dicen que debe hacer.