Expediente mínimo, errores que te hunden y pruebas que sí pesan

Hay una forma muy mala de prepararse para una inspección: pensar que todo gira alrededor del banner. No gira alrededor del banner. Gira alrededor de algo mucho más incómodo: la coherencia entre lo que dices, lo que configuras y lo que realmente ocurre en la web o la app. Las autoridades no miran solo si existe un botón de “Aceptar” o “Rechazar”. Miran si la elección es real, si el comportamiento del sitio cambia de verdad y si la organización puede enseñar pruebas ordenadas de lo que afirma. La CNIL lo ha recordado con claridad al actuar contra banners con patrones oscuros: con ciertas excepciones, las cookies requieren consentimiento y rechazarlas debe ser tan fácil como aceptarlas. (CNIL)

La buena noticia es que esto se puede trabajar. La mala es que no se arregla con una política bien redactada ni con una CMP bonita. Se arregla con un pequeño expediente, pruebas repetibles y disciplina de revisión. El EDPB, de hecho, puso el foco exactamente ahí cuando lanzó su website auditing tool: una herramienta pensada para preparar, ejecutar, evaluar auditorías web y generar informes a partir de visitas reales al sitio. Eso ya te dice mucho sobre el enfoque actual: menos teoría abstracta y más evidencia observable. (EDPB)

1) El punto de partida: una autoridad no “lee” tu banner, lo contrasta con la realidad

Cuando una autoridad entra en este terreno, no suele empezar preguntando qué opina tu equipo legal del consentimiento. Suele mirar algo más básico: qué tecnologías hay, cómo se activan y si el usuario puede rechazarlas de forma efectiva. El ICO lo está dejando bastante claro con su acción sobre los 1.000 sitios más visitados del Reino Unido y con sus actualizaciones de cumplimiento: el foco está en que los sitios ofrezcan clear choices y respeten sus obligaciones sobre tracking online. En diciembre de 2025 informó, además, de que más del 95% de los top 1.000 sitios había alcanzado los checks de cumplimiento tras su intervención, lo que muestra que la supervisión en cookies ya no es un tema marginal ni anecdótico. (ICO)

En España, la AEPD lleva tiempo aterrizando este enfoque con guías que obligan a mirar el servicio “en producción”, especialmente cuando la analítica es externa. No basta con decir “tenemos analítica”; hay que poder explicar qué proveedor es, con qué configuración opera, qué finalidades cubre y qué evidencia lo respalda. Ese enfoque probatorio está muy presente en la guía sobre cookies analíticas externas y también en sus orientaciones sobre cookies y analítica web para Administraciones Públicas. (Agencia Española de Protección de Datos)

Primera lección: una inspección no gira en torno a tu narrativa; gira en torno a lo que el sitio hace realmente. (EDPB)

2) Qué suelen mirar primero: la experiencia de elección

Lo primero que pesa es si el usuario puede elegir de verdad. Y aquí el test es bastante humano: ¿aceptar y rechazar cuestan lo mismo? ¿“Rechazar” está visible en primera capa cuando se pide consentimiento? ¿Hay asimetría de color, tamaño o recorrido? ¿La segunda capa se usa para esconder la negativa? La CNIL fue explícita al emitir formal notices a editores por banners con patrones oscuros que empujaban a aceptar. No estaba discutiendo teoría sobre UX; estaba diciendo que el diseño del banner puede vaciar de contenido la libertad de la elección. (CNIL)

Esto no es solo un asunto francés. El ICO, en su acción de 2025, habló también de “clear choices and confidence in how their information is used”, una formulación que pone el acento en la comprensión y en la facilidad de la decisión, no solo en el cumplimiento formal de una lista de requisitos. Cuando una autoridad mira el banner, en realidad está mirando si el control que prometes es usable. (ICO)

Ejemplo claro: un banner donde “Aceptar” aparece como botón primario y “Rechazar” como enlace textual tenue en la parte inferior. Técnicamente existe la opción, pero desde una óptica de inspección la experiencia no está equilibrada. Ahí no necesitas una discusión filosófica: necesitas rediseñarlo y probar que el recorrido de rechazo es equivalente. (CNIL)

3) Lo segundo: si el rechazo produce un efecto real

Aquí se separan los banners decorativos de los banners que sirven para algo. Una autoridad querrá ver si, una vez rechazado, desaparecen o permanecen bloqueados los terceros que dependen del consentimiento. El ICO, al definir el alcance de las storage and access technologies, deja claro que no solo importan las cookies clásicas, sino también scripts, tags, píxeles, web storage, fingerprinting y mecanismos equivalentes. Eso significa que el examen del “modo rechazo” no puede limitarse a una lista de cookies; debe mirar el comportamiento completo del sitio. (Measured Collective)

