Qué es exactamente un encargado del tratamiento

Un encargado del tratamiento es cualquier persona física o jurídica que trata datos personales por cuenta del responsable. La clave está en “por cuenta de”: el encargado no decide la finalidad ni los medios del tratamiento, solo ejecuta las instrucciones del responsable.

En la práctica, esto incluye casi cualquier proveedor de servicios que toque datos de la organización: el proveedor de correo electrónico, la plataforma de nóminas, el gestor de CRM, el sistema de videovigilancia con almacenamiento en la nube, la asesoría que procesa datos de empleados o clientes, el proveedor de hosting, la empresa de destrucción de documentos y, por supuesto, cualquier plataforma de IA que procese datos personales.

Qué debe contener el contrato del artículo 28

El artículo 28.3 del RGPD lista el contenido mínimo obligatorio. No es una lista orientativa: si falta alguno de estos elementos, el contrato no cumple el requisito:

• Objeto, duración, naturaleza y finalidad del tratamiento.
• Tipo de datos personales tratados y categorías de interesados.
• Obligaciones y derechos del responsable del tratamiento.
• Instrucción expresa de tratar los datos únicamente siguiendo las instrucciones documentadas del responsable.
• Obligación de confidencialidad del personal autorizado.
• Medidas de seguridad técnicas y organizativas del artículo 32.
• Condiciones para subcontratar con terceros (subencargados) y exigencia de que los subencargados asuman las mismas obligaciones.
• Asistencia al responsable para atender derechos ARSOPL y notificaciones de brechas.
• Eliminación o devolución de los datos al finalizar el servicio.
• Puesta a disposición del responsable de toda la información necesaria para demostrar el cumplimiento.

El problema de los contratos genéricos de prestación de servicios

Muchas organizaciones tienen firmado con sus proveedores un contrato mercantil de prestación de servicios que incluye alguna cláusula de confidencialidad. Eso no es suficiente. La AEPD distingue entre el contrato mercantil y el contrato de encargo: pueden ir en el mismo documento o ser documentos separados, pero el contenido del artículo 28.3 tiene que estar explícitamente recogido.

Un contrato que dice “el proveedor guardará confidencialidad sobre los datos a los que acceda” no cubre la obligación. Necesita especificar qué datos, para qué finalidad, con qué medidas de seguridad y qué pasa con ellos cuando termina la relación.

Los subencargados: el punto ciego más habitual

Cuando un encargado del tratamiento subcontrata parte del servicio a un tercero que también accede a datos personales, ese tercero se convierte en subencargado. El artículo 28.4 obliga al encargado a imponer al subencargado las mismas obligaciones de protección de datos que el responsable le impone a él.

Esto tiene consecuencias prácticas importantes. Si tu proveedor de software en la nube utiliza infraestructura de AWS, Google Cloud o Azure (como hace casi cualquier SaaS), esos proveedores de infraestructura son subencargados. El contrato con tu proveedor de software tiene que contemplar esta cadena y el responsable tiene que saber quiénes son los subencargados con acceso a sus datos.

Cómo regularizar la situación

El punto de partida es el Registro de Actividades de Tratamiento. Para cada tratamiento que identifiques, necesitas saber si interviene algún tercero en el procesamiento. Con esa lista de proveedores, el proceso es revisar qué contratos existen, si incluyen el contenido del artículo 28.3 y, donde no, solicitar al proveedor la firma del contrato de encargo.

La mayoría de proveedores grandes (Google, Microsoft, Amazon, Salesforce, HubSpot) tienen documentos de encargo del tratamiento estandarizados disponibles en su portal o bajo petición. El problema no suele ser la negativa del proveedor, sino que nadie en la organización ha iniciado ese proceso.

Conviene también documentar en el RAT, para cada encargado, el número y fecha del contrato firmado. No solo para tener el control interno, sino porque ante una inspección de la AEPD ese registro es la primera evidencia que se solicita.

Fuentes: Reglamento (UE) 2016/679 (RGPD), artículos 28, 29, 30 y 32; Directrices 07/2020 del Comité Europeo de Protección de Datos sobre los conceptos de responsable y encargado del tratamiento.

La entrada Encargados del tratamiento sin contrato: el incumplimiento más común del RGPD y cómo resolverlo se publicó primero en Adaptación RGPD.

Quién está obligado y desde cuándo

La obligación de disponer de un canal interno de información afecta a todas las empresas del sector privado con 50 o más trabajadores. Para las que tienen entre 50 y 249 empleados, la Ley permitió compartir canal con otras empresas del mismo grupo, lo que ha generado soluciones conjuntas en grupos empresariales medianos.

También están obligadas, con independencia de su tamaño, las entidades del sector financiero, los partidos políticos, sindicatos, organizaciones empresariales que reciban financiación pública y fundaciones creadas por partidos.

El canal debe gestionarlo una persona o unidad interna independiente, o puede externalizarse a un tercero. En cualquier caso, la responsabilidad de garantizar la confidencialidad y los plazos de respuesta recae siempre sobre la organización.

Los plazos que no admiten demoras

La Ley establece dos plazos irrenunciables. El primero: acuse de recibo de la denuncia en el plazo máximo de siete días desde su recepción. El segundo: comunicación al informante del resultado de las actuaciones en un plazo máximo de tres meses desde el acuse de recibo, prorrogable a seis meses en casos de especial complejidad.

El incumplimiento de estos plazos es una infracción directa de la Ley 2/2023, gestionada por la Autoridad Independiente de Protección al Informante (A.A.I.), el órgano de supervisión creado específicamente para este régimen.

La capa de protección de datos: artículo 24 LOPDGDD

Aquí es donde la mayoría de implementaciones tienen problemas. El artículo 24 de la LOPDGDD regula específicamente los sistemas de denuncias internas y establece condiciones particulares para el tratamiento de datos personales en este contexto.

Las más relevantes para el responsable del tratamiento:

