La privacidad es lo que queda cuando el sistema aprende a olvidar

El derecho al olvido no es un botón etiquetado como «eliminar». En los sistemas modernos, es una cuestión disciplinada sobre copias, datos derivados,...

La privacidad es lo que queda cuando el sistema aprende a olvidar

Olvidar no es lo contrario de recordar

Un archivo en papel tiene una vida visiblemente tranquilizadora. Llega, se guarda en algún sitio, se copia si alguien tiene una fotocopiadora y, finalmente, acaba en una trituradora o en un archivo histórico. Lo difícil puede ser decidir si debe destruirse, pero el objeto en sí es obedientemente finito. Un registro digital es menos educado. Puede almacenarse como una fila, un adjunto, un índice de búsqueda, una vista previa de mensaje, un bloque de copia de seguridad, una entrada de auditoría, una característica en una entrada de modelo, un vector en un almacén de incrustaciones, una respuesta en caché o un valor que ha viajado al sistema de otra organización. No basta con preguntar dónde vive el original. La pregunta más útil es qué se ha hecho a partir de él, qué sigue permitiendo identificar a una persona y qué propósito cumple cada rastro restante.

Esa es la dignidad práctica del derecho al borrado. A menudo se le llama derecho al olvido, que es una expresión gráfica pero imperfecta. El olvido humano es accidental, parcial y está lleno de retornos embarazosos. Un proceso de borrado legal debería ser deliberado. Debería poder distinguir entre un registro que debe eliminarse y un registro que debe conservarse porque la ley lo exige, una reclamación en disputa que debe permanecer disponible para una defensa legal, y un residuo técnico que puede aislarse hasta su caducidad programada. También debería resistir un instinto corporativo útil: tratar la eliminación como un estado de pantalla en lugar de una propiedad de los sistemas.

El Reglamento General de Protección de Datos no promete que todo elemento relacionado con una persona desaparezca a petición. El artículo 17 establece los motivos por los que un responsable debe borrar los datos personales sin dilación indebida, incluidos los casos en que los datos ya no sean necesarios para la finalidad para la que fueron recogidos o tratados, cuando se retire el consentimiento y no exista otro fundamento jurídico, y cuando el tratamiento haya sido ilícito. El mismo artículo fija límites. El borrado no se aplica cuando el tratamiento sea necesario, por ejemplo, para la libertad de expresión e información, una obligación legal, tareas de interés público en algunas circunstancias, motivos de salud pública, archivo, investigación o estadística sujetos a salvaguardas, o reclamaciones legales. Eso no es una laguna en una promesa. Es la forma real del derecho.

Así que la pregunta para el responsable de un sistema no es: «¿Podemos eliminar datos?». Casi cualquier sistema puede eliminar algo. La pregunta es si la organización puede explicar, para una solicitud concreta y una finalidad de tratamiento concreta, qué datos posee, qué ha ocurrido con esos datos, qué está obligada o autorizada a conservar, a qué destinatarios posteriores debe informar y cómo puede comprobarse la acción completada. La diferencia suena procedimental. En la práctica es arquitectónica. Un producto que solo sabe añadir información descubrirá que la eliminación es una característica mucho más cara.

Esto es especialmente acusado en los sistemas de IA, pero no se limita a la IA. La búsqueda, la analítica, la atención al cliente, la identidad, la supervisión de seguridad y la gestión documental producen derivados. Un modelo solo da nombres nuevos al problema: tokens, gradientes, incrustaciones, índices de recuperación, avisos y salidas. Ninguna de esas etiquetas disuelve la cuestión subyacente de si una persona física sigue siendo identificable. Tampoco un término técnico responde en silencio a la cuestión legal. Una incrustación no es automáticamente anónima porque sea difícil de leer. Un registro no es automáticamente necesario porque sea útil. Una copia de seguridad no está automáticamente exenta porque sea incómoda.

La privacidad después del olvido no es, por tanto, una página en blanco. Es el estado residual que permanece después de que una organización haya tomado una decisión legal, proporcionada y verificable sobre lo que ya no debe tratarse. La calidad de ese estado residual dice a las personas mucho más sobre un sistema que la presencia de un botón de eliminar.

El derecho tiene condiciones, y eso lo hace más fuerte

La legislación europea de protección de datos se describe a veces como si ofreciera al individuo un botón rojo universal. Esa imagen resulta lo bastante ordenada para una diapositiva y lo bastante errónea para causar problemas. El artículo 17 está vinculado a la finalidad, la base jurídica y las circunstancias del tratamiento. Contiene un derecho, obligaciones para los responsables y excepciones que protegen otros derechos e intereses públicos. Una respuesta responsable comienza por determinar la identidad del solicitante cuando sea necesario, comprender los datos y la finalidad del tratamiento implicados, y decidir si se aplican un motivo del artículo 17 y una excepción. La respuesta puede ser el borrado. Puede ser una denegación motivada, total o parcial. Puede ser la limitación del tratamiento mientras se resuelve una controversia. También puede ser una solicitud que apunte a un sistema que la organización no controla.

