Consultoría RGPD e IA: qué revisar antes de meter datos personales en un modelo

Cuando una empresa nos llama para una consultoría RGPD relacionada con inteligencia artificial, casi siempre llega tarde y con la misma frase: «tenemos una herramienta funcionando y alguien ha preguntado si esto es legal». No es una posición cómoda, pero tampoco es el desastre que se teme. La mayoría de los problemas que encontramos no son ilegalidades de manual: son tratamientos sin base legal escrita, contratos de encargado que nadie leyó y datos que llegaron a un sistema al que nunca debieron llegar. Todo eso se arregla, y se arregla más barato antes de escalar que después.

Esta guía es el orden en el que revisamos las cosas. No sustituye al criterio de tu asesoría jurídica —y si tienes delegado de protección de datos, esta conversación empieza con él—, pero sí te da el mapa para saber qué preguntar, qué documentar y qué exigir a tus proveedores antes de conectar datos personales a un modelo.

¿Qué revisa una consultoría RGPD cuando hay IA de por medio?

Lo primero, y suena aburrido: si hay datos personales de verdad. Es sorprendente la cantidad de proyectos que se frenan por miedo cuando el dato es agregado, y la cantidad de proyectos que avanzan sin ruido cuando el dato es un histórico de tickets lleno de nombres, teléfonos y comentarios médicos de clientes.

El RGPD no tiene un capítulo de IA. Lo que hace es aplicar las mismas obligaciones de siempre a un tratamiento nuevo, y hay cinco que se activan casi siempre:

• Base legal y finalidad (art. 6). Por qué puedes tratar ese dato y para qué exactamente. Un dato recogido para facturar no vale sin más para entrenar un modelo de propensión.
• Minimización (art. 5). El modelo debe ver los campos que necesita, no la tabla entera porque era más fácil exportarla.
• Registro de actividades de tratamiento (art. 30). Si la IA es un tratamiento nuevo o cambia uno existente, se refleja ahí. Es el documento que primero pide una autoridad de control.
• Seguridad (art. 32). Quién accede al dato, cómo viaja, dónde se queda cuando el proyecto termina.
• Decisiones automatizadas (art. 22). Si el sistema decide sobre personas sin intervención humana significativa, el listón sube mucho.

Nuestra primera sesión en una revisión de este tipo no habla de modelos. Habla de flujos: de dónde sale el dato, por cuántos sistemas pasa, quién lo ve por el camino y qué queda almacenado en cada parada. Ese dibujo, hecho honestamente, ya resuelve la mitad de las dudas.

El problema rara vez es «usar IA con datos personales». El problema es no poder explicar por escrito qué datos, para qué y con qué garantías.

¿Qué base legal necesitas para usar datos personales en un modelo?

Aquí es donde se decide casi todo, y donde más atajos se toman. Las tres bases que aparecen en la práctica empresarial son estas:

| Base legal | Cuándo encaja | Qué exige en la práctica | Riesgo típico | |---|---|---|---| | Ejecución de contrato | El tratamiento es necesario para prestar el servicio contratado | Que sea necesario, no conveniente. Detección de fraude en un pago, sí; perfilado comercial, no | Estirar «necesario» hasta que deja de serlo | | Interés legítimo | Mejora interna, seguridad, análisis agregado | Ponderación escrita entre tu interés y el impacto en la persona, y un canal de oposición real | Hacer la ponderación después de la inspección | | Consentimiento | Usos que la persona no espera razonablemente | Libre, específico, informado y revocable. Y si lo revoca, tienes que poder cumplirlo | Consentimiento agrupado en un check genérico |

El consentimiento parece la opción segura y suele ser la peor: si el 30 % lo revoca, tu conjunto de entrenamiento cambia y tienes que poder demostrar que has dejado de usar esos datos. El interés legítimo es el caballo de batalla real en proyectos internos, y funciona si haces la ponderación de verdad: qué ganas tú, qué expone a la persona, qué salvaguardas has puesto para reducir ese impacto. Media página bien argumentada vale más que diez de plantilla.

Dos cautelas que salen caras:

Cambio de finalidad. Tienes diez años de expedientes recogidos para gestionar la relación con el cliente y quieres entrenar un modelo de churn. No es automático. Hay que valorar la compatibilidad con la finalidad original, y a veces la respuesta honesta es que ese histórico no se puede usar tal cual, pero sí anonimizado. Lo desarrollamos en anonimización de datos.

