Casi todos los banners de cookies que reviso no bloquean nada. La ventana aparece, el visitante
elige, y da lo mismo lo que elija: la analítica ya escribió sus cookies dos segundos antes, en el
<head>. Ese es el estado normal de los sitios chilenos hoy, y es el punto donde la Ley 21.719
deja de ser un asunto de textos legales y pasa a ser trabajo de implementación: orden de carga de
los scripts, campos del formulario, plazos de borrado. De eso trata este post, elemento por
elemento.
El hilo conductor es este mismo sitio. La política de privacidad y el banner de cookies de franciscomoroso.com están en producción y los escribí yo, así que puedo mostrar las decisiones y también lo que encontré corto al escribirlo. Si lo que buscas primero es el marco legal, desde cuándo rige y cuánto pueden multarte, eso está en Ley 21.719: qué es, desde cuándo rige y qué cambia. No soy abogado: esto es criterio técnico de implementación, no asesoría legal.
La respuesta corta
| Elemento | Qué cambia | Cómo quedó acá |
|---|---|---|
| Formulario | Declarar finalidad antes de enviar, pedir solo lo necesario, no reutilizar el correo para otra cosa | Nombre, correo y mensaje obligatorios. Teléfono y tema opcionales. Sin RUT |
| Banner de cookies | Rechazar tiene que pesar lo mismo que aceptar, y cerrar sin decidir equivale a rechazar | Dos botones idénticos, Esc cierra dejando la medición denegada |
| Analítica | No puede medir antes de que la persona decida | Consent Mode v2 con todo denegado por defecto, en el <head> |
| Registro del consentimiento | Hay que poder demostrar qué aceptó cada persona y cuándo | Cookie propia con estado, versión y marca de tiempo, más una bitácora en el servidor con cuatro campos: sin IP y sin user-agent |
| Retención | Cada dato necesita un plazo escrito y aplicado | 14 meses en analítica, rotación acotada en los logs del servidor |
| Publicidad | Un píxel que perfila necesita permiso y revocación | No hay píxeles. Señales publicitarias denegadas de forma permanente |
Si tu sitio es un WordPress con formulario, Google Analytics y un banner instalado de apuro, los seis puntos de esa tabla te van a dar trabajo. El orden en que los abordaría es exactamente ese.
El formulario de contacto
El formulario es el punto donde tu sitio pasa de publicar a recolectar. Tres preguntas, en orden:
¿Qué campos pides y por qué? El principio de proporcionalidad manda pedir solo lo necesario para la finalidad declarada. En el formulario de este sitio los obligatorios son nombre, correo y mensaje; el teléfono y el tema son opcionales. No pido RUT ni datos de facturación para responder una consulta, porque no los necesito para responderla. Ese es el test: si no lo necesitas para lo que dijiste que ibas a hacer, sobra.
¿La finalidad está declarada antes de enviar? No después, no en una página que hay que buscar. El formulario tiene que decir para qué se usa lo que estás escribiendo, con el enlace a la política de privacidad visible en el mismo bloque.
¿Qué pasa con el envío después? Acá está el hallazgo más común en WordPress: los plugins de formulario guardan cada envío en la base de datos del sitio, y esa tabla no la limpia nadie nunca. Un sitio de cinco años tiene ahí miles de nombres, correos y teléfonos que no sabías que estabas almacenando. Reviso eso antes que el banner. En este sitio el envío no se guarda en base de datos: sale por SMTP autenticado y queda solo en el correo. Un lugar menos que inventariar.
Los controles antispam también tratan datos, así que van declarados: un campo trampa invisible, una marca de tiempo y un límite de cinco envíos por hora y por dirección IP. Ese límite guarda un hash de la IP de forma transitoria, por hora, y no aparece en el correo que me llega. Está en la política como interés legítimo en la seguridad del sitio. Ese nivel de detalle es lo que separa una política escrita desde la operación de una copiada.
Nombre, correo y mensaje van con asterisco; teléfono y tema quedan sin él. La finalidad y el enlace a la política están arriba de los campos, no escondidos en el pie de página.
El banner de cookies
Los banners que fallan lo hacen por una de dos razones, y ninguna es de redacción.
Falla uno: el banner no bloquea nada. El plugin dibuja la ventana, pero los scripts de
analítica y los píxeles ya se cargaron en el <head> y ya escribieron sus cookies. El visitante
hace clic en “aceptar” sobre una medición que lleva dos segundos funcionando. Es la falla más
frecuente y la más fácil de detectar: abre las herramientas de desarrollo, mira las cookies antes
de tocar el banner, y si ya está _ga ahí, el banner llegó tarde.
Falla dos: rechazar es más difícil que aceptar. Botón grande de color para “aceptar” y un enlace gris chico para “configurar”. El consentimiento tiene que ser libre, y una decisión donde un camino cuesta un clic y el otro cuesta tres no lo es.
Cómo quedó acá. El banner vive en la esquina inferior, nunca a pantalla completa, con dos botones de mismo borde, tamaño y tipografía: Rechazar y Aceptar. Ninguno es el botón grande de color. El enlace a la política está siempre visible dentro del banner. La tecla Esc y la equis cierran sin decidir, y eso deja la medición denegada: la inacción no puede leerse como permiso. Se reabre desde “Preferencias de cookies”, en el pie de página, para revocar con el mismo esfuerzo con que se aceptó.
Rechazar y Aceptar comparten borde, alto y tipografía. Ninguno de los dos es el botón grande de color.
La analítica
Acá está el trabajo real, y no es visual. La regla es que la medición no puede ocurrir antes de la decisión, y eso se resuelve en el orden de carga, no en el copy del banner.
En este sitio el script de consentimiento va en el <head>, antes que cualquier script de
terceros, y lo primero que hace es declarar todo denegado: almacenamiento publicitario, datos de
usuario para publicidad, personalización de anuncios y almacenamiento analítico. Google Analytics
4 arranca desde ahí sin poder escribir ni leer las cookies _ga y _ga_*, y sin poder generar un
identificador del visitante. Mientras tanto Google recibe una señal sin cookies que usa para
estimaciones agregadas. Si la persona acepta, se emite la actualización del consentimiento y recién
ahí la medición pasa a identificar.
Tres detalles que no suelen estar y que valen la pena:
- Las señales publicitarias están denegadas de forma permanente, no sujetas al banner. No uso Google Ads, remarketing ni píxeles de redes sociales, así que la decisión correcta no es preguntar por algo que no ocurre: es no cargarlo nunca.
- Hay un control de entorno. El tag solo envía datos en los dominios de producción. Desde desarrollo o desde el entorno de pruebas no sale una sola petición a Google, y los eventos quedan igual en la capa de datos para verificarlos. Suena a higiene técnica y también es protección de datos: un entorno de pruebas mandando visitas reales a una propiedad de producción es tratamiento que nadie declaró.
- La retención está configurada en 14 meses en Google Analytics, y ese plazo está publicado en la política. Configurar el plazo y no publicarlo deja la mitad del deber sin cumplir; publicarlo y no configurarlo deja la peor mitad.
El registro del consentimiento
Este es el punto que casi nadie implementa y el que más importa si algún día tienes que demostrar algo, porque la carga de la prueba de la licitud es tuya.
Un banner que aplica tu decisión y no la registra te deja sin nada que mostrar. Lo mínimo que hay que poder reconstruir es qué se preguntó, en qué versión del texto, qué se respondió y cuándo.
Acá la decisión se guarda en una cookie propia, fm_consent, a 180 días, con respaldo en el
almacenamiento local del navegador. Lo que se guarda es el estado (aceptado o rechazado), la
versión del banner y la marca de tiempo. La versión importa: si mañana cambio qué mide el sitio,
subo el número de versión y los consentimientos anteriores dejan de valer automáticamente, porque
se dieron sobre otro texto. Un banner sin versión hace que una decisión de hace dos años valga
para una medición que no existía entonces.
Cuando empecé a escribir este post, ese registro vivía solo en el navegador de la persona. Servía para aplicar la decisión y para que el sitio no volviera a preguntar, pero no me dejaba a mí una bitácora que pudiera exportar: si el visitante borraba sus cookies, el registro desaparecía. Iba a dejarlo declarado como brecha asumida. Escribir el párrafo que decía “esto no lo cubro” fue más incómodo que cerrarlo, así que lo cerré antes de publicar.
Hoy la decisión queda en dos lugares y cada uno hace una cosa distinta. En el navegador, para aplicarla y no volver a preguntar. Y en el servidor, como bitácora exportable: al momento de aceptar o rechazar, el sitio manda una línea a un archivo que vive fuera de la carpeta pública, con cuatro campos y ni uno más.
| Campo | Qué es |
|---|---|
| Marca de tiempo | La del servidor, en UTC. La del navegador no la guardo: no prueba nada y agrega detalle |
| Identificador | Un número aleatorio que genera tu navegador, no derivado de nada tuyo, guardado en tu almacenamiento local. Sirve para ligar tu decisión con el cambio de opinión de después |
| Estado | Aceptado o rechazado |
| Versión | La versión del banner sobre la que decidiste |
Y ahora lo importante, que es lo que no guarda: no guarda tu dirección IP, no guarda tu user-agent, no guarda de qué página venías ni en qué idioma estabas. El identificador tampoco viaja en la cookie, así que no acompaña cada petición que haces al sitio; se manda una sola vez, cuando decides. La bitácora se purga sola a los 24 meses.
Esa lista de ausencias no es adorno. Un registro de consentimiento que guarda IP y user-agent “por si acaso” convierte la prueba de que respetas la ley en un tratamiento nuevo que también hay que justificar, declarar y borrar. Es el error más fácil de cometer cuando uno implementa esto: como el archivo es tuyo y nadie lo mira, se le agregan campos sin pensar. El test es el mismo del formulario, aplicado a ti mismo: si no lo necesitas para demostrar qué se aceptó y cuándo, sobra.
Con esto, la diferencia con una plataforma pagada deja de ser el registro y pasa a ser otra: gestión. Una plataforma te da el panel para consultar la bitácora, los informes armados, el escaneo periódico de cookies nuevas y todo eso multiplicado por los sitios que administres. Acá tengo un CSV de cuatro columnas que abro cuando lo necesito, que para un sitio es suficiente y para veinte no lo sería.
La retención
Lo que más veo en sitios chicos no es un banner malo: es que nada tiene fecha de vencimiento. La pregunta no es si guardas datos, es hasta cuándo, y “por si acaso” no es un plazo.
Cómo quedó publicado acá, dato por dato:
| Qué | Cuánto tiempo |
|---|---|
| Consultas que no derivan en trabajo | Hasta que la consulta queda resuelta o hasta que pidan su supresión |
| Datos de clientes | Mientras dure la relación, más los plazos que exigen las normas tributarias y comerciales |
| Analítica | 14 meses de retención configurados en Google Analytics |
| Registros técnicos del servidor | Rotación por tamaño, máximo diez rotaciones |
| Cookie de consentimiento | 180 días |
| Bitácora de consentimiento en el servidor | 24 meses, purga automática |
Llenar esa tabla es el trabajo. Obliga a listar cada lugar donde vive un dato, y casi siempre aparecen dos o tres que nadie tenía en el inventario: la bandeja de correo, la tabla del plugin de formularios, el respaldo del año pasado que quedó en una carpeta.
Plataformas de consentimiento: la comparativa
No vendo ninguna de estas y no tengo un plugin propio que empujar, así que la comparación va sin sesgo comercial. Los precios los consulté el 26 de agosto de 2026 en la página oficial de cada proveedor, y la columna de Chile dice qué encontré ese día en su material público.
| Plataforma | Qué es | Cómo cobra y precio de entrada | Plan gratis | Chile / Ley 21.719 |
|---|---|---|---|---|
| Cookiebot (Usercentrics) | CMP como servicio, agnóstica de plataforma | Por subpáginas y por dominio, sin límite de visitas. Premium Lite €7/mes; Small €15/mes hasta 350 subpáginas; Medium €30/mes hasta 3.500 | Sí: 1 dominio, hasta 50 subpáginas | No la menciona en su material público (consultado el 26-ago-2026) |
| CookieYes | CMP como servicio, con plugin de WordPress | Por dominio y por páginas vistas. Basic US$10/mes, Pro US$25/mes, Ultimate US$55/mes | Sí: 100 páginas por escaneo, 5.000 páginas vistas al mes | No la menciona en su material público (consultado el 26-ago-2026) |
| Complianz | Plugin de WordPress, no servicio externo | Licencia anual por instalación. Personal US$59/año (1 sitio), Professional US$179/año (5), Agency US$399/año (25). Sin tope de registros de consentimiento ni de páginas vistas | Sí, versión gratuita del plugin | Cobertura por región configurable; no nombra a Chile en su material público (consultado el 26-ago-2026) |
| iubenda | Suite de cumplimiento (política, banner, registro) | Por páginas vistas. Essentials €4,99/mes con facturación anual (25.000 páginas vistas), Advanced €19,99/mes, Ultimate €79,99/mes | Sí, con funciones limitadas | No la menciona en su material público (consultado el 26-ago-2026) |
| Lawwwing | Suite de cumplimiento en español | Por plan, visitas ilimitadas. Starter €9,90/mes, Growth €15,90/mes, Professional €29,90/mes. Idioma adicional €3/mes | No publica un plan gratuito permanente | Sí: lista “Ley 21.719 (Chile)” entre sus coberturas |
| CookieSent | CMP chilena, banner y registro de consentimiento | No publica precios. Facturación en pesos chilenos, 14 días de prueba | Ofrece un informe de revisión gratuito | Sí, es su caso de uso declarado |
| ConSENT | Plataforma chilena más amplia: consentimiento, solicitudes ARCOP y evidencia | No publica precios, se cotiza por demo | No | Sí, es su caso de uso declarado |
| Banner propio | Código en tu sitio, sin licencia | Costo de desarrollo, sin cuota mensual | No aplica | Depende de cómo lo construyas |
Cómo la leería yo, que es lo que la tabla sola no dice.
Si tienes un WordPress y un solo sitio, un plugin con licencia anual sale más barato y más predecible que una suscripción mensual por dominio, y no te ata a un servicio externo que puede cambiar de precio. La contra es que vive dentro de WordPress: si el sitio se cae o lo migras, el registro de consentimiento se va con él.
Si tienes varios dominios o un sitio grande, el cobro por subpáginas te va a doler más que el cobro por visitas o al revés, según tu forma: un catálogo con miles de URLs y poco tráfico se castiga con el primero, y un sitio de pocas páginas con mucho tráfico, con el segundo. Cuenta tus URLs antes de elegir el modelo de cobro, no después.
Si necesitas facturar en pesos y con documento tributario chileno, las dos opciones chilenas resuelven un problema administrativo real que las plataformas europeas no resuelven. Ninguna de las dos publica precios, así que la comparación de costo hay que pedirla.
La mención de “Ley 21.719” en el material de un proveedor no es garantía de nada. Es marketing de cobertura. Lo que sí revisaría, sea cual sea la plataforma, son cinco cosas concretas:
- Que el banner bloquee de verdad los scripts antes de la decisión, no solo los declare.
- Que el registro de consentimiento se pueda exportar, con fecha, estado y versión del texto.
- Que revocar tome los mismos clics que aceptar, y que el punto de revocación quede visible.
- Que el escaneo de cookies detecte lo que realmente carga tu sitio, no una lista genérica.
- Que quede claro dónde se almacenan los registros y bajo qué contrato, porque ese proveedor pasa a ser un encargado de tratamiento tuyo.
Qué no haría
No instalaría un plugin de banner y daría el tema por cerrado. El banner es la parte visible y la más chica del trabajo; lo que toma tiempo es el inventario de datos, los plazos y el orden de carga de los scripts.
No pondría un banner de cookies en un sitio que no usa cookies. He visto sitios estáticos, sin analítica y sin formulario, con un banner instalado por precaución. Preguntarle a la gente por algo que no ocurre no es cumplimiento: es ruido, y encima te obliga a mantener un texto que no describe nada.
No pagaría una plataforma antes de saber qué mide mi sitio. Primero el inventario, después la herramienta. Al revés se termina pagando una suscripción para gestionar cookies que se podían simplemente sacar.
No copiaría la política de privacidad de otro sitio. Describe la operación de otro. Para partir de una estructura en vez de una copia hay una plantilla comentada sección por sección, para llenarla con lo que hace tu sitio.
Preguntas frecuentes
¿Necesito banner de cookies si solo uso Google Analytics?
Sí. La analítica trata datos personales y necesita base de licitud. Lo que puedes evitar es el banner molesto: si la medición parte denegada por defecto y respeta la decisión, el banner es pequeño y honesto en vez de un muro a pantalla completa.
¿Sirve un banner que solo tiene el botón “aceptar”?
A mi juicio no. Si el único camino disponible es aceptar, no hay nada que decidir, y el consentimiento tiene que ser libre y revocable. Es además la falla más fácil de detectar desde fuera.
¿Cómo sé si mi banner está bloqueando de verdad?
Abre tu sitio en una ventana nueva, entra a las herramientas de desarrollo del navegador y mira las
cookies antes de tocar el banner. Si ya aparecen _ga, _ga_* o un píxel de terceros, el banner
no está bloqueando nada.
¿Puedo hacerlo sin pagar una plataforma?
Sí, y es lo que corre en este sitio, registro del lado del servidor incluido: son unas pocas decenas de líneas de código que escriben cuatro campos en un archivo. El costo se te va a desarrollo en vez de licencia. La diferencia real aparece más arriba: panel para consultar la bitácora, informes armados, escaneo periódico de cookies nuevas y varios sitios a la vez. Si administras uno, te alcanza con lo propio; si administras veinte, la licencia se paga sola.
¿Qué hago con los envíos viejos del formulario que están en la base de datos?
Primero míralos: casi siempre hay más de lo que crees. Después decide un plazo, bórralo hacia atrás y déjalo automatizado. Y publica ese plazo en la política, porque un plazo que se aplica pero no se informa cumple solo la mitad.
Lo que queda
El trabajo de verdad no es el banner: es saber qué datos entran a tu sitio, por dónde, dónde quedan, quién más los ve y hasta cuándo. El banner y la política son la parte visible de ese inventario, y sin inventario la política que publiques describe un sitio imaginario.
Esta revisión aplicada al propio sitio la hago como parte de protección de datos personales. El marco legal completo, con el articulado citado, está en qué es la Ley 21.719 y desde cuándo rige. La validez jurídica de los textos la ve un abogado.
más sobre Protección de datos
- Plantilla de política de privacidad (Ley 21.719)
Un modelo de política de privacidad en texto plano, con lo que casi ninguna plantilla trae: el checklist técnico de lo que hay que hacer antes de publicarla.
Leer la nota - Ley 21.719: qué es, desde cuándo rige y qué cambia
Entra en régimen el 1 de diciembre de 2026, fecha hoy en revisión, y toca cosas que ya tienes en el sitio: el formulario, la analítica, la base de clientes y los respaldos.
Leer la nota