Artículo 27 del AI Act: guía operativa para la evaluación de impacto en derechos fundamentales

Introducción: la obligación crítica del usuario de IA de alto riesgo

El artículo 27 del Reglamento (UE) 2024/1689, conocido como AI Act, establece una obligación específica para los responsables del despliegue (deployers) de sistemas de inteligencia artificial de alto riesgo. A diferencia de las obligaciones del proveedor, que se centran en el diseño y la gestión técnica de riesgos, esta norma recae directamente sobre la entidad que utiliza el sistema en su operativa diaria.

La evaluación de impacto en derechos fundamentales (FRIA) no es una mera formalidad administrativa, sino un mecanismo de aseguramiento preventivo. Su objetivo es identificar, antes del primer uso, cómo el sistema puede afectar a los derechos de las personas físicas y colectivos, y definir las medidas de mitigación y supervisión necesarias para prevenir perjuicios.

La clave práctica de esta obligación está en quién toma las decisiones de uso. La evaluación no se agota en comprobar que el sistema fue diseñado conforme a requisitos técnicos: debe examinar cómo se incorpora a los procesos de la entidad y qué consecuencias puede tener para las personas en ese contexto concreto. Por eso, una misma solución puede requerir análisis distintos cuando cambia la finalidad, la forma de utilización o la población afectada. La responsabilidad del despliegue permanece en quien utiliza el sistema, aunque necesite información del proveedor para cumplirla.

Entender la FRIA como una medida preventiva también ayuda a distinguir su propósito de una respuesta posterior a un daño. El análisis debe realizarse antes de empezar a utilizar el sistema para reconocer posibles perjuicios y considerar de antemano cómo supervisar su funcionamiento y qué medidas adoptar si los riesgos se materializan. No elimina la necesidad de atender a lo que ocurra durante el uso: la evaluación debe poder revisarse cuando cambien sus elementos o la información deje de reflejar la situación efectiva.

Marco legal y alcance de aplicación

La obligación de realizar la FRIA se activa antes de desplegar un sistema de IA de alto riesgo contemplado en el artículo 6, apartado 2, con una excepción importante: no aplica a los sistemas destinados a infraestructuras críticas (Anexo III, punto 2).

Los sujetos obligados son: 1) Los organismos de Derecho público; 2) Las entidades privadas que prestan servicios públicos; y 3) Los responsables del despliegue de sistemas de IA de alto riesgo en el ámbito de la puntuación crediticia y seguros de vida y salud (Anexo III, punto 5, letras b y c). Para el resto de sistemas de alto riesgo del Anexo III, la obligación es de aplicación general para estos perfiles de usuario.

La lectura del ámbito de aplicación exige separar dos preguntas: qué tipo de sistema se va a desplegar y quién lo desplegará. La referencia al artículo 6, apartado 2, y al Anexo III delimita los sistemas pertinentes; el artículo 27 identifica después los perfiles de responsables del despliegue sujetos a la obligación. No basta, por tanto, con que una entidad utilice IA, ni con que el sistema sea calificado genéricamente como de alto riesgo: hay que comprobar la categoría aplicable y la condición del usuario en cada caso.

La excepción relativa a las infraestructuras críticas debe mantenerse dentro de ese análisis de alcance y no confundirse con una dispensa general para cualquier responsable del despliegue. Del mismo modo, las obligaciones específicas vinculadas a la puntuación crediticia y a los seguros de vida y salud se refieren a las categorías indicadas en el Anexo III. Si una organización utiliza más de un sistema o lo hace en contextos distintos, conviene analizar cada despliegue por separado y dejar constancia de la razón por la que queda incluido o fuera del ámbito descrito.

La condición de entidad privada que presta servicios públicos no se resuelve únicamente por la forma jurídica de la organización: lo relevante, a efectos de esta descripción, es que concurran el perfil señalado y el uso de un sistema cubierto. La identificación temprana de esos elementos permite asignar internamente la preparación de la evaluación y evita confundir las obligaciones del responsable del despliegue con las que corresponden al proveedor. La determinación debe ceñirse al sistema y al uso previstos, sin extender las categorías más allá de lo que establece el artículo 27.

Contenido mínimo de la evaluación de impacto

El artículo 27, apartado 1, detalla seis elementos obligatorios que deben incluirse en la evaluación. No se trata de una lista exhaustiva de buenas prácticas, sino del contenido legal mínimo que la autoridad de vigilancia del mercado puede exigir.

La evaluación debe ser específica al contexto de uso. No basta con una declaración genérica; debe describir los procesos concretos, la frecuencia de uso y las categorías de personas afectadas en ese entorno particular.

Los seis elementos del artículo 27.1 deben leerse como partes conectadas de una evaluación, no como casillas aisladas. La descripción de los procesos y del período de uso proporciona el marco para identificar a las personas afectadas; a partir de ese marco se analizan los riesgos de perjuicio específicos y se explican las medidas de supervisión humana y de respuesta. Si falta la relación entre esos elementos, el documento puede enumerar información sin mostrar cómo se ha valorado el impacto en el despliegue previsto.

