FRIA en el AI Act: cuándo es obligatoria y cómo hacer una evaluación de impacto en derechos fundamentales


Última actualización: 10 de agosto de 2026.

Una empresa decide utilizar inteligencia artificial para evaluar la solvencia de sus clientes.

Un organismo público automatiza parte del proceso para conceder una prestación.

Una entidad privada que presta un servicio público utiliza un sistema de alto riesgo para clasificar solicitudes.

En estas situaciones no basta necesariamente con comprobar que el proveedor afirma cumplir el AI Act.

Antes de desplegar determinados sistemas de inteligencia artificial de alto riesgo, algunas organizaciones deben analizar qué efectos puede producir su uso real sobre las personas y sus derechos fundamentales.

Ese análisis recibe el nombre de:

Fundamental Rights Impact Assessment — FRIA

o, en español:

Evaluación de impacto sobre los derechos fundamentales.

La obligación está regulada principalmente en el artículo 27 del AI Act.

Y existe una primera diferencia que conviene dejar muy clara:

No todas las empresas que utilizan un sistema de IA de alto riesgo están obligadas automáticamente a realizar una FRIA.

La obligación afecta a determinados responsables del despliegue y a determinados sistemas.

FRIA en el AI Act: resumen rápido

Una FRIA sirve para analizar cómo el uso concreto de un sistema de IA de alto riesgo puede afectar a las personas.

El artículo 27 exige realizarla, principalmente, a determinados responsables del despliegue que sean:

  1. Organismos sujetos al Derecho público.
  2. Entidades privadas que prestan servicios públicos.
  3. Usuarios de determinados sistemas de IA de alto riesgo para evaluar solvencia o credit scoring.
  4. Usuarios de determinados sistemas que evalúan riesgo o precios en seguros de vida y salud.

La obligación se refiere a sistemas considerados de alto riesgo conforme al artículo 6.2, es decir, principalmente los usos del Anexo III, con una excepción específica para las infraestructuras críticas incluidas en el punto 2 del Anexo III.

La evaluación debe realizarse antes del primer uso y debe estudiar, entre otros aspectos:

  • El proceso en el que se utilizará la IA.
  • Durante cuánto tiempo.
  • Con qué frecuencia.
  • Qué personas pueden resultar afectadas.
  • Qué riesgos pueden producirse.
  • Cómo funcionará la supervisión humana.
  • Qué medidas se adoptarán si el riesgo se materializa.

Cuando cambien elementos relevantes de la utilización, la evaluación deberá actualizarse.

¿Qué significa FRIA?

FRIA son las siglas de:

Fundamental Rights Impact Assessment.

No analiza únicamente si el sistema funciona técnicamente.

Su finalidad es estudiar cómo puede afectar el uso concreto de esa IA a los derechos de las personas.

El considerando 96 explica que determinados riesgos sobre derechos fundamentales solo pueden comprenderse adecuadamente teniendo en cuenta el contexto real en el que se utiliza el sistema. Por eso el responsable del despliegue debe identificar los riesgos específicos para las personas o grupos afectados y las medidas que aplicará si esos riesgos llegan a materializarse.

Esto diferencia la FRIA de una evaluación técnica del proveedor.

El proveedor puede saber:

  • Cómo funciona el modelo.
  • Qué precisión obtiene.
  • Qué datos utiliza.
  • Qué limitaciones tiene.
  • Qué pruebas ha realizado.

Pero la organización que lo utiliza conoce mejor:

  • Qué decisiones tomará.
  • Sobre qué personas.
  • En qué contexto.
  • Con qué consecuencias.
  • Qué alternativas existen.
  • Cómo se utilizará realmente el resultado.

La FRIA cubre precisamente esa segunda perspectiva.

¿Quién tiene que realizar una FRIA?

El artículo 27 no obliga a todos los responsables del despliegue de sistemas de alto riesgo.

Establece categorías concretas.

1. Organismos sujetos al Derecho público

Puede incluir, dependiendo de la estructura jurídica correspondiente:

  • Administraciones.
  • Ayuntamientos.
  • Organismos públicos.
  • Entidades públicas.
  • Otros organismos sujetos al Derecho público.

Si despliegan determinados sistemas de alto riesgo del artículo 6.2, deberán analizar la aplicación del artículo 27.

Ejemplo

Un ayuntamiento utiliza IA para ayudar a determinar qué personas pueden acceder a una ayuda pública.

Además de las obligaciones generales del sistema de alto riesgo, deberá analizar el impacto que el sistema puede producir sobre los derechos de quienes solicitan la prestación.

2. Entidades privadas que prestan servicios públicos

Esta categoría merece especial atención.

No significa que cualquier empresa privada que presta un servicio a clientes pase automáticamente a estar incluida.

El considerando 96 relaciona esta categoría con actividades vinculadas a tareas de interés público, mencionando ámbitos como:

  • Educación.
  • Sanidad.
  • Servicios sociales.
  • Vivienda.
  • Administración de justicia.

