Las solicitudes de derecho al olvido chocan con cómo almacenan realmente los datos los LLM

El artículo 17 del RGPD y disposiciones de supresión similares en otras leyes de privacidad se escribieron sobre un modelo mental simple: los datos personales viven en un registro, dentro de una base de datos, y una empresa puede encontrar ese registro y borrarlo. Ese modelo funciona bien para la dirección de un cliente en un CRM. Se rompe por completo una vez que esos mismos datos del cliente se han usado para entrenar o ajustar un modelo de lenguaje grande, porque un modelo entrenado no almacena datos personales como un registro recuperable. Los almacena como un patrón difuso de ajustes de peso repartidos entre miles de millones de parámetros, y no existe una consulta que seleccione solo la contribución de una persona y la elimine.

La suposición que hace la ley de supresión

Los reguladores de privacidad construyeron sus marcos de borrado alrededor de bases de datos, y la lógica es sólida para ese caso de uso: localizar la fila, borrar la fila, confirmar el borrado. Las empresas han pasado dos décadas construyendo las herramientas para hacer esto de forma fiable a escala. Ninguna de esas herramientas se traslada a los parámetros de un modelo. Una vez que los datos de entrenamiento se han absorbido en los pesos mediante descenso de gradiente, la contribución específica de un documento o de los datos de una persona no es aislable después del hecho. El modelo no “contiene” el ejemplo de entrenamiento en ninguna forma que puedas localizar y eliminar.

Por qué los LLM rompen esa suposición

Las opciones honestas para satisfacer realmente una solicitud de supresión contra un modelo entrenado son todas costosas, y la mayoría incompletas. El reentrenamiento completo desde un conjunto de datos del que se ha eliminado la información de la persona es el único enfoque que satisface limpiamente la letra de la ley, y cuesta millones de dólares y semanas de cómputo para cualquier modelo de tamaño significativo — un coste que escala con el tamaño del modelo y la frecuencia de reentrenamiento, no con cuántas solicitudes de borrado llegan. La investigación en desaprendizaje automático (machine unlearning) ha producido técnicas que ajustan los pesos de un modelo para reducir la influencia de ejemplos de entrenamiento específicos sin un reentrenamiento completo, pero los resultados publicados muestran consistentemente que estos métodos son aproximados: reducen de forma medible la capacidad del modelo para reproducir contenido memorizado específico, pero no garantizan que la eliminación sea completa, y verificar esa completitud es en sí mismo un problema de investigación abierto. Una empresa que lanza un parche de desaprendizaje no puede actualmente demostrar, a satisfacción de un regulador, que los datos realmente han desaparecido.

La mayoría de las empresas actualmente evitan la versión más difícil de este problema manteniendo los datos personales fuera del conjunto de entrenamiento desde el principio y confiando en la generación aumentada por recuperación (RAG) en su lugar — obteniendo los datos del usuario de una base de datos convencional y borrable en el momento de la inferencia, en lugar de incorporarlos a los pesos del modelo. Ese enfoque resuelve genuinamente el problema de supresión para sistemas nuevos diseñados con eso en mente. No hace nada por la generación de modelos ya entrenados con conjuntos de datos recopilados antes de que esta distinción se convirtiera en práctica estándar, que es la mayoría de la flota de modelos de frontera actualmente en producción.

Dónde está ocurriendo realmente la disputa

Los reguladores han empezado a tratar esto como una cuestión real en lugar de hipotética. Las autoridades europeas de protección de datos han abierto investigaciones sobre si los pipelines de entrenamiento de modelos fundacionales cumplen con las obligaciones de supresión, y las respuestas que han dado las empresas —señalando filtrado, bloqueo de contenido a nivel de salida, o ciclos de reentrenamiento programados— todavía no han satisfecho a los reguladores que piden pruebas de que se ha eliminado la influencia de los datos de un individuo específico, no solo suprimido en la etapa de salida. La distinción importa: impedir que un modelo repita el nombre de una persona en su salida no es lo mismo que eliminar los datos de esa persona de los pesos que produjeron esa salida, y varios casos en curso giran exactamente sobre esa diferencia.

Qué están haciendo realmente las empresas al respecto

En la práctica, la mayoría de las empresas de IA que gestionan actualmente este riesgo hacen tres cosas simultáneamente: desplazar los sistemas nuevos hacia arquitecturas RAG que mantienen los datos personales borrables por diseño, programar reentrenamientos completos periódicos sobre conjuntos de datos limpiados como la aproximación más cercana al cumplimiento para modelos ya desplegados, y presionar a los reguladores para que acepten el filtrado a nivel de salida como cumplimiento suficiente en lugar de exigir eliminación a nivel de pesos. Esa tercera estrategia es la que realmente se está disputando en los procedimientos regulatorios actuales.

Conclusiones prácticas

Si estás desplegando un producto basado en LLM que toca datos personales, prefiere diseños aumentados por recuperación que mantengan esos datos en un almacén borrable, no incorporados en pesos ajustados.
No trates el filtrado de contenido a nivel de salida como equivalente a la supresión. Los reguladores cada vez más no lo hacen, y la brecha entre ambos es donde se encuentra la exposición legal actual.
Presupuesta reentrenamientos completos periódicos sobre conjuntos de datos limpiados como un coste de cumplimiento real para cualquier modelo ajustado que maneje datos personales.
Vigila las investigaciones europeas sobre el cumplimiento en el entrenamiento de modelos fundacionales: su resultado probablemente fijará la definición práctica de “supresión” para modelos entrenados en todas las jurisdicciones.
Si tu equipo legal confía en técnicas de desaprendizaje automático para satisfacer una solicitud de borrado, obtén por escrito qué estándar de completitud aceptará realmente el regulador.