Esto no es razón para convertir una solicitud del interesado en una pequeña carrera de obstáculos. El RGPD exige que los responsables faciliten el ejercicio de los derechos. El artículo 12 exige que la información y las comunicaciones sobre las medidas adoptadas ante una solicitud sean concisas, transparentes, inteligibles y de fácil acceso. En general, exige que se informe sobre las medidas adoptadas sin dilación indebida y, en cualquier caso, dentro del mes siguiente a la recepción. El plazo puede prorrogarse dos meses más cuando sea necesario, teniendo en cuenta la complejidad y el número de solicitudes, pero el responsable debe informar a la persona de la prórroga y de sus motivos dentro del primer mes. Un sistema que no puede identificar sus propios flujos de datos hasta el tercer mes no ha encontrado una defensa procesal. Ha encontrado un problema de gobernanza.

Las orientaciones del Comité Europeo de Protección de Datos para pequeñas y medianas empresas exponen con claridad el punto operativo: las personas pueden solicitar el borrado en circunstancias concretas, y las organizaciones deben disponer de procedimientos para responder a las solicitudes de derechos. Un procedimiento no es un dictamen jurídico guardado en una unidad compartida. Es una vía de trabajo desde la solicitud hasta la decisión y la ejecución. Incluye los roles autorizados para tomar una decisión, los mapas de datos que les permiten ver el tratamiento pertinente, los proveedores y destinatarios que pueden necesitar una notificación, los plazos de conservación que explican una excepción y las pruebas que permitan a un revisor posterior entender lo que se hizo.

El Tribunal de Justicia ha contribuido a visibilizar otra distinción. Sus sentencias sobre la desindexación se refieren a la presentación de enlaces por los motores de búsqueda, no a una orden de borrar la publicación subyacente del sitio web de origen. En el asunto Google Spain, el Tribunal consideró que el gestor de un motor de búsqueda puede ser responsable del tratamiento de datos personales que aparecen en páginas web publicadas por terceros, y que el interesado puede, en determinadas circunstancias, solicitar la retirada de enlaces de una lista de resultados mostrada tras una búsqueda por su nombre. En sentencias posteriores, el Tribunal abordó cuestiones como los datos sensibles, el ámbito territorial de la desindexación y la información inexacta. Esas sentencias no convierten cualquier dato molesto en una pretensión de borrado. Muestran por qué un sistema debe nombrar la capa afectada: publicación de origen, índice, lista de resultados, caché, extracto u otra copia.

Esa disciplina de capas también importa dentro de las organizaciones. Un empleado puede pedir a un responsable que borre un registro de contacto que ya no es necesario para una finalidad de contratación. El responsable puede tener que evaluar una obligación de conservación independiente para la nómina o las pruebas de igualdad de trato. Un organismo público puede tratar un registro en el ejercicio de una tarea legal y necesitar evaluar la legislación aplicable en lugar de repetir una respuesta del sector privado. Un editor puede necesitar ponderar la libertad de expresión e información. El resultado no puede decidirse únicamente con el vocabulario de las bases de datos.

Resulta tentador resentir las condiciones porque impiden una promesa sencilla. Pero son ellas las que dan sentido a la promesa. Un derecho que ignora las obligaciones legales, los demás derechos fundamentales y la distinción práctica entre sistemas acabaría reduciéndose a un ritual. El enfoque europeo exige una decisión responsable, no una teatral. Eso requiere más trabajo. También hace que una negativa pueda impugnarse y que un borrado resulte creíble.

El borrado comienza por localizar las superficies de tratamiento. El diagrama es un mapa de sistemas, no una afirmación de que todas las superficies reciban el mismo tratamiento legal.

Un registro puede desaparecer de la pantalla y permanecer en el sistema

El fallo de borrado más fácil de cometer lo conoce cualquiera que haya construido una aplicación: quitar un elemento de la interfaz del producto, dejar los datos subyacentes en un almacén y dar por hecho que el trabajo está hecho porque los usuarios normales ya no pueden verlo. A veces un borrado lógico es exactamente el diseño operativo correcto. Puede preservar un breve periodo de deshacer, hacer seguro el replicado o evitar romper una relación que debe resolverse. Pero el borrado lógico no es un borrado efectivo solo porque la interfaz se haya vuelto más silenciosa. Su uso debe estar vinculado a una finalidad definida, un periodo de retención, controles de acceso y una acción posterior que realmente cambie el estado de los datos.

El borrado físico también tiene sus límites. Eliminar una fila puede dejar un índice de búsqueda hasta el siguiente ciclo de indexación. Un almacén de objetos puede tener control de versiones. Una caché de entrega de contenido puede conservar una respuesta hasta su caducidad o invalidación. Una cola de mensajes puede contener un evento aún no procesado. Un almacén de datos puede haber ingerido una instantánea. Un servicio puede haber transferido los datos a un encargado del tratamiento, a un subencargado o a un destinatario. La lección práctica no es que el borrado sea imposible. Es que una organización necesita un inventario con la fidelidad suficiente para distinguir estas superficies y una política que indique qué ocurre en cada una de ellas.