Por tanto, una empresa privada debe analizar si la actividad concreta en la que despliega la IA constituye realmente la prestación de un servicio público en este sentido.

Ejemplo

Una entidad privada gestiona, por encargo de una administración, un servicio social y utiliza un sistema de IA de alto riesgo para priorizar solicitudes.

La FRIA puede resultar obligatoria.

Esto es muy diferente a una tienda privada que utiliza un sistema de recomendación de productos.

3. Sistemas de evaluación de solvencia y credit scoring

El artículo 27 incluye expresamente a los responsables del despliegue de los sistemas de alto riesgo contemplados en el punto 5(b) del Anexo III.

Se trata de sistemas utilizados para evaluar:

  • Solvencia.
  • Capacidad crediticia.
  • Credit score de personas físicas.

El Anexo III contempla una excepción para determinados sistemas utilizados exclusivamente para detectar fraude financiero.

Por tanto, una entidad financiera que utiliza IA para determinar la solvencia individual de una persona puede tener que realizar una FRIA incluso aunque sea una entidad privada que no presta un servicio público en el sentido anterior.

4. Seguros de vida y salud

También se incluyen expresamente los responsables del despliegue de determinados sistemas del punto 5(c) del Anexo III.

Se trata de sistemas utilizados para evaluar:

  • Riesgo.
  • Precio.

respecto de personas en seguros de:

  • Vida.
  • Salud.

Ejemplo

Una aseguradora utiliza IA para calcular la prima individual de un seguro de vida.

Debe analizarse la obligación de realizar FRIA.

¿Quién NO tiene automáticamente que hacer una FRIA?

Este es un punto fundamental.

Una empresa privada puede utilizar un sistema de alto riesgo y no estar incluida automáticamente en el artículo 27.

Por ejemplo:

Una empresa privada utiliza un sistema de IA para:

  • Seleccionar candidatos.
  • Evaluar trabajadores.
  • Asignar determinadas tareas.

Ese sistema puede ser de alto riesgo conforme al Anexo III.

Sin embargo, eso no convierte automáticamente a la empresa en una de las entidades obligadas a realizar FRIA por el artículo 27.

Seguirá teniendo otras obligaciones importantes como responsable del despliegue:

  • Uso conforme a instrucciones.
  • Supervisión humana.
  • Control del funcionamiento.
  • Conservación de logs.
  • Información a trabajadores.
  • Protección de datos.

Pero alto riesgo y obligación de FRIA no son exactamente lo mismo.

Esto evita un error muy habitual:

“Si mi sistema es de alto riesgo, siempre necesito FRIA.”

No necesariamente.

La pregunta correcta es:

¿Es de alto riesgo y además mi organización o el caso de uso están incluidos en el artículo 27?

La excepción de las infraestructuras críticas

El artículo 27 excluye específicamente de su apartado 1 los sistemas de alto riesgo utilizados en el área del punto 2 del Anexo III, correspondiente a determinadas infraestructuras críticas.

Esto no significa que estos sistemas estén libres de obligaciones.

Pueden seguir siendo sistemas de alto riesgo y estar sujetos a:

  • Gestión de riesgos.
  • Supervisión.
  • Logs.
  • Seguridad.
  • Requisitos del proveedor.
  • Obligaciones del responsable del despliegue.

Simplemente existe una excepción respecto a esta FRIA concreta del artículo 27.

¿Cuándo empieza a aplicarse la obligación?

La reforma del AI Act de julio de 2026 modificó el calendario de los sistemas de alto riesgo.

Las obligaciones correspondientes a los sistemas clasificados como alto riesgo conforme al artículo 6.2, es decir, los vinculados principalmente al Anexo III, se aplicarán con carácter general desde:

2 de diciembre de 2027.

La FRIA del artículo 27 está directamente vinculada a esos sistemas del artículo 6.2.

Por tanto, las organizaciones afectadas disponen todavía de tiempo para:

  • Identificar sus sistemas.
  • Clasificarlos.
  • Revisar proveedores.
  • Definir responsables.
  • Crear metodología.
  • Preparar la información necesaria.

Esperar hasta diciembre de 2027 para descubrir qué sistemas utiliza la organización sería una mala estrategia.

¿Cuándo debe hacerse la FRIA?

Debe realizarse antes de desplegar el sistema de alto riesgo correspondiente.

La obligación se refiere al primer uso.

En términos prácticos:

Primero se evalúa el impacto y después se despliega el sistema.

No debería ocurrir:

Implantamos la IA → funciona durante seis meses → hacemos la FRIA.

La evaluación debe servir para decidir si:

  • El sistema puede utilizarse.
  • Necesita cambios.
  • Deben añadirse controles.
  • Debe limitarse la finalidad.
  • Hace falta una alternativa.
  • El riesgo residual resulta aceptable.

¿Hay que repetirla cada año?

El artículo 27 no establece una periodicidad anual general.

La obligación se aplica al primer uso.

Sin embargo, si durante la utilización cambian o dejan de estar actualizados los elementos de la evaluación, el responsable debe actualizarla.

