Ley 21.719 y tu stack de medición: ¿hay que migrar todo a server-side?

Una de las preguntas que más me hicieron estas semanas, desde equipos de marketing y de TI por igual: cuando entre en vigencia la Ley 21.719, ¿vamos a tener que migrar todo el tracking a server-side? La respuesta corta es no. La respuesta larga es más útil, porque el server-side no resuelve el problema que la mayoría cree que resuelve.

A medida que se acerca el 1 de diciembre de 2026, las conversaciones sobre la Ley 21.719 en los equipos digitales se llenan de una ansiedad técnica concreta: campañas de Google Ads, píxeles de Meta, Google Tag Manager, cookies de analítica, atribución. Y aparece, una y otra vez, la misma creencia: que la nueva ley obliga a abandonar el tracking del lado del navegador y reconstruir todo del lado del servidor.

Esa creencia es incorrecta. Y conviene desarmarla con cuidado, porque actuar sobre una premisa equivocada cuesta dinero, cuesta tiempo de equipo, y —lo más grave— puede dejar a una organización con la falsa sensación de que cumplió cuando en realidad no movió la aguja en lo que la ley realmente exige.

La ley no regula arquitectura de tracking. Regula tratamiento de datos.

La Ley 21.719 no menciona “client-side” ni “server-side” en ninguna parte. No podría hacerlo: una ley de protección de datos no legisla decisiones de arquitectura técnica, legisla el tratamiento de datos personales, sin importar dónde ocurra ese tratamiento.

Y acá está el punto que muchos equipos pasan por alto: una cookie de analítica, un identificador publicitario o un ID de visitante son datos personales tanto si viven en el navegador del usuario como si viven en tu servidor. Mover el procesamiento del browser a un servidor no cambia la naturaleza del dato. Cambia quién tiene el control del flujo, que es valioso, pero es una cuestión distinta del cumplimiento legal.

La consecuencia es directa: el requisito de la ley no es dónde corre el tag. El requisito es si tenés una base de licitud válida para ese tratamiento, si informaste al titular con transparencia, si esa base es revocable cuando corresponde, y si podés demostrar todo lo anterior ante una fiscalización.

Migrar a server-side sin resolver esas cuatro cosas es como cambiar la cerradura de una puerta que dejaste abierta.

Qué exige realmente la Ley 21.719 sobre cookies y medición

Despejado el mito, vale la pena ser preciso sobre lo que la ley sí impone a cualquier organización que mida tráfico y haga publicidad digital en Chile. Son cinco obligaciones concretas.

La primera es el consentimiento explícito para cookies y tecnologías de seguimiento no esenciales. Las cookies estrictamente necesarias para el funcionamiento del sitio —mantener una sesión, recordar un carrito— están exentas. Pero las de analítica, las de publicidad y las de perfilamiento requieren que el usuario acepte de forma activa. El consentimiento implícito por seguir navegando, o las casillas premarcadas, dejan de ser válidos.

La segunda es la simetría entre aceptar y rechazar. El banner de consentimiento debe darle la misma jerarquía visual y la misma facilidad a la opción de rechazar que a la de aceptar. Un botón grande de “Aceptar todo” junto a un enlace pequeño y escondido de “Configurar” no cumple con el estándar.

La tercera es la información clara y accesible. La organización debe explicar qué categorías de cookies usa, con qué finalidad, qué datos recoge a través de ellas y con quién los comparte. Esto se traduce, en la práctica, en una política de cookies detallada y diferenciada por categoría, no en un párrafo genérico.

La cuarta es la revocabilidad. El titular que dio su consentimiento tiene que poder retirarlo después, con la misma facilidad con la que lo otorgó. Eso obliga a que el mecanismo de gestión de preferencias sea persistente y esté siempre disponible, no que aparezca una sola vez en la primera visita.

La quinta es la trazabilidad de las transferencias internacionales. Cuando enviás datos a Google, a Meta o a cualquier plataforma con servidores fuera de Chile, ese flujo necesita una base de legitimación y debe estar documentado. Aquí es donde la conversación técnica vuelve a cruzarse con la arquitectura, pero por una razón distinta a la que la mayoría asume.

Entonces, ¿para qué sirve el server-side?

El server-side tagging no es un requisito legal, pero tampoco es una moda inútil. Resuelve problemas reales, solo que conviene nombrarlos con precisión.

Su valor central es el control del flujo de datos. En un esquema client-side tradicional, los scripts de terceros se ejecutan directamente en el navegador del usuario y envían información a esos terceros sin que la organización tenga una capa de control intermedia. En un esquema server-side, los datos pasan primero por una infraestructura que la organización controla, y desde ahí se decide qué se envía, a quién, en qué formato y bajo qué condiciones de consentimiento.

Eso tiene tres beneficios concretos para el cumplimiento. Permite aplicar las preferencias de consentimiento de forma consistente antes de que el dato salga hacia cualquier plataforma. Permite minimizar datos: enviar solo lo necesario, eliminar lo que no corresponde. Y facilita las auditorías, porque genera registros claros de qué se trató y bajo qué base, que es exactamente el tipo de evidencia que una fiscalización pide.

Pero —y este es el punto que cierra el círculo— el server-side no elimina la necesidad de consentimiento. Las soluciones de server-side tagging generan igualmente un identificador de visitante, y ese identificador es dato personal o pseudonimizado que cae bajo la ley. No existe una configuración técnica que permita “trackear sin pedir permiso”. Esa promesa, cuando aparece, es marketing, no ingeniería.

La forma correcta de pensarlo: el server-side es una decisión de arquitectura que, bien implementada y acompañada de una gestión de consentimiento sólida, hace el cumplimiento más robusto y más auditable. Mal implementada, o implementada como atajo para evitar el consentimiento, no cumple nada y agrega una falsa sensación de seguridad.

El verdadero requisito: gobernanza del consentimiento.

Si hay una sola idea para llevarse de este artículo, es esta: el problema que la Ley 21.719 te obliga a resolver no es de arquitectura de tracking, es de gobernanza del consentimiento.

Gobernar el consentimiento significa que tu organización pueda responder, en cualquier momento y con evidencia, preguntas como estas. Qué tecnologías de seguimiento corren en el sitio y qué dato recoge cada una. Sobre qué base de licitud opera cada tratamiento. Qué consintió cada titular, cuándo, y bajo qué versión de la política. Cómo se propaga ese consentimiento —o su ausencia— hacia Google Ads, hacia Meta, hacia la herramienta de analítica. Y cómo se revoca, en toda la cadena, cuando el titular cambia de opinión.

Una organización que puede responder eso cumple con la ley, corra sus tags del lado del cliente o del lado del servidor. Una organización que no puede responderlo no cumple, por más que haya migrado toda su infraestructura a un servidor propio.

Checklist técnico para llegar a diciembre de 2026.

Lo que sigue es una hoja de ruta práctica, ordenada, para equipos de marketing y TI que necesitan poner su stack de medición en regla. No requiere, en la mayoría de los casos, migrar a server-side. Requiere disciplina.

1. Inventario de tecnologías de seguimiento. Listá cada cookie, píxel, SDK y etiqueta que corre en tu sitio y tus aplicaciones. Para cada uno: qué dato recoge, con qué finalidad, a qué tercero lo envía, y si es esencial o no esencial. Sin este mapa, nada de lo que sigue es posible.
2. Implementá una plataforma de gestión de consentimiento (CMP). El banner tiene que permitir aceptar, rechazar y configurar por categoría, con la misma jerarquía visual para aceptar y rechazar. Tiene que registrar cada decisión de forma datada y auditable. Y tiene que ofrecer un punto de acceso permanente para modificar o revocar la preferencia.
3. Conectá el consentimiento con tu Tag Manager. Las etiquetas de analítica y publicidad no deben dispararse hasta que exista consentimiento para su categoría. Google Tag Manager soporta esto mediante Consent Mode: configurado correctamente, las etiquetas leen el estado de consentimiento y se comportan en consecuencia. Esto es válido y suficiente en un esquema client-side bien armado.
4. Documentá las bases de licitud. Para cada tratamiento, dejá registrado por escrito sobre qué base legal opera. Para cookies no esenciales será, casi siempre, el consentimiento. Pero documentarlo es lo que convierte una práctica en evidencia.
5. Revisá las transferencias internacionales. Identificá cada plataforma que recibe datos fuera de Chile y verificá que exista una base de legitimación documentada para esa transferencia. Esto incluye a Google, a Meta y a cualquier SaaS de marketing que uses.
6. Actualizá la política de privacidad y la política de cookies. Tienen que reflejar con precisión lo que el inventario del punto 1 reveló. Categorías, finalidades, destinatarios, plazos de retención y derechos del titular, en lenguaje claro.
7. Definí el procedimiento de revocación de punta a punta. Cuando un titular retira el consentimiento, tu organización tiene que poder detener el tratamiento en toda la cadena: en el sitio, en el Tag Manager, y en las plataformas de destino. Probalo de verdad, no en teoría.
8. Evaluá server-side solo si tenés un caso que lo justifique. Si después de los siete puntos anteriores identificás necesidades concretas —mayor control sobre qué datos salen hacia terceros, minimización más fina, requisitos de auditoría más exigentes— entonces el server-side es una buena decisión de arquitectura. Pero como una mejora deliberada, no como un requisito legal ni como un atajo.

La pregunta correcta.

La pregunta no es “client-side o server-side”. La pregunta es si tu organización tiene una base de licitud válida, informada, revocable y auditable para cada tratamiento de datos que ocurre cuando alguien visita tu sitio o ve tu publicidad.

Si la respuesta es sí, cumplís con la Ley 21.719, corra tu tracking donde corra. Si la respuesta es no, ninguna arquitectura te salva.

El 1 de diciembre de 2026 no llega a fiscalizar dónde están tus tags. Llega a fiscalizar si podés demostrar que tratás los datos de las personas con una base legítima y con su control efectivo. Esa es la conversación que conviene tener ahora, con tiempo, y no en noviembre.

¿Tu organización necesita poner en regla su stack de medición y su gestión de consentimiento antes de diciembre de 2026? En GOBERNANZA.IO ayudamos a mapear tratamientos, documentar bases de licitud y construir la evidencia que una fiscalización exige. Agendá una conversación de 30 minutos y salí con un diagnóstico claro de dónde estás parado.