• Confidencialidad obligatoria: la identidad del denunciante no puede revelarse sin su consentimiento, ni siquiera al afectado durante la investigación. Esto genera una tensión con el derecho de acceso del artículo 15 RGPD que la AEPD ha tenido que resolver en varias resoluciones.
• Acceso restringido: solo puede consultar los datos del canal el personal estrictamente necesario para gestionar las denuncias, no el departamento de RRHH general ni la dirección de forma indiscriminada.
• Plazo de conservación: los datos deben suprimirse en el plazo de tres meses desde la recepción si no se abre investigación. Con investigación en curso, pueden conservarse el tiempo necesario para su resolución y el eventual procedimiento sancionador o judicial.
• Registro de actividades de tratamiento: el canal debe tener su propio tratamiento en el RAT, con finalidad, base jurídica, categorías de datos y plazos de conservación correctamente documentados.

La posición de la AEPD sobre denuncias anónimas

La Ley 2/2023 permite, aunque no obliga, que el canal admita denuncias anónimas. La AEPD ha señalado en sus directrices que la decisión de admitir o no el anonimato es organizativa, pero que si se admite, el tratamiento de los datos del denunciante debe garantizar técnica y organizativamente que la identidad no puede vincularse a la denuncia. No basta con una política interna: las medidas tienen que ser efectivas.

Un canal que dice aceptar denuncias anónimas pero que registra la IP del formulario de envío o no separa técnicamente los datos identificativos de la denuncia está incumpliendo tanto la Ley 2/2023 como el artículo 24 LOPDGDD.

Errores más frecuentes en la implementación

Más allá de los problemas técnicos de anonimización, los fallos habituales son: no incluir el canal en el registro de actividades de tratamiento, no designar expresamente al responsable de gestión del canal, utilizar el correo electrónico corporativo general como canal (lo que compromete la confidencialidad), y no haber actualizado la política de privacidad para informar de la existencia y funcionamiento del sistema.

El canal de denuncias es uno de los pocos ámbitos donde el incumplimiento puede activar simultáneamente la A.A.I. por el lado laboral y la AEPD por el lado de protección de datos. Tenerlo bien configurado desde el principio es bastante más sencillo que gestionarlo a posteriori.

Fuentes: Ley 2/2023, de 20 de febrero, reguladora de la protección de las personas que informen sobre infracciones normativas; Directiva (UE) 2019/1937; Ley Orgánica 3/2018 (LOPDGDD), artículo 24; Reglamento (UE) 2016/679 (RGPD), artículos 13, 15 y 30.

La entrada Canal de denuncias Ley 2/2023: quién está obligado, qué datos se tratan y qué dice la AEPD se publicó primero en Adaptación RGPD.

El calendario real, sin ruido

El AI Act no se aplica de golpe. Su despliegue es escalonado y ya lleva dos años en marcha:

• Agosto 2024: entrada en vigor del Reglamento. Sin obligaciones operativas aún.
• Febrero 2025: prohibiciones absolutas (artículo 5) y obligación de alfabetización en IA del personal (artículo 4). Ya sancionable desde esa fecha.
• Agosto 2025: obligaciones para modelos de IA de uso general (GPAI) como ChatGPT, Claude o Gemini, más gobernanza y autoridades nacionales.
• Agosto 2026: aplicación plena para sistemas de alto riesgo del Anexo III, transparencia del artículo 50 y arranque efectivo de la vigilancia de mercado por la AESIA.
• Diciembre 2027: resto de sistemas de alto riesgo del Anexo III, según el aplazamiento aprobado por el Reglamento Ómnibus Digital en junio de 2026.

Aquí está el matiz importante: el Reglamento Ómnibus Digital aprobado en junio de 2026 aplazó hasta diciembre de 2027 las obligaciones de los sistemas de alto riesgo del Anexo III que aún no habían activado sus plazos completos. Los sistemas de alto riesgo integrados en productos regulados sectorialmente (Anexo I: dispositivos médicos, maquinaria, vehículos) pasan a agosto de 2028. Lo que no se aplazó son las obligaciones de transparencia del artículo 50 y las facultades sancionadoras de la Comisión.

Qué es un sistema de alto riesgo del Anexo III

El Anexo III lista los contextos de uso que convierten un sistema de IA en alto riesgo. Si tu empresa utiliza herramientas de IA en alguno de estos ámbitos, es probable que estés dentro del perímetro:

• Selección, evaluación o gestión del rendimiento de empleados.
• Scoring crediticio o fijación de precios de seguros de forma automatizada.
• Admisiones o evaluación en centros educativos.
• Decisiones sobre prestaciones sociales o acceso a servicios públicos.
• Infraestructuras críticas: energía, agua, transporte, redes digitales.

Para estos sistemas, las obligaciones incluyen un sistema de gestión de riesgos documentado y operativo, documentación técnica completa (Anexo IV), registros automáticos de actividad con trazabilidad, supervisión humana efectiva, no meramente formal, y una declaración UE de conformidad antes de poner el sistema en servicio.

La obligación que más empresas incumplen sin saberlo: el artículo 4

La obligación de alfabetización en IA del artículo 4 está vigente desde febrero de 2025 y ya es plenamente sancionable. Obliga a los proveedores y responsables del despliegue de sistemas de IA a garantizar que el personal que trabaja con esos sistemas tiene el nivel de conocimiento adecuado. No se trata de convertir a todo el equipo en ingenieros de ML: basta con que quien usa una herramienta de IA en su trabajo cotidiano entienda sus capacidades, sus limitaciones y los riesgos asociados a un uso indebido.

En España, la AESIA tiene competencia para supervisar este punto desde agosto de 2026. Es la única autoridad de IA dedicada de la Unión Europea (otros Estados canalizan la supervisión a través de su autoridad de protección de datos) y tiene sede en A Coruña desde 2023.

Transparencia del artículo 50: lo que afecta a casi todos

Aunque tu empresa no opere sistemas de alto riesgo, el artículo 50 sí te afecta probablemente. Obliga a identificar como tal cualquier chatbot o agente conversacional desplegado hacia usuarios, marcar técnicamente el contenido sintético generado (imágenes, vídeos, textos) e informar a los empleados cuando un sistema de IA interviene en decisiones que les afectan. Esto cubre la mayoría de las implementaciones de IA generativa en uso empresarial hoy.

Por dónde empezar

El primer paso es siempre clasificar cada sistema de IA que usa la empresa: prohibido, alto riesgo, riesgo limitado o riesgo mínimo. De esa clasificación depende todo lo demás. Un sistema mal clasificado en riesgo mínimo que en realidad opera en un contexto del Anexo III es el escenario que la AESIA va a encontrar con más frecuencia en sus primeras inspecciones.

