RGPD y el Reglamento de IA: dónde chocan las obligaciones

Muchas empresas tratan el RGPD y el Reglamento de IA como dos expedientes distintos: uno para la persona que ya llevaba la protección de datos, otro nuevo para "lo de la IA". En la práctica, casi siempre es el mismo expediente. Un sistema de IA que procesa currículums, historiales de compra o transcripciones de llamadas está sujeto a las dos normas a la vez, y esas dos normas no siempre responden lo mismo ante el mismo hecho. Este artículo no explica qué es el Reglamento de IA desde cero: parte de que ya sabe que existe, y se centra en dónde se acumula con el RGPD y dónde genera fricción real, para que pueda abordar ambos regímenes de forma conjunta en lugar de uno después del otro.

El interés legítimo para entrenar modelos: lo que aclaró el CEPD, y lo que no

En diciembre de 2024, el Comité Europeo de Protección de Datos (CEPD) adoptó el Dictamen 28/2024, a petición de la autoridad irlandesa, para responder a una pregunta que llevaba tiempo sin resolverse con claridad: ¿puede una empresa entrenar o ajustar un modelo de IA con datos personales invocando el interés legítimo (artículo 6.1.f del RGPD) en lugar de pedir el consentimiento de cada persona? El Dictamen responde que sí es posible, pero no de forma automática: exige aplicar el mismo test de tres pasos que ya rige cualquier otro uso del interés legítimo —interés real, necesidad, ponderación frente a los derechos de las personas afectadas— aplicado ahora al entrenamiento de modelos.

El Dictamen también aborda cuándo un modelo puede considerarse anónimo, es decir, cuándo deja de estar sujeto al RGPD porque resulta muy improbable extraer datos personales de él. Aquí tampoco hay un criterio automático: se evalúa caso por caso, y entrenar un modelo con datos personales no lo convierte en un activo "limpio" de RGPD por el simple hecho de haber pasado por el entrenamiento. Para una empresa que use modelos de terceros ajustados con datos propios, o que aporte sus propios datos a un proceso de fine-tuning, esto significa que la pregunta "¿este modelo sigue siendo datos personales?" no se cierra sola: hay que poder justificarla.

Una misma decisión, dos pruebas jurídicas distintas

El artículo 22 del RGPD limita las decisiones basadas únicamente en tratamiento automatizado que produzcan efectos jurídicos o le afecten a una persona de forma significativa, y da derecho a intervención humana, a explicación y a impugnar la decisión. El Reglamento de IA, en cambio, clasifica como "alto riesgo" ciertos sistemas listados en su Anexo III —selección de personal, evaluación crediticia, acceso a prestaciones esenciales— con independencia de si la decisión final la toma el algoritmo en solitario o una persona que revisa su recomendación.

Son dos pruebas jurídicas distintas, y aprobar una no significa aprobar la otra. Un sistema puede quedar fuera del artículo 22 porque una persona revisa cada resultado antes de aplicarlo, y aun así ser de alto riesgo bajo el Reglamento de IA por la simple materia que trata. Y a la inversa, un sistema puede no figurar en el Anexo III y, sin embargo, producir decisiones automatizadas con efecto significativo que sí activan el artículo 22. Conviene revisar cada sistema de IA relevante contra ambos criterios por separado, en lugar de asumir que uno cubre al otro.

EIPD y FRIA: se parecen, pero no son intercambiables

El RGPD exige una Evaluación de Impacto relativa a la Protección de Datos (EIPD, artículo 35) cuando un tratamiento pueda suponer un alto riesgo para los derechos de las personas. El Reglamento de IA añade, en su artículo 27, una Evaluación de Impacto sobre los Derechos Fundamentales (FRIA) exigible a determinados responsables del despliegue de sistemas de alto riesgo, sobre todo organismos públicos o entidades que prestan servicios esenciales. La FRIA es más amplia que la EIPD: no se limita a la privacidad, sino que cubre el conjunto de derechos de la Carta de la UE, incluidos la no discriminación, la dignidad o el acceso a la justicia.

El propio artículo 27.4 del Reglamento de IA prevé que, si ya se ha realizado una EIPD que cubre parte del terreno, la FRIA debe complementarla en lugar de repetirla desde cero. Es una indicación clara de que el legislador esperaba que las empresas integraran ambos ejercicios, no que los tramitaran como procesos paralelos que acaban entrevistando a las mismas personas y revisando los mismos flujos de datos dos veces, con el riesgo añadido de llegar a conclusiones distintas sobre el mismo sistema.

Minimizar datos frente a modelos que rinden mejor con más datos

El principio de minimización del RGPD pide usar solo los datos necesarios para la finalidad concreta. El rendimiento de muchos sistemas de IA, en cambio, suele mejorar cuanto más volumen y variedad de datos ven durante el entrenamiento o el ajuste fino. Esta tensión no es un malentendido que se resuelva con un contrato bien redactado: es estructural, y aparece tanto al entrenar un modelo desde cero como al conectar un asistente de IA a los documentos internos de la empresa para que responda mejor.