La AEPD, desde otro ángulo, empuja exactamente al mismo sitio cuando habla de configuración real de servicios analíticos externos y de las condiciones para su uso. Lo relevante no es el claim del proveedor ni la descripción del banner, sino si el tercero sigue recibiendo datos, identificadores o señales cuando el usuario ya rechazó. (Agencia Española de Protección de Datos)

Ejemplo claro: el usuario pulsa “Rechazar”, el banner desaparece, pero el chat, el replay o una conversión publicitaria se activan al hacer scroll, al cambiar de página o a los diez segundos de permanencia. En una revisión superficial puede pasar desapercibido; en una inspección seria se interpreta como un rechazo inefectivo o meramente cosmético. El enfoque de auditoría repetible del EDPB está precisamente pensado para capturar ese tipo de diferencias entre escenarios. (EDPB)

Segunda lección: la autoridad no se queda en el botón; mira el efecto del botón. (EDPB)

4) Lo tercero: la coherencia entre CMP y tráfico real

Este es uno de los puntos más devastadores cuando falla. Tu CMP puede declarar una serie de finalidades y vendors, pero si el tráfico real muestra otra cosa, la defensa se resiente de inmediato. En la práctica, esto aparece de tres maneras:

• vendors declarados que nunca aparecen (CMP inflada o mal ajustada);
• dominios o endpoints observados que no figuran en la CMP (terceros silenciosos);
• categorías mal asignadas (por ejemplo, algo declarado como “necesario” que en realidad responde a una finalidad analítica o publicitaria).

La guía de la AEPD sobre cookies analíticas externas y las orientaciones para web analytics en el sector público son especialmente útiles aquí porque obligan a mirar el servicio en términos de roles, configuración y finalidad efectiva, no solo en términos de etiqueta comercial. (Agencia Española de Protección de Datos)

Ejemplo claro: la CMP declara 150 vendors por defecto porque así viene el framework del proveedor, pero en la red solo aparecen 12. Eso no solo genera ruido; también afecta a la transparencia y hace más difícil explicar al usuario qué pasa realmente. El caso inverso —tráfico de terceros no declarado— es aún peor. (Agencia Española de Protección de Datos)

Tercera lección: si tu CMP y tu tráfico cuentan historias distintas, la autoridad va a creer a la red. (EDPB)

5) Lo cuarto: la justificación de lo “necesario”

Otro foco clásico de inspección es la tendencia a llamar “necesario” a todo lo que molesta revisar. La AEPD y el ICO obligan a diferenciar con cuidado entre lo que es realmente imprescindible para prestar el servicio solicitado y lo que simplemente es útil, conveniente o comercialmente deseable. El ICO, por ejemplo, es claro al decir que las finalidades de publicidad online no pueden ampararse en la excepción de estrictamente necesarias. (Measured Collective)

Esto afecta mucho a tres familias de terceros que suelen pasar como inocuos: CDN/WAF, fuentes externas y embeds. No todo en estas familias exige consentimiento, pero tampoco todo puede pasar como “necesario” sin explicación. Lo que una autoridad querrá ver es una justificación breve pero seria: qué función cumple, por qué no hay alternativa menos intrusiva o equivalente, qué datos implica y cómo lo has documentado. La orientación de la AEPD para analítica pública y el material de la CNIL sobre medición de audiencia son buenos recordatorios de que la arquitectura y la configuración importan tanto como la finalidad declarada. (Agencia Española de Protección de Datos)

Ejemplo claro: Google Fonts cargadas desde un tercero “porque es más cómodo”. Difícilmente eso se sostiene como estrictamente necesario si puedes self-hostear la fuente o sustituirla por otra alternativa local. La cuestión aquí no es demonizar todas las dependencias externas, sino dejar claro que “me viene bien” no equivale a “era indispensable”. (Measured Collective)

Cuarta lección: “necesario” no es lo que evita trabajo interno; es lo que el servicio no puede prestar razonablemente sin ello. (Measured Collective)

6) Lo quinto: la carpeta de evidencias

Aquí muchas organizaciones fallan por exceso de sofisticación o por defecto de orden. Una autoridad no te va a premiar por tener 200 capturas sueltas en un drive mal nombrado. Tampoco necesita un informe de 80 páginas para cada release. Lo que de verdad pesa es una carpeta sencilla, coherente y mantenida.

El expediente mínimo que sí vale

Yo esperaría, como mínimo, esto:

1. Capturas del banner/CMP
   • primera capa desktop;
   • primera capa móvil;
   • segunda capa (si existe);
   • estado “rechazado”.
2. Pruebas de comportamiento
   • escenarios Pre / Accept / Reject;
   • y, si quieres hacer bien el trabajo, Reject + scroll/espera/navegación.
3. Lista de terceros
   • tabla “declarado vs observado”;
   • proveedor real;
   • finalidad;
   • categoría CMP;
   • decisión.
4. Control de cambios
   • versión de la CMP o del contenedor;
   • fecha;
   • nota breve de cambios.

El EDPB lanzó su herramienta de auditoría web justamente para facilitar auditorías que preparen, ejecuten, evalúen y reporten este tipo de pruebas. Eso encaja muy bien con la idea de tener un expediente pequeño, pero robusto. (EDPB)

Quinta lección: la prueba que pesa no es la más larga, sino la más clara y repetible. (EDPB)

7) Errores típicos que te hunden

Error 1 — El banner está bien, pero el contenedor lo rompe

CMP correcta, Tag Manager mal condicionado, scripts hardcoded o una landing aislada con otro contenedor. Resultado: el expediente “de escritorio” dice una cosa y el sitio otra. Es un fallo muy común precisamente porque el problema está repartido entre equipos. (EDPB)

Error 2 — Se prueba la home y nada más

Muchas webs pasan una revisión superficial en inicio y se rompen en login, checkout, formularios o páginas con embeds. Una inspección medianamente seria no se va a quedar en una sola URL. (EDPB)

Error 3 — Se confía ciegamente en el proveedor

Que el proveedor diga “consent mode”, “privacy-friendly” o “exemption-ready” no te ahorra el análisis. Lo vimos con Clarity, Matomo o herramientas equivalentes: la promesa comercial tiene que pasar por configuración real y por red. (Agencia Española de Protección de Datos)

Error 4 — No hay cadencia de revisión

La web cambia. Entra una campaña, se añade un widget, se reemplaza una plantilla, aparece un script en el head, se activa un nuevo proveedor. Si no revisas por release o por trimestre, el cumplimiento se degrada solo. La acción del ICO sobre los top 1.000 sitios y la lógica del EDPB van justo en la línea contraria: revisión material, no foto fija. (ICO)

Sexta lección: una inspección se pierde muchas veces por acumulación de pequeños descuidos, no por un gran escándalo técnico. (ICO)

8) Qué haría yo si quisiera estar “razonablemente listo” en 30 días

Sin convertir esto en un proyecto mastodóntico, hay cuatro movimientos que elevan mucho el nivel:

Semana 1 — Foto real del sitio

• Seleccionar 6 páginas de muestreo.
• Ejecutar Pre / Accept / Reject.
• Guardar capturas y una tabla “observado vs declarado”.

Semana 2 — Corregir asimetrías del banner

• igualar Aceptar/Rechazar;
• eliminar fricciones innecesarias;
• revisar móvil.

Semana 3 — Limpiar terceros y categorías

• sacar vendors fantasma;
• declarar terceros silenciosos;
• justificar lo necesario;
• condicionar o eliminar lo opcional mal resuelto.

Semana 4 — Cerrar expediente y método

• carpeta de pruebas;
• control de cambios;
• fecha de próxima revisión;
• responsable.

No es perfección. Es gobernanza básica. Y cambia mucho la capacidad de respuesta si mañana alguien te pide explicaciones. (Agencia Española de Protección de Datos)

Cierre

Una autoridad no busca que tu banner sea elegante. Busca saber si el control que prometes existe de verdad y si puedes demostrarlo. Por eso, cuando se inspecciona banner, CMP y analítica, en el fondo se está inspeccionando algo más grande: tu capacidad de gobernar lo que pasa en tu web.

Si tuviera que resumirlo en una sola idea, sería esta:

La diferencia entre una web “que parece cumplir” y una web defendible está en la carpeta de evidencias y en la coherencia entre interfaz, configuración y tráfico.

Siguiente post (Post 9)

“Cierre de la serie: el pack mínimo para tener tu banner, tu CMP y tu analítica listos para auditoría interna o inspección”

Bibliografía y recursos

• CNIL — Dark patterns in cookie banners: formal notices to website publishers. La CNIL recuerda que, salvo excepciones, rechazar debe ser tan fácil como aceptar. (CNIL)
• ICO — ICO takes action to tackle cookie compliance across the UK’s top 1,000 websites. Acción oficial de enero de 2025 enfocada en “clear choices”. (ICO)
• ICO — ICO action secures increased cookie compliance. Actualización de diciembre de 2025 con más del 95% de los top 1.000 sitios superando checks. (ICO)
• AEPD — Guide on the use of cookies. Guía general sobre cookies y requisitos de información/consentimiento. (Agencia Española de Protección de Datos)
• AEPD — Guidelines on cookies and web analytics in public administration websites. Orientaciones prácticas para cookies y analítica en AA.PP. (Agencia Española de Protección de Datos)
• EDPB — Website auditing tool / EDPB launches website auditing tool. Recurso oficial para preparar, ejecutar y evaluar auditorías web y generar informes. (EDPB)