Si no tienes ese inventario, el autodiagnóstico AESIA disponible en su sede electrónica es un punto de partida razonable antes de hacer cualquier inversión en adaptación.

Si necesitas adaptar tu empresa al AI Act, en Adapta RGPD ofrecemos consultoría y software de cumplimiento del AI Act con clasificación de riesgo, las 193 medidas AESIA y seguimiento continuo desde 199€/año.

Fuentes: Reglamento (UE) 2024/1689 (AI Act), artículos 4, 5, 50 y Anexos I, III y IV; Reglamento Ómnibus Digital (UE), junio de 2026; Real Decreto 729/2023 de creación de la AESIA.

La entrada AI Act: qué cambia en agosto de 2026 y qué tiene que hacer tu empresa antes de fin de año se publicó primero en Adaptación RGPD.

Si tu empresa usa inteligencia artificial para tratar datos de clientes, empleados o usuarios, tiene que cumplir dos reglamentos a la vez: el AI Act y el RGPD. No uno u otro según convenga. Los dos, en paralelo, porque regulan ángulos distintos del mismo problema.

El RGPD protege a las personas como titulares de datos. El AI Act protege a las personas como destinatarias de decisiones automatizadas. Son perspectivas complementarias, y en la mayoría de los sistemas de IA prácticos —análisis de clientes, selección de personal, segmentación de audiencias— las dos perspectivas se activan a la vez.

Entender cómo encajan no es teoría jurídica. Es saber qué tienes que hacer, en qué orden y quién es responsable de qué dentro de tu organización.

Qué regula cada normativa

El RGPD lleva en vigor desde mayo de 2018 y la mayoría de empresas ya han pasado por algún proceso de adaptación. Regula qué datos personales puedes recoger, con qué base jurídica, durante cuánto tiempo, con qué medidas de seguridad y qué derechos tienen las personas sobre esa información.

El AI Act (Reglamento UE 2024/1689) es más reciente: empezó a aplicarse de forma progresiva desde agosto de 2024. Su lógica es diferente: clasifica los sistemas de inteligencia artificial según el riesgo que generan y asigna obligaciones en función de ese riesgo. Los más peligrosos están directamente prohibidos; los de alto riesgo deben cumplir requisitos estrictos antes de operar; los de riesgo mínimo quedan prácticamente libres de obligaciones específicas.

Cuándo se aplican los dos a la vez

Un sistema de IA activa el RGPD en cuanto trata datos personales. Y casi cualquier sistema de IA orientado a personas lo hace: motores de recomendación, herramientas de selección de personal, chatbots que recogen información de usuarios, sistemas de videovigilancia inteligente, algoritmos de scoring crediticio. En todos esos casos, las dos normativas se aplican simultáneamente y no hay posibilidad de elegir una sola.

Dónde se solapan y dónde divergen

Hay varios puntos donde ambos marcos convergen y se refuerzan:

• Transparencia: el RGPD exige informar a las personas cuando se toman decisiones automatizadas sobre ellas (artículo 22). El AI Act exige transparencia en sistemas que interactúan con personas o toman decisiones con impacto significativo. Son obligaciones que deben cumplirse juntas, no por separado.
• Evaluaciones de impacto: el RGPD prevé la Evaluación de Impacto en la Protección de Datos (EIPD) para tratamientos de alto riesgo. El AI Act exige una evaluación de conformidad para sistemas de alto riesgo. En la práctica, muchos sistemas que son de alto riesgo según el AI Act también requieren una EIPD según el RGPD. Ambas deben hacerse, aunque pueden coordinarse para no duplicar trabajo.
• Calidad de los datos: el RGPD exige que los datos sean adecuados, pertinentes y limitados a lo necesario. El AI Act exige que los datos de entrenamiento y operación de sistemas de alto riesgo tengan calidad suficiente. El principio de minimización del RGPD y los requisitos de gobernanza de datos del AI Act apuntan en la misma dirección.
• Datos sensibles: el RGPD da protección especial a datos como origen racial, salud, biometría u orientación sexual. El AI Act prohíbe o restringe severamente usar IA para inferir esas mismas categorías.

La principal diferencia está en el objeto de regulación. El RGPD se activa por el tratamiento de datos personales, haya IA de por medio o no. El AI Act se activa por el uso de sistemas de IA, traten o no datos personales. En la práctica, los sistemas de IA casi siempre tratan datos personales, por lo que la combinación es la norma, no la excepción.

Quién es responsable de qué

Bajo el RGPD, la figura central es el responsable del tratamiento: quien decide por qué y cómo se tratan los datos. El AI Act introduce dos figuras distintas: el proveedor —quien desarrolla y comercializa el sistema de IA— y el deployer —quien lo implanta y usa en su contexto concreto.

Una empresa que compra una herramienta de IA para RRHH es responsable del tratamiento bajo el RGPD y deployer bajo el AI Act. El proveedor que desarrolló la herramienta tiene sus propias obligaciones (documentación técnica, marcado CE cuando aplica, registro), pero no es necesariamente responsable del tratamiento bajo el RGPD.

Este reparto importa porque debe quedar reflejado en los contratos. Los contratos de encargo del tratamiento que exige el RGPD deben complementarse ahora con cláusulas que regulen también las obligaciones del AI Act. Si los contratos con tus proveedores de IA no lo recogen, tienes una laguna que hay que cerrar.

Qué debe hacer una empresa que usa IA para cumplir los dos

El punto de partida es el mismo en ambas normativas: saber qué sistemas de IA usas, qué datos personales tratan, con qué finalidad y qué decisiones generan sobre personas. Sin ese inventario, no hay forma de saber qué te exige cada reglamento.

A partir de ahí:

• Clasificar cada sistema según el nivel de riesgo del AI Act (prohibido, alto riesgo, riesgo limitado, mínimo).
• Para los de alto riesgo, completar la evaluación de conformidad del AI Act y la EIPD del RGPD de forma coordinada.
• Revisar los contratos con proveedores de IA para incluir tanto las cláusulas de encargo del tratamiento (RGPD) como las obligaciones del deployer (AI Act).
• Actualizar los registros de actividades de tratamiento para reflejar los sistemas de IA que tratan datos personales.
• Informar a las personas cuando interactúan con sistemas de IA o son objeto de decisiones automatizadas.

