RGPD básico para proyectos IA

El RGPD no es un PDF de 60 páginas para asustar al comité. En un piloto de IA es una lista corta: qué dato tocas, con qué base legal, quién es el encargado, dónde vive, y qué no se pega nunca en un modelo público.

Las pymes que se saltan esto no lo hacen por maldad. Lo hacen porque “es solo una prueba”. Las pruebas se quedan. Los prompts se loguean. El Excel de clientes acaba en un historial que no controlas.

Esto no sustituye a un abogado. Es el mínimo que exigimos antes de encender un flujo. Si no se puede escribir en una página, el alcance es demasiado grande.

Inventario antes del prompt

Nombra el flujo (facturas de proveedores, tickets de soporte, FAQ interna). Lista campos: nombre, NIF, importe, email, salud, menores, credenciales. Marca cuáles son personales y cuáles especiales. Si hay categorías especiales o menores, párate: no es un piloto de dos semanas.

El inventario es aburrido y es lo que te salva cuando alguien pregunta “¿qué habéis metido en el modelo?”. Sin inventario, la respuesta es un encogimiento de hombros. Eso no es una defensa.

Base legal, no un checkbox

Contrato (ejecutar un pedido, facturar), obligación legal (conservar facturas), interés legítimo (mejorar un proceso interno con garantías), consentimiento (raro en IA de back-office y fácil de romper). Elige una y escríbela. “Porque nos viene bien” no es una base.

El interés legítimo exige ponderación: qué ganas, qué riesgo para la persona, qué alternativas menos invasivas. Si no puedes explicarlo en cinco líneas, no lo uses como cajón.

Encargados y subencargados

Quien aloja el modelo, quien guarda logs, quien transcribe, quien hace backup: encargados. Pide el contrato, la lista de subencargados, la residencia, si entrenan con tus entradas, y cómo borran. “Cumplimos RGPD” en la home no es un contrato.

Si el proveedor no responde por escrito en una semana, no es un proveedor para un piloto con datos reales. Usa datos sintéticos o un corpus interno sin personales hasta que responda.

Lo que no se pega nunca

• Credenciales, tokens, contraseñas, seeds.
• Salud, ideología, afiliación, biométricos.
• Nóminas completas, DNI escaneados, datos de menores.
• Secretos de cliente cubiertos por contrato.
• Bases enteras “para que el modelo se haga una idea”. Minimiza: el campo que hace falta, no el Excel.

Información al equipo y a los interesados

El equipo necesita un cartel de sí / no / preguntar, no un manual. Los interesados (clientes, empleados) necesitan saber si un nuevo tratamiento les afecta. A veces basta actualizar la cláusula; a veces hay que decirlo de forma específica. No lo decidas en el pasillo el día del go-live.

Documenta el flujo: una página con inventario, base, encargado, plazos de conservación y el interruptor. Eso es el embrión del registro de actividades para este tratamiento.

Encaje con el piloto y con el programa

El perímetro legal corre en paralelo al diseño del flujo, no después. Kit Consulting encaja para inventario, riesgos y criterios de proveedor. La implantación no empieza con datos reales hasta que esa página existe.

Si el bono aprieta el calendario, recorta el piloto, no el inventario. Un entregable rápido con una filtración no es un entregable.

Conservación y borrado, en práctico

Las facturas se conservan por obligación mercantil y fiscal; el piloto no las borra a los 30 días. Los prompts de prueba con datos personales, sí se borran cuando acaba la prueba — y la prueba tiene fecha. Los logs del proveedor, preguntad el plazo y pedid que no superen lo que necesitáis para depurar.

Cuando un cliente ejerce un derecho, tenéis que saber en qué colas está su dato. Por eso el inventario de una página no es burocracia: es el mapa de la respuesta. Si la respuesta es “no sabemos”, el piloto se adelantó al registro.

Documentad el borrado una vez (pasos, pantallas, quién lo hace). No hace falta un procedimiento de 15 páginas. Hace falta poder repetirlo.

Qué no es un “interés legítimo” en este contexto

“Queremos mejorar la productividad” no basta. Tampoco “el proveedor lo hace así” ni “es una prueba”. El interés legítimo se sostiene si el flujo es interno, el dato es el mínimo, hay alternativas peores (teclear 80 facturas a mano con más errores) y las personas no salen perjudicadas de forma desproporcionada.

Si el flujo toca clientes finales en un chat público, casi nunca es interés legítimo. Ahí o hay contrato claro, o hay consentimiento real, o no hay piloto. No inventéis una cuarta vía en la memoria.

Preguntas frecuentes

¿Hace falta un DPO?

Depende de volumen y tipo de dato. Muchas pymes no están obligadas. Eso no las exime de base legal, contratos e inventario.

¿Podemos anonimizar y ya?

Seudonimizar no es anonimizar. Si aún puedes volver a la persona, sigue siendo personal. Anonimizar bien es más difícil de lo que parece en un Excel.

¿Y los modelos locales?

Reducen encargados, no eliminan la base legal ni el perímetro del equipo. El riesgo de pegar de más sigue en la mesa.

Sigue con datos y privacidad y proveedores UE. Escríbenos con el flujo y el tipo de dato.