Evaluación de impacto en protección de datos (EIPD) para agentes de IA: obligación, umbrales y procedimiento paso a paso

Una evaluación de impacto relativa a la protección de datos (EIPD, en inglés DPIA) es obligatoria según el art. 35 del RGPD cuando sea probable que un tratamiento entrañe un alto riesgo para los derechos y libertades de las personas físicas. Para los agentes de IA es necesaria en la práctica casi siempre, porque estos sistemas suelen cumplir varios criterios de riesgo a la vez, por ejemplo tecnología innovadora más elaboración de perfiles, decisiones automatizadas o la combinación de conjuntos de datos de varias fuentes.

Este artículo forma parte del hub temático «Uso de agentes de IA conforme al RGPD» y ofrece un procedimiento paso a paso sólido y una lista de comprobación de desencadenantes para responsables del tratamiento en Europa.

Respuestas rápidas

• Umbral: La EIPD es obligatoria en cuanto sea probable un alto riesgo (art. 35, apartado 1). El art. 35, apartado 3, enumera tres supuestos típicos y el art. 35, apartado 4, obliga a las autoridades de control a publicar listas obligatorias: en Alemania, la lista de la DSK para el sector no público; en Austria, el reglamento DSFA-V de la autoridad de protección de datos. En Suiza, la obligación de EIPD se deriva del art. 22 de la DSG; el RGPD solo se aplica allí cuando concurren los supuestos del art. 3, apartado 2, del RGPD.
• La IA en la práctica: Por la elaboración de perfiles, las decisiones automatizadas y la tecnología innovadora, los agentes de IA activan casi siempre la obligación de realizar una EIPD.
• Procedimiento: La EIPD sigue un proceso documentado: descripción del tratamiento como componente obligatorio y, después, necesidad/proporcionalidad, identificación de riesgos, evaluación de riesgos y medidas correctoras. Si el riesgo residual es alto, sigue la consulta previa según el art. 36.

Qué es una EIPD según el art. 35 del RGPD

El art. 35, apartado 1, del RGPD obliga al responsable del tratamiento a realizar una EIPD cuando sea probable que un tipo de tratamiento, en particular si utiliza nuevas tecnologías, por su naturaleza, alcance, contexto o fines, entrañe un alto riesgo para los derechos y libertades de las personas físicas. La EIPD es, por tanto, un instrumento previo de gestión de riesgos: se elabora antes de iniciar el tratamiento y documenta si los riesgos se controlan y cómo.

Importante: el responsable del tratamiento (controller) sigue siendo competente para la EIPD aunque no haya desarrollado él mismo el agente de IA. La DSK establece en su guía orientativa «Künstliche Intelligenz und Datenschutz» (versión 1.0, 6 de mayo de 2024) que el uso de aplicaciones de IA requerirá en muchos casos una EIPD (punto 39). Si el responsable no es a la vez proveedor del sistema de IA, depende para ello de la información del proveedor sobre su funcionamiento (punto 40).

Cuándo es obligatoria la EIPD para agentes de IA

El art. 35, apartado 3, enumera tres supuestos legales típicos (presunciones):

1. Evaluación sistemática y exhaustiva de aspectos personales, incluida la elaboración de perfiles, con efectos significativos.
2. Tratamiento a gran escala de categorías especiales (art. 9) o de datos relativos a condenas penales (art. 10).
3. Observación sistemática a gran escala de zonas de acceso público.

Además, el art. 35, apartado 4, del RGPD obliga a las autoridades de control a publicar listas de los tratamientos que requieren una EIPD. Para los responsables privados en Alemania rige la lista obligatoria de la DSK para el sector no público (versión 1.1 del 17 de octubre de 2018); en Austria, el reglamento DSFA-V de la autoridad de protección de datos (BGBl. II Nr. 278/2018). En Suiza, la obligación de EIPD se deriva del art. 22 de la DSG. El RGPD solo se aplica a los responsables suizos si ofrecen bienes o servicios a personas en la UE o controlan su comportamiento allí (art. 3, apartado 2, del RGPD). Para los agentes de IA, las entradas más relevantes de la lista de la DSK son estas:

• Uso de IA que trata datos personales para dirigir la interacción con los interesados o evaluar aspectos personales (n.º 11), por ejemplo en la atención al cliente
• Combinación a gran escala de datos de varias fuentes cuando con ello se preparan decisiones con efectos jurídicos, por ejemplo en el scoring (n.º 5), o se buscan correlaciones desconocidas (n.º 10)
• Perfiles exhaustivos sobre intereses, relaciones o personalidad (n.º 9)
• Análisis automatizado de grabaciones de vídeo o audio para evaluar la personalidad (n.º 13)
• Identificación biométrica o datos genéticos, cuando se cumpla al menos otro criterio del WP248 (n.º 1 y 2)
• Análisis a gran escala del comportamiento de los empleados para evaluar su trabajo (n.º 8)

La consecuencia práctica: por uno o varios de estos puntos, los agentes de IA activan casi siempre la obligación de realizar una EIPD.

