GDPR + RAG: cómo implementar IA con datos sensibles sin sustos legales.
Una guía operativa para pymes europeas que quieren desplegar copilots y RAG sobre datos internos (contratos, expedientes, clientes, finanzas) cumpliendo GDPR y la EU AI Act. Con checklist legal, criterios de selección de proveedor y plantilla de cláusulas mínimas.
1. El contexto regulatorio en 2 minutos
Si tu pyme está en la UE o trata datos de ciudadanos europeos, hoy te aplican tres marcos simultáneamente:
- GDPR (Reglamento 2016/679): cómo tratas datos personales. Sigue siendo la columna vertebral.
- EU AI Act (Reglamento 2024/1689): clasifica tus sistemas IA por riesgo. La mayoría de copilots de pyme caen en “riesgo limitado” o “mínimo”, pero hay obligaciones de transparencia.
- Normativas sectoriales: si estás en banca, sanidad, seguros, hay capas adicionales (DORA, MiFID II, RH específica).
2. Las tres decisiones que lo cambian todo
Antes de mirar arquitecturas, responde estas tres. La respuesta condiciona todo lo que viene:
¿Qué tipo de dato va a tocar el sistema?
Datos personales, datos especialmente protegidos (salud, biometría, ideología), datos confidenciales no personales (estrategia, IP), o datos públicos. Cada categoría tiene su régimen.
¿Dónde se procesan los datos?
UE (lo más fácil), USA con SCC + DPA reciente (legal pero frágil tras Schrems II), o territorios sin adecuación (no recomendado para personales).
¿El sistema toma decisiones automatizadas con efectos legales?
Si sí (ej. denegar un crédito, filtrar candidatos), entras en GDPR Art. 22 y AI Act de “alto riesgo”. Mucho más exigente. Si no (ej. asistir, sugerir, resumir), te quedas en “riesgo limitado”.
3. Arquitectura RAG segura por capas
Una arquitectura RAG (Retrieval-Augmented Generation) bien diseñada cumple por defecto. Las cuatro capas:
| Capa | Qué hace | Decisión clave de privacidad |
|---|---|---|
| Ingesta | Importa documentos a la base vectorial | Filtrar/anonimizar PII en ingesta o conservar y cifrar |
| Almacenamiento | Vector DB + metadata | Hosting UE, cifrado at-rest, control de acceso por documento |
| Recuperación | Busca chunks relevantes para la consulta | Filtros por permisos del usuario que pregunta |
| Generación | LLM redacta respuesta con esos chunks | LLM en UE, sin retención, sin uso para entrenamiento |
”Un RAG bien arquitecturado nunca envía datos sensibles a un LLM al que no controlas. Esa frase debería estar grabada en la pared del proveedor.”
4. Self-hosted vs API gestionada
La pregunta del millón. Resumen honesto:
API gestionada (OpenAI, Anthropic, Mistral La Plateforme...)
Contra: dependencia, datos salen de tu perímetro, dificultad para auditoría profunda.
Cuándo: casos sin datos especialmente sensibles, equipos pequeños, time-to-value crítico.
Self-hosted (Llama, Mistral, Mixtral, Qwen open-weight)
Contra: infra, MLOps, calidad ligeramente inferior, latencia.
Cuándo: datos altamente sensibles, sectores regulados, IP crítica, soberanía de datos como requisito.
Nuestra recomendación práctica para pymes europeas: híbrido por caso de uso. Usos administrativos generales en API gestionada (con DPA correcta), usos sobre datos confidenciales en self-hosted dentro de tu cloud privado o cliente. No tiene que ser todo o nada.
5. Cómo evaluar al proveedor LLM
Si optas por API gestionada, exige documentación pública y/o contractual sobre:
- Localización física del procesamiento
- Política de retención (objetivo: 0 días o “ephemeral”)
- Garantía explícita de no entrenamiento con tus datos
- Sub-encargados del tratamiento (lista actualizada)
- Mecanismo de transferencia internacional (SCC, BCR, decisiones de adecuación)
- Certificaciones (ISO 27001, SOC 2 Type II como mínimo)
- Procedimiento de notificación de brechas (≤72h GDPR)
6. Cláusulas mínimas en contrato
Estas cláusulas deben estar sí o sí. Si el proveedor se resiste, es señal:
- DPA (Data Processing Agreement) firmado y vigente
- Cláusula de no uso de datos para entrenamiento
- Política de retención cero o configurable a cero
- Notificación de brecha en ≤24h al cliente (mejor que el mínimo legal de 72h)
- Derecho de auditoría con preaviso razonable
- Localización de datos garantizada por contrato (no solo por configuración)
- Salida limpia: exportación + borrado verificable al cancelar
- Cláusula de transparencia: cualquier cambio sustantivo en sub-encargados o jurisdicción requiere aviso ≥30 días
7. DPIA: cuándo es obligatorio
El Data Protection Impact Assessment (Art. 35 GDPR) es obligatorio cuando hay riesgo alto. En contexto IA, eso ocurre normalmente cuando:
- Tratas datos a gran escala (>10.000 sujetos)
- Tratas categorías especiales (salud, biometría, ideología, sindical)
- Hay decisiones automatizadas con efectos significativos
- Combinas múltiples fuentes que crean perfiles enriquecidos
- Innovación tecnológica nueva (la IA generativa entra aquí en muchas interpretaciones)
Recomendación: aunque no sea obligatorio, hacer un DPIA ligero (8-10 horas de trabajo del DPO con el equipo del proyecto) siempre que despliegues IA con datos personales. Reduce mucho el riesgo y deja documentación útil.
8. Checklist legal final
- Tengo identificadas las categorías de dato que toca el sistema
- Tengo base legal de tratamiento documentada (Art. 6 GDPR)
- He clasificado el sistema según la EU AI Act (riesgo mínimo / limitado / alto)
- El hosting de datos está en UE o tiene mecanismo de transferencia válido
- El DPA está firmado y revisado
- Tengo cláusula explícita de no entrenamiento
- El sistema implementa control de acceso por permisos del usuario que consulta
- Hay logs de auditoría inmutables de todas las consultas
- Hay aviso de IA al usuario final cuando aplique (Art. 50 AI Act)
- He hecho DPIA si aplica (o ligero si no aplica pero quiero estar tranquilo)
- Política interna de uso aceptable comunicada al equipo
- Plan de respuesta a incidentes incluye específicamente IA