Categorías especiales (art. 9). Salud, biometría, afiliación sindical, ideología, origen étnico. Cambian el juego: base legal reforzada, riesgo alto por defecto y, casi siempre, evaluación de impacto. Y ojo, entran por la puerta de atrás: un campo de texto libre de atención al cliente puede contener datos de salud sin que nadie lo haya diseñado así.

¿Cuándo hace falta una evaluación de impacto?

La evaluación de impacto (EIPD, art. 35) es obligatoria cuando el tratamiento entraña un alto riesgo para los derechos de las personas. En proyectos de IA, se activa con más frecuencia de la que la gente supone. Señales claras de que la necesitas:

• Hay evaluación o perfilado sistemático de personas con efectos relevantes: scoring crediticio, cribado de candidaturas, priorización de expedientes.
• Se tratan datos a gran escala o de categorías especiales.
• Hay observación sistemática de zonas accesibles al público, como el vídeo analítico en tienda.
• Se combinan conjuntos de datos de orígenes distintos de una forma que la persona no espera.
• Se aplica tecnología nueva a un tratamiento que antes era manual.

Con dos de esas señales, hazla. No por ritual: la EIPD bien hecha es el documento más útil del proyecto porque obliga a escribir qué puede salir mal y qué has puesto para evitarlo. La estructura mínima que funciona: descripción del tratamiento, necesidad y proporcionalidad, riesgos concretos para las personas, medidas para mitigarlos y riesgo residual asumido, con firma de quien lo asume.

Un matiz de calendario que casi nadie respeta: la EIPD va antes del tratamiento, no después del piloto. Si ya tienes el modelo en producción y la escribes ahora, hazla igualmente, pero asume que es un ejercicio de regularización y que puede obligarte a apagar algo.

¿Qué exigir cuando el modelo lo pone un tercero?

Casi ninguna empresa entrena sus propios modelos desde cero, y ahí está el punto que más contratos rompe. Si el proveedor trata datos personales por tu cuenta, es encargado de tratamiento y necesitas un contrato del artículo 28. Con esto dentro:

• Instrucciones documentadas: solo trata los datos para lo que tú le dices, y nada más.
• Prohibición de uso propio: por escrito, que tus datos no se usan para entrenar o mejorar sus modelos generales. Si la cláusula no está, no la des por supuesta; en muchos servicios por defecto ocurre lo contrario.
• Subencargados: lista, obligación de comunicarte altas y derecho de oposición.
• Ubicación y transferencias: dónde se procesa. Si sale del Espacio Económico Europeo, qué mecanismo lo ampara y qué medidas suplementarias hay.
• Retención: cuánto tiempo conserva prompts, entradas y salidas. Muchos servicios guardan registros semanas «por abuso»; eso es un tratamiento y tiene que constar.
• Devolución y borrado al terminar, con certificado.
• Notificación de brechas en plazo compatible con tus 72 horas.

Un detalle práctico: pide el diagrama de flujo de datos del proveedor, no solo su certificado. Un certificado te dice que tiene procesos; el diagrama te dice por dónde pasa tu dato. Si no te lo puede dar, ya tienes una respuesta. Este es también uno de los puntos duros al elegir proveedor, y lo tratamos desde el otro lado en cómo elegir consultora de IA.

¿Qué controles técnicos reducen el riesgo de verdad?

El cumplimiento se escribe en papel, pero se sostiene en arquitectura. Estos son los controles que más riesgo quitan por unidad de esfuerzo, ordenados por lo que solemos implantar primero:

| Control | Qué evita | Esfuerzo | |---|---|---| | Filtrado de campos en el origen | Que el modelo vea columnas que no necesita | Bajo | | Seudonimización antes de salir del sistema | Que un incidente exponga identidades directas | Medio | | Entorno separado para pruebas con datos sintéticos | Usar producción «solo para probar» | Medio | | Registro de accesos y de prompts | No poder reconstruir qué pasó tras un incidente | Bajo | | Revisión humana documentada en decisiones sobre personas | Caer en el artículo 22 sin darte cuenta | Bajo | | Política de retención aplicada por sistema, no por acuerdo | Copias eternas en carpetas intermedias | Medio | | Detección de datos personales en campos de texto libre | Datos de salud colados en comentarios | Alto |

Dos advertencias sobre la seudonimización, porque se malinterpreta a diario: un dato seudonimizado sigue siendo dato personal y sigue bajo el RGPD; reduce riesgo, no obligaciones. Y la anonimización real —irreversible, resistente a reidentificación— es más difícil de lo que promete cualquier script de sustitución de nombres.