Lista de comprobación de desencadenantes para agentes de IA

Si el tratamiento entra en un supuesto típico del art. 35, apartado 3, o figura en una lista obligatoria según el art. 35, apartado 4, la EIPD es obligatoria. Para los demás criterios, las directrices WP248 rev.01 dan una regla práctica: a partir de dos criterios cumplidos debe realizarse una EIPD, y en casos concretos ya con uno. En caso de duda, conviene un examen previo de umbral documentado («threshold assessment») que justifique por qué no sería necesaria una EIPD; así se cumple la responsabilidad proactiva del art. 5, apartado 2.

La metodología de la EIPD paso a paso

La descripción del tratamiento es, según el art. 35, apartado 7, letra a), del RGPD, un componente obligatorio previo de toda EIPD: una descripción sistemática del agente de IA con un diagrama de flujo de datos que refleje cada salto de datos personales (usuario → runtime del agente → API del modelo → almacén vectorial → servidor MCP → backend de observabilidad → logs), además de la arquitectura del sistema con mapa de subencargados y asignación de roles (responsable, corresponsables, encargados, subencargados con una cadena ininterrumpida según el art. 28, apartado 4).

Sobre esta base siguen los cuatro pasos centrales que se derivan del art. 35, apartado 7, letras b) a d), del RGPD. Coinciden con las directrices WP248 rev.01 del Grupo de Trabajo del Artículo 29, que el CEPD ha ratificado. El Kurzpapier n.º 5 de la DSK los sitúa en un ciclo de preparación, ejecución, implementación y revisión:

1. Necesidad y proporcionalidad. ¿Es el tratamiento estrictamente necesario? ¿Bastarían datos anónimos, seudonimizados o sintéticos? ¿Se han minimizado el volumen de datos y el plazo de conservación? En concreto, con RAG: indexación de chunks seudonimizados y minimización de los payloads de contexto.
2. Identificación de riesgos. Registro de los riesgos específicos de la IA (ver la sección siguiente), referidos a cada grupo de interesados.
3. Evaluación de riesgos. Valoración de cada riesgo según probabilidad por gravedad.
4. Tratamiento de riesgos y aceptación del riesgo residual. Medidas técnicas según el art. 32 (cifrado, seudonimización, controles de acceso, registro de actividad, defensa contra la inyección de prompts), medidas organizativas (formación, gobernanza) y medidas contractuales (cláusulas del contrato de encargo), así como la aceptación documentada del riesgo residual.

Forman parte de ello las pruebas de consulta necesarias: el dictamen del delegado de protección de datos (art. 35, apartado 2), la participación del comité de empresa o de la representación del personal cuando proceda (§ 87 BetrVG, ArbVG austriaca, normas suizas de participación) y, cuando sea viable, la consulta a los grupos de interesados (art. 35, apartado 9).

Riesgos específicos de la IA en el registro de riesgos

En los agentes de IA, el catálogo de riesgos es mucho más amplio que en el tratamiento de datos clásico. La EIPD debe tener en cuenta como mínimo:

• Alucinación: datos personales inventados pero verosímiles; a la vez inexactos (art. 5, apartado 1, letra d) y fuente de riesgo de reidentificación
• Sesgo y discriminación en los resultados de scoring y ranking
• Inyección de prompts, incluidos ataques entre clientes (cross-tenant) que extraen datos ajenos
• Fuga de memoria entre sesiones a través de memoria compartida o prompts de sistema
• Regurgitación en los outputs de PII de los datos de entrenamiento
• Desviación del alcance (scope creep) e inferencia no autorizada
• Exfiltración de datos mediante llamadas a herramientas hacia subencargados no documentados
• Reidentificación mediante inversión de embeddings: los embeddings no son anónimos de forma automática y se consideran datos personales seudonimizados
• Riesgo de la cadena de suministro a través de una pila de subencargados de cinco a ocho niveles

La guía orientativa de la DSK sobre RAG (2025) añade dos riesgos específicos de RAG: los ataques de inferencia de pertenencia (membership inference) y el envenenamiento de datos (data poisoning). La publicación de la DSK «Datenschutzrechtliche Anforderungen an KI-Systeme» (17 de junio de 2025) aporta además la correspondencia operativa con el Modelo Estándar de Protección de Datos (SDM).

Ejemplo concreto con cifras: agente de atención al cliente

Una empresa mediana (800 empleados) de Austria planea un agente de atención al cliente basado en Azure OpenAI. Cada mes, el agente procesa unas 40.000 conversaciones, de las cuales se estima que el 30 % (es decir, unas 12.000) contienen datos identificativos de clientes en los prompts. Las decisiones de escalado se preparan inicialmente de forma automatizada.