Si tu empresa ya está adaptada al RGPD, tienes una base sólida para el AI Act. La documentación, los contratos y los procesos de evaluación que ya existen son el punto de partida, no el punto cero.

El papel de la AEPD y la AESIA

La Agencia Española de Protección de Datos (AEPD) sigue siendo la autoridad competente para el RGPD en España. Para el AI Act, el organismo designado es la Agencia Española de Supervisión de la Inteligencia Artificial (AESIA), creada en 2023 y con sede en A Coruña.

Ambas pueden actuar sobre la misma empresa si un sistema de IA infringe los dos reglamentos a la vez —lo que no es un escenario improbable. En esos casos, las empresas deben estar preparadas para responder ante las dos agencias.

Si quieres analizar cómo afecta el AI Act a los sistemas que ya usa tu empresa y cómo coordinar ese cumplimiento con el RGPD, en Adapta RGPD podemos ayudarte a hacer ese análisis y establecer un plan concreto.

La entrada AI Act y RGPD: cómo se relacionan y qué implica para tu empresa cumplir los dos se publicó primero en Adaptación RGPD.

Las autoridades de protección de datos europeas han pasado de concentrarse en expedientes grandes contra grandes tecnológicas a supervisar cómo las empresas gestionan la protección de datos en su operativa cotidiana. Eso amplía el perímetro de riesgo de forma considerable.

La AEPD en 2025: el volumen sancionador más alto de su historia

La Agencia Española de Protección de Datos cerró 2025 con 299 resoluciones sancionadoras firmes, un 12% más que en 2024, y un importe acumulado próximo a los 40 millones de euros. España representa alrededor del 35% del volumen total de resoluciones sancionadoras de toda la Unión Europea, con un importe medio por sanción inferior a la media europea pero compensado por el número de expedientes.

Algunos de los casos más relevantes de 2025:

• Aena recibió más de 10 millones de euros por instalar reconocimiento facial en aeropuertos sin haber realizado la Evaluación de Impacto obligatoria (artículo 35 RGPD).
• Vodafone España fue sancionada con 4,2 millones por tratamientos sin base jurídica suficiente.
• Endesa pagó 2,8 millones por medidas de seguridad insuficientes.

Los patrones que se repiten cada año

Más allá de los casos mediáticos, los focos de enforcement de la AEPD son estables y previsibles: videovigilancia sin cartelería ni base jurídica adecuada, marketing directo sin consentimiento válido, brechas de seguridad notificadas fuera de plazo o no notificadas, e información insuficiente al interesado en el momento de recogida de datos.

Las infracciones más frecuentes siguen siendo tres: ausencia de base jurídica para el tratamiento (artículo 6 RGPD), incumplimiento del deber de atender los derechos de los interesados (artículos 12 a 22) e información insuficiente o inexistente en el momento de recogida (artículo 13).

Qué tiene en el punto de mira la AEPD para 2026

La Memoria Anual 2025 de la AEPD, publicada bajo la nueva presidencia de Lorenzo Cotino Hueso, detalla las áreas de enforcement prioritarias para este año: IA generativa y entrenamiento de modelos con datos personales, cookies y consentimiento en plataformas digitales, y el tratamiento de datos de trabajadores en plataformas. A esto se suma que durante 2026 la agencia asume nuevas competencias derivadas del Reglamento de Inteligencia Artificial, el DSA y el Reglamento del Espacio Europeo de Datos Sanitarios.

Un dato preocupante de la memoria: la tasa de resolución de reclamaciones bajó del 96% al 76% pese a haberse resuelto 23.361 expedientes, cifra récord. La agencia atribuye la caída a la saturación de la Subdirección de Inspección. El efecto práctico es que los plazos de resolución se alargan, pero el volumen sancionador no disminuye.

El factor de reducción que muchos olvidan

El importe publicado en una resolución sancionadora no es el importe que finalmente paga la empresa. La LOPDGDD prevé reducciones acumulables de hasta el 40% por reconocimiento de responsabilidad (20%) y pago voluntario en el plazo establecido (20%). Conocer este mecanismo antes de recibir una propuesta de resolución marca la diferencia entre el importe máximo y el efectivo.

Mantener actualizado el registro de actividades de tratamiento, tener firmados los contratos con encargados y disponer de una política de privacidad que cumpla el artículo 13 sigue siendo la base del cumplimiento que más expedientes evita. No por ser lo más sofisticado, sino porque es lo que la AEPD comprueba primero.

Fuentes: GDPR Enforcement Tracker Report, CMS (datos hasta marzo 2026); Memoria Anual AEPD 2025; Reglamento (UE) 2016/679 (RGPD), artículos 6, 12-22, 35 y 83; Ley Orgánica 3/2018 (LOPDGDD), artículos 72-77.

La entrada Las multas RGPD superan 6.000 millones en Europa: qué sectores concentran el riesgo en 2026 se publicó primero en Adaptación RGPD.

El plazo original venció el 17 de octubre de 2024. Llevamos más de veinte meses de retraso y sin fecha confirmada de aprobación.

El error de razonamiento más caro

La conclusión fácil es que sin ley publicada en el BOE no hay obligación que cumplir. Es un razonamiento comprensible y bastante caro, porque las obligaciones de NIS2 ya están llegando a las empresas españolas por dos vías distintas a la inspectora.

La primera es contractual. Las empresas establecidas en países que sí han transpuesto (Alemania lleva operativa desde diciembre de 2025; Países Bajos aprobó su ley el 7 de julio de 2026) están exigiendo cuestionarios de seguridad a sus proveedores con los requisitos del artículo 21 de la Directiva. Si tu cliente es alemán, neerlandés o de cualquier otro Estado que ya tiene ley, el hecho de que España siga en tramitación parlamentaria no te exime de responder ese cuestionario. NIS2 ya está decidiendo contratos.

La segunda vía es regulatoria sectorial. El Esquema Nacional de Seguridad, DORA en el sector financiero y la normativa de infraestructuras críticas vigente ya cubren obligaciones sustancialmente equivalentes al artículo 21. Los organismos supervisores de esos sectores no esperan al BOE.

Dónde está el anteproyecto español

España aprobó el anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad en enero de 2025. Desde entonces sigue en tramitación parlamentaria sin mayoría suficiente para avanzar. La estimación más optimista lo sitúa en el último trimestre de 2026, pero no hay fecha confirmada. Mientras tanto, la Comisión acumula un caso con petición expresa de penalizaciones económicas diarias.

