Privacidad en modelos de lenguaje: un mapa de fugas y defensas

Reeditado el 30 de julio de 2026, este artículo empieza por una distinción que evita muchas falsas soluciones: la privacidad de un modelo de lenguaje no es un único problema. Los datos pueden exponerse durante la recogida, el entrenamiento, la consulta, la recuperación de documentos, el registro, el uso de herramientas o la salida. Proteger una etapa no protege automáticamente las demás.

Por eso «los datos no salen del dispositivo», «están cifrados» o «hemos borrado los nombres» son respuestas incompletas. Cada una cubre una amenaza distinta y puede dejar abiertas las restantes. La herramienta duradera es un mapa de flujos: qué dato entra, quién lo recibe, para qué se usa, cuánto se conserva, qué artefactos produce y cómo se elimina.

Primero, dibujar las superficies de exposición

Un servicio de lenguaje suele manejar al menos cinco clases de información. Están los datos de preentrenamiento; los de adaptación o ajuste; las indicaciones y archivos del usuario; el corpus de recuperación; y los registros con respuestas, correcciones y telemetría. A ellos se suman índices vectoriales, copias de seguridad, cachés, evaluaciones y conjuntos creados a partir de conversaciones.

Para cada flujo hay que identificar responsables y receptores: organización, proveedor del modelo, alojamiento, herramienta externa y personas revisoras. También importa la finalidad. Una conversación necesaria para contestar no queda automáticamente autorizada para entrenar, evaluar empleados o conservarse indefinidamente. La configuración contractual y técnica debe coincidir con lo que la interfaz promete.

El NIST Privacy Framework propone relacionar datos, procesamiento y efectos sobre las personas, y organizar acciones de identificar, gobernar, controlar, comunicar y proteger. Su utilidad aquí es obligar a describir el sistema completo. El modelo es un nodo; la privacidad se gana o se pierde en el recorrido.

El mapa debe incluir el tiempo. Un dato puede ser necesario durante segundos para contestar y convertirse después en un log, una muestra de evaluación o un conjunto de ajuste. Cada transformación necesita una decisión propia y un identificador que permita localizarla. También se ensaya el incidente: cómo se bloquea una integración, se preserva evidencia mínima, se informa a responsables y se evita que una corrección copie otra vez el material expuesto.

Memorización y extracción no son lo mismo que una base de datos

Los parámetros no guardan filas como una tabla, pero un modelo puede memorizar secuencias, especialmente cuando son raras o se repiten. El trabajo de extracción de datos de entrenamiento de modelos de lenguaje mostró que un adversario podía generar candidatos y reconocer fragmentos memorizados, incluidos datos identificables. La publicación es de 2020, no un estudio genérico de 2019, y describe un ataque concreto con condiciones y costes.

La investigación para cuantificar memorización halló que la capacidad del modelo, la duplicación de ejemplos y el contexto influyen en la extracción. Esto no significa que todo texto de entrenamiento pueda recuperarse ni que cada salida parecida pruebe copia. Significa que deduplicar, reducir secretos y evaluar secuencias raras son controles relevantes antes de entrenar.

Otro riesgo es la inferencia de pertenencia: determinar si un registro formó parte del entrenamiento. El trabajo de membership inference mostró este ataque en modelos de aprendizaje automático a partir de diferencias entre miembros y no miembros. En lenguaje, la evaluación necesita un modelo de amenaza realista: acceso disponible, consultas, población, conocimiento auxiliar y ventaja frente al azar.

La respuesta responsable combina prevención y prueba. Se filtran secretos y datos fuera de finalidad, se deduplican corpus, se controla procedencia y se ejecutan pruebas de extracción con canarios autorizados o datos sintéticos diseñados para el test. Publicar una lista de ejemplos encontrados sin denominador no mide riesgo; afirmar «el modelo no almacena datos» tampoco.

La consulta y la recuperación abren fugas nuevas

Aunque el modelo base no haya visto información privada, el servicio puede recibirla en la indicación. Hay que decidir si el proveedor retiene consultas, si las usa para mejora, dónde se procesan y quién accede a registros. Se aplican minimización, redacción de campos, periodos breves, cifrado en tránsito y reposo, permisos y auditoría. El filtro debe actuar antes de enviar, no únicamente sobre la respuesta.

Los sistemas de generación aumentada por recuperación añaden documentos e índices. Un buscador semántico debe respetar los permisos del origen en cada consulta; no basta con construir un índice común y pedir al modelo que «no revele». Las fuentes recuperadas se registran, se etiquetan por sensibilidad y se excluyen de logs innecesarios. Una inyección incluida en un documento no debe obtener permisos para consultar otros.

Los vectores tampoco son texto irreconocible y, por tanto, seguro. El trabajo Text Embeddings Reveal (Almost) As Much As Text demostró ataques de inversión capaces de reconstruir información a partir de embeddings en su escenario experimental. La conclusión operativa es tratarlos como derivados sensibles: control de acceso, retención, separación por cliente y evaluación de inversión.

La salida y las herramientas completan el circuito. Un modelo puede resumir un documento que el usuario no debía ver, incluir un dato personal en una respuesta o enviar contenido a una API externa. Se valida autorización antes de recuperar y antes de actuar; se limita el contexto; se filtra la salida como última defensa, no como única; y se registra la decisión sin copiar más datos de los necesarios.

Las defensas no son intercambiables

La privacidad diferencial ofrece una garantía matemática respecto a cuánto cambia la distribución de salidas al añadir o retirar un registro, bajo parámetros y supuestos explícitos. El algoritmo de entrenamiento con gradientes diferencialmente privados recorta gradientes por ejemplo y añade ruido. Hay una relación entre privacidad, utilidad y presupuesto: decir «usa DP» sin publicar unidad protegida, epsilon, delta, muestreo y contabilidad no permite juzgar la garantía.

El aprendizaje federado mueve el entrenamiento hacia dispositivos o silos y agrega actualizaciones. La propuesta de optimización federada de redes profundas aborda comunicación y datos descentralizados. Mantener datos en origen reduce ciertos movimientos, pero las actualizaciones pueden filtrar información y el servidor, dispositivos o agregación tienen sus propias amenazas. Suele combinarse con agregación segura, controles y, si procede, privacidad diferencial.

El cifrado protege datos en tránsito y reposo; técnicas criptográficas pueden permitir ciertos cálculos sobre datos protegidos, pero no corrigen una finalidad indebida ni impiden que el resultado autorizado revele demasiado. La seudonimización reduce exposición directa, pero una clave o combinación puede reidentificar. La redacción automática produce falsos negativos y positivos. Cada defensa debe enlazarse con la amenaza que reduce.

La eliminación también necesita diseño. Borrar un registro de la base operativa no lo retira necesariamente de copias, índices, conjuntos derivados o parámetros. El inventario debe indicar dónde se propaga y qué compromiso puede cumplirse. Si no existe un método fiable para retirar una contribución del modelo, se dice con claridad y se prioriza no incorporarla.

Un protocolo de privacidad que se puede comprobar

Empiece con finalidad y necesidad: qué tarea requiere qué campos. Trace después el diagrama de datos, incluido proveedor, región, logs, recuperación, herramientas, copias e índices. Asigne amenaza y control a cada borde. Defina pruebas: extracción, pertenencia, inversión de embeddings, acceso entre usuarios, inyección, retención y borrado. Registre resultados y riesgo residual.

El Reglamento General de Protección de Datos aporta principios aplicables en la Unión Europea, entre ellos licitud, transparencia, limitación de finalidad, minimización, exactitud, limitación del plazo, integridad y responsabilidad proactiva. La aplicación concreta depende del rol, la finalidad y el contexto; «cumple GDPR» no es una propiedad genérica de un modelo.

Antes de comprar un servicio, pregunte si las entradas entrenan modelos, cuánto se retienen, dónde se procesan, quién actúa como encargado, cómo se exportan y borran datos, cómo se notifican incidentes y qué evidencia respalda las promesas. Antes de lanzar, haga una prueba con datos no sensibles y verifique materialmente los registros, permisos y borrado. Una política escrita sin configuración coincidente no protege.

La capacidad transferible es construir una matriz de dato, etapa, amenaza, control, prueba y riesgo residual. Con ella se entiende por qué federación, privacidad diferencial, cifrado y filtros resuelven partes distintas. La privacidad deja de ser una etiqueta colocada sobre el modelo y se convierte en una propiedad comprobable —y necesariamente imperfecta— del servicio completo.