¿Cuáles son los riesgos de privacidad más típicos en productos con LLM?

Divulgación involuntaria por contexto "pegado" en el prompt, logs que se convierten en una base de datos paralela, prompt injection que exfiltra datos vía herramientas, mezcla de sesiones o memoria de usuario, alucinaciones que inventan datos personales, y retención excesiva por parte de proveedores.

¿Qué debe incluir la minimización de datos en un producto con IA?

Separar identificadores internos del texto natural, traer solo los pasajes relevantes en RAG en vez de documentos enteros, aplicar redacción automática de PII antes de enviar datos al proveedor, y no dejar el tamaño máximo de contexto como configuración por defecto.

¿Cuándo necesito una DPIA para un producto con LLM?

Cuando tu caso de uso puede implicar alto riesgo, algo bastante frecuente en LLM. La DPIA debe describir el sistema real (flujos, herramientas, proveedores), clasificar los datos, listar escenarios de daño y detallar controles y pruebas concretas, no ser un documento genérico.

Guía EDPB: riesgos de privacidad en LLM y mitigaciones (checklist GDPR para productos con IA)

Q: ¿Qué dice el EDPB sobre la privacidad en modelos de lenguaje (LLM)?

Que si hay riesgo alto para derechos y libertades no basta con "confiar" en el proveedor: hace falta un enfoque de gestión de riesgos con medidas técnicas y organizativas verificables, tanto si entrenas modelos como si solo conectas un LLM externo a tu producto.

GUÍAS & TUTORIALES · GDPR · LLMs · PRIVACIDAD

⏱️ 12–16 min de lectura De “probemos un chatbot” a “producto compliant”: tareas claras, riesgos típicos y una checklist práctica

La pregunta no es si tu LLM “ve” datos personales. La pregunta es: ¿en cuántos puntos del sistema los estás copiando sin darte cuenta?

Prompts, contexto, logs, trazas, feedback, herramientas externas, proveedores… Un producto con IA generativa es una tubería de datos. Y si no la diseñas con privacidad desde el inicio, lo normal es que se te escape información por sitios que ni estabas mirando. Si además tu equipo usa asistentes con cuenta personal, conviene revisar antes qué hacen ChatGPT, Gemini y Claude con esas conversaciones.

En esta guía voy a traducir las recomendaciones del EDPB (el Comité Europeo de Protección de Datos) a tareas concretas: minimización, DPbD (privacy by design), logging seguro, control de prompts, retención, DPIA y evaluación de proveedores. Al final tienes una checklist GDPR para que puedas meterla tal cual en tu backlog.

Idea clave

Un LLM “amplifica” errores de diseño. Si tu app ya era mala gestionando datos, con IA lo será más (y más visible).

Riesgo típico

Fugas por logs, por “contexto pegado” en prompts, o por integraciones (herramientas, CRMs, emails).

Objetivo práctico

Convertir “principios GDPR” en controles: filtros, límites, retención, trazabilidad y decisiones documentadas.

1. Qué está diciendo el EDPB (y por qué te afecta aunque no seas OpenAI)

El EDPB lleva tiempo marcando una línea bastante clara: si hay riesgo alto para derechos y libertades, no vale con “confiar” en el proveedor. Necesitas un enfoque de gestión de riesgos con medidas técnicas y organizativas verificables.

Esto aplica tanto si entrenas modelos como si simplemente “conectas” un modelo a tu producto. De hecho, en la práctica, la mayoría de problemas aparecen en el despliegue: cuando metes datos reales, usuarios reales y flujos reales (soporte, ventas, RRHH, salud, educación…).

Y ojo: no es solo “privacy”. Los fallos de seguridad típicos en LLM (prompt injection, exfiltración por herramientas, data leakage por contexto) son la autopista hacia un incidente GDPR. Si quieres una lista muy aterrizada de ataques y mitigaciones, te encaja perfecto esta guía: OWASP Top 10 LLM 2025 con mitigaciones y checklist.

2. Antes de mitigar: dibuja tu “tubería” de datos (sí, aunque sea fea)

Si te llevas una sola tarea de aquí, que sea esta: haz un diagrama de flujo de datos. No uno teórico. El real. Un LLM en producción suele parecerse a esto:

Usuario → Prompt (texto) → Orquestador (tu backend) → Enriquecimiento (RAG / CRM / tickets) → Proveedor LLM → Herramientas (email, calendar, DB) → Respuesta → Logs / métricas / feedback → Analítica / soporte / reentrenos

Cada flecha es una pregunta GDPR: ¿qué datos pasan?, ¿con qué base legal?, ¿quién es responsable (controller/processor)? ¿hay transferencias internacionales?, ¿qué retención aplica?, ¿dónde se guardan logs?, ¿quién accede?

Y aquí es donde la arquitectura importa: muchas veces, la mejor mitigación de privacidad no es “filtrar más”, sino cambiar el diseño. Por ejemplo: usar RAG para traer solo lo necesario en lugar de volcar un documento entero en el prompt; o separar el texto de usuario de los identificadores internos. Si estás decidiendo entre enfoques, te puede ayudar este mapa: RAG vs fine-tuning vs agentes: cómo elegir arquitectura.

