En mayo de 2023, la autoridad irlandesa de protección de datos multó a Meta con 1.200 millones de euros por transferir datos personales de europeos a Estados Unidos sin base jurídica válida. Es una de las multas más grandes que ha impuesto el RGPD, y comparte patrón con casi todas las demás: el fallo está en cómo se mueve el dato, no en dónde se computa el modelo. Ahí es donde la IA local cambia el tablero: el modelo corre en tu GPU, el prompt no viaja y no aparece un encargado nuevo en la cadena. Lo que no cambia es el Reglamento: ejecutar en local simplifica el cumplimiento, no lo elimina.
El RGPD no se apaga porque el modelo viva en tu servidor
El Reglamento (UE) 2016/679, RGPD en español y GDPR en inglés, sigue al dato, no al hardware. Si tratas facturas de clientes con un modelo de pesos abiertos instalado en tu oficina, tu empresa es responsable del tratamiento y conserva las obligaciones de siempre: seguridad (artículo 32), minimización (artículo 5) y registro de actividades (artículo 30).
Lo que sí resuelve el enfoque local son tres puntos débiles típicos de la nube: las transferencias internacionales del capítulo V, la cadena de encargados del artículo 28 y la exposición del dato a terceros que no controlas. Lo que no resuelve son los derechos de la persona: acceso, rectificación, supresión, oposición, limitación y portabilidad siguen operativos, y debes poder localizar el rastro de un cliente en tus conversaciones, tus logs y tus copias si lo pide.
Hay una trampa frecuente con la seudonimización. Sustituir nombres por identificadores no anonimiza nada mientras exista una tabla que una ID y persona: para el Reglamento, eso sigue siendo datos personales.
El paso siguiente es barato y ordena todo lo demás: dibuja el mapa de tratamientos y anota cada flujo donde un dato identificativo entre en un prompt, un documento indexado o un audio.
Los datos que no deberían salir jamás de tu servidor
Empieza por lo evidente: currículums y nóminas, tickets de soporte con nombre y correo, contratos con NIF y dirección, y los datos del artículo 9, que incluyen salud, biometría, ideología u orientación sexual. El escenario típico que la IA local corta de raíz es el empleado que pega una hoja con miles de contactos en un chat público para ordenarla: el dato acaba en servidores ajenos sin contrato de encargo ni base documentada.
Las transcripciones de voz cuentan igual: una locución permite reconocer a la persona que habla. Y si un sistema visual identifica rostros, las imágenes tratan datos del artículo 9; subirlas a un servicio cloud de transcripción o de generación de imagen añade manos nuevas a la cadena.
Queda la categoría que nadie planifica: claves API, tokens y credenciales internas pegadas en un prompt por descuido. En cloud, se van al servidor del proveedor; en local, se quedan en tu log, que conviene purgar con la misma disciplina.
La regla práctica divide tus flujos en tres niveles: solo local para datos identificativos y del artículo 9, preferencia local para lo operativo, y cloud con contrato para lo que no identifica a nadie. Escribe esa clasificación: es la primera pieza de tu documento de cumplimiento.
Dónde se esconden los datos personales en un stack de IA local
Las conversaciones no viven solo en la ventana del chat. Interfaces como Open WebUI guardan el historial en una base de datos en el servidor, y el proceso de inferencia escribe logs donde puede aparecer el prompt completo.
Si montas RAG, los embeddings duplican el problema. Un vector guardado en pgvector, Qdrant o Chroma reproduce contenido del documento original, con nombres incluidos, así que borrar el PDF fuente no borra nada hasta que purgas la colección y reindexas.
Los pesos ajustados son el caso incómodo. Si entrenas un adaptador con correos de clientes o tickets reales, esa información queda incrustada en los parámetros, y extraerla después es un problema de investigación abierto, el llamado machine unlearning. Para entender cuándo un modelo entrenado con datos personales puede considerarse anónimo, el EDPB publicó a finales de 2024 un dictamen que conviene leer antes de ajustar pesos con tus propios datos.
Fuera del radar también quedan backups, snapshots y telemetría. Muchas herramientas de escritorio consultan su servidor para comprobar actualizaciones o mandan métricas de uso; revisa qué conexiones hace cada componente y desactiva las que no aportan.
Tu inventario debe listar cada punto donde algo persiste (historial, logs, índice de vectores, pesos, copias de seguridad) y definir una retención con fecha de purga para cada uno. Sin ese inventario, el derecho de supresión se convierte en promesa incumplible.
Cuándo la nube sigue siendo razonable
IA local no es dogma. Para flujos sin datos identificativos, un proveedor con región de proceso en la UE, contrato de encargado firmado y compromiso documentado de no entrenar con tus datos puede encajar sin drama.
Lo que no encaja es hacerlo sin papel: te faltan el artículo 28, el capítulo V si hay transferencia y, cuando aplica, la evaluación de impacto de la transferencia. El marco ha cambiado tres veces en menos de una década: Schrems I tumbó el Safe Harbor en 2015 (C-362/14), Schrems II invalidó el Privacy Shield en julio de 2020 (C-311/18) y la Comisión aprobó el nuevo Data Privacy Framework en julio de 2023.
La escala de exposición la marcan las cifras: las infracciones graves del RGPD llegan hasta 20 millones de euros o el 4 % de la facturación anual global, lo que resulte mayor (artículo 83.5). Con esa horquilla delante, conviene decidir con datos, no con intuiciones.
La base legal tampoco cambia por correr en tu hardware. Si procesas datos de un cliente para prestarle el servicio, el artículo 6.1.b (ejecución de contrato) suele cubrirlo; para usos internos sobre empleados, valora el interés legítimo documentado con una prueba de ponderación.
Con ese marco en la mesa, la decisión se toma por flujo y por documento, no por marca del proveedor: define ya qué flujos pueden salir con contrato y cuáles no salen nunca.
Un stack local que aguanta una auditoría
Para lenguaje, Ollama o llama.cpp exponen una API sobre 127.0.0.1; Ollama escucha por defecto en el puerto 11434, y esa puerta no debe abrirse a internet. Modelos de pesos abiertos como Llama, Gemma, Qwen o Mistral cubren la mayoría de tareas internas, y algunos, como Mistral 7B, se distribuyen con licencia Apache 2.0. Si prefieres botones a terminal, LM Studio hace lo mismo con interfaz gráfica.
Descargar pesos no es transferir datos personales: tu máquina habla con el registro (tu IP y el nombre del modelo es lo único que viaja). Si tu política lo exige, descarga cada modelo una vez y compártelo por un mirror interno.
Para consultar documentos, un RAG local con pgvector, Qdrant o Chroma y un orquestador tipo LangChain funciona sin nube; PrivateGPT surgió justo para ese caso de uso. En voz, whisper.cpp y faster-whisper transcriben en tu máquina, de modo que las locuciones de clientes no pasan por ningún proveedor.
En imagen, ComfyUI con SDXL o Flux genera sobre tu GPU sin subir nada; si quieres comparar números antes de decidir dónde corre cada flujo, en el blog tienes la comparativa de generación de imagen en local frente a los servicios cloud. En vídeo, los pesos abiertos tipo Wan, LTX-Video o Mochi siguen la misma lógica, y los probamos en detalle en nuestra guía de vídeo generativo en local.
Sobre esa base, tres controles baratos sostienen todo el edificio: cifrado de disco con LUKS o BitLocker, cuentas separadas con permisos mínimos y una regla de firewall que mantenga la API en la interfaz local.
Pilota un caso acotado, como soporte con RAG sobre tickets o RR. HH. clasificando CVs, en una GPU que ya tengas. Antes de generalizar, decide dónde vive cada dato (base de datos, índice de vectores o historial) y quién puede borrarlo.
Lo mínimo que hay que documentar
El principio de responsabilidad proactiva (artículo 5.2) no exige papeleo infinito: exige evidencias proporcionales. Con menos de 250 empleados y tratamientos ocasionales de bajo riesgo, el artículo 30.5 puede eximirte hasta del registro de actividades; si tratas datos del artículo 9 o la IA aparece en procesos habituales, documenta igual.
Una evaluación de impacto (artículo 35) toca cuando el tratamiento es de alto riesgo, por ejemplo con biometría o con cribado sistemático de personas. Y la notificación de brechas en 72 horas (artículo 33) aplica igual: un ransomware en la máquina de inferencia es una brecha notificable como cualquier otra.
El lugar donde corre el cómputo tampoco cambia las obligaciones del Reglamento de IA europeo, en vigor desde agosto de 2024: se mira el uso, y una IA local que criba candidaturas sigue siendo un sistema de alto riesgo. Ojo con el almacenamiento: sin control de acceso ni registro de cambios, las hojas de cálculo son una mala capa para datos personales, y una base de datos con permisos delimitados cumple mejor ese papel tanto en local como en nube.
Tu checklist mínimo: base legal por flujo, retención con purga automática, control de accesos, destino de los logs y una prueba real de un ejercicio de supresión.
Por dónde empezar esta semana
Primero, inventaría los puntos por donde entran datos personales hoy: prompts, índices de vectores o audios, incluidos los servicios cloud que ya uses. Segundo, marca los flujos sensibles como solo local y muévelos a una pila como la del apartado anterior. Tercero, para lo que quede en cloud, comprueba región, contrato de encargo y política de entrenamiento, y deja constancia escrita.
La IA local no suprime el RGPD: mueve la responsabilidad hacia tu infraestructura, con su superficie de ataque, sus logs y sus copias. A cambio, convierte la privacidad desde el diseño (artículo 25) en elementos verificables: la regla de firewall, la política de purga y el inventario de tratamientos. Ese es el cambio de perspectiva con el que conviene empezar — y la primera auditoría para la que conviene prepararse.