Existe además una distinción entre contenido y evidencia. Un ticket de atención al cliente puede contener el mensaje de una persona. Un sistema puede necesitar un registro de que un ticket existió, se resolvió y se eliminó conforme a una regla aprobada. Conservar el mensaje completo para siempre para demostrar que se eliminó es una pequeña obra maestra burocrática, pero no un control de privacidad. Un diseño mejor conserva únicamente la evidencia mínima necesaria para la rendición de cuentas, separada del contenido que ya no tiene finalidad. Esa evidencia puede ser un identificador de solicitud, el tipo de decisión, el momento de finalización, la categoría de retención aplicable y los sistemas alcanzados. El diseño depende de la organización. El principio no: la prueba no debe recrear los datos personales innecesarios.

Las copias de seguridad merecen el mismo lenguaje claro. Una copia de seguridad puede ser necesaria para la disponibilidad, la seguridad o la recuperación ante desastres. Sigue siendo tratamiento. La cuestión práctica es si la copia es accesible por separado, durante cuánto tiempo sigue siendo recuperable, quién puede restaurarla, si está incluida en el flujo normal de borrado y cómo se evita que un entorno restaurado reintroduzca silenciosamente datos que ya se han eliminado del sistema en producción. Una política razonable puede basarse en el periodo de rotación definido de la copia en lugar de modificar individualmente cada bloque histórico de la copia. Pero una política debe decirlo, proteger el acceso mientras tanto y garantizar que la restauración siga el estado actual de los datos siempre que sea posible. «Está en la copia de seguridad» describe un problema. No es una respuesta a ese problema.

Los registros son similares. Los registros de seguridad y operativos pueden ser esenciales. Pueden ser la única constancia de un acceso, de un intento de autenticación fallido o de un cambio en producción. También pueden conservar identificadores, direcciones, cuerpos de solicitud o fragmentos de contenido que nunca fueron necesarios para el diagnóstico. Un buen diseño de registro minimiza la recopilación, enmascara o seudonimiza cuando procede, separa las cargas útiles sensibles de los metadatos de eventos, limita el acceso y aplica calendarios de retención. Intentar descubrir cada campo sensible durante una solicitud de borrado es posible, pero es un mal sustituto de decidir en el momento del diseño qué debería haber contenido nunca el registro.

Un responsable técnico no necesita prometer un borrado inmediato y uniforme en todos los dispositivos para actuar con responsabilidad. Sí necesita poder indicar el ciclo de vida: qué deja de estar disponible de inmediato, qué se elimina en la siguiente ejecución del proceso, qué persiste según un calendario de retención documentado, qué permanece protegido hasta su expiración y qué ocurrirá si se realiza una operación de recuperación. Esa explicación ofrece a una persona, a un regulador y a un operador algo concreto que examinar. Una notificación verde les ofrece muy poco.

Los datos derivados no son una vía de escape

Los sistemas modernos suelen transformar los datos personales antes de utilizarlos. Extraen una fecha de un documento, clasifican un mensaje, calculan una puntuación, infieren un idioma, crean un índice de búsqueda, generan un resumen, vinculan dos cuentas o convierten texto e imágenes en vectores utilizados para la búsqueda por similitud. Esas transformaciones pueden ser útiles. También pueden hacer que una organización sienta que ha ido más allá de los datos personales. No necesariamente es así.

El RGPD es tecnológicamente neutro. Sus considerandos explican que los datos seudonimizados que pudieran atribuirse a una persona física mediante información adicional deben considerarse información sobre una persona física identificable. También explican que la identificabilidad debe tener en cuenta todos los medios que razonablemente sea probable utilizar, por el responsable o por otra persona, considerando factores como el coste, el tiempo, la tecnología disponible y la evolución tecnológica. La cuestión no es si una representación parece un nombre en una hoja de cálculo. Es si se refiere a una persona identificada o identificable en el contexto real.

Un embedding hace que este punto resulte incómodamente ilustrativo. En un sistema de recuperación, un documento puede dividirse en fragmentos y representarse como vectores numéricos para que una consulta pueda encontrar material semánticamente similar. El vector no es un párrafo legible. Sin embargo, puede estar vinculado a un documento de origen, un inquilino, un usuario, un control de acceso, un campo de metadatos o una clave de recuperación. Puede permitir que el sistema seleccione material personal en respuesta a una consulta. La organización no puede calificarlo de anónimo simplemente porque una persona no pueda reconstruir una frase mirando una lista de coordenadas. Debe evaluar la representación, los datos asociados, los medios de vinculación y la finalidad del tratamiento.

