La mayoría de las PYMEs con un banner de cookies creen que han terminado con el cumplimiento de cookies. No lo han hecho. El banner es la mitad del cuadro — el mecanismo de consentimiento. La otra mitad — el inventario de aquello sobre lo que el banner está pidiendo consentimiento — es donde las auditorías de las autoridades de control siguen encontrando lagunas. Una operación coordinada de 2024 por la Autoriteit Persoonsgegevens neerlandesa, la CNIL francesa y el Garante italiano halló el mismo patrón en cientos de sitios web: banners presentes, pero ningún registro subyacente que documente qué rastreadores se disparan, quién los coloca, qué datos leen del dispositivo y si están realmente clasificados correctamente.
Un inventario de cookies y rastreadores es la capa de documentación bajo su CMP. Es lo que un auditor pide cuando la verificación del banner pasa. Esta guía explica qué debe contener un inventario, por qué vive separado de su mapa de datos RGPD, qué exige realmente el artículo 5(3) ePrivacy y cómo mantener el inventario al día sin duplicar el trabajo.
ePrivacy Art. 5(3): la regla que la mayoría de las PYMEs malinterpreta
La directiva ePrivacy 2002/58/CE artículo 5(3) — a veces llamada "ley de cookies", más precisamente la regla de equipos terminales — exige consentimiento previo antes de que cualquier información sea almacenada en o leída desde el dispositivo de un usuario. Dos cosas la hacen más difícil de lo que parece:
Se aplica incluso cuando los datos almacenados no son datos personales. Una cookie contadora que registra "esta es la tercera visita del usuario" se rige por el art. 5(3), independientemente de si ese conteo es vinculable a una persona identificada. ePrivacy y RGPD son marcos jurídicos separados; cumplir el RGPD no exime de ePrivacy.
Se aplica a cualquier cosa almacenada en el dispositivo, no solo cookies. localStorage, sessionStorage, entradas de IndexedDB, etiquetas pixel que leen identificadores existentes, beacons de SDK, fingerprinting que deriva una señal estable del navegador, cachés de service worker — todos son "información almacenada en el equipo terminal de un abonado o usuario". Si su inventario solo registra cookies por nombre, omite la mayor parte de lo que las autoridades de control examinan ahora.
La excepción es estrecha: un rastreador se permite sin consentimiento solo si es "estrictamente necesario" para entregar el servicio que el usuario explícitamente solicitó. El TJUE y las autoridades nacionales han leído esto estrictamente. Cookies de sesión para un flujo de pago autenticado cumplen. Analytics que "nos ayuda a mejorar el servicio" no. Píxeles de marketing nunca.
Qué inventariar
Un inventario de cookies y rastreadores es más amplio que la lista de cookies que muestra el escáner de su CMP. Cuentan seis categorías de mecanismos de almacenamiento y recopilación de señales:
- Cookies — first-party y third-party, de sesión y persistentes
- localStorage y sessionStorage — almacenes clave-valor del navegador que persisten más que las cookies para orígenes first-party
- Etiquetas pixel — solicitudes de imagen 1×1 que llevan identificadores en la URL o leen cookies existentes en el dominio de destino
- SDKs — bibliotecas JavaScript de terceros (analytics, widgets de chat, monitores de error, redes publicitarias) que a menudo colocan sus propias cookies y leen o escriben en localStorage y disparan beacons
- Fingerprinting — derivación de un identificador estable a partir de características del dispositivo (canvas, WebGL, lista de fuentes, contexto de audio). Incluso sin almacenar nada, el fingerprinting lee desde el dispositivo — el artículo 5(3) se aplica.
- Beacons — llamadas a
navigator.sendBeacon()que se disparan al descargar la página, comunes en SDKs de analytics y notificación de errores
Para cada entrada, el registro auditable necesita al menos: nombre, proveedor (la empresa detrás), dominio donde se coloca, tipo, finalidad, duración, base ePrivacy (consentimiento o estrictamente necesario) y el mecanismo de consentimiento que lo controla (su CMP, o "sin CMP — estrictamente necesario"). Menos que eso, y no podrá responder a la pregunta de la autoridad de control: "muéstreme la base legal de este rastreador específico en este servicio específico".
Inventario ≠ CMP — hacen trabajos distintos
Una CMP (Plataforma de Gestión del Consentimiento) — Cookiebot, OneTrust, Didomi, Iubenda, Usercentrics, Cookie Information, Axeptio — hace tres cosas:
- Mostrar el banner con interruptores por categoría
- Almacenar registros individuales de consentimiento con marca de tiempo y la versión de la política vigente
- Bloquear rastreadores hasta que se otorgue el consentimiento (la capa técnica de aplicación)
Una CMP es operativa. Se ejecuta en cada carga de página. Su trabajo es gestionar el consentimiento en tiempo real.
Un inventario hace algo diferente: es la documentación de aquello sobre lo que la CMP pide consentimiento. Responde a preguntas que una CMP no puede:
- ¿Por qué este rastreador está clasificado como analytics y no como marketing?
- ¿Quién en la organización aprobó añadir el LinkedIn Insight Tag, y en qué fecha?
- ¿Qué datos lee o escribe realmente este SDK — más allá de lo que afirma la documentación del proveedor?
- Si un regulador pregunta "demuestre la necesidad de esta cookie analytics bajo su evaluación de intereses legítimos", ¿cuál es la respuesta?
- Cuando la lista de cookies cambia — un nuevo SDK añadido, un proveedor cambiado — ¿aparece el cambio en su registro de auditoría?
Un escaneo CMP le dice qué cookies se disparan hoy. Un inventario le dice cuáles deberían dispararse, por qué cada una está en la lista y qué ha cambiado en los últimos seis meses. Los dos son complementarios; ninguno reemplaza al otro.
Por eso también las autoridades de control piden cada vez más ambos. Una CMP sin inventario es un banner sin justificación. Un inventario sin CMP es un registro sin mecanismo de aplicación. Las PYMEs que confunden ambos — generalmente tratando el escaneo automático de la CMP como el inventario — descubren durante una auditoría que el escáner CMP omitió los SDKs que solo se disparan tras un clic, el beacon analytics que solo se activa con errores, y la entrada localStorage que el widget de chat escribe después de que el usuario teclea un mensaje.
Las cuatro categorías de rastreadores
Toda CMP seria y todo documento de orientación de las autoridades de control clasifica los rastreadores en los mismos cuatro cubos. La clasificación determina tanto el flujo de consentimiento como la postura de riesgo del inventario.
Estrictamente necesarios. Rastreadores sin los cuales el servicio explícitamente solicitado no puede funcionar. Identificadores de sesión para una sesión autenticada, una cookie de token CSRF, la cookie que recuerda su preferencia de idioma para la visita actual, la cookie de afinidad del balanceador. Estos están exentos del requisito de consentimiento. Sea conservador — si un regulador pudiera plausiblemente decir "el servicio funcionaría sin esto", no es estrictamente necesario.
Funcionales. Rastreadores que mejoran la experiencia del usuario pero no son esenciales — recordar preferencias de UI entre sesiones, recordar una lista de elementos vistos recientemente, persistir la preferencia de idioma entre visitas. Estos requieren consentimiento. La línea entre estrictamente necesario y funcional es estrecha y a menudo debatida; documentar su razonamiento por rastreador es lo que sobrevive a una auditoría.
Analytics. Rastreadores que miden cómo se usa el servicio — vistas de página, duración de sesión, rutas de conversión, tasas de error. El TJUE y la mayoría de las autoridades nacionales han dictaminado que incluso los analytics first-party requieren consentimiento, salvo que los datos estén genuinamente agregados y sean utilizados solo por el responsable para medir su propio servicio. Matomo autoalojado con anonimización de IP y sin seguimiento entre sitios es lo más cercano a una configuración analytics sin consentimiento; Google Analytics 4 no.
Marketing. Píxeles de retargeting, identificadores de redes publicitarias, etiquetas de conversión, píxeles de seguimiento de redes sociales. Siempre requieren consentimiento. Casi siempre third-party. La categoría que atrae más atención sancionadora.
El inventario registra la categoría para cada rastreador, la base ePrivacy (consentimiento o necesario) y — crucialmente — el razonamiento. La categoría determina el flujo de consentimiento; el razonamiento determina si la clasificación resiste la inspección.
Base ePrivacy vs base legal RGPD Art. 6: no confundir
Este es el error más común en la documentación de cookies de PYMEs. ePrivacy Art. 5(3) y RGPD Art. 6 son marcos jurídicos separados que plantean preguntas separadas:
- ePrivacy Art. 5(3) pregunta: ¿puede colocarse este rastreador en el dispositivo? La respuesta es
consentimientooestrictamente necesario. - RGPD Art. 6 pregunta: si de este tratamiento resultan datos personales, cuál es la base legal para tratarlos? La respuesta es una de las seis bases del art. 6(1) — consentimiento, contrato, obligación legal, intereses vitales, misión de interés público, intereses legítimos.
Una cookie analytics first-party que requiere consentimiento del usuario bajo ePrivacy puede, una vez dado el consentimiento, tratar los datos resultantes bajo el RGPD Art. 6(1)(a) (consentimiento) — o bajo el Art. 6(1)(f) (intereses legítimos) una vez obtenido válidamente el consentimiento para la colocación de la cookie. En algunas interpretaciones, la colocación y el tratamiento se apoyan ambos en el consentimiento; en otras, la colocación es de consentimiento y el tratamiento es de intereses legítimos. Las orientaciones de las autoridades nacionales varían. Lo universal: las dos bases se registran por separado. Un inventario con un solo campo "base legal" por rastreador confunde ambas y produce un registro que ninguna autoridad aceptará.
Un inventario serio tiene un campo legal_basis_eprivacy en cada rastreador (consentimiento / necesario) y un campo legal_basis separado en los elementos de datos personales que el rastreador genera (la base RGPD Art. 6). Viven en tablas distintas del modelo de datos porque responden a preguntas distintas.
Qué cambia con la propuesta Digital Omnibus
En noviembre de 2025 la Comisión Europea publicó la propuesta Digital Omnibus COM(2025) 837 final. Aún no está adoptada — y no es seguro que pase en su forma actual — pero la dirección importa porque remodelaría la aplicación de ePrivacy.
La propuesta movería la regla cookies/equipo terminal del art. 5(3) ePrivacy a un nuevo art. 88a RGPD para abonados personas físicas. Seis finalidades nombradas serían lícitas sin consentimiento: realizar una comunicación electrónica, prestar un servicio explícitamente solicitado, medición agregada de audiencia para uso propio del responsable, mantener la seguridad del servicio, y soportar servicios de la sociedad de la información solicitados por el usuario. La negativa al consentimiento debería poderse hacer con un clic, y un responsable rechazado debería esperar al menos seis meses antes de volver a preguntar.
Un art. 88b complementario obligaría a los responsables a respetar señales de consentimiento legibles por máquina — Global Privacy Control, un eventual estándar ESO — una vez publicadas las especificaciones técnicas, y exigiría a los navegadores no-PYME proporcionarlas.
Para las PYMEs que mantienen un inventario de rastreadores hoy, nada cambia operativamente. La distinción actual consentimiento/necesario bajo ePrivacy Art. 5(3) sigue siendo correcta bajo la directiva vigente. Pero se desprenden dos orientaciones prospectivas:
- La taxonomía que importará en adelante es la finalidad, no el tipo de cookie. Un inventario que registra la finalidad de cada rastreador (el servicio explícitamente solicitado por el usuario, medición de audiencia para uso propio, etc.) se transporta limpiamente al régimen del art. 88a si llega. Un inventario que solo registra "analytics — consentimiento requerido" tendrá que ser reclasificado.
- El soporte para señales de consentimiento legibles por máquina será una característica de la CMP, no del inventario — pero el inventario debe registrar qué CMP está en uso para que el auditor pueda verificar el cumplimiento del art. 88b una vez publicado el estándar.
La propuesta es de fecha y previsiona explícitamente derecho futuro. Construya para el derecho vigente; diseñe para la dirección propuesta.
Cómo Readmodel® gestiona los inventarios de cookies y rastreadores
Readmodel® mantiene el inventario de cookies y rastreadores a nivel de servicio — bajo el mismo modelo de datos que almacena sus servicios, elementos de datos y transferencias — para que un rastreador esté siempre vinculado al servicio que lo coloca, los datos que lee o genera, y (cuando resultan datos personales) el registro RGPD que los procesa.
Cada entrada de rastreador captura: nombre, proveedor, dominio, tipo (cookie / localStorage / pixel / fingerprint / SDK / beacon / otro), categoría (estrictamente_necesario / funcional / analytics / marketing), la legal_basis_eprivacy (consentimiento / necesario) — deliberadamente nombrada para evitar confusión con la legal_basis del RGPD Art. 6 en elementos de datos — finalidad, duración, la referencia al mecanismo de consentimiento (su CMP) y una URL opcional a la documentación del proveedor.
Una biblioteca precargada de 167 rastreadores comunes — cubriendo CMPs europeos (Cookiebot, Didomi, Iubenda, Usercentrics, Axeptio), analytics (GA4, Matomo, Piwik PRO, Hotjar, Microsoft Clarity), redes publicitarias (Meta, LinkedIn, TikTok, Criteo, RTB House, Google Ads), widgets de chat (Intercom, Crisp, LiveChat, Tidio), SDKs de pago (Stripe, Adyen, Mollie, Klarna), identidad (Auth0, Keycloak, NextAuth.js), comercio (Shopify, WooCommerce, Magento), error/APM (Sentry, Datadog, New Relic) y patrones CMS (WordPress, Drupal, TYPO3) — cubre la mayoría de los stacks de PYMEs en pocos clics. Las entradas personalizadas siguen el mismo esquema.
El registro de riesgos marca automáticamente cualquier rastreador no esencial (category != 'strictly_necessary' y legal_basis_eprivacy = 'consent') para el que no se documenta ningún mecanismo de consentimiento a nivel de fila y no se establece una CMP a nivel de proyecto. Cualquiera de los niveles elimina la marca — así que las PYMEs que documentan una CMP a nivel de proyecto (Cookiebot para todo el sitio, por ejemplo) no tienen que repetirlo en cada fila de rastreador.
Un generador integrado de política de cookies produce un documento de política de cookies listo para imprimir y copiar-como-Markdown / copiar-como-HTML, agrupando los rastreadores por categoría e incluyendo descripciones y duraciones. Es el documento que publica en su sitio web para cumplir el requisito de transparencia que acompaña al requisito de consentimiento.
Crucialmente, Readmodel® no reemplaza su CMP. No genera banners de consentimiento, no almacena registros individuales de consentimiento, no parsea cadenas TCF y no escanea su sitio automáticamente. Es la capa de inventario bajo la CMP que utilice. Para la imagen general de cómo Readmodel® encaja en su stack de privacidad, vea la comparación de herramientas de cumplimiento RGPD.
Inventario de cookies y rastreadores: preguntas frecuentes
¿Es legalmente obligatorio un inventario de cookies? El inventario de cookies como tal no se nombra en ninguna ley, pero la obligación que satisface sí. El art. 5(3) ePrivacy exige consentimiento antes de colocar o leer información en el dispositivo de un usuario, salvo para rastreadores estrictamente necesarios. Bajo el principio de responsabilidad proactiva del RGPD (art. 5(2)), el responsable debe poder demostrar el cumplimiento — lo que en la práctica significa un inventario documentado de cada rastreador, su categoría, su finalidad y la base legal. Las autoridades de control piden cada vez más el inventario durante las auditorías.
¿No me da el escáner de mi CMP el inventario automáticamente? Un escáner CMP le da una instantánea de las cookies que se dispararon durante el escaneo. Omite los rastreadores que se disparan condicionalmente (tras un clic, en errores, en zonas autenticadas a las que el escáner no se conectó), omite en la mayoría de planes el almacenamiento que no es cookie (localStorage, fingerprinting, beacons), y no registra el razonamiento detrás de sus clasificaciones de categoría. Use el escáner como entrada al inventario; no trate la salida del escáner como el inventario.
¿Cuál es la diferencia entre estrictamente necesario y funcional? Los rastreadores estrictamente necesarios son aquellos sin los cuales el servicio que el usuario explícitamente solicitó no puede funcionar — identificadores de sesión para un flujo de pago, tokens CSRF, afinidad del balanceador. Los rastreadores funcionales mejoran la experiencia del usuario pero no son esenciales — recordar preferencias de UI entre sesiones, listas de elementos vistos recientemente. Estrictamente necesario está exento de consentimiento; funcional requiere consentimiento. Las autoridades nacionales leen la excepción estrictamente; en caso de duda, clasifique como funcional y exija consentimiento.
¿Necesito inventariar rastreadores de terceros? Sí. Cualquier cosa que coloque o lea información en el dispositivo del usuario cuenta, sin importar quién la opera. Vídeos de YouTube incrustados que colocan cookies de DoubleClick, Stripe Elements que coloca cookies de prevención de fraude, la incrustación de Google Maps que coloca NID — todo eso debe estar en el inventario, con el proveedor tercero documentado.
¿Mi biblioteca de fingerprinting debe estar en el inventario? Sí. El fingerprinting lee características del dispositivo del usuario para derivar un identificador estable — el TJUE y el EDPB han confirmado que esto cae bajo el art. 5(3) incluso cuando no se almacena nada. Documente la biblioteca, su finalidad y el mecanismo de consentimiento que la rige. La mayor parte del fingerprinting en producción es para prevención de fraude (Sift, Forter, DataDome) y puede calificar como estrictamente necesario para la finalidad de seguridad; documente el razonamiento.
¿Cómo se relaciona esto con el Reglamento europeo de IA? Si usa IA sobre los datos que recopilan sus rastreadores — sistemas de recomendación alimentados por clickstream, modelos de segmentación publicitaria conductual, ML de detección de fraude — la capa de procesamiento de IA está regida por el Reglamento de IA, mientras que la colocación subyacente del rastreador está regida por ePrivacy. Ambos deben documentarse por separado. Vea la guía de gobernanza de IA para la capa de IA.
¿Qué ocurre si se adopta la propuesta Digital Omnibus? La regla cookies/equipo terminal pasa del art. 5(3) ePrivacy a un nuevo art. 88a RGPD para abonados personas físicas, con seis finalidades nombradas lícitas sin consentimiento. Un inventario construido alrededor de la finalidad (en lugar de alrededor de los nombres de las cookies) se transporta limpiamente. La propuesta aún no está adoptada; construya para el derecho vigente.
¿Con qué frecuencia debo actualizar el inventario? Al menos trimestralmente, además de en cada cambio: un nuevo SDK añadido al sitio, un cambio de proveedor (Cookiebot → OneTrust), una nueva característica que introduzca rastreadores condicionales, una actualización de las reglas de la CMP. El inventario es un documento vivo; el registro de auditoría en cada rastreador prueba que lo está manteniendo.
Empiece a documentar sus rastreadores
Los inventarios de cookies y rastreadores son ingratos. También son adonde se mueven las auditorías de las autoridades de control a medida que la aplicación centrada solo en el banner alcanza su techo. El trabajo es genuinamente manejable para una PYME una vez que se tiene la estructura: un rastreador por fila, una categoría, una base, una finalidad, una referencia a CMP y una duración.
Cree una cuenta gratuita de Readmodel®, traiga la biblioteca precargada y tendrá un inventario listo para auditoría en menos de una hora. La página de rastreadores, el generador de política de cookies, la marca del registro de riesgos para consentimiento faltante y la inclusión en el registro de actividades de tratamiento están disponibles en todos los planes, incluido el plan Explore gratuito.