En la práctica, describir los procesos supone aclarar en qué punto de la operativa se empleará el sistema y cuál es su finalidad prevista dentro de ella. El período y la frecuencia ayudan a precisar la exposición: no equivalen a una previsión abstracta, sino a una explicación del uso que la entidad anticipa. La identificación de personas físicas y colectivos, por su parte, debe responder a ese proceso concreto; no es suficiente utilizar categorías tan amplias que impidan comprender quién podría verse afectado.

El análisis de perjuicios debe apoyarse en la información del proveedor contemplada en el artículo 13, pero traducirla a las condiciones del uso propio. La documentación recibida no sustituye el juicio del responsable del despliegue: sirve de base para considerar qué riesgos pueden presentarse para las categorías identificadas en los procesos descritos. La evaluación debe hacer visible esa conexión y conservar las cautelas cuando la información disponible no permita determinar con precisión la posibilidad o el alcance de un perjuicio.

La supervisión humana y las medidas previstas ante la materialización de riesgos cumplen funciones relacionadas, pero distintas. La primera describe cómo se aplicará la supervisión conforme a las instrucciones de uso; la segunda establece qué hará la entidad si los riesgos se producen, incluida la gobernanza interna y los mecanismos de reclamación. Explicitar responsables, procedimientos y vías de actuación permite que la evaluación no se limite a señalar riesgos, sino que registre cómo se prevé gestionarlos en el contexto analizado.

Diferencias con la gestión de riesgos del proveedor

Es fundamental no confundir la FRIA del usuario con el sistema de gestión de riesgos del proveedor (artículo 9). El proveedor debe implementar un sistema continuo de identificación, análisis y mitigación de riesgos técnicos durante todo el ciclo de vida del sistema.

La FRIA, en cambio, es un análisis puntual (aunque actualizable) centrado en el impacto en derechos fundamentales desde la perspectiva del uso real. El usuario debe basarse en la información de transparencia que el proveedor le facilita (art. 13) para realizar su evaluación, pero no puede delegar su obligación de evaluar el impacto en su propio contexto.

La complementariedad entre los artículos 9 y 27 no significa que los análisis sean intercambiables. El proveedor aborda la gestión de riesgos del sistema durante su ciclo de vida y desde las obligaciones que le corresponden; el responsable del despliegue examina los efectos previsibles de utilizarlo en su propio contexto. Una documentación técnica adecuada puede aportar información relevante, pero no demuestra por sí sola que se hayan identificado las personas afectadas ni los riesgos específicos asociados a los procesos de la entidad.

La diferencia de perspectiva también explica por qué el responsable del despliegue necesita comprender la información de transparencia del proveedor y relacionarla con el uso previsto. Si los procesos, la frecuencia o las categorías de personas difieren de lo que se consideró de forma general para el sistema, la evaluación debe reflejar esa circunstancia en vez de trasladar sin análisis una conclusión ajena al contexto. El usuario no tiene que rehacer la gestión técnica del proveedor, pero sí debe cumplir su propia obligación de valorar el impacto en derechos fundamentales.

Aunque la FRIA se realice antes del primer uso, su carácter inicial no la convierte en un documento inmutable. La necesidad de actualización conecta la evaluación con la evolución de las condiciones de despliegue y con la vigencia de sus elementos. Así se mantiene la distinción central: la gestión del proveedor continúa durante el ciclo de vida del sistema, mientras que la evaluación del responsable del despliegue parte de un análisis previo y debe actualizarse cuando la información evaluada cambie o deje de estar al día.

Implementación práctica y documentación

La obligación se aplica al primer uso del sistema. Sin embargo, si durante la utilización el usuario considera que alguno de los elementos evaluados ha cambiado o dejado de estar actualizado, debe adoptar medidas para actualizar la información. Esto implica un monitoreo continuo de la vigencia de la FRIA.

Una vez realizada, los resultados deben notificarse a la autoridad de vigilancia del mercado utilizando el modelo de cuestionario que la Oficina de IA elaborará. La norma permite incluir referencias cruzadas a evaluaciones de impacto en protección de datos (EIPD) previas, facilitando la integración con el cumplimiento del RGPD.

Para que la revisión de vigencia sea practicable, la entidad puede conservar junto a la evaluación la información que permita reconocer qué procesos, frecuencias, grupos afectados y medidas se tuvieron en cuenta. Ese registro facilita advertir si un elemento cambió o ya no describe el uso actual y, cuando corresponda, adoptar medidas de actualización. No se trata de añadir una obligación distinta a la prevista, sino de hacer posible la comprobación que exige mantener la evaluación ajustada al despliegue real.