Por ejemplo:

  • Cambia la finalidad.
  • Se incorporan nuevos grupos de personas.
  • Aumenta la autonomía.
  • Cambian los datos.
  • Cambian los criterios.
  • El proveedor sustituye el modelo.
  • Se detectan nuevos daños.
  • Aparecen sesgos.
  • Cambia el proceso.
  • Se modifica la supervisión.

Por eso resulta recomendable asignar una fecha interna de revisión aunque no exista una obligación universal de “FRIA anual”.

¿Puede reutilizarse una FRIA anterior?

Sí.

En casos similares, el artículo 27 permite apoyarse en:

  • Evaluaciones de impacto sobre derechos fundamentales realizadas anteriormente.
  • Evaluaciones existentes realizadas por el proveedor.

Esto puede reducir duplicidades.

Pero reutilizar no significa copiar.

La organización debe comprobar que siguen coincidiendo:

  • Sistema.
  • Finalidad.
  • Personas afectadas.
  • Contexto.
  • Riesgos.
  • Supervisión.
  • Medidas.

Una FRIA realizada para una administración pública no debería reutilizarse automáticamente por otra organización con procesos y población diferentes.

Qué debe contener una FRIA

El artículo 27 establece expresamente el contenido mínimo de la evaluación.

Podemos convertirlo en seis grandes bloques.

1. Descripción del proceso

Debe explicarse en qué procesos de la organización se utilizará el sistema de alto riesgo.

No basta con indicar:

“Sistema para atención al ciudadano.”

Conviene describir:

  • Qué sucede antes.
  • Cuándo interviene la IA.
  • Qué información recibe.
  • Qué resultado genera.
  • Quién lo recibe.
  • Qué decisión se adopta después.

Ejemplo

El sistema analiza las solicitudes de una ayuda pública, extrae determinadas variables y genera una puntuación que utiliza el personal encargado para priorizar la revisión de expedientes.

Esta descripción permite comprender dónde puede aparecer el riesgo.

2. Duración y frecuencia

Debe documentarse:

  • Durante cuánto tiempo se utilizará.
  • Con qué frecuencia.

Por ejemplo:

Sistema operativo permanentemente y utilizado aproximadamente en 15.000 solicitudes anuales.

No presenta el mismo impacto:

  • Una prueba de dos semanas.
  • Un sistema utilizado una vez al año.
  • Una herramienta que evalúa diariamente a miles de personas.

3. Personas y grupos afectados

Debe identificarse qué categorías de personas pueden resultar afectadas por la utilización en ese contexto concreto.

Pueden incluir:

  • Clientes.
  • Trabajadores.
  • Candidatos.
  • Estudiantes.
  • Pacientes.
  • Solicitantes de prestaciones.
  • Personas aseguradas.
  • Personas con discapacidad.
  • Menores.
  • Personas mayores.
  • Personas en situación económica vulnerable.
  • Grupos potencialmente discriminados.

No debería utilizarse únicamente la categoría:

“Usuarios.”

Conviene identificar grupos que puedan sufrir efectos diferentes.

4. Riesgos concretos de daño

La FRIA debe identificar los riesgos específicos que el sistema puede provocar sobre esas personas o grupos, teniendo en cuenta también la información facilitada por el proveedor.

Aquí empieza el análisis verdaderamente importante.

No se trata de elaborar una lista abstracta de derechos.

Debe establecerse una relación:

Característica del sistema → situación → persona → posible daño → derecho afectado.

5. Supervisión humana

La evaluación debe describir las medidas de supervisión humana que se aplicarán conforme al artículo 26.

Debe quedar claro:

  • Quién revisa.
  • Qué revisa.
  • Cuándo interviene.
  • Qué información recibe.
  • Si puede rechazar el resultado.
  • Si puede corregirlo.
  • Si puede detener el sistema.
  • Qué formación tiene.
  • Qué autoridad posee.

Una supervisión puramente simbólica no reduce adecuadamente el riesgo.

6. Medidas cuando el riesgo se materializa

La FRIA debe explicar qué ocurrirá si los riesgos identificados llegan a producirse.

Puede incluir:

  • Suspender el sistema.
  • Cambiar la configuración.
  • Repetir la evaluación.
  • Revisar decisiones.
  • Informar a personas.
  • Corregir datos.
  • Cambiar proveedor.
  • Limitar funcionalidades.
  • Abrir una investigación.
  • Activar un canal de reclamaciones.
  • Aplicar mecanismos internos de gobernanza.

Esto convierte la FRIA en un documento operativo y no simplemente descriptivo.

Qué derechos fundamentales deberían analizarse

El artículo 27 no obliga a rellenar mecánicamente una tabla idéntica de todos los derechos de la Carta en cualquier caso.

La evaluación debe centrarse en los derechos que razonablemente puedan resultar afectados en el contexto concreto. El objetivo del régimen es identificar riesgos específicos para personas y grupos, especialmente cuando existen relaciones de poder asimétricas o decisiones relevantes.