La parte de seguridad pura se solapa con lo que contamos en IA y ciberseguridad, y el andamiaje de responsabilidades y dueños del dato es exactamente gobierno del dato. Sin ese andamiaje, cada proyecto vuelve a discutir lo mismo desde cero.

¿Qué errores se repiten en las empresas que ya usan IA?

Los mismos, en sectores muy distintos:

• El piloto en la sombra. Alguien de negocio pega datos de clientes en una herramienta contratada con su tarjeta. No es mala fe, es falta de una alternativa aprobada. La solución no es prohibir por circular: es dar una vía oficial y sencilla.
• Confundir el reglamento de IA con el RGPD. Son dos normas distintas y acumulativas. Cumplir una no te exime de la otra; lo separamos en el reglamento europeo de IA para pymes.
• Informar en el sitio equivocado. Actualizas la política de privacidad de la web y das por hecho que basta. Si el tratamiento afecta a empleados o a clientes por otro canal, la información hay que darla ahí, en su idioma y en su momento.
• No poder responder a un derecho de supresión. Suena teórico hasta que llega la primera solicitud y descubres que el dato está en el origen, en el almacén intermedio, en el conjunto de entrenamiento y en los registros del proveedor.
• Documentar el modelo y no el tratamiento. Guardas métricas de precisión y ninguna nota sobre finalidad, base legal ni personas afectadas. Lo primero interesa al equipo técnico; lo segundo es lo que te piden.
• Dejar el cumplimiento para el final. Es el patrón que más pilotos mata, y no solo por lo legal: lo vimos al analizar por qué fracasan los pilotos de IA.

¿Cómo se ordena esto en un plan realista?

Para una empresa mediana que ya tiene algo en marcha, un orden que funciona en unas seis semanas de trabajo repartido:

| Semana | Qué se hace | Con qué se cierra | |---|---|---| | 1 | Inventario de usos de IA reales, incluidos los no oficiales | Lista de casos con dueño y dato que consumen | | 2 | Clasificación: qué toca datos personales y de qué tipo | Mapa de flujos por caso | | 3 | Base legal y finalidad por caso, con la ponderación escrita | Fichas de tratamiento actualizadas | | 4 | Revisión de contratos de proveedor y transferencias | Adendas pedidas o proveedor descartado | | 5 | EIPD en los casos de alto riesgo | Documento con riesgo residual firmado | | 6 | Controles técnicos y política de retención | Cambios implantados y registro de actividades al día |

No hace falta hacerlo con todo a la vez. Empieza por el caso que más datos personales toca y el que más gente usa; suelen ser distintos, y suelen ser los dos que importan.

Preguntas frecuentes

¿Se pueden usar datos de clientes para entrenar un modelo propio?

Sí, si tienes una base legal válida para esa finalidad concreta y lo documentas. Lo que no vale es asumir que el dato recogido para prestar el servicio sirve automáticamente para entrenar. Cuando la finalidad original no cubre el uso, las salidas habituales son la anonimización previa o un interés legítimo bien ponderado con posibilidad real de oposición.

¿Qué diferencia hay entre el RGPD y el reglamento europeo de IA?

El RGPD protege datos personales; el reglamento de IA regula sistemas de IA según su riesgo, tengan o no datos personales. Se acumulan: un sistema puede ser de alto riesgo para la norma de IA y además tratar datos personales, y entonces cumples las dos. Ninguna sustituye a la otra ni exime de la otra.

¿Necesito delegado de protección de datos por usar IA?

Usar IA no obliga por sí solo. La figura es obligatoria si eres autoridad pública, si tu actividad principal exige observación habitual y sistemática a gran escala, o si tratas categorías especiales a gran escala. Ahora bien, si tu proyecto de IA te empuja hacia alguno de esos supuestos, la respuesta puede cambiar por el proyecto.

¿Basta con que el proveedor esté certificado?

No. Una certificación acredita que existen procesos, no que tu tratamiento concreto esté cubierto. Lo que te protege es el contrato de encargado con instrucciones documentadas, la ubicación del procesamiento, la retención declarada y la prohibición expresa de reutilizar tus datos para entrenar modelos del proveedor.

Si estás en el punto de «tenemos algo funcionando y no sabemos si aguanta una revisión», el paso barato es ordenar el mapa antes de tocar nada: qué usos hay, qué datos consumen y qué falta por escrito. Eso es parte de lo que sale de la auditoría, con la lista de lo que hay que corregir priorizada por riesgo real y no por susto. Y si prefieres contrastar tu caso concreto en media hora antes de mover ficha, hablemos.