La notificación de resultados y la elaboración del cuestionario son cuestiones relacionadas, pero no idénticas. El artículo 27 contempla que el responsable del despliegue notifique los resultados a la autoridad de vigilancia del mercado y dispone que la Oficina de IA elaborará un modelo de cuestionario. Mientras ese modelo no esté disponible, conviene no presentar como definitivo un formato concreto ni confundir la preparación interna de la FRIA con el instrumento de notificación previsto. La incertidumbre sobre el formulario no elimina la obligación de evaluación descrita en el artículo.

La posibilidad de hacer referencias cruzadas a una EIPD previa permite coordinar documentación pertinente, pero no convierte ambas evaluaciones en una sola ni implica que todo su contenido pueda trasladarse sin revisión. La FRIA debe cubrir sus propios elementos y atender al impacto en derechos fundamentales en el contexto del despliegue. La relación con el RGPD puede ayudar a evitar duplicaciones cuando la información sea pertinente, conservando la trazabilidad de qué aspectos se reutilizan y cuáles requieren un análisis específico.

La integración documental debe ser proporcional al propósito de cada evaluación: aprovechar información coincidente no debe ocultar vacíos ni dar por examinados aspectos que la EIPD no abordó. Por ello, una referencia cruzada resulta útil si permite localizar la información y entender cómo se conecta con los procesos, personas y riesgos considerados en la FRIA. El texto reconoce esa posibilidad, pero la interacción exacta entre evaluaciones no está desarrollada por completo; cualquier conclusión sobre su alcance debe conservar esa cautela.

Sanciones y consecuencias del incumplimiento

El incumplimiento de las obligaciones establecidas en el artículo 27 se considera una infracción de las obligaciones de los responsables del despliegue de sistemas de IA de alto riesgo.

Según el régimen sancionador del AI Act (artículo 99), las infracciones de las obligaciones de los responsables del despliegue pueden ser sancionadas con multas de hasta 15 millones de euros o el 3% de la facturación global anual, lo que sea mayor. Para pymes y empresas emergentes, se aplica el menor de los dos importes.

La consecuencia sancionadora debe entenderse dentro del régimen del artículo 99 y de la obligación concreta incumplida. El artículo 27 establece deberes propios para determinados responsables del despliegue, y el incumplimiento puede dar lugar a sanciones conforme al régimen aplicable. La cifra indicada representa un máximo descrito para infracciones de obligaciones de este tipo, no una multa automática que se imponga en todos los casos ni una predicción del resultado de un procedimiento.

En la exposición de los importes también importa conservar la regla diferenciada para pymes y empresas emergentes mencionada en el texto. Esa precisión no elimina la necesidad de valorar la infracción ni permite anticipar la sanción concreta: el importe máximo y la aplicación del régimen dependen de las condiciones previstas por la norma. Para las organizaciones, la implicación práctica es documentar que la obligación se identificó, que la evaluación se preparó y que se atendió a su actualización, en lugar de asumir que una cifra máxima resume por sí sola todas las consecuencias posibles.

Límites, vacíos y buenas prácticas

Aunque el texto legal es claro, la aplicación práctica depende de la guía de la Comisión Europea y la Oficina de IA, que aún están en desarrollo (incluyendo el modelo de cuestionario del art. 27.5).

Se recomienda a las organizaciones: 1) Mapear todos los sistemas de IA de alto riesgo en uso; 2) Identificar si encajan en los perfiles obligados; 3) Realizar la FRIA antes del despliegue; 4) Documentar la supervisión humana (art. 14) como parte integral de la FRIA; y 5) Establecer un proceso de revisión periódica de la evaluación.

Mientras se desarrollan la guía y el modelo de cuestionario, una organización puede avanzar en la identificación de los sistemas y en la determinación de si concurren los perfiles obligados descritos. Ese trabajo preparatorio no debe presentarse como sustituto de instrucciones oficiales futuras ni como una interpretación definitiva de los puntos aún pendientes. Permite, más modestamente, conocer qué despliegues necesitan análisis y organizar la información pertinente antes del primer uso.

Un proceso interno ordenado puede asignar quién reúne la información del proveedor, quién describe los procesos de utilización y quién documenta la supervisión humana y las medidas de respuesta. La participación de las funciones responsables de esos elementos ayuda a que la evaluación refleje la operativa efectiva, sin trasladar al proveedor la responsabilidad que corresponde al usuario. El documento puede dejar constancia de las fuentes de información disponibles y de los aspectos que todavía requieren confirmación, manteniendo separadas las conclusiones respaldadas de las cuestiones abiertas.

La revisión periódica recomendada debe entenderse junto con el criterio expresado en el artículo 27: actualizar la información cuando el responsable del despliegue considere que algún elemento ha cambiado o ha dejado de estar actualizado. Establecer una pauta de revisión puede facilitar que esos cambios se detecten, pero no convierte por sí sola una periodicidad concreta en un requisito legal que el texto no establece. La evaluación como documento vivo es útil precisamente si permanece vinculada al uso real, a la supervisión humana y a los mecanismos de reclamación internos, y si sus conclusiones se revisan cuando la situación lo requiera.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.