Qué puedes construir hoy sin esperar al legislador

Los controles técnicos del artículo 21 de NIS2 no dependen de que el Parlamento español los traslade a una norma nacional. Se pueden implementar ahora:

• Gestión de riesgos documentada: inventario de activos, análisis de amenazas y plan de tratamiento actualizado.
• Procedimiento de notificación de incidentes con los tres plazos: alerta en 24 horas, notificación formal en 72 horas e informe completo en un mes.
• Seguridad en la cadena de suministro: revisión de contratos con proveedores TIC críticos.
• Formación básica del personal, incluida la dirección. La responsabilidad de los órganos de gobierno es uno de los puntos más novedosos de NIS2.

Lo que más falla cuando finalmente llega la ley no son los controles técnicos (esos se pueden levantar en semanas), sino el reloj de notificación de incidentes. Un procedimiento no entrenado que tiene que responder en 24 horas por primera vez bajo presión real es el escenario que más expedientes abre.

Qué significa el caso ante el TJUE para el calendario

Los procedimientos ante el Tribunal de Justicia de la UE no suspenden las obligaciones subyacentes: las refuerzan con presión económica sobre el Gobierno. La historia de las transposiciones tardías en España muestra que la publicación de la ley normalmente se acelera una vez que el Tribunal fija las sanciones. Con ese precedente, la ventana de preparación se estrecha.

Si tu organización necesita revisar su posición frente a NIS2, el primer paso es determinar si cae bajo el perímetro de entidad esencial o entidad importante según los sectores del Anexo I y II de la Directiva y los umbrales de tamaño. Desde ahí, el plan de adaptación tiene una secuencia clara.

Fuentes: Decisión de la Comisión Europea de 8 de julio de 2026; Directiva (UE) 2022/2555 (NIS2), artículos 21, 23 y 41; anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad (España, enero 2025).

La entrada España ante el TJUE por no transponer NIS2: lo que ya obliga a tu empresa aunque no haya ley en el BOE se publicó primero en Adaptación RGPD.

Es, según la propia AEPD, uno de los primeros trabajos a nivel mundial que aborda esta cuestión de forma sistemática.

El problema de fondo: el RGPD no pensaba en la IA

Cuando el Reglamento General de Protección de Datos entró en vigor en 2018, los modelos de aprendizaje automático a gran escala apenas existían en el ámbito empresarial. Sus principios —entre ellos la exactitud y la minimización— se diseñaron pensando en tratamientos donde cada dato tiene un propósito claro y una relación directa con una persona.

Los sistemas de IA rompen ese esquema. Un modelo de clasificación de imágenes puede entrenarse con millones de fotos, de las cuales una fracción minoritaria contiene datos personales. Un modelo de lenguaje puede procesar texto en el que aparecen nombres, lugares y situaciones de personas reales. ¿Cómo aplican exactitud y minimización en ese contexto? Hasta ahora, la respuesta no era clara. La nota técnica de la AEPD pretende cambiar eso.

Exactitud no significa perfección: la matización clave

El principio de exactitud del artículo 5.1.d) del RGPD establece que los datos deben ser exactos y, si fuera necesario, actualizados. La interpretación clásica ha tendido a equiparar exactitud con veracidad absoluta: el dato debe ser correcto.

La AEPD matiza eso significativamente. La exactitud, en el contexto de tratamientos con IA, no exige que los datos sean siempre plenamente verídicos o estén completamente actualizados. Lo que exige es que sean adecuados para cumplir el objetivo del tratamiento y que esa adecuación se garantice cuando resulte relevante para las personas afectadas.

Esta distinción es importante en la práctica. Una exigencia de exactitud demasiado estricta podría entrar en conflicto con el principio de minimización —si hay que recopilar datos adicionales para verificar la exactitud de los existentes— o generar cargas desproporcionadas en el desarrollo de sistemas de IA que trabajan con datos históricos o incompletos por naturaleza.

La calidad del conjunto, no solo de cada dato

Uno de los hallazgos más relevantes de la nota técnica es el desplazamiento del foco desde el dato individual hacia el conjunto de datos. En modelos de aprendizaje automático, la calidad del dataset importa más que la exactitud de cada registro aislado.

La AEPD señala tres factores que determinan la calidad del conjunto en el contexto de la IA:

• Representatividad: el dataset debe representar adecuadamente la realidad que el modelo pretende aprender. Un conjunto sesgado producirá predicciones sesgadas, lo que puede generar impactos desproporcionados sobre determinados grupos de personas.
• Ausencia de sesgos: los datos de entrenamiento pueden contener sesgos históricos que el modelo replicará y amplificará. Identificarlos y mitigarlos forma parte de la obligación de exactitud.
• Relevancia: los datos deben ser pertinentes para la tarea que el sistema va a realizar. Incluir datos irrelevantes no es neutral: introduce ruido y puede comprometer tanto la calidad del modelo como el principio de minimización.

Los resultados también tienen que ser exactos

La nota técnica extiende el requisito de exactitud más allá de los datos de entrada. Las inferencias, predicciones y decisiones generadas por los sistemas de IA también deben ser exactas en el sentido del RGPD. No deben producir representaciones incorrectas o desproporcionadas de las personas afectadas.

Esto tiene implicaciones directas para los sistemas que toman decisiones automatizadas con impacto en personas: scoring crediticio, sistemas de selección de personal, recomendación de tratamientos médicos, valoración de riesgos de seguros. El hecho de que sea un algoritmo quien produzca la predicción no exime a la organización de la obligación de que esa predicción sea exacta y no genere consecuencias injustas.

Minimización y IA: el equilibrio difícil

El principio de minimización exige recoger únicamente los datos necesarios para la finalidad del tratamiento. En el contexto del entrenamiento de modelos de IA, esto plantea una tensión real: los modelos suelen mejorar con más datos, pero más datos no siempre está justificado.

La AEPD no resuelve esta tensión con una regla simple, porque no la hay. Lo que establece es que la evaluación debe hacerse en función de la finalidad concreta del sistema, considerando qué datos son realmente necesarios para lograr la precisión requerida, y documentando esa decisión.