Entre los derechos que pueden resultar relevantes se encuentran, dependiendo del caso:

Derecho o principioPosible riesgo de IA
Dignidad humanaTratar a personas exclusivamente como puntuaciones
IgualdadResultados sistemáticamente desfavorables para un grupo
No discriminaciónSesgos por sexo, edad, origen o discapacidad
Vida privadaInferencias excesivas sobre personas
Protección de datosUso innecesario o desproporcionado de información
Derechos del menorEvaluaciones que afectan a educación o bienestar
Integración de personas con discapacidadSistemas inaccesibles o modelos que penalizan determinados patrones
Derecho al trabajoSelección o evaluación laboral sesgada
Protección socialDenegación incorrecta de prestaciones
Acceso a serviciosExclusión injustificada
Tutela judicialDificultad para cuestionar una decisión
Buena administraciónDecisiones opacas o imposibles de revisar
Libertad de expresiónSistemas que penalizan determinadas manifestaciones
Libertad de reuniónEfectos disuasorios derivados de vigilancia
Protección de consumidoresEvaluaciones o precios injustos

La relevancia concreta depende del uso.

Cómo identificar un riesgo de derechos fundamentales

Una fórmula útil es:

Persona + decisión + error o sesgo + consecuencia.

Por ejemplo:

Candidato + selección laboral + el modelo penaliza interrupciones profesionales + menor probabilidad de entrevista.

Después se pregunta:

  • ¿A qué grupos puede afectar?
  • ¿Con qué frecuencia?
  • ¿Con qué gravedad?
  • ¿Puede detectarse?
  • ¿Puede corregirse?
  • ¿Puede la persona reclamar?

Esto suele producir un análisis mucho mejor que:

“Riesgo: discriminación.”

Ejemplo: IA para conceder una ayuda pública

Supongamos un organismo público que utiliza IA para priorizar solicitudes.

Personas afectadas

  • Solicitantes.
  • Personas de bajos ingresos.
  • Personas mayores.
  • Personas con discapacidad.
  • Familias vulnerables.

Riesgos

El sistema podría:

  • Puntuar incorrectamente.
  • Utilizar datos desactualizados.
  • Penalizar situaciones poco habituales.
  • Reproducir desigualdades.
  • Dificultar la comprensión de la decisión.
  • Aumentar el tiempo de espera de determinados perfiles.

Derechos potencialmente afectados

  • Igualdad.
  • No discriminación.
  • Protección social.
  • Protección de datos.
  • Buena administración.
  • Tutela efectiva.

Medidas

  • No permitir denegaciones automáticas.
  • Revisión humana obligatoria.
  • Muestreo de resultados.
  • Evaluación por grupos.
  • Canal de reclamación.
  • Revisión prioritaria de casos excepcionales.
  • Registro de decisiones.

Esto es una FRIA útil.

No simplemente:

“El sistema cumple con los derechos fundamentales.”

Ejemplo: credit scoring

Una entidad utiliza un sistema de IA para evaluar solvencia.

La FRIA podría analizar:

  • Variables utilizadas.
  • Variables proxy.
  • Calidad de los datos.
  • Grupos afectados.
  • Diferencias entre grupos.
  • Explicabilidad.
  • Errores.
  • Supervisión.
  • Posibilidad de revisión.
  • Consecuencias de una clasificación incorrecta.

Un error puede impedir:

  • Acceder a una vivienda.
  • Financiar un vehículo.
  • Realizar una inversión.
  • Afrontar un gasto importante.

Por eso el impacto no debe analizarse únicamente como un porcentaje de precisión.

Ejemplo: seguro de vida

Un sistema calcula riesgo y precio.

Debe analizarse si:

  • Utiliza datos adecuados.
  • Existen variables indirectamente discriminatorias.
  • Determinados grupos reciben sistemáticamente precios superiores.
  • Las inferencias son explicables.
  • Se utilizan datos especialmente sensibles.
  • Existe revisión.
  • Puede cuestionarse el resultado.

Ejemplo: empresa privada que selecciona personal

Supongamos una empresa privada ordinaria que no presta servicios públicos y utiliza una IA de alto riesgo para seleccionar trabajadores.

El sistema puede estar sometido al régimen de alto riesgo.

Pero la empresa no queda automáticamente incluida entre los sujetos obligados por el artículo 27 únicamente por utilizar IA de selección.

Esto no significa que pueda ignorar los derechos fundamentales.

Puede seguir necesitando:

  • DPIA.
  • Análisis de discriminación.
  • Supervisión humana.
  • Información laboral.
  • Medidas de transparencia.
  • Cumplimiento del artículo 26.
  • Evaluación de proveedor.

Además, puede ser razonable realizar voluntariamente una evaluación similar a una FRIA como medida de gobernanza.

FRIA y DPIA: no son lo mismo

Esta será probablemente una de las búsquedas más importantes alrededor del artículo.

DPIA

La Data Protection Impact Assessment o evaluación de impacto relativa a la protección de datos procede del artículo 35 del RGPD.

