RGPD e IA: qué datos puedes enviar a un LLM

Cada vez que una empresa se plantea usar IA en serio aparece la misma pregunta, y casi siempre demasiado tarde: ¿puedo mandar estos datos a la IA? La duda es legítima. Un modelo de lenguaje resuelve tareas que hasta ahora hacía una persona —leer, clasificar, resumir— pero para hacerlo necesita ver el dato, y ese dato a menudo incluye nombres, correos, teléfonos o información de clientes protegida por el RGPD.

La respuesta honesta no es “la IA está prohibida” ni “manda todo, ya veremos”. Es una decisión de ingeniería que se toma dato a dato, antes de conectar nada. En esta guía te contamos cómo decidimos qué información sale hacia un LLM, qué se queda dentro y los errores que hemos visto costar caros.

Qué significa realmente combinar RGPD e IA

El RGPD no prohíbe la IA. Exige base legal para el tratamiento, minimización del dato, transparencia y control sobre a quién se lo entregas. Cuando mandas texto a un proveedor como OpenAI o Anthropic, ese proveedor actúa como encargado del tratamiento: necesitas un contrato de encargo (DPA), saber dónde se procesa la información y si se usa para entrenar sus modelos.

Cumplir el RGPD con IA no es marcar una casilla al final. Es diseñar el flujo para que salga el dato mínimo necesario, con garantías, y para que el resto no salga nunca. La mayoría de los problemas que nos encontramos no son del modelo: son de un flujo montado sin decidir antes qué información viajaba y con qué protección.

Escenarios reales que nos encontramos

Resumir y clasificar tickets de soporte

Los tickets traen nombres, direcciones y, según el sector, datos de salud o de pago. Resumir cien correos con IA ahorra horas reales, pero mandar el correo entero al modelo casi nunca hace falta. Se puede seudonimizar el remitente y quitar los identificadores antes de enviarlo: el resumen sigue siendo útil y el dato personal se queda en tu sistema.

Enriquecer o puntuar leads en el CRM

Cuando la IA lee un mensaje entrante y lo prioriza dentro del CRM —algo que abordamos en nuestra guía de integración de Zoho CRM— está tratando datos de una persona identificable. Aquí decidimos qué campos necesita de verdad el modelo para puntuar (sector, tamaño, intención de compra) y cuáles no (DNI, teléfono directo), y solo le enviamos los primeros. El scoring no mejora por ver el teléfono del contacto.

Extraer datos de documentos con información personal

Facturas, contratos, formularios. Extraer los campos con un modelo es potente, pero son documentos llenos de datos personales y, a veces, fiscales. La decisión no es “IA sí o no”: es si el documento puede procesarse en un modelo con residencia de datos en la UE y sin retención, o si el caso es tan sensible que pide un modelo desplegado en tu propia infraestructura.

El empleado que pega datos en ChatGPT

El riesgo más común no es el proyecto de IA bien planteado: es la “shadow AI”. Alguien pega una lista de clientes en una herramienta pública para redactar un correo, y esos datos salen sin control, sin contrato y sin que nadie lo sepa. Parte del trabajo es dar una alternativa segura y una política clara, porque prohibir por decreto no funciona: la gente busca el atajo igual.

Cómo lo abordamos

Después de montar varios de estos proyectos, el orden que seguimos evita casi todos los sustos.

Clasificamos el dato antes de elegir el modelo

Antes de decidir qué LLM usar, clasificamos qué datos entran en juego: públicos, internos, personales, categorías especiales. Esa clasificación manda en todo lo demás. Elegir el modelo antes de saber qué va a ver es empezar por el tejado.

Minimizar, seudonimizar y tokenizar en el origen

El mejor dato personal es el que no sale. Antes de llamar al modelo, quitamos o sustituimos los identificadores cuando la tarea no los necesita. Muchas tareas —clasificar, resumir, extraer estructura— funcionan igual de bien sin nombres reales, y el riesgo baja de golpe.

Cuando el flujo sí necesita volver a asociar la respuesta del modelo con el registro real, no borramos el dato: lo tokenizamos. Sustituimos el identificador (nombre, email, DNI) por un token sin significado y guardamos la correspondencia en una bóveda bajo tu control; el modelo trabaja con el token y nosotros rehacemos la asociación después, sin que el dato sensible llegue a salir. Un matiz importante y que muchos pasan por alto: seudonimizar o tokenizar reduce el riesgo, pero mientras guardes la tabla de correspondencia el dato sigue siendo personal a efectos del RGPD. Solo una anonimización real e irreversible queda fuera del reglamento.

Elegir dónde vive el modelo

No todos los modelos ofrecen las mismas garantías. Un modelo por API con contrato de encargo, residencia de datos en la UE y sin uso para entrenamiento cubre la mayoría de los casos. Cuando el dato es especialmente sensible, valoramos un modelo desplegado en tu propia nube. Esa elección es parte del diseño, no un detalle que se resuelve al final.

Un humano en los casos que importan

El modelo propone y una persona valida donde hay impacto, sobre todo en los casos límite. Diseñar qué dato sale y diseñar la supervisión van de la mano: no tiene sentido cuidar la salida de datos y luego automatizar a ciegas una decisión con consecuencias.

Errores que conviene evitar

• Mandar el documento entero “porque es más fácil”. Enviar de más es el error más común y el más caro de corregir después.
• Confundir “está en la nube” con “cumple el RGPD”. La nube no es el problema; el contrato de encargo, la residencia del dato y la política de retención sí lo son.
• Creer que por tokenizar ya estás fuera del RGPD. Si guardas la tabla de correspondencia, sigue siendo dato personal; confundir seudonimización con anonimización es un error caro.
• No firmar el DPA con el proveedor del modelo. Sin ese contrato de encargo no hay base sólida para el tratamiento.
• Prohibir la IA en vez de dar una vía segura. La shadow AI aparece igual, pero sin ningún control.
• Dejar la decisión de datos para el final. Cuando el flujo ya está montado, rehacerlo cuesta diez veces más que haberlo pensado al principio.

Cómo elegir con quién montarlo

El RGPD y el AI Act no son un obstáculo para usar IA: son parte del diseño de un buen sistema. Al elegir con quién montarlo, fíjate en que te pregunten qué datos entran antes de hablar de modelos, que planteen minimización y residencia en la UE desde el primer día, y que sepan cuándo un caso pide un modelo en tu propia infraestructura. Un buen equipo no te vende “IA que cumple”: te ayuda a decidir qué sale, con qué garantías y por qué.

En LMNHUB aplicamos IA sobre tus procesos decidiendo desde el diseño qué dato viaja y con qué protección, no improvisando la parte legal al final. Somos un equipo europeo y tratamos el RGPD como lo que es: una ventaja de diseño, no una excusa para no hacer nada.

Si tienes un proceso donde la IA ayudaría pero te frena la duda de los datos, cuéntanos tu caso y te respondemos con un plan concreto y un equipo senior, sin humo ni un presupuesto genérico.