En la práctica, esto significa que las organizaciones deben ser capaces de justificar por qué cada categoría de dato incluida en el entrenamiento es necesaria, y no limitarse a recopilar todo lo disponible porque “más datos es mejor”.

Qué deben hacer ahora los responsables de proyectos de IA

La nota técnica de la AEPD no crea nuevas obligaciones formales, pero sí clarifica cómo se aplican las existentes. Para los equipos que desarrollan o supervisan sistemas de IA en sus organizaciones, las implicaciones prácticas son inmediatas:

• Documentar la evaluación de calidad del dataset antes del entrenamiento, incluyendo análisis de representatividad y sesgos
• Definir criterios de exactitud para los outputs del modelo, no solo para los inputs
• Justificar la necesidad de cada categoría de dato en el expediente de evaluación de impacto
• Revisar periódicamente la calidad del conjunto de entrenamiento, especialmente si el modelo se usa durante años
• Incorporar estos criterios en los contratos con encargados que desarrollen o mantengan modelos de IA

Conclusión

La nota técnica de la AEPD sobre calidad de datos en IA llega en un momento en que muchas organizaciones están tomando decisiones de fondo sobre cómo y con qué datos construir sus sistemas. Leerla ahora, antes de que esas decisiones estén tomadas, es mucho más útil que tener que reconstruirlas después bajo presión regulatoria.

¿Tu empresa está desarrollando o implantando sistemas de IA? En Adaptación RGPD te ayudamos a evaluar el impacto sobre la protección de datos y a documentar el cumplimiento del RGPD y el AI Act desde el primer día.

La entrada La AEPD aclara cómo aplican exactitud y minimización de datos en sistemas de inteligencia artificial se publicó primero en Adaptación RGPD.

Qué es la IA agéntica y por qué plantea nuevos retos para la protección de datos

Un agente de IA es un sistema capaz de ejecutar tareas de forma autónoma: consultar fuentes de información, adoptar decisiones intermedias, activar herramientas externas y completar flujos de trabajo sin intervención humana paso a paso. Desde chatbots con capacidad de acción hasta sistemas de automatización de procesos internos, la IA agéntica ya está presente en muchas organizaciones.

El problema es que el RGPD fue diseñado pensando en tratamientos donde el responsable controla y documenta cada operación. Con un agente autónomo, el proceso se convierte en una cadena de microacciones que, si no se registra adecuadamente, resulta imposible de auditar o de explicar ante la AEPD o ante los propios interesados.

Lo que exige la AEPD: reconstruir el proceso, no solo el resultado

La Agencia destaca que registrar únicamente el resultado final ya no es suficiente. Las organizaciones que despliegan agentes de IA necesitan poder reconstruir el proceso completo seguido por el agente:

• Qué información utilizó en cada paso
• Qué decisiones adoptó y con qué criterios
• Qué herramientas o APIs consultó
• Qué acciones ejecutó finalmente

Esta capacidad de trazabilidad es, según la AEPD, esencial para tres objetivos: investigar incidentes cuando algo sale mal, justificar actuaciones ante reclamaciones o inspecciones, y demostrar el cumplimiento del principio de responsabilidad proactiva del RGPD.

La conexión con el AI Act: trazabilidad como obligación doble

La trazabilidad no es solo un requisito del RGPD. El AI Act, aplicable desde agosto de 2026 para los sistemas de IA de alto riesgo, refuerza exactamente las mismas exigencias. Los artículos sobre registro de eventos, documentación técnica del Anexo IV y supervisión durante todo el ciclo de vida del sistema convergen en el mismo punto: hay que poder explicar qué hizo el sistema, cuándo y por qué.

Para las organizaciones que ya trabajan en su adaptación al AI Act, esto significa que la infraestructura de logs y auditoría que construyan para el Reglamento de IA servirá también para reforzar el cumplimiento del RGPD. Es una inversión con doble retorno regulatorio.

Calidad y exactitud de los datos en tratamientos con IA: la nota técnica de julio

Paralelamente, la AEPD publicó el 21 de julio de 2026 una nota técnica sobre calidad, exactitud y minimización de datos personales en tratamientos con IA. Es uno de los primeros documentos en el mundo que aborda de forma sistemática cómo proyectar los principios del RGPD sobre sistemas de aprendizaje automático.

Las conclusiones más relevantes para las empresas son tres:

• Exactitud no significa perfección absoluta, sino adecuación al propósito del tratamiento. Exigir datos perfectamente verídicos en todos los casos podría entrar en conflicto con el principio de minimización.
• La calidad del conjunto importa más que la de cada dato. En modelos de aprendizaje automático, la representatividad y la ausencia de sesgos pueden ser más determinantes que la exactitud individual de cada registro.
• Los resultados también deben ser exactos. Las inferencias, predicciones y decisiones generadas por los sistemas de IA no deben producir representaciones incorrectas o desproporcionadas de las personas.

Qué deben hacer las organizaciones que usan agentes de IA

Las orientaciones de la AEPD sobre gobernanza de la IA agéntica son claras en cuanto a la dirección, aunque cada organización debe adaptarlas a su contexto. Los pasos más inmediatos son:

• Inventariar qué sistemas de IA agéntica están en uso y qué datos personales procesan
• Diseñar o revisar la arquitectura de logs para que capture el proceso completo, no solo el output
• Establecer una política de retención de registros proporcional al riesgo del sistema
• Integrar la revisión de logs en los procedimientos de respuesta a incidentes y a solicitudes de derechos
• Documentar los criterios con los que el agente toma decisiones, especialmente cuando afectan a personas

La trazabilidad no es un lujo técnico. Es la condición mínima para que una organización pueda demostrar que controla lo que su IA hace en su nombre.

Conclusión

La AEPD está marcando el paso: quien use IA agéntica sin registros auditables está operando con un riesgo regulatorio significativo bajo el RGPD y, desde agosto de 2026, también bajo el AI Act. Construir esa capacidad ahora, antes de que llegue una inspección o un incidente, es mucho más barato que remediarlo después.

¿Tu empresa está implementando agentes de IA? En Adaptación RGPD te ayudamos a evaluar los riesgos y a diseñar una arquitectura de cumplimiento que cubra tanto el RGPD como el AI Act.

La entrada Trazabilidad en agentes de IA: la AEPD fija criterios para cumplir RGPD y AI Act se publicó primero en Adaptación RGPD.