Su foco principal está en los riesgos del tratamiento de datos personales para los derechos y libertades de las personas.

FRIA

La FRIA procede del artículo 27 del AI Act.

Su alcance se centra en cómo el uso de determinados sistemas de IA de alto riesgo puede afectar a los derechos fundamentales en su contexto real.

Por tanto:

DPIA y FRIA pueden coincidir, pero no son equivalentes.

Un sistema puede afectar a:

  • No discriminación.
  • Acceso a servicios.
  • Derecho al trabajo.
  • Protección social.

aunque algunas de esas consecuencias vayan más allá del problema estrictamente asociado al tratamiento de datos.

¿Hay que hacer dos documentos completamente separados?

No necesariamente.

El propio artículo 27 contempla la coordinación entre ambas evaluaciones.

Cuando alguna obligación de la FRIA ya haya sido satisfecha mediante una DPIA realizada conforme al RGPD, la evaluación de derechos fundamentales debe complementar esa evaluación de protección de datos.

Esto permite evitar duplicidades.

Una organización podría trabajar con un expediente conjunto:

Evaluación de impacto IA

con:

Parte A

Protección de datos — DPIA.

Parte B

Derechos fundamentales adicionales — FRIA.

Parte C

Controles comunes.

Siempre que pueda demostrarse que se han cubierto todos los requisitos de ambos instrumentos.

FRIA y evaluación de riesgos del proveedor

Tampoco son equivalentes.

Proveedor

Debe analizar los riesgos del sistema durante su diseño y ciclo de vida.

Responsable del despliegue

Mediante la FRIA analiza los riesgos del uso concreto en su organización.

El mismo producto puede producir impactos diferentes.

Por ejemplo:

Una herramienta de puntuación utilizada para:

priorizar revisiones administrativas.

puede tener consecuencias distintas a utilizarla para:

denegar automáticamente una prestación.

El contexto cambia el riesgo.

FRIA y evaluación de conformidad

También son instrumentos diferentes.

La evaluación de conformidad analiza si el sistema de alto riesgo cumple los requisitos regulatorios correspondientes.

La FRIA analiza cómo ese sistema afectará a derechos fundamentales cuando se despliegue en un contexto determinado.

Que un producto tenga marcado CE no elimina automáticamente la obligación de realizar FRIA cuando resulte aplicable.

Paso a paso: cómo preparar una FRIA

Paso 1. Confirmar que el sistema es de alto riesgo

Primero analiza:

  • Artículo 6.
  • Anexo III.
  • Excepciones.
  • Finalidad.

Utiliza la guía de sistemas de IA de alto riesgo antes de iniciar la FRIA.

No tiene sentido comenzar evaluando derechos fundamentales sin haber determinado primero qué sistema se está desplegando.

Paso 2. Confirmar si el artículo 27 te obliga

Comprueba:

Sistema

¿Es alto riesgo conforme al artículo 6.2?

Área

¿No pertenece únicamente a la excepción de infraestructuras críticas del punto 2 del Anexo III?

Organización

¿Es:

  • Organismo de Derecho público?
  • Entidad privada que presta servicios públicos?
  • Usuario de credit scoring?
  • Usuario de IA para riesgo o precio de seguro de vida o salud?

Si la respuesta es negativa, puede no existir obligación legal de FRIA bajo el artículo 27, aunque otras evaluaciones sigan siendo necesarias.

Paso 3. Describir el sistema

Registra:

  • Nombre.
  • Proveedor.
  • Versión.
  • Finalidad.
  • Funciones.
  • Datos.
  • Integraciones.
  • Autonomía.
  • Usuarios.
  • Instrucciones.
  • Clasificación.

La FRIA debe estar vinculada a un sistema claramente identificado.

Paso 4. Dibujar el proceso

Puede utilizarse un esquema:

Solicitud
   ↓
Recogida de datos
   ↓
Sistema de IA
   ↓
Puntuación / recomendación
   ↓
Revisión humana
   ↓
Decisión
   ↓
Información / reclamación

Este simple mapa permite encontrar problemas que no aparecen leyendo únicamente la documentación técnica.

Paso 5. Identificar a las personas

No analices solo “el usuario”.

Distingue:

  • Persona directamente evaluada.
  • Familiares.
  • Trabajadores.
  • Grupos vulnerables.
  • Minorías.
  • Personas con discapacidad.
  • Personas que no dominan el idioma.
  • Personas sin acceso digital.
  • Personas indirectamente afectadas.

Paso 6. Identificar decisiones

Pregúntate:

  • ¿Qué decide la IA?
  • ¿Qué recomienda?
  • ¿Qué prioriza?
  • ¿Qué descarta?
  • ¿Qué puntuación genera?
  • ¿Qué ocurre cuando se equivoca?

Paso 7. Analizar posibles daños

Para cada situación:

Evento

Resultado incorrecto.

Persona

Solicitante.

Consecuencia

Solicitud colocada al final de la cola.

Derecho

Acceso efectivo a una prestación / igualdad.

Gravedad

