Qué debes tener, qué debes probar y cómo ordenar todo para no improvisar

Si has seguido la serie hasta aquí, ya has visto el patrón. Los problemas no suelen venir de una sola gran ilegalidad, sino de una suma de pequeños fallos: un banner que empuja, un “rechazar” que no bloquea, una analítica que se llama “ligera” pero hace bastante más, vendors declarados que no existen, terceros silenciosos que nadie ha inventariado, una landing que escapa al control del contenedor principal. Lo que una auditoría o una autoridad termina examinando no es solo tu banner: examina si tu organización sabe qué pasa en su web, puede explicarlo y puede probarlo. La CNIL lo ha planteado de forma muy directa en su acción sobre dark patterns en banners, y el ICO ha seguido una línea similar al exigir elecciones claras y reforzar el cumplimiento de los sitios más visitados del Reino Unido. (CNIL)

Este último artículo no busca añadir más teoría. Busca dejarte un pack mínimo, práctico y defendible para que no empieces de cero cada vez que revisas cookies, CMP o analítica. Si tuviera que resumirlo en una sola frase, sería esta:

No necesitas una montaña de documentación. Necesitas una carpeta pequeña, clara y repetible.

Ese es el objetivo del cierre de la serie. Y es también la lógica detrás de la herramienta de auditoría web del EDPB: convertir la revisión de un sitio en algo que se puede preparar, ejecutar, evaluar y reportar con método. (EDPB)

1) Qué significa estar “razonablemente listo”

Estar listo no significa tener una web perfecta ni haber eliminado cualquier riesgo posible. Significa poder responder con orden a cinco preguntas muy concretas:

1. Qué tecnologías y terceros se activan en la web/app.
2. Cuándo se activan: antes de elegir, tras aceptar, tras rechazar, por scroll, por navegación, por clic, por carga diferida.
3. Qué declaras al usuario: finalidades, vendors, categorías, lógica de la CMP.
4. Qué pruebas tienes de que esa declaración coincide con la realidad.
5. Qué haces cuando algo falla: remediación, control de cambios y revisión periódica.

Ese es el mínimo razonable. Y es coherente con la manera en que la AEPD y el ICO aterrizan el cumplimiento: claridad para el usuario, configuración real de las herramientas y capacidad de demostrar que el comportamiento observado coincide con lo prometido. (Agencia Española de Protección de Datos)

Lección 1: una buena preparación no busca impresionar; busca responder sin titubeos.

2) La carpeta mínima que deberías tener

La mayoría de equipos falla aquí por dos razones opuestas: o guardan demasiado material sin orden, o apenas guardan nada. Ninguno de los dos extremos ayuda. Lo que funciona mejor es una carpeta muy sencilla, con una estructura estable.

Carpeta A — Banner y CMP

Aquí debería vivir lo básico del interfaz y del control declarado:

• captura de primera capa en escritorio;
• captura de primera capa en móvil;
• captura de segunda capa, si existe;
• captura del estado “rechazado”;
• versión o fecha de la CMP;
• nota breve de cambios cuando algo se toque.

¿Por qué importa esto? Porque tanto la CNIL como el ICO están poniendo atención en la experiencia de elección: rechazar debe ser tan fácil como aceptar y no puede quedar escondido en recorridos más complejos o menos visibles. Tener esa evidencia visual te permite demostrar que no solo tienes banner, sino que el diseño de la elección está bajo control. (CNIL)

Carpeta B — Pruebas de comportamiento

Aquí van las pruebas que más pesan:

• escenario Pre;
• escenario Accept;
• escenario Reject;
• si quieres hacer bien el trabajo: Reject + scroll/espera y Reject + navegación.

Puedes guardar HAR o, si quieres mantenerlo más ligero, capturas de la pestaña Network con la lista de dominios observados. Lo importante no es el formato; lo importante es que permita comparar escenarios. Este tipo de prueba está muy alineado con el enfoque de auditoría repetible que el EDPB promueve con su herramienta específica para webs. (EDPB)

Carpeta C — Inventario y clasificación

Aquí debería existir una tabla “declarado vs observado” con:

• dominios/endpoints observados;
• si aparecen en Pre, Accept o Reject;
• si figuran en la CMP;
• categoría declarada;
• proveedor real;
• acción pendiente o justificación.

Esto es especialmente importante porque uno de los fallos más frecuentes es la divergencia entre lo que cuenta la CMP y lo que muestra la red. La AEPD, cuando trata la analítica externa, obliga precisamente a mirar proveedor, rol, configuración y finalidad efectiva. (Agencia Española de Protección de Datos)

Carpeta D — Decisión y revisión

Con una sola hoja basta:

• qué hemos considerado correcto;
• qué hemos detectado como problema;
• qué se va a corregir;
• quién lo hace;
• cuándo se vuelve a revisar.

