Cada pocos meses alguien anuncia la muerte del banner de cookies.
Y cada pocos meses todos acabamos actualizando el banner de cookies.
Hemos construido toda una industria de la privacidad a base de capas. Banners encima de trackers. Modos de consentimiento encima de analítica. Textos legales encima de productos que nunca se diseñaron pensando en la privacidad.
El RGPD lo llama “privacidad desde el diseño y por defecto”. En la práctica, casi todo lo que hacemos es poner parches.
Seamos honestos sobre cómo funciona la mayoría de stacks hoy en día.
Una web típica:
- Recoge datos por defecto
- Los envía a varios terceros
- Luego pregunta al usuario si eso estaba bien
- Y si el usuario dice que no, intenta limitar o maquillar lo que ya ha pasado
Incluso la mejor implementación de Consent Mode sigue siendo básicamente un sistema de tráfico para datos que quieren fluir sí o sí.
Desde el punto de vista legal, esto puede ser válido.
Desde el punto de vista técnico, es al revés de cómo debería hacerse.
¿Y si la privacidad viviera dentro del sistema?
Mientras el mundo del marketing y el compliance sigue parcheando capas, hay ingenieros y grupos de investigación explorando otra idea.
En vez de pedirle a las aplicaciones que se porten bien, es el propio sistema el que impone las reglas.
En ese modelo:
- El acceso a los datos se controla a nivel de sistema
- Los flujos de datos son explícitos y limitados
- Las aplicaciones no pueden “recoger de más por si acaso”
- El consentimiento no es un popup, es una capacidad técnica
Esto ya existe en entornos muy específicos y de alto riesgo. Los detalles técnicos dan un poco igual.
Lo importante es la idea.
Por qué esto sí tiene que ver con el RGPD de verdad
El RGPD no dice “pon un banner”.
Dice:
- Minimiza datos
- Limita finalidades
- Restringe accesos
- Diseña con privacidad desde el principio
- Haz que la opción por defecto sea la más privada
La mayoría de webs hacen justo lo contrario y luego intentan corregirlo con capas legales y CMPs.
Funciona. Hasta que deja de funcionar.
Un enfoque a nivel de sistema se parece mucho más a lo que realmente pretendía el artículo 25.
No en un PDF. En la arquitectura.
La pregunta incómoda para cualquier negocio
Aquí viene la parte que nadie quiere oír.
Si tu producto solo funciona porque puede recogerlo todo por defecto y ya se ordenará después, entonces no es “privacy-first”. Es “privacy-if-we-have-to”.
Un sistema realmente centrado en privacidad obliga a hacerse preguntas incómodas:
- ¿De verdad necesitamos este dato?
- ¿O lo queremos porque “por si acaso” puede servir algún día?
- ¿Qué se rompe si no podemos recogerlo?
Esto no es un problema legal. Es un problema de producto.
Qué puedes hacer hoy sin reinventar internet
No necesitas un nuevo sistema operativo para cambiar la mentalidad.
Algunos cambios prácticos:
- Empieza desde “no recogemos nada” y justifica cada excepción.
- Dibuja los flujos reales de datos, no solo los legales.
- Haz que el producto tenga sentido incluso sin tracking.
- Trata los scripts de terceros como potencialmente hostiles.
- Deja de llamar a esto “compliance”. Esto es arquitectura de producto.
El banner de cookies no es el futuro de la privacidad
Es un apaño temporal.
Necesario, por ahora.
Pero existe porque estamos intentando meter privacidad en sistemas que nunca se diseñaron para respetarla.
El futuro de la privacidad no son mejores banners.
Son sistemas donde comportarse mal con los datos es técnicamente imposible, no solo legalmente peligroso.
Y ese cambio va a ser mucho más importante que cualquier nueva versión de Consent Mode.