Alta.

Probabilidad

Media.

Control

Revisión humana y auditoría de resultados.

Paso 8. Analizar grupos

Un sistema puede alcanzar una precisión global elevada y perjudicar mucho a un grupo pequeño.

Por eso deben estudiarse:

  • Diferencias de error.
  • Representatividad.
  • Datos incompletos.
  • Variables proxy.
  • Accesibilidad.
  • Idioma.
  • Exclusión digital.
  • Situaciones atípicas.

Paso 9. Diseñar supervisión humana

Define exactamente:

  • Responsable.
  • Formación.
  • Información disponible.
  • Casos obligatorios de revisión.
  • Autoridad.
  • Escalado.
  • Registro.

Evita:

“Todos los resultados son supervisados.”

Describe cómo.

Paso 10. Definir mitigaciones

Pueden incluir:

  • Eliminar variables.
  • Limitar automatización.
  • Añadir revisión.
  • Cambiar umbrales.
  • Mejorar datos.
  • Crear excepciones.
  • Facilitar reclamaciones.
  • Añadir explicaciones.
  • Hacer pruebas específicas.
  • Limitar el uso.
  • Cambiar de proveedor.

Paso 11. Evaluar el riesgo residual

Después de aplicar controles:

¿Qué riesgo permanece?

Puede ser:

  • Bajo.
  • Medio.
  • Alto.
  • No aceptable.

La clasificación interna no sustituye una categoría jurídica, pero ayuda a decidir.

Paso 12. Adoptar una decisión

Las posibilidades pueden ser:

Aprobar

Los riesgos están controlados.

Aprobar con condiciones

Requiere medidas antes de desplegar.

Piloto limitado

Falta evidencia.

Rediseñar

Hay riesgos evitables.

No desplegar

El impacto residual resulta excesivo.

Paso 13. Preparar reclamaciones y respuesta

La evaluación debe contemplar qué ocurrirá si una persona:

  • Impugna el resultado.
  • Detecta un error.
  • Alega discriminación.
  • Solicita explicación.
  • Pide revisión.
  • Presenta una reclamación.

La capacidad de corregir el daño forma parte esencial de la gestión del riesgo.

Paso 14. Documentar la aprobación

Registra:

  • Fecha.
  • Versión.
  • Responsable.
  • Participantes.
  • Riesgos.
  • Controles.
  • Decisión.
  • Condiciones.
  • Próxima revisión.

Paso 15. Monitorizar

Después del despliegue analiza:

  • Errores.
  • Reclamaciones.
  • Diferencias entre grupos.
  • Anulaciones humanas.
  • Incidentes.
  • Cambios del proveedor.
  • Cambios del sistema.

La FRIA no debe convertirse en un documento que queda archivado después del lanzamiento.

¿Hay que comunicar la FRIA a una autoridad?

Sí.

El artículo 27 establece que, después de realizar la evaluación, el responsable del despliegue debe notificar sus resultados a la autoridad de vigilancia del mercado competente.

Esto es importante porque diferencia la FRIA de muchos documentos internos de gobernanza.

No debería prepararse pensando únicamente:

“Lo guardamos por si algún día nos lo piden.”

Existe una obligación específica de comunicación cuando el artículo 27 resulte aplicable.

¿Existirá una plantilla oficial?

Sí.

El artículo 27 obliga a la Oficina de IA a desarrollar una plantilla de cuestionario, incluso mediante una herramienta automatizada, para facilitar el cumplimiento.

A 10 de agosto de 2026, la Comisión sigue incluyendo las directrices y plantilla de FRIA entre los materiales de implementación pendientes de completar.

Por tanto, una empresa que prepare ahora su metodología puede estructurarla siguiendo el contenido legal, pero deberá comprobar la futura plantilla oficial antes de realizar la comunicación definitiva.

¿Quién debería participar en una FRIA?

El AI Act no exige que cualquier FRIA sea realizada por un despacho externo.

Dentro de una organización pueden participar, según el caso:

  • Responsable del proceso.
  • Protección de datos.
  • Legal.
  • Cumplimiento.
  • Tecnología.
  • Seguridad.
  • Recursos humanos.
  • Responsables sectoriales.
  • Dirección.
  • Personas encargadas de supervisión.

En sistemas de mayor impacto puede resultar útil incorporar conocimientos sobre:

  • No discriminación.
  • Accesibilidad.
  • Derechos de infancia.
  • Derechos laborales.
  • Servicios sociales.
  • Derechos de consumidores.

¿Hay que consultar a las personas afectadas?

El artículo 27 no establece una obligación general idéntica de consulta formal para todos los casos.

Sin embargo, desde una perspectiva práctica, consultar a:

  • Usuarios.
  • Trabajadores.
  • Personas afectadas.
  • Representantes.
  • Expertos.

puede ayudar a descubrir riesgos que un equipo técnico no detectaría.

Debe entenderse como una posible buena práctica, no como una obligación automática del artículo 27 en cualquier caso.

Matriz práctica de una FRIA

