Si está implementando un agente de IA en un proceso regulado (clasificación de delitos financieros, evaluación de pagos, incorporación de préstamos, adjudicación de reclamaciones), es casi seguro que debe una Evaluación de impacto de la protección de datos según el [Artículo 35 del RGPD] (https://eur-lex.europa.eu/eli/reg/2016/679/oj). Y si ese mismo sistema es de alto riesgo según la Ley de IA de la UE, también debe una Evaluación de impacto en los derechos fundamentales según el Artículo 27. Las dos evaluaciones se superponen en gran medida, la regulación espera que usted reutilice la superposición y, sin embargo, la mayoría de los equipos las ejecutan como dos ejercicios de papeleo desconectados que se separan en el momento en que cambia el modelo. Esta guía hace lo contrario: le brinda una estructura de EIPD que se adapta claramente a su FRIA (y a su evaluación de intereses legítimos) para que pueda producir un paquete de evidencia combinado en lugar de tres documentos que se contradicen entre sí en la auditoría. Puedes generar ese pack combinado con el generador DPIA + FRIA. La tesis del KLA en todo momento: una evaluación de impacto sólo vale la pena si los controles que promete realmente se ejecutan en el momento en que actúa el agente: gobiernan por ejecución, no por PDF.
¿Cuándo es obligatoria una EIPD para un sistema de IA?
Una EIPD no es una burocracia opcional. El artículo 35(1) establece una obligación legal antes de que comience el procesamiento, siempre que el procesamiento ("en particular utilizando nuevas tecnologías"*) pueda resultar en un alto riesgo para los derechos y libertades de las personas físicas. Los agentes de IA que actúan sobre datos personales en un flujo de trabajo regulado se acercan al caso paradigmático que tenían en mente los redactores.
El artículo 35(3) enumera tres factores desencadenantes legales, cualquiera de los cuales hace que una EIPD sea obligatoria. La orientación del Grupo de Trabajo del Artículo 29 (WP248) (respaldada por el CEPD) añade nueve criterios y una regla general: si su procesamiento cumple dos o más de ellos, trate una EIPD según sea necesario. Las autoridades nacionales de supervisión también publican sus propias "listas negras" de procesamiento que siempre necesitan una. La siguiente tabla muestra los criterios por los que viajan con mayor frecuencia los agentes de IA en servicios financieros y seguros.
La conclusión práctica para un implementador de IA regulado: no pase una semana debatiendo si está técnicamente obligado. Si su agente perfila a las personas, las califica o alimenta una decisión que afecta el acceso al crédito, los pagos o el pago de un seguro, es casi seguro que usted está dentro del alcance: documente la evaluación y pase al fondo.
| Desencadenar | Fuente | Escenario típico de un agente de IA que lo golpea |
|---|---|---|
| Evaluación o elaboración de perfiles sistemática y exhaustiva, basada en un tratamiento automatizado, en la que se basan las decisiones | Arte. 35(3)(a) | Agente de monitoreo de transacciones que califica a los clientes por riesgo de delitos financieros; puntuación de fraude conductual |
| Decisiones que producen efectos legales o igualmente significativos en la persona | Arte. 35(3)(a) / art. 22 | Toma de decisiones automatizada sobre incorporación de préstamos; aceptación o denegación automatizada de reclamaciones |
| Procesamiento a gran escala de datos de categorías especiales o delitos penales | Arte. 35(3)(b) | Detección ALD contra sanciones/adverse-media que infieren origen étnico, exposición política o antecedentes penales |
| Monitoreo sistemático de un área de acceso público a gran escala | Arte. 35(3)(c) | Menos común para los agentes administrativos; relevante para la incorporación de identidad/biometric |
| Coincidencia o combinación de conjuntos de datos | WP248 | Enriquecer el registro de un solicitante uniendo datos de KYC, dispositivos y oficinas de terceros |
| Datos relativos a interesados vulnerables | WP248 | Los precios del crédito minorista o de los seguros afectan a los consumidores con poder de negociación limitado |
| Uso innovador de nuevas soluciones tecnológicas | WP248 | Implementación de un sistema de decisión agente o basado en LLM: una señal casi automática |
Qué debe contener realmente una EIPD: artículo 35, apartado 7
El artículo 35(7) es breve y prescriptivo. Una EIPD que cumpla con las normas contiene al menos cuatro elementos, y un regulador buscará cada uno de ellos de manera explícita, sin ocultarlos en la narrativa.
Junto al contenido coexisten dos deberes procesales. Según el Artículo 35(2), el responsable del tratamiento debe buscar el asesoramiento del Delegado de Protección de Datos, y según el Artículo 35(9) debe, cuando corresponda, buscar las opiniones de los interesados o sus representantes. Para un sistema de agencia, la aprobación del DPO y el registro de quién fue consultado son parte de la evidencia, no una ocurrencia tardía. Y según el Artículo 36, si el riesgo residual sigue siendo alto después de la mitigación, debe consultar a la autoridad supervisora antes de entrar en funcionamiento.
Los cuatro elementos de contenido obligatorios son:
- (a) Una descripción sistemática de las operaciones de tratamiento previstas y los fines del tratamiento, incluido, cuando proceda, el interés legítimo perseguido por el responsable del tratamiento.
- (b) Una evaluación de la necesidad y proporcionalidad de las operaciones de procesamiento en relación con los fines: la parte que la mayoría de las EIPD omiten y la parte que tiene más probabilidades de fallar en la auditoría.
- (c) Una evaluación de los riesgos para los derechos y libertades de los interesados.
- (d) Las medidas previstas para abordar los riesgos, incluidas salvaguardas, medidas de seguridad y mecanismos para garantizar la protección de los datos personales y demostrar su cumplimiento.
La superposición: donde la EIPD y la FRIA son el mismo documento
La Ley de IA de la UE no exige empezar de cero. El artículo 27(4) es explícito: cuando las obligaciones de la FRIA ya se cumplen mediante una EIPD realizada de conformidad con el artículo 35 del RGPD, la FRIA "complementará" esa evaluación de impacto de la protección de datos. En otras palabras, el legislador espera la reutilización y penaliza la duplicación que se desvíe.
Las dos valoraciones no son idénticas. Una EIPD es una obligación del responsable de los datos personales; una FRIA es un deber del implementador sobre todos los derechos fundamentales en la Carta de la UE: incluidos los derechos que no tienen nada que ver con la protección de datos, como la no discriminación, la dignidad humana y el acceso a un recurso efectivo. La FRIA es más amplia y debe evaluarse derecho por derecho (no se puede compensar un daño por discriminación con una ganancia de eficiencia). Pero la columna vertebral estructural (describir el sistema, justificarlo, identificar los riesgos, establecer las mitigaciones) se comparte casi elemento por elemento.
La siguiente tabla asigna cada elemento del Artículo 35(7) de la DPIA a su contraparte del Artículo 27(1) de la FRIA. Cuando una celda dice Sólo FRIA, ese es el contenido que la EIPD no captura y usted debe agregarlo. Trate las filas compartidas como de una sola escritura: créelas en el paquete combinado y haga referencia a ellas desde ambas evaluaciones en lugar de copiarlas.
| Elemento EIPD: RGPD art. 35(7) | Elemento FRIA: Ley AI, art. 27(1) | Estado de reutilización |
|---|---|---|
| (a) Descripción sistemática del tratamiento y finalidades | (a) Descripción de los procesos del implementador en los que se utilizará el sistema de alto riesgo; (b) período y frecuencia de uso previsto | Compartido: una descripción de system/process sirve para ambos |
| Categorías de interesados y datos personales (dentro de la (a) descripción) | (c) Categorías de personas físicas y grupos que probablemente se verán afectados | Compartido: ampliar la lista de interesados a los colectivos afectados por FRIA |
| (b) Evaluación de necesidad y proporcionalidad | Implícito en el art. 27 contexto de uso; reforzado por la proporcionalidad de la Carta | Compartido: el razonamiento de need/proportionality se transmite |
| (c) Riesgos para los derechos y libertades de los interesados | (d) Riesgos específicos de daños que probablemente afecten a las personas y grupos afectados | Compartido pero ampliado: FRIA cubre todos los derechos de la Carta, no solo la protección de datos |
| (d) Medidas, salvaguardias y seguridad para hacer frente a los riesgos | (f) Medidas de gobernanza, incluida la supervisión humana, y (g) acuerdos de queja/redress. | Compartido pero ampliado: FRIA exige explícitamente medidas de reparación y supervisión humana |
| asesoramiento del RPD (art. 35(2)); opiniones de los interesados (Art. 35(9)) | (e) Medidas de supervisión humana según las instrucciones de uso. | Parcialmente compartido: mantener el registro de consulta una vez, satisfacer ambos |
| , (no requerido por GDPR) | Notificación de la FRIA a la autoridad de vigilancia del mercado (Art. 27(3)) | Solo FRIA: agregue este paso; sin equivalente DPIA |
Integración en la evaluación de intereses legítimos (LIA)
Si su base legal para el procesamiento son intereses legítimos según el Artículo 6(1)(f) (común para la detección de fraude y AML, que los considerandos del RGPD reconocen expresamente como intereses legítimos), también debe una Evaluación de intereses legítimos. La buena noticia: la LIA no es un tercer silo. Su prueba de tres partes se inserta directamente en la EIPD que ya está escribiendo.
La prueba de finalidad (¿existe un interés legítimo?) y la prueba de necesidad (¿es necesario el procesamiento para ello?) de la LIA son el mismo análisis que exige el artículo 35(7)(b). La prueba de equilibrio de la LIA (¿el interés prevalece sobre los derechos del interesado, dadas sus expectativas razonables?) es una versión más precisa de la evaluación de riesgos del Artículo 35(7)(c). Cree el interés legítimo una vez en la descripción sistemática de su EIPD (el artículo 35(7)(a) lo invita explícitamente: "incluido, cuando corresponda, el interés legítimo perseguido"), y haga referencia a él desde la salida del generador de LIA.
Una advertencia específica para los agentes de IA: un agente impulsado por un LLM puede expandir silenciosamente el propósito del procesamiento a medida que agrega herramientas y contexto. Un interés legítimo evaluado para "seleccionar transacciones contra listas de sanciones" no cubre automáticamente "perfilar el estilo de vida del cliente a partir de narrativas de transacciones". La prueba de equilibrio debe volver a ejecutarse cuando el propósito efectivo del agente cambia, que es exactamente la razón por la que la evaluación no puede vivir sólo en un documento estático.
Un paquete de evidencia combinado y por qué tiene que estar disponible
Al ejecutar la DPIA, la FRIA y la LIA como tres archivos de Word separados, los equipos terminan defendiendo contradicciones en una auditoría: la DPIA promete una revisión humana, la FRIA describe un modelo de supervisión diferente y la LIA equilibra un propósito que ninguno de los otros menciona. La solución es un paquete de evidencia combinado único con secciones compartidas de escritura única y tres superposiciones específicas de la evaluación. Constrúyalo con el generador DPIA + FRIA, que produce los elementos del artículo 35(7) y del artículo 27(1) como un documento mapeado.
Pero el problema más difícil no es la autoría: es la deriva. Una evaluación de impacto describe el sistema tal como estaba el día en que se escribió. En el momento en que alguien agrega una herramienta al agente, cambia el modelo o amplía su acceso a los datos, la evaluación queda obsoleta y una EIPD obsoleta no cumple. Esta es la posición central del ELK: gobernar mediante la ejecución, no el papeleo. Las mitigaciones que promete su EIPD (revisión humana de decisiones de alto impacto, bloqueos de datos fuera de alcance, intensificación cuando la confianza es baja) no deberían ser oraciones en un PDF; deben ser controles que se ejecuten cuando actúa el agente.
En el plano de control del KLA ese mapeo es concreto. Las medidas a las que se compromete en el Artículo 35(7)(d) y el Artículo 27(1)(f) de la FRIA se convierten en puertas de Constructor de Políticas con decisiones explícitas (permitir, advertir, requerir_aprobación o bloquear. Los acuerdos de supervisión humana y compensación (Art. 27(1)(e)–(g) de la FRIA) se convierten en una Mesa de Decisiones de dos personas, con aprobación de fabricante y verificador de las decisiones que tienen consecuencias legales o significativas. Y cada acción cerrada) lo que hizo el agente, qué política disparó, quién aprobó: aterriza en la Sala de Evidencias como un registro de ejecución sellado y a prueba de manipulaciones. Ésa es la diferencia entre una evaluación que reivindica una salvaguardia y un paquete de evidencia que puede probar que la salvaguardia se ejecutó en una transacción específica en un momento específico.
La laguna en la plantilla del artículo 27(5) y cómo actuar ahora
El artículo 27(5) instruye a la Oficina de AI a desarrollar un modelo de cuestionario (que incluya una herramienta automatizada) para ayudar a los implementadores a llevar a cabo la FRIA de manera simplificada. A junio de 2026, esa plantilla no se ha publicado. Los implementadores que preguntan "¿deberíamos esperar el formato oficial?" están haciendo la pregunta equivocada: la obligación no espera a la plantilla, y los elementos de contenido subyacentes en el Artículo 27(1) ya están fijados en el Reglamento.
Hay un segundo momento. El ómnibus digital sobre IA de la UE, adoptado el 29 de junio de 2026, trasladó las obligaciones independientes de alto riesgo del Anexo III, incluido el artículo 27 de la FRIA, del 2 de agosto de 2026 al 2 de diciembre de 2027. Trate el aplazamiento como una conveniencia de planificación y siga elaborando la evaluación. (Consulte la [guía de plantilla FRIA] (/blog/fria-template-eu-ai-act) para ver la imagen completa de la fecha límite).
El camino pragmático, entonces, es construir sobre la estructura que es estable hoy: el esqueleto del Artículo 35(7) del RGPD, asignado a los elementos del Artículo 27(1) como se muestra en la tabla anterior. Cuando llega la plantilla de AI Office, la reexportas a su formato, pero tu sustancia, tu análisis de riesgos y tu evidencia ya están hechos y en ejecución.
Preguntas frecuentes
¿Siempre se requiere una EIPD para un sistema de IA?
No siempre literalmente, pero sí muy a menudo. Una EIPD es obligatoria según el artículo 35(1) del RGPD siempre que el procesamiento pueda resultar en un alto riesgo para los derechos y libertades de las personas, especialmente el uso de nuevas tecnologías. El artículo 35(3) enumera tres activadores automáticos (elaboración de perfiles sistemáticos que alimentan las decisiones, datos de categorías especiales a gran escala y monitoreo público a gran escala) y la guía WP248 trata dos o más de sus nueve criterios como un umbral. La mayoría de los agentes de IA regulados que perfilan, califican o impulsan una decisión importante activan al menos un desencadenante, por lo que lo más seguro es asumir que se requiere una EIPD y documentar su evaluación.
¿Cuál es la diferencia entre una EIPD y una FRIA?
Una DPIA (artículo 35 del RGPD) es una obligación del responsable centrada en los riesgos para los datos personales y la privacidad. Una FRIA (Artículo 27 de la Ley de IA de la UE) es una obligación del ejecutor centrada en todos los derechos fundamentales de la Carta de la UE (incluida la no discriminación, la dignidad humana y el acceso a recursos) y se aplica incluso cuando hay pocos o ningún dato personal involucrado. Comparten una columna vertebral estructural (describir, justificar, evaluar riesgos, mitigar), razón por la cual el Artículo 27(4) dice que una FRIA debe complementar una EIPD existente en lugar de duplicarla.
¿Puede un documento satisfacer tanto la DPIA como la FRIA?
Puede satisfacer ambas cosas con un paquete de evidencia combinado que contiene secciones compartidas de escritura única más superposiciones específicas de la evaluación, y el Artículo 27(4) fomenta activamente la reutilización. Pero no son intercambiables: la FRIA es más amplia (todos los derechos de la Carta, evaluados derecho por derecho) y agrega pasos de los que carece la DPIA, como notificar a la autoridad de vigilancia del mercado conforme al Artículo 27(3). Así que mapéelos juntos, pero mantenga ambas evaluaciones claramente abordables.
¿Cuáles son los cuatro elementos requeridos de una EIPD según el artículo 35(7)?
(a) una descripción sistemática del procesamiento y sus fines, incluido cualquier interés legítimo perseguido; (b) una evaluación de la necesidad y proporcionalidad del procesamiento en relación con esos fines; c) una evaluación de los riesgos para los derechos y libertades de los interesados; y d) las medidas previstas para hacer frente a esos riesgos, incluidas las salvaguardias y la seguridad. Además de esto, el artículo 35(2) exige el asesoramiento del RPD y el artículo 35(9) requiere solicitar opiniones de los interesados cuando corresponda.
¿La Oficina de AI ya ha publicado el modelo FRIA del Artículo 27?
No. A junio de 2026, la Oficina de AI no ha publicado el modelo de cuestionario ni la herramienta automatizada prevista en el artículo 27, apartado 5. La obligación en sí no depende de esa plantilla (los elementos de contenido están fijados en el Artículo 27(1)), por lo que el enfoque práctico es construir sobre la estructura estable del Artículo 35(7) del RGPD ahora y reexportarla al formato oficial cuando se lance.
¿Cómo encaja una evaluación de intereses legítimos en la EIPD?
Si su base legal son los intereses legítimos según el Artículo 6(1)(f) (común para fraude y AML), la prueba de tres partes de la LIA (propósito, necesidad, equilibrio) se relaciona directamente con la EIPD. Las pruebas de finalidad y necesidad son el análisis de necesidad y proporcionalidad del artículo 35(7)(b), y la prueba de equilibrio agudiza la evaluación de riesgos del artículo 35(7)(c). Escriba el interés legítimo una vez en la descripción sistemática de la EIPD, que el artículo 35(7)(a) invita explícitamente, y haga referencia a él desde su LIA.
Conclusiones clave
Una DPIA, una FRIA y una LIA no son tres tareas en competencia: son tres visiones de la misma pregunta: ¿es este sistema de IA necesario, proporcionado y gobernado adecuadamente antes de que actúe sobre una persona real? El artículo 35(7) del RGPD le brinda el andamio más estable y probado por reguladores disponible en la actualidad, y el artículo 27(4) casi le ordena que construya su FRIA encima de él en lugar de al lado de él. Mapee los elementos una vez, agregue el análisis de intereses legítimos y tendrá un único paquete de evidencia combinado en lugar de tres documentos que se separan. El paso final es el que el papeleo nunca puede cumplir por sí solo: las mitigaciones que usted se compromete a ejecutar (como puertas, como aprobaciones de dos personas, como registros de ejecución sellados) en el momento en que actúa el agente. Inicie la evaluación combinada con el generador DPIA + FRIA y cree los controles para que la evidencia se demuestre.