Lo mismo se aplica a una puntuación derivada. Una puntuación de riesgo, una categoría de preferencia o un indicador de elegibilidad pueden contener menos detalle bruto que los datos de origen y aun así tener efectos graves para la persona. Pueden ser datos personales si se refieren a una persona identificada o identificable. Eliminar el origen y conservar una puntuación que sigue influyendo en una decisión no es una respuesta limpia. Puede simplemente trasladar a la persona a una forma más opaca. El sistema necesita una regla para los derivados: cuáles se eliminan con el origen, cuáles se recalculan, cuáles ya no pueden utilizarse, cuáles deben conservarse en virtud de una obligación separada y quién decide.

No existe una prueba técnica universal que resuelva todos los derivados. Algunas estadísticas agregadas pueden ser anónimas. Otras pueden seguir siendo vulnerables a la individualización o la vinculación. Algunos parámetros de modelos pueden no ser razonablemente atribuibles a una persona en un contexto determinado. Otros pueden estar asociados con datos de entrenamiento, un modelo de alcance limitado o una superficie de ataque que modifica la evaluación. El concepto de información anónima del RGPD no es una etiqueta decorativa para datos a los que se ha hecho difíciles de interpretar. El responsable debe realizar una evaluación basada en los medios y el contexto de identificación.

Esa incertidumbre no es motivo para describir todo derivado como permanentemente tóxico. Es un motivo para mantener la trazabilidad. Un equipo debe saber qué colecciones de entrada se utilizaron para un almacén de características, un índice, una ejecución de entrenamiento o una tabla de informes; qué versiones de un derivado se produjeron; qué sistemas los consumen; y qué respuesta debe desencadenar un cambio en la fuente. La trazabilidad convierte una pregunta incómoda en una tarea de ingeniería acotada. Sin ella, cada solicitud de derechos se convierte en una expedición arqueológica a través de nombres de trabajos, cubos de almacenamiento y la memoria de alguien sobre una migración de hace dos inviernos.

El aprendizaje automático añade una pregunta difícil, no una exención mágica

El aprendizaje automático dificulta el borrado porque el entrenamiento no es una operación de archivo. Un ejemplo de entrenamiento puede afectar a los parámetros a través de una larga secuencia de actualizaciones, junto con muchos otros ejemplos. Un modelo desplegado puede haberse copiado en varios entornos. Un modelo posterior puede haberse ajustado a partir de uno anterior. Un equipo puede utilizar datos de evaluación, indicaciones, corpus de recuperación y registros de comentarios que siguen ciclos de vida diferentes. Si los datos de una persona han entrado en un sistema de este tipo, una organización no puede responder responsablemente con un encogimiento de hombros sobre las matemáticas. Tampoco puede prometer honestamente que la eliminación de una base de datos elimina toda influencia posible de cada parámetro.

El primer paso es separar los sistemas. Un corpus de recuperación no es un modelo entrenado. Si un documento se utiliza como fuente de recuperación, el borrado puede implicar eliminar o deshabilitar el documento, sus fragmentos, metadatos y entradas de índice, y luego comprobar que la recuperación ya no lo alcanza. Un registro de indicaciones no es un almacén de incrustaciones. Un conjunto de datos de ajuste fino no es un registro de auditoría de seguridad. Un punto de control del modelo no es un registro de fuente actual. La respuesta correcta puede ser diferente para cada superficie, pero no se puede diseñar una respuesta hasta que se nombren las superficies.

Para los datos de entrenamiento, el análisis jurídico y técnico puede requerir una decisión sobre si el reentrenamiento, la sustitución, la restricción, la retención u otra medida es adecuada. La investigación sobre el desaprendizaje automático es relevante porque explora métodos para reducir la influencia de datos concretos sin reentrenar un modelo desde cero. No es un certificado general de que un sistema ha olvidado. Los métodos tienen supuestos, clases de modelos, condiciones de datos y límites de verificación. Una organización no debe comercializar una técnica experimental como una implementación universal del artículo 17. Tampoco debe esperar a una técnica perfecta antes de diseñar mejores controles de datos.

Mejores controles comienzan aguas arriba. Minimiza los datos recopilados. Separa los datos personales del material de entrenamiento cuando el propósito previsto lo permita. Establece un período de retención antes de que la acumulación haga que la pregunta sea emocionalmente costosa. Mantén registros versionados de conjuntos de datos y ejecuciones de entrenamiento. Haz explícitas las condiciones de consentimiento u otras condiciones legales cuando sean la base pertinente. Evita que un archivo de indicaciones de producción se convierta silenciosamente en un corpus de desarrollo de modelos. Mantén los datos de evaluación y soporte distinguibles de los datos de entrenamiento. Cuanto menos dependa un sistema de una procedencia desconocida, con más precisión podrá responder a una pregunta de eliminación.

También existe un límite a la palabra «influencia». Una persona puede preocuparse de que un texto formara parte en su momento de un conjunto de entrenamiento. Un equipo técnico puede ser capaz de determinar que el registro de origen se eliminó de un corpus actual, pero no demostrar, en un sentido filosófico amplio, que no queda ningún fragmento de influencia en ningún parámetro de un modelo histórico. La normativa de privacidad no se vuelve más sencilla cuando una organización sustituye una descripción concreta por metafísica. La obligación es evaluar el tratamiento, las bases y las medidas conforme a la ley. La organización debe explicar el alcance de su conclusión, los sistemas que abarca y la limitación restante. La precisión es más amable que una promesa extravagante.

Para los responsables del despliegue de IA, la carga práctica recae a menudo tanto en la contratación como en la ingeniería. Un proveedor debería poder explicar qué hace con las indicaciones, los archivos subidos, la telemetría y los comentarios opcionales; cuáles de ellos se utilizan para el entrenamiento o la mejora del servicio; qué controles de retención existen; cómo puede obtener un cliente la información necesaria para responder a las solicitudes de derechos; y qué ocurre en un entorno compartido frente a uno dedicado. Un contrato que simplemente dice «cumple el RGPD» no ha proporcionado la información necesaria para operar un proceso de supresión. Ha proporcionado un adjetivo.

Los motores de búsqueda enseñan una lección útil sobre las capas

La jurisprudencia del Tribunal de Justicia sobre la exclusión de resultados es útil aquí precisamente porque es más limitada que la frase popular «derecho al olvido». Los asuntos se refieren a si un motor de búsqueda debe eliminar enlaces de los resultados basados en el nombre de una persona y bajo qué condiciones. No crean un poder simple para alterar la historia en su origen. Esa distinción demuestra que las cuestiones de privacidad suelen versar sobre cómo se pone a disposición la información, cómo se conecta y cómo se amplifica, y no solo sobre si existió un registro en algún momento.

En el asunto Google Spain, el Tribunal examinó los enlaces de la lista de resultados de un motor de búsqueda a páginas publicadas por un tercero. La sentencia dejó claro que la actividad de un motor de búsqueda puede constituir tratamiento de datos personales y que, en determinadas condiciones, puede exigirse al operador que elimine enlaces de los resultados mostrados tras una búsqueda por el nombre de una persona. La sentencia no fue una orden al periódico que publicó los avisos originales. El responsable de un sistema que examine una base de conocimiento interna puede aprender de esto: los índices de búsqueda, las vistas previas y la clasificación de resultados son capas de tratamiento con consecuencias propias.

GC y otros examinaron solicitudes de eliminación de enlaces a páginas web que contenían datos personales sensibles. El Tribunal abordó la ponderación implicada y las obligaciones que pueden surgir para el operador de un motor de búsqueda. Google contra CNIL abordó el alcance territorial y determinó, en las circunstancias de ese asunto, que el Derecho de la UE no exigía la exclusión de resultados en todas las versiones de un motor de búsqueda en todo el mundo, al tiempo que exigía medidas efectivas para impedir o desalentar seriamente el acceso desde los Estados miembros a los enlaces eliminados de las versiones de la UE. TU y RE se referían a una solicitud relativa a información presuntamente inexacta y aclararon elementos de la carga de la prueba y el tratamiento de las imágenes de vista previa. Estas sentencias son decisiones jurídicas específicas de cada caso, no una lista de verificación para el despliegue. En conjunto plantean un punto sistémico: el enlace, la lista de resultados, la vista previa de la imagen y la página original no tienen automáticamente la misma solución.

Ese punto se traslada bien. Un portal corporativo puede conservar lícitamente un registro de origen para un fin limitado mientras que el acceso a través de una amplia superficie de búsqueda resulta excesivo. Un sistema de soporte técnico puede necesitar una entrada de auditoría protegida mientras que su vista previa de autocompletado no debería mostrar los datos de un antiguo cliente a un grupo numeroso. Un documento puede eliminarse de un corpus de recuperación mientras que un resumen generado por un modelo permanece en un almacén distinto. La respuesta correcta no es declarar que todas las capas son idénticas. Es comprender cómo la capa cambia la exposición, la finalidad y el riesgo.

También advierte contra un atajo popular: suponer que la visibilidad es el único problema de privacidad. Un registro puede estar técnicamente oculto y aun así ser procesado, consultado, perfilado, transferido o restaurado. Por el contrario, una organización puede necesitar un registro cuidadosamente limitado para demostrar que respondió adecuadamente, proteger una reclamación legal o cumplir una obligación legal. La privacidad no es una competición para producir la menor cantidad de datos en cualquier circunstancia imaginable. Es una disciplina de finalidad, necesidad, proporcionalidad y control.

Por eso, un inventario de supresión debe incluir las rutas de recuperación y presentación. Pregunte qué índices contienen el registro, qué cachés lo sirven, qué exportaciones lo incluyen, qué API lo devuelven, qué campos derivados se usan para clasificar o recomendar, y qué rutas de restauración de copias de seguridad podrían reactivarlo. La lista no será elegante. Será más útil que la elegancia.

Demostrar es diferente de afirmar

Cuando un sistema afirma que puede borrar datos, hay dos preguntas distintas. La primera es si el diseño tiene una ruta legítima y documentada para hacerlo. La segunda es si una organización puede demostrar que se siguió esa ruta para una solicitud concreta sin conservar más material personal del que la demostración requiere. La primera es una capacidad del producto. La segunda es responsabilidad.

Un registro de supresión útil es deliberadamente modesto. No necesita reproducir la solicitud completa de una persona, sus documentos o su historial de cuenta en una nueva base de datos de cumplimiento. Puede registrar una referencia de solicitud, el resultado de la verificación de identidad cuando proceda, la categoría de la solicitud, los sistemas aplicables, la decisión y la justificación legal a un nivel adecuado, las fechas de las acciones, las excepciones o motivos de conservación, las notificaciones a los destinatarios cuando sea necesario, y el estado de la supresión asíncrona o la caducidad de las copias de seguridad. Los campos exactos dependen del responsable y del contexto. Lo que importa es que un revisor posterior pueda ver la ruta sin reconstruir el contenido sensible a partir de fragmentos.

La verificación debe coincidir con la superficie de datos. Un registro de aplicación en vivo se puede comprobar confirmando que una consulta autorizada ya no lo devuelve. Un sistema de recuperación se puede probar con el identificador original y los patrones de consulta relevantes, evitando intentos amplios de recrear contenido personal. Un índice puede informar de su estado de supresión. Una cola puede mostrar su finalización. Un proceso de copia de seguridad puede mostrar que una imagen de recuperación está protegida según su regla de retención y que la restauración aplica un registro de supresión actualizado o un control equivalente. La verificación no necesita demostrar un negativo metafísico. Necesita proporcionar evidencia proporcional a la afirmación que se hace.

Aquí hay una trampa sutil. Un equipo puede crear un panel impresionante con todas las luces en verde y sin ninguna relación estable con el trabajo. Un panel significativo nombra la superficie de datos, la acción, el estado, el propietario, la evidencia y la próxima revisión. Permite distinguir entre «solicitud aceptada», «registro en vivo suprimido», «notificación al destinatario pendiente», «copia de seguridad pendiente de caducidad» y «conservado por obligación legal». Estos estados tienen significados diferentes. Convertirlos todos en «suprimido» transforma la incertidumbre en diseño de interfaz de usuario.

La supresión demostrable también depende de la gestión de cambios. Un sistema de origen puede ser reemplazado, se puede añadir un procesador, cambiar el formato de un índice, introducir un nuevo destino de analítica, o revisarse la política de retención de un proveedor de IA. Si el procedimiento de supresión no se actualiza con esos cambios, el procedimiento acaba describiendo gradualmente un sistema que ya no existe. El resultado es familiar en cualquier disciplina operativa: un manual impecable y un servicio real moviéndose en direcciones opuestas. Probar regularmente una pequeña muestra de la ruta, incluido el sistema incómodo, suele revelar más que encargar un gran documento de aseguramiento que nadie puede ejecutar.

Para una autoridad pública o una empresa regulada, esto no es una preocupación limitada a la oficina de privacidad. El delegado de protección de datos puede orientar la interpretación, pero ingeniería es responsable de las interfaces y los mecanismos de borrado, producto es responsable de la finalidad y el recorrido del usuario, compras es responsable de las obligaciones de información impuestas a los proveedores, seguridad es responsable de los controles de acceso y restauración, y operaciones es responsable de la ejecución bajo presión. Un único responsable no puede inspeccionar cada capa por sí solo. Una capa sin responsable no se vuelve segura por el hecho de que sea difícil de discutir.

Un proceso defendible registra su decisión y su ejecución sin crear una segunda biografía innecesaria de la persona.

La retención es la otra mitad del borrado

Muchos problemas de borrado comienzan mucho antes de una solicitud. Comienzan cuando un sistema no tiene ninguna decisión de retención. Los datos llegan porque podrían resultar útiles. Los registros se vuelven permanentes porque el almacenamiento es barato. Las exportaciones se conservan porque una futura auditoría podría solicitarlas. Los datos de entrenamiento se acumulan porque un modelo posterior podría beneficiarse. Cada decisión parece inofensiva de forma aislada. Juntas convierten a la organización en propietaria de un archivo grande y mal comprendido, y encarecen, vuelven más incierta y más conflictiva cada solicitud de borrado.

El principio de limitación del almacenamiento del RGPD establece que los datos personales deben mantenerse de una forma que permita la identificación de los interesados durante no más tiempo del necesario para los fines para los que se tratan, sin perjuicio de un almacenamiento más prolongado con fines de archivo de interés público, fines de investigación científica o histórica o fines estadísticos, cuando se apliquen las salvaguardas correspondientes. El principio no prescribe un único calendario para todas las organizaciones. Exige un juicio vinculado a la finalidad. Un calendario de retención debe, por tanto, nombrar las categorías de datos, la finalidad, la base jurídica, el período normal, el evento desencadenante, la excepción, la acción de eliminación, el responsable y el punto de revisión. «Mientras sea necesario» es un principio. Se convierte en una regla operativa solo cuando alguien puede decir necesario para qué, hasta cuándo y decidido por quién.

Esa estructura es útil para la IA porque evita que una etiqueta amplia, como datos de entrenamiento, oculte varias cosas diferentes. Una contribución en bruto, un conjunto de datos limpio, un conjunto de características, una versión de modelo, un historial de indicaciones, un conjunto de evaluación y un registro de supervisión pueden tener cada uno finalidades y consideraciones de retención diferentes. Combinarlos en un único depósito indefinido empeora tanto la innovación como la rendición de cuentas. Separarlos no garantiza una respuesta jurídica, pero la hace posible.

Las decisiones de retención también se benefician de una condición de denegación. ¿Qué haría que dejáramos de retener esto? Un contrato finalizado, una disputa resuelta, el fin de un período legal, una investigación de seguridad completada, una versión de modelo sustituida, la expiración de una ventana de restauración o una decisión de no perseguir un propósito de investigación pueden ser todos desencadenantes reales. La cuestión no es automatizar un reloj de borrado para todo. Se trata de evitar un sistema en el que la única condición para conservar datos sea que nadie haya tenido aún que explicarlos.

Hay un pequeño instinto neerlandés que merece la pena conservar aquí: un armario no está ordenado porque tenga una puerta. Está ordenado porque puedes encontrar lo que buscas, saber por qué está ahí y retirarlo sin tener que mudarte de casa. Un patrimonio de datos merece al menos ese estándar. Un calendario de retención que no pueda sobrevivir a una conversación con las personas que operan el sistema no es un calendario. Es un pronóstico meteorológico escrito en prosa jurídica.

Esto no significa que toda organización deba centralizar cada decisión de borrado. Los equipos locales suelen entender mejor sus procesos. Significa que las reglas locales necesitan conceptos comunes, una propiedad visible y una vía de escalado. De lo contrario, el archivo de un equipo es la infracción de otro, y la solicitud de una persona se canaliza por un laberinto de servicios con nombres amables.

Lo que un proveedor honesto de IA puede decir

Un proveedor honesto de IA no afirma que todos los datos de clientes se desvanezcan cuando llega una solicitud. Tampoco se esconde tras la dificultad de los modelos. Describe el límite del servicio. Qué se procesa para la inferencia. Qué se conserva para la administración de cuentas, la seguridad, el soporte, la facturación o la prevención de abusos. Si las indicaciones y los resultados se almacenan. Si se utilizan para formación, evaluación o mejora del servicio. Qué procesadores y regiones intervienen. Cómo pueden configurar los clientes la retención. Qué documentación existe para las solicitudes de los interesados. Qué acciones son inmediatas, cuáles asíncronas y cuáles dependen de una evaluación jurídica independiente.

Para los compradores, las preguntas de contratación son prácticas. ¿Podemos obtener un mapa claro del flujo de datos? ¿Podemos identificar los roles de responsable y encargado del tratamiento para el tratamiento correspondiente? ¿Podemos exportar o eliminar material de forma utilizable? ¿Se incluyen los índices de recuperación y los almacenes derivados en el ciclo de vida documentado? ¿Qué ocurre con las copias de seguridad? ¿Cómo se comunican los cambios de subencargados? ¿Puede el proveedor ayudarnos a responder a una solicitud dentro del plazo aplicable? ¿Los usos para formación y mejora del servicio son de adhesión, de exclusión, contratados por separado o descritos solo en una página que puede cambiar después de la compra? ¿Qué registros técnicos están disponibles para demostrar la acción?

Las respuestas variarán. Un servicio compartido grande no siempre puede ofrecer el mismo control que un entorno dedicado. Un registro de seguridad no siempre puede eliminarse al mismo tiempo que el perfil de una cuenta. Un archivo legal no puede tratarse como una preferencia de consumo. Esas diferencias no son necesariamente fallos. El silencio sobre ellas sí lo es. La respuesta correcta del comprador es ajustar el comportamiento documentado del servicio al propósito, las obligaciones y el riesgo de la organización. Un producto puede no ser adecuado para una tarea muy sensible aunque sea totalmente adecuado como herramienta de redacción de bajo riesgo.

En Dweve, nuestro Centro de confianza adopta la misma visión estricta de la evidencia. Una página pública puede describir controles y límites documentales, pero no puede certificar cada despliegue de un cliente ni decidir la base jurídica del tratamiento de un cliente. Ese límite importa. Una plataforma puede ofrecer controles de retención, registros y flujos de trabajo revisables. La organización que la utiliza sigue siendo dueña de su propósito, de sus decisiones sobre los datos y de la decisión de responder a una persona concreta. Un buen texto de producto debe aclarar esa responsabilidad, no asumirla en silencio.

La declaración más valiosa de un proveedor suele ser una limitación. «Este registro permanecerá en las copias de seguridad protegidas hasta que termine el periodo de rotación indicado». «Este servicio no utiliza el contenido especificado del cliente para formación en virtud de estos términos». «Este índice se elimina de forma asíncrona y el estado puede consultarse aquí». «No podemos hacer esta afirmación por una integración de terceros». Estas frases pueden parecer menos mágicas que una promesa universal de privacidad. Permiten al comprador diseñar un proceso real.

Preguntas que conviene plantear antes de que llegue la solicitud

Una organización no necesita inventar una brecha, un individuo angustiado o un incidente heroico de madrugada para probar su diseño de borrado. Puede utilizar una solicitud hipotética claramente etiquetada durante el horario laboral ordinario. Supongamos que una persona solicita la eliminación de material almacenado en un sistema orientado al cliente. ¿Qué equipo recibe la solicitud? ¿Cómo se verifica la identidad sin recopilar información nueva excesiva? ¿Qué finalidades son relevantes? ¿Qué sistemas contienen datos fuente, derivados, índices, registros, cachés, exportaciones y copias de recuperación? ¿Qué encargados necesitan una instrucción o notificación? ¿Qué excepción u obligación de retención, en su caso, se aplica? ¿Quién puede decidir? ¿Quién puede ejecutar? ¿Cómo explicará la organización el resultado?

Después, hay que plantear las preguntas técnicas incómodas. ¿Puede un operador encontrar el inventario de datos actual sin un antiguo ingeniero? ¿Puede comprobarse un índice de búsqueda independientemente de su tabla fuente? ¿Reaparece un identificador eliminado después de una restauración? ¿Utilizan los trabajos por lotes instantáneas antiguas? ¿Puede vincularse un almacén de incrustaciones con sus documentos y su inquilino? ¿Captura una canalización de supervisión el contenido de las indicaciones por defecto? ¿Se rigen los archivos de exportación por las mismas reglas de retención que su fuente? ¿Crea el registro de evidencia una nueva acumulación de contenido sensible? Estos no son casos extremos añadidos para que una política parezca seria. Son consecuencias ordinarias de sistemas que hacen copias para funcionar.

Por último, hay que plantear la pregunta de gobernanza: ¿qué haría que la organización cambiara su respuesta? Una nueva obligación legal, una identidad impugnada, una reclamación legal abierta, un cambio en el acuerdo con un proveedor, una verificación de borrado fallida, una copia de seguridad restaurada, una nueva canalización de modelo o una decisión de un regulador pueden ser relevantes. Un proceso sin un desencadenante de revisión es simplemente una suposición inicial que se ha elevado a política.

Nada de esto sustituye al asesoramiento jurídico en un caso concreto. Los requisitos del RGPD, la legislación nacional, las obligaciones sectoriales, los contratos y los hechos del tratamiento son todos relevantes. Pero las organizaciones no necesitan una disputa legal para empezar a diseñar las condiciones de una respuesta inteligible. Necesitan conocer sus sistemas lo suficientemente bien como para dejar de ofrecer una promesa simple para una realidad complicada.

La privacidad es la calidad del residuo

La ambición detrás del borrado no es hacer que el pasado sea irreal. Es dar a las personas un control significativo cuando los datos ya no necesitan tratarse, cuando se ha retirado el consentimiento, cuando el tratamiento es ilícito o cuando se aplica otro motivo del artículo 17. Pide a los responsables que traten los datos personales como algo que se conserva para una finalidad, no como materia prima con una tenencia indefinida. Les pide que expliquen las excepciones en lugar de usarlas como una máquina de humo. Pide a los sistemas que lleven suficiente linaje para que el olvido pueda ser deliberado.

Para los servicios digitales, la prueba silenciosa es lo que queda. Después de que un registro se elimina de una pantalla de producto, ¿qué sigue activo? Después de que un documento sale de un corpus de recuperación, ¿qué representación derivada todavía lo selecciona? Después de que se elimina una cuenta, ¿qué registro se conserva, con qué finalidad y durante cuánto tiempo? Después de que se restaura una copia de seguridad, ¿qué impide que un registro retirado vuelva? Después de que cambia un modelo, ¿qué historial de datos puede inspeccionarse? Después de que se cierra una solicitud, ¿puede la organización mostrar su trabajo sin crear otro perfil oculto?

Un sistema rara vez responderá a todas esas preguntas con una sola acción y una sola marca de tiempo. Eso es normal. Lo que no es normal es fingir que las preguntas desaparecen porque los datos son difíciles, están distribuidos o son rentables. La privacidad no es el momento en que un servicio aprende un comando de borrado. Es lo que queda después de que el sistema ha aprendido a olvidar con una finalidad, un límite y un registro de su propia contención.

Fuentes