Qué dice el artículo 21 del RGPD sobre el derecho de oposición

El artículo 21.2 del Reglamento General de Protección de Datos reconoce que, cuando los datos personales se tratan con fines de mercadotecnia directa, el interesado puede oponerse en cualquier momento y sin necesidad de justificar su decisión. El artículo 21.3 es igual de claro: una vez ejercitado ese derecho, los datos dejan de tratarse para esa finalidad de forma inmediata.

La lógica es sencilla en papel, pero su aplicación práctica en organizaciones con múltiples sistemas resulta más compleja de lo que parece.

El error más frecuente: retirar de una campaña sin bloquear en todos los sistemas

Muchas empresas dan por cumplida su obligación cuando eliminan al interesado de la lista de una campaña concreta. Eso no es suficiente. La obligación es estructural: la exclusión debe propagarse a todos los sistemas que la organización utilice para comunicaciones comerciales —CRM, herramienta de email marketing, bases de datos comerciales y, cuando proceda, proveedores externos que actúen como encargados del tratamiento.

Además, la empresa debe mantener una lista interna de exclusión publicitaria con los datos mínimos necesarios para identificar al interesado y evitar que sea reincorporado a futuras acciones comerciales. No se trata de borrar el registro, sino de marcarlo y asegurarse de que ningún proceso posterior lo reactive.

La sanción: 680.000€ a una empresa de vehículos de ocasión

La AEPD, en la resolución PS-00540-2025, sanciona con 680.000 euros a una empresa especializada en la compraventa de vehículos de ocasión tras una brecha de seguridad que permitió el acceso y exfiltración de datos personales de clientes y potenciales clientes.

El incidente afectó a información identificativa y de contacto facilitada a través de formularios web, incluyendo en determinados casos números de DNI. La investigación puso de manifiesto deficiencias en las medidas técnicas y organizativas de seguridad, algunas de ellas previamente identificadas mediante auditorías y no corregidas de forma eficaz antes del ciberataque.

La AEPD apreció tres incumplimientos principales:

• Vulneración del principio de integridad y confidencialidad (400.000€)
• Insuficiencia de medidas de seguridad (250.000€)
• Deficiencias en el deber de información, especialmente sobre los plazos de conservación de datos de potenciales clientes (30.000€)

La resolución es especialmente relevante porque evidencia algo que muchas empresas descuidan: los datos de personas que rellenaron un formulario pero no llegaron a formalizar ninguna contratación también tienen plazos de conservación definidos y derechos que respetar.

La obligación de conservar evidencias del ejercicio de derechos

Uno de los principios del RGPD que con más frecuencia se olvida en la práctica es el de responsabilidad proactiva. No basta con aplicar el derecho de oposición: hay que poder demostrar que se recibió y se gestionó correctamente.

Esto implica registrar la fecha de recepción de la solicitud, el canal por el que llegó, las acciones adoptadas y los sistemas que se actualizaron. Ante una reclamación o una auditoría de la AEPD, esa trazabilidad es la única defensa sólida.

Qué debe revisar tu empresa ahora mismo

Si tu organización realiza envíos de email marketing, campañas publicitarias o comunicaciones comerciales de cualquier tipo, vale la pena verificar lo siguiente:

• ¿Existe un procedimiento documentado para gestionar el derecho de oposición?
• ¿La exclusión se propaga automáticamente a todos los sistemas, incluidos proveedores externos?
• ¿Se conservan evidencias de cada solicitud y de las acciones adoptadas?
• ¿Los datos de formularios web de potenciales clientes tienen un plazo de conservación definido y comunicado?
• ¿Se revisan periódicamente las listas de exclusión para detectar posibles reincorporaciones involuntarias?

Si alguna de estas respuestas es negativa, tu empresa acumula un riesgo real. La resolución PS-00540-2025 demuestra que la AEPD no se limita a sancionar la brecha en sí, sino también las deficiencias previas que la facilitaron y que no se corrigieron a tiempo.

Conclusión

El derecho de oposición no es un trámite puntual. Es un proceso continuo que afecta a la arquitectura de datos de la organización. Gestionarlo bien requiere integración entre sistemas, documentación de cada gestión y revisiones periódicas. Y hacerlo mal, como demuestra esta resolución, puede costar más de medio millón de euros.

¿Necesitas revisar cómo tu empresa gestiona el derecho de oposición y las comunicaciones comerciales? En Adaptación RGPD te ayudamos a hacer una revisión rápida y a implantar las medidas necesarias.

La entrada Sanción de 680.000€ por no gestionar el derecho de oposición en marketing directo se publicó primero en Adaptación RGPD.

El AI Act —el Reglamento europeo de inteligencia artificial— no solo regula cómo deben diseñarse los sistemas de IA. También establece una lista de prácticas de IA directamente prohibidas, sin excepciones posibles, que entraron en vigor el 2 de febrero de 2025.

A diferencia de las obligaciones para sistemas de alto riesgo, que dependen del sector y del uso, las prohibiciones del AI Act son absolutas: da igual el tamaño de la empresa, el sector en el que opera o el propósito declarado. Si tu sistema de IA realiza alguna de estas prácticas, debes eliminarlo o modificarlo de forma que deje de hacerlo.

Este artículo recorre cada práctica prohibida con lenguaje claro, sin tecnicismos innecesarios, para que puedas evaluar si alguna afecta a tu organización.

La lista completa de prácticas de IA prohibidas por el AI Act

El artículo 5 del AI Act enumera ocho categorías de prácticas prohibidas. Las repasamos una a una.

1. Manipulación subliminal o engañosa

Está prohibido utilizar sistemas de IA que empleen técnicas subliminales —por debajo del umbral de conciencia— o métodos deliberadamente engañosos para distorsionar el comportamiento de una persona de forma que pueda causarle un perjuicio. Esto incluye interfaces diseñadas para manipular decisiones sin que el usuario sea consciente de ello.

El ejemplo más claro son los sistemas de recomendación que usan patrones de diseño oscuros (dark patterns) combinados con IA para inducir compras, suscripciones o comportamientos que el usuario rechazaría si fuera plenamente consciente de la influencia.

2. Explotación de vulnerabilidades