Una tabla de trabajo puede utilizar estas columnas:

CampoContenido
IDFRIA-001
SistemaNombre y versión
FinalidadPara qué se utiliza
ProcesoDónde interviene
PersonaGrupo afectado
DecisiónResultado influido
RiesgoQué puede ocurrir
DerechoDerecho afectado
ProbabilidadBaja / media / alta
GravedadBaja / media / alta
Control existenteMedida aplicada
Riesgo residualTras el control
ResponsableQuién controla
EvidenciaDocumento o registro
RevisiónFecha

Ejemplo de riesgo documentado

CampoEjemplo
SistemaScoring de solicitudes
PersonaSolicitantes mayores
RiesgoDatos históricos incompletos
ConsecuenciaPuntuación inferior
DerechoIgualdad y acceso al servicio
ProbabilidadMedia
GravedadAlta
ControlRevisión manual de puntuaciones bajas
EvidenciaRegistro de revisiones
ResidualMedio
AcciónAuditoría trimestral

Esto convierte conceptos jurídicos abstractos en un control operativo.

Señales de alerta durante una FRIA

Presta especial atención cuando:

  • Nadie sabe explicar cómo se utiliza la puntuación.
  • La revisión humana casi nunca cambia el resultado.
  • No existen datos sobre errores por grupos.
  • Las personas no saben que se utiliza IA.
  • No existe canal de reclamación.
  • El proveedor no facilita documentación.
  • No pueden exportarse logs.
  • El sistema cambia frecuentemente.
  • Se utilizan variables indirectas difíciles de justificar.
  • Las personas vulnerables dependen del resultado.
  • No existe alternativa manual.
  • Un error produce consecuencias difíciles de revertir.
  • El responsable no puede detener el sistema.

Errores frecuentes

Hacer FRIA porque “usa IA”

No.

Primero debe analizarse la clasificación y el sujeto obligado.

Pensar que toda IA de alto riesgo exige FRIA

Tampoco.

El artículo 27 delimita quién debe realizarla.

Copiar la evaluación del proveedor

El proveedor no conoce completamente tu contexto de uso.

Confundir FRIA y DPIA

Pueden complementarse, pero tienen focos diferentes.

Evaluar únicamente privacidad

Los derechos fundamentales abarcan mucho más.

Enumerar todos los derechos sin analizarlos

Una lista no identifica impactos.

No identificar grupos específicos

Un promedio puede ocultar discriminación.

Considerar supervisión humana cualquier aprobación

La persona debe tener capacidad real de intervención.

Analizar únicamente errores técnicos

Un resultado técnicamente correcto también puede generar un impacto desproporcionado.

No estudiar las consecuencias

Una desviación del 5 % puede ser irrelevante en un recomendador musical y gravísima al conceder una prestación.

No prever reclamaciones

La persona afectada debe poder cuestionar errores relevantes.

Archivar la FRIA y olvidarla

Debe actualizarse cuando cambien elementos relevantes.

Checklist FRIA

Antes de aprobarla, comprueba:

  • El sistema está identificado.
  • La versión está registrada.
  • Se ha confirmado que es alto riesgo.
  • Se ha confirmado la obligación del artículo 27.
  • Se ha documentado la finalidad.
  • Se ha descrito el proceso completo.
  • Se ha indicado duración y frecuencia.
  • Se han identificado personas.
  • Se han identificado grupos vulnerables.
  • Se han analizado posibles daños.
  • Se han relacionado daños con derechos.
  • Se ha evaluado gravedad.
  • Se ha evaluado probabilidad.
  • Se ha descrito supervisión humana.
  • Se han definido controles.
  • Se ha evaluado riesgo residual.
  • Existe un canal de reclamaciones.
  • Existe procedimiento de incidentes.
  • Se ha revisado la DPIA.
  • Se han evitado duplicidades con otras evaluaciones.
  • Existe responsable.
  • Se ha documentado la decisión.
  • Existe fecha de revisión.
  • Se ha preparado la notificación correspondiente.

Preguntas frecuentes

¿Qué significa FRIA?

Fundamental Rights Impact Assessment, o evaluación de impacto sobre los derechos fundamentales.

¿Dónde está regulada?

Principalmente en el artículo 27 del AI Act.

¿Toda empresa tiene que realizarla?

No.

¿Todo sistema de alto riesgo necesita FRIA?

No automáticamente. Debe analizarse también quién despliega el sistema y el tipo concreto de uso.

¿Una empresa que utiliza IA en Recursos Humanos debe hacer FRIA?

No necesariamente por el artículo 27 si se trata de una empresa privada ordinaria que no entra en las categorías allí enumeradas. Sí puede tener muchas otras obligaciones por tratarse de un sistema de alto riesgo.

¿Una administración pública debe hacerla?

Puede estar obligada cuando despliega sistemas de alto riesgo del artículo 6.2 incluidos en el ámbito del artículo 27.

¿Un banco necesita FRIA?

Cuando despliega un sistema de alto riesgo para evaluar solvencia o credit scoring de personas, el artículo 27 puede resultar directamente aplicable.