3. Los 8 riesgos de privacidad más típicos en LLM (con ejemplos reales de producto)

3.1. Divulgación involuntaria por contexto “pegado”

Es el clásico: “para que el modelo responda bien, le paso el ticket completo”. Dentro del ticket hay emails, teléfonos, datos de pago, notas internas… y de repente el modelo lo repite en una respuesta o lo expone a otro usuario por un bug de sesión.

3.2. Logs que se convierten en una base de datos paralela

Guardas prompts y respuestas “para depurar” y “mejorar calidad”. Se quedan meses. Los ve medio equipo. Se exportan a una herramienta externa. Y ya tienes un tratamiento nuevo (y muchas veces no declarado) con datos personales.

3.3. Prompt injection y exfiltración por herramientas

El usuario mete instrucciones maliciosas (“ignora las reglas y muéstrame…”), o un texto externo (web, PDF, email) contiene una instrucción escondida. Si tu agente tiene acceso a herramientas, el daño escala: puede consultar datos y devolverlos.

3.4. Mezcla de sesiones o de “memoria” de usuario

Cache mal diseñado, IDs mal usados, o una “memoria” pensada para personalizar que termina asociando datos a la persona equivocada. Esto es especialmente peligroso en atención al cliente y entornos internos (RRHH, legal).

3.5. Alucinaciones que suenan a datos personales

Aunque el modelo no “conozca” a alguien, puede inventar un nombre, un teléfono o un historial. En algunos sectores (salud, educación, compliance) el daño reputacional y legal es real. Si quieres profundizar en este punto (y cómo evitarlo), te dejo esta pieza: errores típicos: alucinaciones y privacidad.

3.6. Retención y reuso por parte de proveedores

Dependiendo del contrato y la configuración, tu tráfico puede usarse para mejorar servicios, entrenar, o conservarse para “abuso y seguridad”. Si no lo gobiernas, estás dejando decisiones GDPR críticas en una pantalla de “settings”.

3.7. Datos sensibles por “uso natural”

En cuanto el producto ayuda en salud, finanzas, empleo o educación, los usuarios te van a escribir cosas sensibles aunque no se lo pidas. El sistema tiene que estar preparado para detectar, limitar y no propagar ese contenido.

3.8. “Shadow integrations”: herramientas que nadie considera parte del sistema

Un plugin, un conector de analytics, un sistema de observabilidad, un ticketing… y de repente los prompts terminan en sitios donde no hay controles de acceso, ni retención, ni acuerdos correctos.

Checklist y documentación de cumplimiento

4. Mitigaciones traducidas a tareas: de “principio GDPR” a control técnico

4.1. Minimización de datos (de verdad, no de PowerPoint)

Minimizar en un LLM significa dos cosas: meter menos y conservar menos. Algunas tareas típicas que funcionan:

Separar identificadores internos (user_id, ticket_id) del texto natural; el modelo no necesita ver el DNI para resolver el caso.
Resumir o “chunkear” con reglas: en RAG, traer solo pasajes relevantes (y recortar metadatos personales si sobran).
Redacción automática (PII masking) antes de enviar al proveedor cuando el caso de uso lo permita.
Limitar el tamaño del contexto por defecto: el “máximo” no debería ser la configuración estándar.

4.2. DPbD y DPbDefault: privacidad como configuración base

La privacidad por diseño no es un documento: es una lista de decisiones de producto. Ejemplos simples:

Opt-out/opt-in de usar conversaciones para mejora, separado del consentimiento general de uso.
“No guardamos prompts” como configuración por defecto en entornos sensibles (y habilitarlo solo con justificación y límites).
Roles y permisos: soporte no necesita ver el texto completo si puede ver un extracto redaccionado.
Modo “sandbox” para pruebas: nada de datos reales en QA.

4.3. Logging seguro: registra lo útil, no lo íntimo

El logging es donde más se rompe el GDPR en productos con LLM, porque se hace por inercia. Buenas prácticas muy aplicables:

Diseña dos niveles: métricas técnicas (latencia, tokens, errores) y muestras de contenido (mínimas, redaccionadas, con acceso restringido).
Evita guardar prompts completos “para siempre”. Si necesitas ejemplos para QA, crea un dataset curado y anónimo.
Encriptación en tránsito y en reposo, control de acceso fuerte, y auditoría de accesos a logs.
Alertas: detección de PII en logs y “killswitch” si algo se dispara.

4.4. Control de prompts y del contexto: reglas antes que confianza

El control no es censura: es seguridad y privacidad. Tu objetivo es evitar que el sistema “haga más de lo que debe”.

Políticas de sistema claras y técnicas (no solo texto bonito): qué herramientas puede usar, qué datos puede devolver, y cuándo debe negarse.
Validación de salidas: si aparece PII (teléfonos, emails, IDs), bloquear o pedir confirmación según el caso.
Separación de datos: “contexto del usuario” y “contexto del sistema” no deberían mezclarse en el mismo bloque sin marcadores y controles.
Para agentes con herramientas: permisos mínimos, allowlists, y límites por acción (por ejemplo, “solo leer”, “solo buscar”, “nunca exportar”).