Lección 2: la carpeta ideal no es la más grande; es la que te permite reconstruir la historia de un vistazo.

3) El checklist mínimo de una revisión seria

Si mañana tuvieras que revisar la web sin complicarte, este sería el orden razonable.

Paso 1 — Revisar elección y fricción

• ¿Aceptar y rechazar están al mismo nivel?
• ¿Rechazar está disponible sin rodeos injustificados?
• ¿Móvil y escritorio cuentan la misma historia?

La CNIL ha insistido precisamente en esto al actuar contra banners con patrones oscuros. No es un detalle cosmético; es una cuestión central de validez material del consentimiento. (CNIL)

Paso 2 — Ejecutar Pre / Accept / Reject

No en una sola página, sino al menos en un conjunto pequeño pero representativo:

• home;
• landing o página de campaña;
• login/registro;
• formulario;
• página con embed;
• checkout/pricing si existe.

La utilidad aquí es doble: detectas problemas y, además, creas una línea base para comparaciones futuras. Eso es exactamente el tipo de lógica que hace útil la herramienta de auditoría del EDPB. (EDPB)

Paso 3 — Revisar “modo rechazo” con algo de mala idea

Esta es una parte que muchos equipos omiten:

• espera 10–15 segundos;
• haz scroll;
• interactúa con un vídeo o un mapa;
• cambia de página.

Así detectas carga diferida tramposa: situaciones en las que el sitio parece limpio justo tras rechazar, pero activa terceros poco después o por evento. El enfoque del ICO sobre storage and access technologies obliga a mirar la realidad del acceso/almacenamiento, no solo la foto inicial. (ICO)

Paso 4 — Contrastar lo declarado con lo observado

¿La CMP declara vendors que no aparecen? ¿Aparecen terceros que no figuran? ¿Hay categorías mal asignadas? ¿Algo está declarado como “necesario” sin una justificación seria? La AEPD, al analizar cookies y analítica web, insiste precisamente en el valor de esa coherencia entre información, roles y configuración efectiva. (Agencia Española de Protección de Datos)

Lección 3: el checklist útil no es largo; es ordenado.

4) Qué errores hunden una revisión aunque el banner “parezca correcto”

Error 1 — Revisar solo la home

Es muy habitual que la página principal esté cuidada y el problema esté en una landing, un formulario, un subdominio o un checkout. Una inspección seria no se queda donde tú estás más cómodo. La lógica del ICO sobre sus revisiones masivas y la del EDPB con herramientas de auditoría empujan exactamente en sentido contrario: mirar escenarios reales, no solo la portada. (ICO)

Error 2 — Confiar en la CMP como si fuera infalible

La CMP no “hace cumplir” nada por sí sola. Si el contenedor está mal configurado, si hay scripts hardcoded o si hay widgets laterales, el rechazo puede ser meramente aparente. La AEPD, con su foco en configuración real de analítica externa, obliga precisamente a salir del “tenemos CMP” y entrar en “qué ocurre”. (Agencia Española de Protección de Datos)

Error 3 — Llamar “necesario” a todo lo que molesta revisar

El ICO es bastante claro al recordar que los fines de publicidad online no se amparan en la excepción de estrictamente necesarias. Y, en general, lo “útil para negocio” no equivale a “imprescindible para prestar el servicio solicitado”. (ICO)

Error 4 — Dar por bueno lo “privacy-friendly” sin pruebas

Lo vimos en artículos anteriores con herramientas que ofrecen consent mode, cookieless tracking o exemption mode. Nada de eso sustituye la revisión de finalidad, configuración y comportamiento real. La exención no nace del claim; nace, si nace, del encaje concreto con las condiciones que marcan autoridades como la CNIL o la AEPD. (Agencia Española de Protección de Datos)

Error 5 — No revisar cambios

La web cambia sola: un tag nuevo, un plugin, un vídeo embebido, una landing de marketing, una fuente externa añadida deprisa. Si no hay revisión por release o por trimestre, el cumplimiento se erosiona aunque nadie “decida incumplir”. La propia acción continuada del ICO sobre los sitios más visitados refleja que el cumplimiento de cookies es una cuestión de mantenimiento, no de foto fija. (ICO)

Lección 4: la mayoría de los problemas graves no nacen de una mala fe espectacular, sino de pequeños descuidos acumulados.

5) El pack de pruebas que realmente pesa

Si tuviera que reducir todo el trabajo de la serie a un paquete de prueba que valga para auditoría interna o para una primera respuesta ante inspección, sería este:

1. Cuatro capturas del banner/CMP

• primera capa escritorio;
• primera capa móvil;
• segunda capa;
• estado “rechazado”.

2. Tres pruebas básicas por página crítica

• Pre;
• Accept;
• Reject.

3. Dos pruebas extra en Reject

• Reject + scroll/espera;
• Reject + navegación.

4. Una tabla “declarado vs observado”

Con proveedores reales, categorías, acciones y fechas.

5. Una hoja de control de cambios

Con la última revisión, lo modificado y la próxima fecha de prueba.

El EDPB, al explicar su herramienta de auditoría web, presenta precisamente esa lógica: visitas simples al sitio que se traducen en preparación, ejecución, evaluación e informe. No hace falta sofisticar mucho más para tener un núcleo defendible. (EDPB)

Lección 5: un expediente mínimo bien hecho vale más que una política impecable sin pruebas.

6) Cómo convertir esto en un hábito y no en una campaña puntual

Si quieres evitar la dinámica de “cada seis meses hacemos una revisión heroica”, convierte el control en rutina.

Revisión ligera por release

Cada vez que cambies la CMP, el contenedor, una plantilla crítica o un embed, repite al menos una mini versión del protocolo:

• banner visible;
• Pre / Accept / Reject;
• una comprobación en Reject por scroll o navegación.

Revisión trimestral completa

• muestreo de 5–6 páginas;
• actualización de la tabla “declarado vs observado”;
• limpieza de vendors fantasma;
• verificación de terceros silenciosos;
• control de cambios y próxima fecha.

Esto es totalmente consistente con la orientación del ICO hacia supervisión continuada y con la filosofía del EDPB de pruebas repetibles y reportables. (ICO)

Lección 6: la madurez no está en hacer una gran revisión, sino en poder repetir una revisión razonable sin drama.

7) El cierre de la serie: lo que de verdad deberías haberte llevado

Si tuviera que resumir toda la Serie 2 en siete aprendizajes, serían estos:

1. Un banner bonito no demuestra nada por sí solo. La CNIL ha puesto el acento en la facilidad real del rechazo. (CNIL)
2. La prueba útil es siempre material: qué cambia en la red entre Pre, Accept y Reject. El EDPB ha orientado sus herramientas precisamente a esa lógica. (EDPB)
3. Rechazar debe ser fácil, pero además debe ser efectivo. ICO y CNIL empujan claramente en esa dirección. (CNIL)
4. La analítica “exenta” es un espacio estrecho, no un comodín; AEPD y CNIL obligan a mirar configuración, finalidad y proveedor. (Agencia Española de Protección de Datos)
5. “Privacy-friendly” no equivale a “cumplimiento automático”. Hay que revisar qué hace realmente la herramienta. (Agencia Española de Protección de Datos)
6. La tabla “declarado vs observado” resuelve más discusiones internas que muchos informes largos. (Agencia Española de Protección de Datos)
7. Una buena carpeta de pruebas cambia por completo tu posición en una auditoría o inspección. (EDPB)

Cierre

El verdadero salto de madurez no está en tener más texto legal, sino en tener más realidad controlada. Un banner, una CMP y una herramienta analítica dejan de ser un riesgo difuso cuando puedes enseñar, con orden y sencillez, qué hacen, cómo lo decides y qué pruebas guardas.

Ese es el “pack mínimo” que merece la pena construir. Y, una vez lo tienes, el resto del trabajo deja de parecer niebla.

Qué viene después de esta serie

Con esto cerramos la Serie 2 (Cookies/CMP/UX). El siguiente bloque natural, y además el que probablemente más interés va a generar, es el de IA en front-office, chatbots, perfilado y decisiones automatizadas: el punto donde la conversación pasa de “qué se instala en el navegador” a “qué se decide sobre las personas con los datos que ya estás recogiendo”. Muchas de las piezas ya las has ido viendo aquí: control real, evidencia, arquitectura, configuración y la diferencia entre marketing del proveedor y cumplimiento defendible.

Bibliografía y recursos

• CNIL — Dark Patterns in Cookie Banners: CNIL issues formal notice to website publishers. Énfasis en que rechazar debe ser tan fácil como aceptar y en la crítica a diseños engañosos. (CNIL)
• ICO — ICO action secures increased cookie compliance. Actualización de diciembre de 2025: más del 95% de los top 1.000 sitios superaron checks tras la acción del ICO. (ICO)
• AEPD — Guide on the use of cookies. Guía general sobre uso de cookies, información y rechazo/aceptación. (Agencia Española de Protección de Datos)
• AEPD — Guía uso de cookies para herramientas de medición de audiencia. Muy útil para roles, configuración y enfoque probatorio en analítica externa. (Agencia Española de Protección de Datos)
• AEPD — Orientaciones sobre cookies y analítica web en portales de las Administraciones Públicas. Buen material para aterrizar criterios de necesidad, finalidad y configuración. (Agencia Española de Protección de Datos)
• EDPB — Website auditing tool. Recurso oficial para preparar, ejecutar, evaluar y documentar auditorías web. (EDPB)