Eliminado de la base de datos - vivo en las copias de seguridad

Toda empresa tiene una política de retención. Vive en un documento en algún lugar, probablemente actualizado por última vez cuando alguien se dio cuenta de que se acercaba la auditoría, y dice algo con confianza como "los datos personales se eliminan después de 90 días", un número elegido para sonar impresionantemente corto en lugar de derivado de cualquier análisis documentado de limitación de propósito. La gerencia asiente. El departamento legal lo aprueba. El documento se archiva.

Los datos, mientras tanto, son inmortales. Particularmente en las copias de seguridad, que nadie mencionó durante la reunión de política, y que han estado reteniendo silenciosamente todo durante los últimos tres años.

Esta es la brecha de la que nadie habla: la diferencia entre tener una política de retención y realmente aplicarla. Escribir la política lleva una tarde. Aplicarla en un sistema de producción real (bases de datos, copias de seguridad, registros, procesadores de terceros, exportaciones archivadas, almacenes de datos, copias en la sombra) lleva considerablemente más tiempo y saca a la luz decisiones arquitectónicas que probablemente no tomaste pensando en la eliminación.

¿Por qué la mayoría de las aplicaciones de retención fallan antes de empezar?

El problema central es que los datos se acumulan en más lugares de los que conocían las personas que escribieron la política. Estaban pensando en la base de datos principal. No estaban pensando en el pipeline de registro que captura cuerpos de solicitudes que contienen datos de usuario, retenidos indefinidamente porque nadie estableció una política de rotación de registros que realmente se ejecute. O el almacén de análisis donde se volcaron datos de eventos brutos hace dieciocho meses para un proyecto que nunca se lanzó, que aún contiene identificadores de usuario completos porque la seudonimización estaba "en la hoja de ruta". O la copia de seguridad diaria de la base de datos que se guarda durante noventa días, lo que significa que los datos que eliminaste de tu base de datos en vivo el primer día permanecen intactos en una copia de seguridad hasta el día noventa y uno, posiblemente más si alguien archivó manualmente una copia antes de un lanzamiento importante "por si acaso".

Tu obligación de retención también se extiende a cada integración de terceros que mapeaste en la publicación anterior. Si eliminas un usuario de tu sistema pero tu CRM aún tiene su registro, tu herramienta de monitoreo de errores aún tiene sus rastros de pila, y tu API de modelo de IA aún tiene su historial de conversación en un conjunto de datos de ajuste fino, en realidad no has eliminado nada. Solo has eliminado la copia que controlas.

Y luego está el CSV que alguien exportó para un análisis puntual y guardó en su computadora portátil. No puedes automatizar la salida de eso, pero puedes convertirlo en un problema disciplinario en lugar de una ocurrencia tardía técnica.

Eliminación, anonimización, seudonimización: por qué la distinción importa

Antes de escribir una sola línea de código de eliminación, decide qué enfoque vas a tomar, porque son realmente diferentes y el GDPR los trata de manera diferente.

Eliminación significa que los datos han desaparecido. Si alguien presenta una Solicitud de Acceso del Interesado después de la eliminación, la respuesta correcta es "no tenemos datos sobre usted". Limpio, simple y lo más difícil de implementar limpiamente a escala.

Anonimización significa que los datos aún existen pero ya no se pueden vincular a ningún individuo. Ni por ti, ni por nadie, ni siquiera con conjuntos de datos adicionales o un esfuerzo razonable. Si haces esto correctamente, el GDPR ya no se aplica a los datos anonimizados. Puedes conservarlos indefinidamente. Úsalos para análisis, conjuntos de datos de QA, entrenamiento de modelos, pruebas de carga, lo que necesites. Esto no es una laguna. Es la solución prevista. El GDPR fomenta activamente la anonimización precisamente para que las organizaciones puedan retener datos para fines secundarios legítimos sin que el reloj de retención esté en marcha. La regulación quiere que hagas esto. Solo quiere que lo hagas correctamente.

El problema es que la anonimización adecuada es más difícil de lo que parece. Eliminar un nombre y un correo electrónico de un registro no es anonimización si los campos restantes (rango de edad, código postal, puesto de trabajo, fecha de creación de la cuenta) son lo suficientemente específicos como para que una persona decidida pueda identificar al individuo de todos modos. Esto se llama riesgo de reidentificación, y subestimarlo es cómo los proyectos de anonimización se convierten silenciosamente en proyectos de seudonimización que no engañan a nadie, y mucho menos a un regulador.

La seudonimización (reemplazar identificadores directos con tokens mientras se mantiene una tabla de mapeo en algún lugar) es útil operativamente y el GDPR te da crédito por hacerlo, pero no satisface una obligación de eliminación por sí sola. El individuo sigue siendo identificable a través de la tabla de mapeo. Eliminar la tabla de mapeo ayuda, pero tampoco se garantiza que sea suficiente, porque los registros seudonimizados aún pueden ser reidentificables a través de otros atributos en el conjunto de datos. Si planeas confiar en la seudonimización para satisfacer las obligaciones de retención, obtén una opinión adecuada antes de enviar el trabajo y no después.

La división práctica para la mayoría de los desarrolladores: elimina los datos personales que ya no necesitas para el propósito original, anonimiza los datos que tienes una razón legítima y genuina para retener para fines secundarios como QA, pruebas y mejora de modelos. Realiza la anonimización correctamente: elimina los identificadores directos, evalúa el riesgo de reidentificación contra los campos restantes, documenta tu evaluación. Si no puedes hacer eso con confianza, elimina en su lugar. Hacer mal la anonimización y darla por terminada es peor que no intentarlo.