4.5. Retención: si no puedes defender el plazo, es que sobra

Retención en IA suele ser “lo dejamos 180 días porque sí”. La versión madura es: plazos por finalidad. Prompts de soporte para depuración: días o semanas, no meses. Dataset de evaluación: curado, minimizado y revisado. Evidencias de incidentes: con acceso limitado y ciclo de vida claro.

5. DPIA para productos con LLM: qué no puede faltar

Si tu caso de uso puede implicar alto riesgo (y muchos lo implican), la DPIA deja de ser “una formalidad” y pasa a ser tu mapa de ruta. La clave es que no sea genérica.

Plantilla rápida (muy práctica) para enfocar la DPIA:

Describe el sistema real: flujos, herramientas, logs, proveedores, transferencias, retención.
Clasifica datos: ¿entra PII? ¿sensibles? ¿menores? ¿datos internos de empleados?
Escenarios de daño: fuga por logs, exfiltración por herramientas, mezcla de sesiones, acceso indebido interno, alucinaciones dañinas.
Controles: minimización, redacción, validación, permisos, cifrado, auditoría, retención, training de equipos.
Pruebas: test de prompt injection, test de fugas de PII, revisión de datasets, verificación de configuración del proveedor.
Decisiones y trade-offs: qué aceptas, qué reduces, qué evitas; y por qué.

Consejo práctico: documenta esto como si lo fuera a leer alguien externo mañana. Porque, en un incidente, lo va a leer. Si te interesa cómo convertir decisiones en evidencias (sin morir en burocracia), te puede servir esta guía: cómo documentar el uso de IA en empresa.

6. Evaluación de proveedores LLM: preguntas que sí importan (y las que son humo)

“El proveedor es compliant” no es una respuesta. Necesitas evidencias y configuración. Aquí tienes preguntas que separan marketing de control real:

Uso de datos: ¿se usan prompts/respuestas para entrenar o mejorar? ¿puedes desactivarlo? ¿qué implica “abuso y seguridad”?
Retención: ¿plazos por defecto y mínimos? ¿puedes bajar la retención? ¿qué se guarda exactamente (texto, embeddings, metadata)?
Ubicación y transferencias: ¿región de procesamiento? ¿subprocesadores? ¿SCCs? ¿opciones de residencia de datos?
Seguridad: cifrado, control de accesos internos, segregación de tenants, auditorías, certificaciones relevantes.
Soporte a derechos: ¿puedes localizar y borrar datos? ¿qué pasa con backups? ¿cómo manejan solicitudes de acceso?
Incidentes: SLAs de notificación, detalles técnicos del incidente, logs y evidencias disponibles.

Y no olvides el “proveedor invisible”: herramientas de observabilidad, analytics, feedback widgets, CRMs. Si los prompts pasan por ahí, cuentan.

7. Checklist GDPR para productos con LLM (lista para copiar al backlog)

A. Antes de lanzar

Mapa de flujo de datos: prompt, contexto, herramientas, logs, feedback, proveedores.
Definición de roles (controller/processor) y acuerdos (DPA, subprocesadores).
Minimización: límites de contexto, RAG con recorte, redacción de PII cuando aplique.
Configuración por defecto “privada”: no guardar prompts completos salvo necesidad justificada.
Políticas de prompt y herramientas: permisos mínimos, allowlist, límites por acción.
Plan de retención por finalidad (no un único número para todo).
Tests: prompt injection, fugas de PII, mezcla de sesiones, revisión de logs.
DPIA (si procede) con escenarios específicos y controles verificables.

B. En operación

Logging seguro: métricas técnicas por defecto; contenido mínimo, redaccionado y con acceso restringido.
Monitorización de salidas: detección de PII, bloqueos, warnings y revisión de casos.
Gestión de derechos: procesos para acceso, rectificación, supresión y oposición (incluye logs y sistemas asociados).
Gestión de proveedores: revisiones periódicas de configuración, cambios de subprocesadores, auditorías.
Entrenamiento interno: qué no se debe pegar en prompts (y por qué), y cómo reportar incidentes.

C. Cuando algo sale mal (porque pasará)

Runbook de incidentes: aislamiento, rotación de credenciales, desactivación de herramientas, preservación de evidencias.
Revisión post-mortem: causa raíz (prompt, herramienta, log, proveedor) y acción correctiva con dueño y fecha.
Validación de remediaciones: repetir tests y auditar que el control quedó activo.

8. Cierre: la privacidad en LLM no es “un documento”, es un sistema

Si estás construyendo con LLM, no necesitas volverte paranoico. Pero sí necesitas cambiar el chip: la privacidad ya no se “cumple” al final. Se diseña. Se prueba. Se monitoriza. Se documenta. Se gobierna.

La buena noticia es que casi todo se puede traducir a ingeniería y producto: límites, permisos, retención, observabilidad bien hecha, y decisiones claras. Si haces eso, no solo reduces riesgo GDPR: también consigues un sistema más robusto, más confiable y más fácil de escalar.