En la EIPD, el riesgo «regurgitación en los outputs de PII de los datos de entrenamiento» se valora con probabilidad «media» y gravedad «alta». Medidas: filtros de salida, prueba de red team sobre memorización y ponderación de intereses documentada. En el riesgo «fuga de memoria entre sesiones», un aislamiento estricto entre clientes reduce la probabilidad de «media» a «baja». La conservación de prompts en el sistema propio se limita a 30 días, con enmascaramiento de datos antes del almacenamiento permanente. A esto se suma la supervisión de abusos de Microsoft: empleados autorizados de Microsoft pueden revisar prompts y respuestas marcados; en despliegues en el EEE, estos empleados están en el EEE. Con el «Modified Abuse Monitoring» aprobado, esta revisión humana desaparece. Como toda decisión con consecuencias se escala a una persona y el agente prepara en lugar de decidir, el riesgo residual del art. 22 baja a un nivel aceptable. Resultado: no es necesaria una consulta previa según el art. 36.

Consulta previa según el art. 36

Si tras todas las medidas persiste un riesgo residual alto, debe consultarse a la autoridad de control según el art. 36 antes de iniciar el tratamiento. En el contexto de los agentes de IA es poco frecuente, pero plausible en agentes de selección de personal con efectos significativos sobre los candidatos, en agentes autónomos de triaje sanitario y en agentes de suscripción de seguros. Si la autoridad considera que el tratamiento no es conforme con el RGPD, emite recomendaciones por escrito en un plazo de hasta ocho semanas; en tratamientos complejos puede prorrogar el plazo seis semanas (art. 36, apartado 2, del RGPD). En el derecho suizo rige el art. 23 de la DSG: el EDÖB comunica sus objeciones en un plazo de dos meses, o de tres en tratamientos complejos.

Integración con la FRIA del Reglamento de IA de la UE

El art. 27 del Reglamento de IA de la UE exige una evaluación de impacto relativa a los derechos fundamentales (FRIA) a los responsables del despliegue de sistemas de alto riesgo del anexo III que sean organismos públicos o entidades privadas que prestan servicios públicos, o que operen en ámbitos especificados. Para los sistemas del anexo III, esta obligación no se aplica hasta el 2 de diciembre de 2027: el Ómnibus de IA (Reglamento (UE) 2026/1744) aplazó a esa fecha, desde el 2 de agosto de 2026, las obligaciones de alto riesgo del capítulo III, secciones 1 a 3, a las que pertenece el art. 27. El art. 27, apartado 4, permite expresamente que la FRIA complemente la EIPD del RGPD y reutilice los contenidos que se solapan. Proceso recomendado:

• Realizar primero la EIPD (o en paralelo) siguiendo la metodología del RGPD.
• Ampliarla con elementos específicos de la FRIA: impacto en los derechos fundamentales más allá de la protección de datos (no discriminación, dignidad, libertad de expresión, tutela judicial efectiva), grupos de personas afectados, daños, supervisión, mecanismos de reclamación.
• Elaborar un único documento fusionado con referencias cruzadas al art. 35 del RGPD y al art. 27 del Reglamento de IA.

Nota sobre la interacción: el derecho a explicación de decisiones tomadas individualmente del art. 86 del Reglamento de IA de la UE corresponde a las personas afectadas jurídicamente o de forma similarmente significativa por una decisión basada en un sistema de IA de alto riesgo del anexo III (salvo el punto 2, infraestructuras críticas). Solo se aplica en la medida en que el Derecho de la Unión, por ejemplo el RGPD, no prevea un derecho equivalente (art. 86, apartado 3). El art. 86 no está en el capítulo III; el Ómnibus de IA no ha aplazado su fecha de aplicación, el 2 de agosto de 2026. Sin embargo, el derecho está vinculado a los sistemas de alto riesgo del anexo III, y su clasificación según el art. 6, apartado 2, solo se aplica a partir del 2 de diciembre de 2027 (art. 113 del Reglamento de IA en la versión del Ómnibus de IA). Queda por ver si el art. 86 surte efecto en la práctica antes.

Para agencias y B2B

Las agencias de marketing y los proveedores B2B que despliegan agentes de IA para sus clientes suelen ser encargados del tratamiento. En ese caso, la obligación de EIPD recae en el cliente como responsable, pero la agencia debe aportar una descripción sólida del tratamiento y el mapa de subencargados. Esto se subestima a menudo. Si la agencia y el cliente son corresponsables del tratamiento según el art. 26 del RGPD, la agencia comparte la obligación de EIPD. Quien ya en la fase de oferta aporta una plantilla de EIPD, un diagrama de flujo de datos y un catálogo de medidas revisado acorta notablemente los ciclos de aprobación y reduce la objeción más frecuente en las auditorías: un despliegue de Copilot o de agentes sin EIPD y sin consulta al comité de empresa. Blck Alpaca ayuda a empresas de toda Europa a poner en marcha la EIPD, desde el examen de umbral hasta el documento fusionado EIPD/FRIA.

Nota jurídica: este artículo tiene fines meramente informativos y no constituye asesoramiento jurídico. Para una evaluación vinculante de un tratamiento concreto con agentes de IA, consulta a un asesor jurídico cualificado y a tu autoridad de control competente.