Cómo el enmascaramiento de privacidad en session replay lo mantiene en cumplimiento con RGPD y CCPA

Bien hecho, el enmascaramiento de privacidad en session replay es lo que separa una herramienta de grabación que cumple la normativa de un pasivo de protección de datos, y es lo primero que pregunta un comprador cuidadoso antes de almacenar una sola sesión.

La objeción es razonable. Una repetición reconstruye lo que una persona real vio y escribió. Sin controles, eso puede incluir una dirección de correo electrónico, un número de tarjeta, una dirección postal o un detalle de salud. El RGPD y la CCPA no prohíben el session replay, pero sí tratan esa reconstrucción como datos personales, lo que significa que debe minimizarse, protegerse, conservarse durante un tiempo limitado y, en muchos casos, estar cubierta por el consentimiento.

La buena noticia es que todo el riesgo se desvanece cuando lo maneja en la capa correcta. Si el valor sensible nunca sale del navegador del visitante, no hay nada en sus servidores que se pueda filtrar, requerir judicialmente o retener en exceso.

Enmascare antes de capturar, no después

Hay dos momentos fundamentalmente diferentes en los que puede ocurrir el enmascaramiento, y solo uno de ellos protege realmente al usuario.

Enmascarar antes de capturar se ejecuta en el navegador del visitante. El grabador recorre la página, reemplaza el texto y los valores de entrada sensibles con caracteres de marcador de posición, y solo se serializa y envía la versión enmascarada. El valor sin procesar nunca se transmite. PostHog lo documenta directamente: sus controles de privacidad "se ejecutan en el navegador o en la aplicación móvil", por lo que "los datos enmascarados nunca se envían por la red". Microsoft Clarity afirma el mismo principio, que "nunca captura nada que esté enmascarado ni lo envía por la red".

Enmascarar después de capturar graba los valores reales, los envía a un servidor y los difumina o redacta en el momento de la reproducción. Los datos sin enmascarar aun así cruzaron la red y aterrizaron en una base de datos. Si ese almacén se vulnera, una regla de redacción en el reproductor no hace nada.

Para una conversación sobre cumplimiento, la distinción es todo el argumento. La minimización de datos según el artículo 5 del RGPD trata sobre no recopilar los datos, no sobre ocultarlos después.

	Enmascarar antes de capturar	Enmascarar después de capturar
Dónde se ejecuta el enmascaramiento	Navegador del visitante	Servidor o reproductor del proveedor
¿La PII sin procesar sale del dispositivo?	No	Sí
Qué expone una vulneración	Solo marcadores de posición	Valores reales
Se alinea con la minimización de datos	Sí	Débilmente
Cambios de reglas retroactivos	No es necesario	Es necesario, y no puede corregir datos pasados

Los cuatro controles que realmente lo cubren

Redacción de entradas por defecto

Toda herramienta seria enmascara las entradas de formulario de fábrica, porque ahí es donde residen las contraseñas, los números de tarjeta y los correos electrónicos. En PostHog, todas las entradas se enmascaran por defecto y los campos de contraseña siempre se enmascaran independientemente de la configuración. En Clarity, los cuadros de entrada y los menús desplegables se enmascaran en todos los modos, incluido el más permisivo. Trate cualquier herramienta que venga con las entradas visibles por defecto como una señal de alarma.

Enmascaramiento de elementos y texto

Los datos sensibles también aparecen fuera de los campos de formulario: una confirmación de pedido, un saldo de cuenta, el nombre de un paciente en un encabezado. Estos se enmascaran con selectores CSS o un atributo de datos en el elemento, que se propaga a sus elementos secundarios. PostHog usa clases como ph-no-capture; Clarity usa data-clarity-mask. La postura más segura para una aplicación de alta sensibilidad es enmascarar todo y desenmascarar de forma selectiva solo los elementos que ha confirmado que son seguros.

Exclusión de páginas y rutas

Algunas pantallas nunca deberían grabarse en absoluto, como un paso de pago, un formulario de datos bancarios o una pantalla de autenticación renderizada por un tercero. Detener e iniciar el grabador alrededor de esas rutas elimina toda la pantalla de la captura en lugar de intentar enmascararla campo por campo.

Límites de retención

Una retención que cumple la normativa significa que las grabaciones caducan según un calendario definido en lugar de vivir para siempre. Una retención más corta reduce tanto su superficie de vulneración como sus obligaciones cuando un usuario ejerce un derecho de eliminación. Establézcala en la ventana más corta que aun así responda a las preguntas sobre su producto.

Consentimiento, IP y cookies

Que necesite una aceptación explícita depende de la jurisdicción y de lo que almacene. Dos decisiones de diseño reducen drásticamente la carga:

• Sin cookies. Un grabador que no establece cookies identificativas evita el clásico desencadenante de consentimiento de ePrivacy para cookies no esenciales.
• Sin direcciones IP almacenadas. Las direcciones IP son datos personales según el RGPD. Una herramienta que las descarta en la ingesta en lugar de almacenarlas elimina uno de los identificadores sin procesar más comunes de su base de datos.

Incluso con esto implementado, trate el consentimiento como una cuestión legal para su equipo, no como una casilla que un proveedor pueda marcar por usted. Lo que un proveedor sí puede hacer es convertir la vía que cumple la normativa en la opción por defecto para que el consentimiento cubra un terreno menos sensible.

Subencargados del tratamiento y dónde residen los datos

El enmascaramiento protege el contenido de una grabación. No responde dónde se almacena esa grabación ni quién más puede tocarla. Antes de comprometerse, confirme tres cosas: la lista de subencargados del tratamiento que utiliza el proveedor, la región donde se alojan los datos de sesión y si hay disponible un Acuerdo de Tratamiento de Datos. Una propuesta de replay que prioriza la privacidad se desmorona si los datos fluyen discretamente hacia una docena de terceros no divulgados.

Cómo aborda esto Flowsery

Flowsery está diseñado para priorizar la privacidad en lugar de tratarla como algo opcional. El enmascaramiento está activado por defecto, por lo que el texto y las entradas sensibles se reemplazan en el navegador antes de que se serialice nada. Flowsery no usa cookies y no almacena las direcciones IP de los visitantes, lo que elimina dos de los identificadores más comunes antes de que lleguen a un servidor. Usted mantiene un control granular para excluir elementos y rutas específicos y para limitar cuánto tiempo se conservan las grabaciones.

El resultado es un replay que puede defender en una revisión de seguridad: el valor sensible permanece en el dispositivo del visitante, y lo que almacena ya está minimizado.

Preguntas frecuentes

¿El session replay cumple con el RGPD?

Puede hacerlo. El RGPD no prohíbe el session replay, pero trata la grabación como datos personales. Cumple la normativa minimizando lo que captura, enmascarando la PII antes de que salga del navegador, limitando la retención, protegiendo el acceso y recopilando el consentimiento donde su jurisdicción lo exija.

¿Enmascarar después de la captura satisface la CCPA y el RGPD?

Es más débil. Si los valores reales llegan a los servidores del proveedor y solo se ocultan en la reproducción, los datos sin procesar aun así se recopilaron y almacenaron, lo que socava la minimización de datos y deja esos datos expuestos en una vulneración. Enmascarar antes de la captura es la posición más sólida.

¿Qué se enmascara automáticamente?

En las herramientas que priorizan la privacidad, las entradas de formulario se enmascaran por defecto y los campos de contraseña siempre se enmascaran. El texto libre, los encabezados y las imágenes que puedan contener datos personales se enmascaran mediante selectores CSS, un atributo de datos o una configuración global de enmascarar todo.

¿Sigo necesitando un banner de consentimiento?

Depende de su jurisdicción y de lo que almacene. Un grabador sin cookies que no retiene direcciones IP reduce los desencadenantes, pero el consentimiento es una determinación legal. Confirme sus obligaciones con su propio asesor legal o equipo de privacidad.

¿Puedo cambiar las reglas de enmascaramiento de forma retroactiva?

No. El enmascaramiento se aplica en el momento de la captura, por lo que un cambio de regla solo afecta a las nuevas grabaciones. Cualquier cosa ya capturada conserva el enmascaramiento que estuviera en vigor entonces, lo cual es otra razón para empezar estricto y relajar de forma deliberada.

Grabe sesiones sin grabar PII con Flowsery - enmascaramiento activado por defecto, sin cookies y sin IP almacenadas.

Fuentes: Controles de privacidad de session replay de PostHog y Enmascaramiento de contenido de Microsoft Clarity. Consultado el 24 de julio de 2026.