¿Una aseguradora necesita FRIA?

Puede necesitarla cuando utiliza sistemas de alto riesgo para evaluar riesgo o fijar precios de seguros de vida o salud.

¿Una infraestructura crítica necesita FRIA?

El apartado 1 del artículo 27 excluye específicamente los sistemas del punto 2 del Anexo III de esta obligación de FRIA.

¿FRIA y DPIA son lo mismo?

No. La DPIA se centra en riesgos relacionados con protección de datos; la FRIA tiene un alcance más amplio sobre derechos fundamentales.

¿Pueden hacerse juntas?

Sí puede integrarse trabajo común. Cuando determinados requisitos ya estén cubiertos por una DPIA, la FRIA debe complementarla.

¿Hay que hacerla antes o después de instalar la IA?

Antes del despliegue correspondiente.

¿Debe repetirse?

Debe actualizarse cuando cambien o dejen de estar actualizados elementos relevantes de la evaluación.

¿Puede utilizarse una evaluación anterior?

Sí, en casos similares pueden aprovecharse evaluaciones anteriores o evaluaciones existentes del proveedor, siempre que realmente sean aplicables.

¿Hay que enviarla a una autoridad?

El artículo 27 contempla la notificación de los resultados a la autoridad de vigilancia del mercado competente.

¿Existe ya una plantilla europea definitiva?

El AI Act exige que la Oficina de IA prepare una plantilla y herramienta para facilitar la FRIA. A 10 de agosto de 2026, la Comisión continúa incluyendo estas directrices y plantilla entre sus trabajos de implementación pendientes.

¿Desde cuándo se aplica?

El régimen general correspondiente a los sistemas de alto riesgo del artículo 6.2 se aplica desde el 2 de diciembre de 2027 tras la reforma de julio de 2026.

Comprueba si necesitas una FRIA

La herramienta incluida a continuación permite realizar una primera comprobación de:

  • Clasificación del sistema.
  • Tipo de organización.
  • Caso de uso.
  • Posible obligación del artículo 27.
  • Relación con DPIA.
  • Elementos que deberían prepararse.

El resultado puede indicar:

  • FRIA probablemente obligatoria.
  • Revisar si la entidad presta un servicio público.
  • No se detecta obligación automática de FRIA.
  • Primero debe confirmarse que el sistema es de alto riesgo.
Evaluador gratuito

¿Tu organización debe realizar una FRIA?

Comprueba de forma orientativa si el artículo 27 del AI Act puede resultar aplicable al uso previsto.

🔒 No introduzcas nombres, documentos ni datos personales. Las respuestas se procesan únicamente en tu navegador.

1. Clasificación del sistema

¿El sistema ha sido clasificado como alto riesgo conforme al artículo 6.2 y el Anexo III?

2. Tipo de organización

Si es una entidad privada que presta un servicio público, ¿la IA se utiliza precisamente dentro de ese servicio?

3. Evaluaciones existentes

¿La organización ya ha realizado una DPIA de protección de datos?

¿Existe una FRIA anterior o evaluación equivalente para un caso realmente similar?

¿Han cambiado finalidad, personas afectadas, datos o forma de tomar decisiones?

Tu siguiente paso

1. Confirma la clasificación

Consulta la guía sobre sistemas de IA de alto riesgo.

2. Registra el sistema

Inclúyelo en el inventario de sistemas de IA.

3. Evalúa al proveedor

Comprueba documentación, logs, supervisión, datos y riesgos.

4. Coordina FRIA y DPIA

Evita realizar dos análisis completamente desconectados.

5. Forma al personal

Las personas encargadas del sistema y de su supervisión deben conocer riesgos y controles.

6. Mantén evidencias

La evaluación debe poder explicar:

qué riesgo detectaste, qué hiciste para reducirlo y quién tomó la decisión final.

Conclusión

La FRIA no es un formulario pensado para demostrar que una inteligencia artificial “es ética”.

Es un proceso para obligar a una organización a responder preguntas mucho más concretas:

¿Quién puede resultar perjudicado?

¿Cómo podría producirse ese daño?

¿Qué derecho puede verse afectado?

¿Qué papel tiene la IA en la decisión?

¿Puede una persona detectar y corregir un error?

¿Qué ocurrirá si el riesgo se materializa?

Esa es la diferencia entre evaluar una tecnología en abstracto y evaluar su impacto real sobre personas concretas.

Y precisamente por eso la FRIA se sitúa en el responsable del despliegue: porque conocer el modelo no basta.

Hay que conocer también qué ocurre cuando ese modelo entra en una organización y empieza a influir en decisiones que afectan a personas.


Aviso: Este contenido tiene una finalidad exclusivamente informativa y divulgativa. La obligación de realizar una FRIA depende de la clasificación del sistema, el papel y naturaleza de la organización, el caso de uso y las circunstancias concretas. No constituye asesoramiento jurídico ni una evaluación de impacto definitiva.

Si te parece útil, compártelo: