Cuatro modelos de consentimiento en Europa
Los cuatro modelos sitúan el consentimiento a nivel de navegador. Se diferencian en quién controla la experiencia y cuánta granularidad obtiene el usuario: el CMP del sitio web (hoy), una cabecera HTTP estandarizada (GPC), los proveedores de navegadores (Ómnibus) o el asistente elegido por el propio usuario (arquitectura abierta).
Matriz de comparación
| Hoy | GPC (ene. 2027) | Directiva Ómnibus Digital | Arquitectura abierta | |
|---|---|---|---|---|
| ¿Quién diseña la experiencia de consentimiento? Quién controla la interfaz que ve el usuario | El CMP de cada sitio web, configurado por el propietario del sitio. Enorme variación en calidad, de excelente a manipuladora. | Totalmente automático: una cabecera HTTP binaria enviada por el navegador antes de que cargue la página. Simple y sin fricción, aunque los usuarios no toman decisiones por sitio. | Cuatro proveedores de navegadores: Google, Apple, Microsoft, Mozilla. Ellos diseñan la interfaz para todos los usuarios de la UE. | El asistente de consentimiento elegido por el usuario (p. ej. Consent-o-matic, Taste, SuperAgent), comunicándose con el CMP del sitio a través de una API de navegador neutral. |
| ¿Cuán específico es el consentimiento? GDPR Art. 4(11): el consentimiento debe ser específico e informado | Depende del CMP. Las buenas implementaciones ofrecen elecciones por proveedor y por finalidad. Las malas presentan un muro de texto y un único botón de «aceptar». | Binaria: una única señal «no vendan ni compartan» aplicada de forma uniforme. Diseñada para la exclusión de la CCPA; no expresa preferencias por finalidad ni por proveedor. | Una señal global (aceptar/rechazar) aplicada por igual a todos los sitios. No distingue entre la analítica de una tienda de confianza y una red publicitaria desconocida. | Granular, contextual. El asistente analiza los proveedores y finalidades de cada sitio, y aplica preferencias que pueden variar de un sitio a otro. |
| ¿Hay competencia? ¿Puede el usuario elegir una solución diferente? | Los usuarios no tienen elección: interactúan con el CMP que utilice el sitio web. Existen algunas extensiones de navegador, pero dependen de la ingeniería inversa, que se rompe frecuentemente. | La señal está estandarizada por el W3C e integrada en el navegador. Los usuarios pueden activarla o desactivarla. La señal en sí es uniforme; no existe un mecanismo para implementaciones alternativas ni para añadir granularidad. | No. Cada proveedor de navegador implementa su propio enfoque. Los usuarios están atados al navegador que utilizan. Sin pantalla de elección. | Sí. Una pantalla de elección (inspirada en la selección de motores de búsqueda del DMA) permite a los usuarios elegir entre asistentes de consentimiento competidores. Los incentivos de mercado impulsan la calidad. |
| ¿Conflicto de intereses? ¿Se beneficia el operador de consentimiento del resultado? | Los CMPs son pagados por los sitios web, lo que puede incentivar diseños favorables al consentimiento. La aplicación regulatoria (CNIL, etc.) actúa como contrapeso. | Indirecto. Los proveedores de navegadores deciden el estado por defecto (activado/desactivado). La elección por defecto tiene implicaciones de mercado significativas, ya que las plataformas con relaciones de datos de primera parte se ven menos afectadas que aquellas que dependen del acceso basado en el consentimiento. | Significativo. Los proveedores de navegadores gestionan sus propias plataformas de publicidad y datos. Retienen datos de primera parte independientemente de la señal, mientras los competidores dependen del consentimiento. | Reducido. Los asistentes independientes compiten por servir los intereses del usuario. Si uno favorece a los anunciantes, los usuarios cambian. La disciplina de mercado reemplaza los conflictos estructurales. |
| ¿Qué ocurre en móvil / navegadores integrados en aplicaciones? Webviews en Instagram, LinkedIn, aplicaciones de noticias, etc. | El consentimiento se pierde en cada visita. Los webviews están aislados y no pueden acceder al consentimiento almacenado. Esta es una causa importante de la fatiga del consentimiento actual. | Funciona en webviews: la cabecera HTTP se envía independientemente del contexto. La señal sigue siendo binaria, por lo que no puede reflejar las preferencias del usuario por sitio o por finalidad. | No se aborda. La Directiva Ómnibus guarda silencio sobre los webviews. Las extensiones de navegador no se ejecutan en navegadores integrados en aplicaciones. La mayor fuente de fatiga del consentimiento queda intacta. | Parcialmente abordado. La API neutral (navigator.consent) opera a nivel de navegador, no depende de extensiones, lo que la hace compatible con futuras soluciones móviles. Pero el vacío de los webviews requiere legislación separada. |
| ¿Qué papel desempeñan los CMPs? Información contextual, registro de auditoría, gestión de proveedores, cumplimiento | Central. Los CMPs recogen el consentimiento, proporcionan información, gestionan los permisos de los proveedores y mantienen registros auditables. | Limitado. La señal se envía antes de que cargue el CMP. Los CMPs pueden leer la cabecera y respetarla, pero no existe un canal estructurado para que el CMP proporcione información contextual u ofrezca una elección granular a cambio. | Disminuido. Los CMPs reciben la señal del navegador y mantienen registros, pero pierden la capacidad de proporcionar información contextual y elección granular en el punto de decisión. | Preservado y mejorado. Los CMPs siguen proporcionando información contextual, controles granulares y registros de auditoría. El asistente se comunica con el CMP, no eludiendo al CMP. |
| ¿Impacto en la fatiga del consentimiento? El objetivo declarado de la Directiva Ómnibus Digital | Fatiga significativa. Causada principalmente por los navegadores que borran las cookies de consentimiento (ITP, ETP), los navegadores integrados en aplicaciones y la baja calidad de los CMPs. No por la existencia de los CMPs en sí. | Elimina eficazmente la fatiga de los banners: la señal es automática y no requiere acción del usuario. La contrapartida es que los usuarios que desean un control por sitio o por finalidad no disponen de un mecanismo para expresarlo. | Mejora limitada. Los banners desaparecen en sitios que no son de medios, pero las causas raíz (borrado de consentimiento, webviews) no se abordan. Los sitios de medios — donde la fatiga es peor — están exentos. | Mejora significativa. Los asistentes de consentimiento gestionan las decisiones silenciosamente para la mayoría de los sitios. Los banners de CMP desaparecen a menos que el usuario quiera decidir manualmente. Las causas raíz aún necesitan abordarse por separado. |
| Evaluación general | Funciona, pero con calidad desigual y problemas reales de fatiga. El sistema necesita mejoras, no ser reemplazado. | Probado a escala y altamente eficaz para reducir la fricción del consentimiento. El modelo binario encaja bien con la CCPA; para el GDPR, una capa de granularidad por encima salvaría la distancia entre la sencillez de la exclusión y la especificidad que exige la regulación. | Intercambia un problema (fatiga) por otro (concentración de poder), dejando las causas principales de la fatiga sin resolver. | Reduce la fatiga mediante automatización elegida por el usuario, preserva el consentimiento significativo y crea un mercado europeo competitivo de herramientas de privacidad. |