Se prohíbe expresamente el uso de IA para explotar las vulnerabilidades de personas o grupos específicos —edad, discapacidad, situación socioeconómica— con el objetivo de distorsionar su conducta de forma perjudicial para ellos. Un sistema de IA dirigido a personas mayores con deterioro cognitivo para inducirles a contratar servicios que no necesitan es un ejemplo directo de esta prohibición.

3. Sistemas de puntuación social por parte de poderes públicos

El AI Act prohíbe que las autoridades públicas utilicen sistemas de IA para evaluar o clasificar a personas físicas en función de su comportamiento social durante un determinado periodo de tiempo, cuando esa clasificación derive en un trato perjudicial o desfavorable. Es la prohibición conocida popularmente como la del “crédito social” al estilo chino, pero el artículo 5 la extiende a cualquier sistema de puntuación social con efectos negativos.

Esta prohibición afecta principalmente a administraciones públicas, no a empresas privadas, aunque los sistemas de IA que estas últimas desarrollen para uso gubernamental también quedan alcanzados.

4. Evaluación del riesgo de comportamiento criminal basada solo en características personales

Está prohibido utilizar sistemas de IA para predecir que una persona cometerá un delito basándose únicamente en su perfil —rasgos físicos, localización geográfica, etnia, historial familiar— sin que existan hechos objetivos relacionados con esa persona concreta. Esto afecta directamente a los sistemas de IA predictiva usados por fuerzas de seguridad y cierra la puerta a herramientas que hacen perfilado racial o socioeconómico para anticipar comportamientos delictivos.

5. Reconocimiento facial y biometría en espacios públicos en tiempo real

El uso de sistemas de identificación biométrica remota en tiempo real en espacios de acceso público está prohibido, con excepciones muy acotadas que solo se aplican a fuerzas y cuerpos de seguridad del Estado bajo autorización judicial. Esto significa que una empresa privada no puede instalar sistemas de reconocimiento facial en tiempo real en centros comerciales, eventos o instalaciones de acceso público.

Importante: los sistemas de identificación biométrica en diferido (a posteriori, no en tiempo real) no están prohibidos para autoridades, pero sí están fuertemente regulados como sistemas de alto riesgo.

6. Categorización biométrica por atributos sensibles

Está prohibido usar sistemas de IA que infieran o categoricen a personas en función de atributos especialmente sensibles a partir de datos biométricos: origen racial o étnico, opiniones políticas, creencias religiosas, orientación sexual o afiliación sindical. La prohibición aplica tanto a datos biométricos directos (imagen facial, huella) como indirectos (voz, marcha).

7. Inferencia de emociones en el entorno laboral y educativo

Los sistemas de IA diseñados para detectar o inferir el estado emocional de trabajadores y estudiantes están prohibidos, salvo excepciones médicas o de seguridad debidamente justificadas. Esto afecta directamente a herramientas de recursos humanos que analizan el tono de voz en llamadas, la expresión facial en videoentrevistas o el nivel de atención en plataformas de e-learning.

Si tu empresa usa o planea usar este tipo de herramientas de análisis emocional sobre empleados o alumnos, debes revisarlo urgentemente.

8. Scraping masivo de imágenes para bases de datos de reconocimiento facial

Está prohibida la creación de bases de datos de reconocimiento facial mediante la recopilación masiva y no selectiva de imágenes de personas en internet o en espacios públicos. Esta práctica, que algunos sistemas de IA han usado para entrenarse con millones de fotos sin consentimiento, queda expresamente vetada.

¿Cuándo entraron en vigor las prohibiciones del AI Act?

El AI Act se publicó en el Diario Oficial de la Unión Europea el 12 de julio de 2024 y entró en vigor 20 días después. Las prohibiciones del artículo 5 fueron las primeras en aplicarse, con un periodo de adaptación de seis meses: su fecha de obligado cumplimiento es el 2 de febrero de 2025.

Esto significa que, a diferencia de otras obligaciones del AI Act que no serán exigibles hasta 2026 o 2027, las prácticas prohibidas ya son ilegales hoy. Las empresas que operen sistemas de IA con alguna de estas características están en situación de incumplimiento ahora mismo.

Qué pasa si tu empresa incumple las prohibiciones

El AI Act establece un régimen sancionador propio. Las infracciones por prácticas prohibidas del artículo 5 son las más graves del reglamento y pueden conllevar multas de hasta 35 millones de euros o el 7% de la facturación anual mundial, la cifra que sea mayor.

Aunque los organismos nacionales de supervisión del AI Act todavía están en proceso de configuración en muchos Estados miembros —incluida España—, el reglamento ya es aplicable. La Agencia Española de Supervisión de la Inteligencia Artificial (AESIA) fue creada precisamente para asumir estas funciones de control.

AI Act y RGPD: dos normativas que se aplican a la vez

Muchas de las prácticas prohibidas por el AI Act también vulneran el RGPD, especialmente cuando implican tratamiento de datos biométricos o categorías especiales de datos. Las dos normativas se aplican de forma paralela: cumplir el AI Act no exime del RGPD, y viceversa.

Para empresas ya adaptadas al RGPD, el análisis de las prohibiciones del AI Act debe hacerse como una capa adicional, no como un proceso separado. Si tienes dudas sobre cómo afecta el AI Act a tus sistemas de IA actuales, el punto de partida es revisar qué datos tratan esos sistemas y con qué finalidad.

Cómo saber si tu empresa usa alguna práctica prohibida

Estas son las preguntas que deberías hacerte:

• ¿Usas sistemas de IA para analizar o inferir emociones de empleados, candidatos o estudiantes?
• ¿Tienes reconocimiento facial activo en instalaciones de acceso público?
• ¿Algún sistema de IA clasifica a personas en función de su comportamiento o características personales para tomar decisiones que les perjudican?
• ¿Has comprado o desarrollado bases de datos de imágenes faciales sin consentimiento explícito de los afectados?

Si la respuesta a alguna de estas preguntas es sí, o no lo tienes claro, conviene hacer una auditoría de tus sistemas de IA antes de que llegue una inspección.

En Adapta RGPD analizamos los sistemas de inteligencia artificial de tu organización y evaluamos su cumplimiento con el AI Act y el RGPD. Contacta con nosotros si tienes dudas sobre alguna herramienta concreta.

La entrada Prácticas de IA prohibidas por el AI Act: lo que tu empresa ya no puede hacer se publicó primero en Adaptación RGPD.