La AEPD ha insistido en esta idea en su guía sobre adecuación al RGPD de tratamientos que incorporan inteligencia artificial: usar IA no justifica ampliar el volumen de datos tratados ni acceder a repositorios que no guarden relación con la finalidad original. La minimización, señala, debe aplicarse desde el diseño y mantenerse durante todo el ciclo de vida del tratamiento, no solo al recogerlo. En la práctica, esto no obliga a renunciar a los datos que un sistema realmente necesita, sino a poder explicar por qué cada categoría de dato es necesaria para ese uso concreto, y a preferir, cuando sea posible, técnicas que reduzcan la exposición sin degradar la función esencial del sistema.

Dos reguladores, dos procedimientos, un mismo sistema de IA

En España, la AEPD hace cumplir el RGPD. La vigilancia del mercado bajo el Reglamento de IA corresponde a AESIA, la agencia creada por el Real Decreto 729/2023 con sede en A Coruña, mientras que los modelos de IA de propósito general (GPAI) quedan bajo la Oficina de IA de la Comisión Europea, apoyada en el Código de Buenas Prácticas para GPAI publicado en julio de 2025. Son autoridades distintas, con procedimientos y calendarios propios.

La AEPD y AESIA han empezado a coordinarse públicamente, y el anteproyecto español de ley de IA prevé una comisión conjunta para evitar investigaciones duplicadas. Pero esa coordinación está en construcción, no terminada. En la práctica, un mismo sistema de IA que trata datos personales puede ser objeto de escrutinio por más de una autoridad, siguiendo lógicas distintas: una centrada en el tratamiento de datos, otra en el riesgo del sistema como producto.

Proveedores de IA fuera de la UE: el RGPD y el Reglamento de IA se acumulan

Cuando una empresa usa un proveedor de IA cuya infraestructura o matriz está fuera del Espacio Económico Europeo, entra en juego el capítulo V del RGPD sobre transferencias internacionales (artículos 44 a 49): hace falta una decisión de adecuación, cláusulas contractuales tipo u otra garantía adecuada y, tras la sentencia Schrems II, una evaluación del riesgo de la transferencia en la práctica. Esta obligación existe con independencia de cómo clasifique el Reglamento de IA a esa misma herramienta.

Es fácil dar por resuelta la cuestión de datos cuando se ha revisado la ficha del proveedor bajo el Reglamento de IA (su papel, su nivel de riesgo, si ha adherido al Código de Buenas Prácticas para GPAI). Pero son preguntas distintas: una empresa puede tener bien clasificado un sistema bajo el Reglamento de IA y seguir sin resolver, o sin plantearse siquiera, la base para la transferencia internacional de los datos que introduce en él cada vez que un empleado lo usa.

Qué significa esto en la práctica: revíselo junto, no en dos pasos

El punto en común de todo lo anterior es que tratar el RGPD y el Reglamento de IA como procesos secuenciales —primero uno, luego el otro— multiplica el trabajo y aumenta la probabilidad de llegar a conclusiones incoherentes sobre el mismo sistema. Algunas líneas concretas que ayudan a evitarlo:

• Mantenga un único inventario de usos de IA, no dos: para cada uso, registre qué datos personales toca, si encaja en el Anexo III de alto riesgo y si requiere EIPD, FRIA o ambas.
• Al evaluar un proveedor de IA no europeo, revise a la vez el contrato de tratamiento de datos (RGPD) y su papel bajo el Reglamento de IA (proveedor, importador, distribuidor o usuario), no solo uno de los dos frentes.
• Antes de iniciar una EIPD sobre un sistema de IA, pregúntese si también exige una FRIA, y si es así, constrúyalas como un único documento en vez de dos procesos paralelos.
• Documente la base jurídica del entrenamiento o ajuste con datos propios (interés legítimo u otra) con el mismo rigor que cualquier otra base de tratamiento; "es para mejorar el producto" no basta por sí solo como justificación.
• Organice la documentación de forma que sirva tanto ante una eventual actuación de la AEPD como de AESIA, sin tener que reconstruir el expediente para cada una.

Este contenido es información general para orientarse y no constituye asesoramiento jurídico sobre el caso concreto de su empresa: la interacción real entre el RGPD y el Reglamento de IA depende de los datos, los sistemas y los proveedores exactos que use cada organización. Cuando Komplya publica material de este tipo, distinguimos con claridad qué capas están revisadas legalmente y cuáles son borrador, para que pueda valorarlo con conocimiento de causa.

La forma más rápida de pasar de "probablemente esto nos afecta a los dos niveles" a una respuesta concreta es revisar, sistema por sistema, cómo usa realmente la IA su empresa y qué datos personales entran en cada uso.