Cómo implementar realmente la eliminación

Comienza mapeando cada lugar donde residen los datos de un usuario. No los lugares donde crees que residen. Los lugares donde realmente residen. Realiza el ejercicio de la misma manera que realizaste la auditoría de integración en la publicación anterior: comienza con lo que es observable (tablas de bases de datos, destinos de registros, integraciones de terceros), no con lo que dice el diagrama de arquitectura.

Para cada ubicación, responde tres preguntas. ¿Puedes eliminar o anonimizar bajo demanda? ¿Puedes automatizar esa eliminación en un horario? ¿Puedes verificar que la eliminación se realizó?

La tercera pregunta es la que la mayoría de los equipos omiten. Un trabajo de eliminación que falla silenciosamente e informa éxito es peor que ningún trabajo de eliminación, porque ahora tienes un registro de cumplimiento que afirma que los datos fueron eliminados cuando no lo fueron. Incorpora la verificación desde el principio. Registra la eliminación, registra el recuento de registros afectados, alerta sobre eliminaciones de recuento cero para usuarios que deberían haber tenido datos.

Para tu base de datos principal, la eliminación suele ser sencilla: un trabajo programado con clave en created_at o last_active, con un período de eliminación suave si tu equipo de soporte necesita una ventana de recuperación. El período de eliminación suave también es un período de retención. Defínelo explícitamente y aplícalo.

Para los registros, establece políticas de retención a nivel de pipeline, no como una tarea de limpieza manual. Si tu infraestructura de registro lo admite, filtra la PII de las entradas de registro en la ingesta en lugar de intentar eliminarla más tarde. Eliminar registros específicos de un flujo de registro retroactivamente es doloroso. No escribirlos en primer lugar es mucho más fácil.

Para las copias de seguridad, acepta que habrá un retraso. Si tus copias de seguridad se retienen durante treinta días, los datos eliminados de tu sistema en vivo persistirán en las copias de seguridad durante un máximo de treinta días. Documenta esto. Generalmente es aceptable bajo el GDPR siempre que tu política de retención lo tenga en cuenta y no estés utilizando las copias de seguridad como una forma de eludir las obligaciones de eliminación. Lo que no es aceptable es mantener las copias de seguridad indefinidamente porque nadie revisó la configuración de retención en el trabajo de copia de seguridad.

Para los procesadores de terceros, las solicitudes de eliminación deben fluir hacia abajo. Esto significa llamadas a la API automatizadas para activar la eliminación con cada procesador, o un proceso manual documentado con un registro de finalización. La mayoría de los principales proveedores admiten API de eliminación. Úsalas. Para los proveedores que no lo hacen, esa es una conversación que debes tener antes de confiar en ellos para cualquier cosa que involucre datos personales.

El problema de las copias de seguridad en términos sencillos

Las copias de seguridad merecen su propio párrafo porque es donde la mayoría de los programas de retención se desmoronan silenciosamente.

Una copia de seguridad es una instantánea en un momento dado. Cuando eliminas datos de tu sistema en vivo, esa eliminación no se propaga a las copias de seguridad existentes. Los datos eliminados aún existen en cada copia de seguridad realizada antes de la eliminación. Esto está bien y es lo esperado. La pregunta es cuánto tiempo se guardan esas copias de seguridad.

La respuesta en la mayoría de las empresas es "más tiempo del que nadie se dio cuenta". La configuración de retención de copias de seguridad se configura una vez y se olvida. El almacenamiento es barato. Nadie audita la política de retención de copias de seguridad contra la política de retención de datos. El resultado es un cementerio de instantáneas en el tiempo que contienen los datos personales de usuarios que eliminaron sus cuentas hace años.

Revisa la configuración de retención de tus copias de seguridad ahora. Alinéalas con tu política de retención de datos. Si tu política dice que los datos se eliminan después de noventa días, tus copias de seguridad no deben retenerse durante un año. Y si recibes una solicitud de eliminación para un individuo específico, anota en tus registros que la eliminación se completará una vez que expire la ventana de copia de seguridad relevante. Esa es la respuesta honesta y es defendible.

Cómo se ve un buen resultado

Un programa de retención que realmente funciona tiene cuatro propiedades.

Está automatizado. Los procesos de eliminación manual fallan porque la gente olvida, se enferma, deja la empresa y hereda el atraso de eliminación de quien se fue antes que ellos. Si no está automatizado, no es un programa de retención. Es una buena intención.

Está verificado. Cada trabajo de eliminación produce un registro de lo que se eliminó, cuándo y cuántos registros se vieron afectados. Las anomalías activan alertas. El registro de verificación se retiene. Sí, hay cierta ironía en mantener registros sobre tus registros de eliminación, pero así es como se ve la evidencia de auditoría.

Cubre todo el patrimonio de datos. Base de datos principal, registros, copias de seguridad, procesadores de terceros, almacenes de datos, archivos exportados cuando sea posible. La aplicación de la retención que solo afecta a la base de datos principal no es una aplicación de la retención. Es ordenar un estante mientras el resto de la casa se acumula.

Está probado. Ejecuta un trabajo de eliminación en un conjunto de datos de prueba antes de ejecutarlo en producción. Verifica el resultado. Haz esto cada vez que cambie el trabajo. "El trabajo de eliminación se ejecuta" y "el trabajo de eliminación funciona correctamente" son afirmaciones diferentes y quieres pruebas para ambas.