Evaluación de impacto en derechos fundamentales para IA: cómo decidir si corresponde y qué documentar

Alcance y cautela: una evaluación para decidir antes del uso

La evaluación de impacto en los derechos fundamentales del artículo 27 del Reglamento de Inteligencia Artificial, conocido como AI Act, es un análisis previo que determinados desplegadores deben realizar antes de utilizar ciertos sistemas de IA de alto riesgo. Su propósito práctico es examinar cómo el uso previsto podría afectar a personas o grupos en el contexto concreto, y establecer qué medidas, responsables y mecanismos de respuesta hacen falta antes de autorizarlo.

No es una certificación del sistema, una garantía de que no habrá daños ni una evaluación general de toda la actividad de una organización. Tampoco sustituye automáticamente una evaluación de impacto relativa a la protección de datos (DPIA). El objeto de esta guía es más limitado: ayudar a determinar si la obligación corresponde al caso y ordenar el trabajo necesario para que la decisión de despliegue sea trazable.

La legislación aplicable puede cambiar y las fuentes oficiales aportadas recogen una modificación de 2026 que afecta, entre otros aspectos, al tratamiento de elementos de la DPIA y al cuestionario que debe elaborar la Oficina de IA. Por ello, antes de aplicar esta guía hay que consultar el texto consolidado vigente, los formularios oficiales y el calendario aplicable. Esta guía organiza el análisis; no constituye asesoramiento jurídico.

Árbol de aplicabilidad: quién debe evaluar y qué uso comprobar

La obligación del artículo 27 no recae indistintamente sobre cualquier organización que utilice IA. En términos generales, debe comprobarse si el sistema está comprendido en la categoría de alto riesgo pertinente y si quien lo despliega pertenece a una de las categorías descritas por la norma. El artículo contempla, entre otros, organismos de derecho público, entidades privadas que prestan servicios públicos y desplegadores de determinados sistemas de alto riesgo del ámbito del crédito y de los seguros de vida o salud.

La evaluación se vincula al uso real previsto, no solo al nombre comercial del producto ni a una clasificación genérica del proveedor. Hay que identificar la finalidad, las funciones activadas, el proceso organizativo en que se insertan y las personas afectadas. Si una herramienta tiene varios usos, conviene analizar cada caso de uso por separado: la obligación y los riesgos pueden variar entre ellos.

El artículo 27 excluye de esta obligación específica los sistemas de alto riesgo señalados en el punto 2 del anexo III. La exclusión no debe extrapolarse a cualquier sistema que parezca de riesgo limitado, ni resuelve por sí sola otras obligaciones del AI Act, de protección de datos o de normas sectoriales. Si la clasificación depende de una excepción, una modificación del uso o una interpretación de la finalidad, documenta la base de esa conclusión y obtén revisión jurídica.

La pregunta de decisión puede resumirse así: ¿la entidad es un desplegador incluido?, ¿el sistema y el caso de uso entran en el ámbito pertinente?, ¿se aplica una excepción?, y ¿la evaluación ya realizada sigue siendo válida para este uso? Si falta información para contestar, la conclusión responsable no es asumir que no aplica: es identificar el dato pendiente, su responsable y la condición que impide cerrar la aprobación.

Momento, responsables y comunicación con la autoridad

La evaluación debe estar terminada antes del despliegue que corresponda, no cuando ya se hayan materializado daños o se haya iniciado una operación habitual. En la práctica, el punto de control debería situarse antes de autorizar el acceso a usuarios, integrar el sistema en un proceso decisorio o permitir que sus resultados influyan en decisiones sobre personas.

La responsabilidad organizativa debe asignarse de forma explícita. El equipo que impulsa el caso de uso aporta la descripción del proceso y las decisiones que el sistema apoyará; las funciones de cumplimiento, privacidad, derechos fundamentales, seguridad y operaciones examinan sus ámbitos; y una instancia con autoridad suficiente decide si el uso puede aprobarse, debe modificarse o se detiene. La colaboración no debe diluir quién responde por completar y mantener la evaluación.

La norma prevé la comunicación de la evaluación a la autoridad de vigilancia del mercado competente una vez realizada. Determinar qué autoridad corresponde y el canal y formato aplicables requiere comprobar la jurisdicción, la organización institucional nacional y las instrucciones oficiales vigentes. No conviene inventar un destinatario o un trámite a partir de una plantilla interna.

También hay que fijar cuándo se actualizará la evaluación. Un cambio de finalidad, población afectada, datos de entrada, frecuencia de uso, nivel de automatización, medidas de supervisión o condiciones de operación puede alterar el análisis. Registra qué cambios obligan a reabrir la decisión, quién detecta esos cambios y quién puede suspender el uso mientras se revisan.

Qué documentar: del propósito a las personas afectadas

El artículo 27 establece un núcleo de información que permite relacionar el sistema con su contexto de uso. La evaluación debe describir los procesos en los que se utilizará conforme a su finalidad prevista; el periodo y la frecuencia de uso; las categorías de personas y grupos que probablemente resulten afectados; los riesgos específicos de daño en ese contexto, teniendo en cuenta la información pertinente del proveedor; la aplicación de medidas de supervisión humana; y las medidas que se adoptarán si los riesgos se materializan, incluidas disposiciones de gobernanza interna y mecanismos de reclamación.

Para que esos apartados sirvan a una decisión, evita expresiones vagas como «puede haber sesgo» o «se mantendrá supervisión humana». Explica quién puede verse perjudicado, mediante qué paso del proceso, qué consecuencia es plausible y qué evidencia permitiría detectarla. Si el impacto depende de circunstancias que no se conocen —por ejemplo, el tamaño de un grupo afectado o la calidad de ciertos datos—, anota la incertidumbre en lugar de convertirla en una afirmación.

La información facilitada por el proveedor puede ayudar a entender las capacidades, limitaciones y riesgos conocidos del sistema, pero no reemplaza el análisis del desplegador. El mismo sistema puede producir consecuencias diferentes según los criterios de admisión, el personal que interpreta sus resultados, la posibilidad de corregir datos y las vías que tenga una persona para cuestionar una decisión. La evaluación debe reflejar esas condiciones concretas.

La consulta con personas afectadas, representantes o especialistas puede aportar información que no aparece en la documentación técnica. La obligación legal debe distinguirse de las buenas prácticas editoriales u organizativas: cuando la norma no prescribe un método concreto de consulta, registra la consulta como una medida elegida para mejorar el análisis, no como un requisito textual atribuido al artículo.

De los riesgos a las decisiones: medidas, evidencia y límites

Una lista de riesgos no basta. Cada riesgo relevante debe conectarse con una medida verificable, un responsable, un plazo y una evidencia que permita comprobar si la medida funciona. Si una medida depende de otra unidad, de una función todavía no implementada o de una validación pendiente, no la describas como si ya estuviera operativa. Trátala como condición previa al despliegue.

Las medidas pueden incluir limitar la finalidad o las personas elegibles, reducir la frecuencia de uso, mejorar la calidad de los datos, establecer umbrales de revisión, probar resultados para detectar diferencias relevantes, exigir revisión humana antes de una decisión adversa, habilitar correcciones y reclamaciones, o detener el sistema ante señales de daño. Son opciones que deben justificarse en el contexto; no son una lista cerrada ni garantizan por sí mismas el cumplimiento.

La supervisión humana debe ser concreta y viable. Especifica quién revisa, qué información recibe, qué formación necesita, qué margen tiene para apartarse del resultado y cómo registra la decisión. Una persona que solo confirma salidas automáticamente, sin tiempo, información o autoridad para intervenir, no constituye una medida efectiva por el mero hecho de aparecer en un procedimiento.

La autorización puede ser condicional. Por ejemplo, se puede permitir un piloto restringido solo después de completar pruebas, validar el canal de reclamaciones y asignar recursos de revisión. La decisión debe incluir criterios de suspensión o modificación, como errores por encima de un umbral previamente definido, reclamaciones que indiquen un patrón, cambios no aprobados del sistema o incapacidad para realizar la supervisión comprometida. Los umbrales concretos deben derivarse de la evaluación y no inventarse como valores universales.

Relación con la DPIA: coordinar sin confundir

Una DPIA, o evaluación de impacto relativa a la protección de datos, se realiza conforme al régimen de protección de datos cuando el tratamiento previsto puede entrañar un alto riesgo para los derechos y libertades de las personas. Su foco es el tratamiento de datos personales y las obligaciones de protección de datos; la evaluación del artículo 27 se centra en los impactos sobre derechos fundamentales del uso del sistema de IA dentro del alcance previsto por el AI Act. Puede haber intersección, pero el objetivo y el ámbito no son idénticos.

El artículo 27 contempla la relación con evaluaciones de protección de datos. Además, las fuentes oficiales aportadas indican que una modificación de 2026 afecta a la reutilización de elementos de la DPIA y al cuestionario que debe elaborar la Oficina de IA. Por tanto, no debe aplicarse automáticamente una formulación anterior sobre si la evaluación debe complementar, reutilizar o referenciar una DPIA: hay que leer la versión consolidada vigente y las instrucciones oficiales para conocer las condiciones actuales.

Como método de trabajo, conserva un mapa de correspondencias. Señala qué análisis de la DPIA también informa sobre personas, datos o riesgos pertinentes para la evaluación de derechos fundamentales; qué elementos requieren análisis adicional; y qué cuestiones no cubre una evaluación con el otro propósito. Las referencias cruzadas reducen duplicaciones, pero deben permitir que una persona revisora encuentre la evidencia y entienda por qué sirve para el punto correspondiente.

Si no se exige una DPIA en el caso concreto, eso no demuestra que tampoco corresponda la evaluación del artículo 27. Y si existe una DPIA, su mera existencia tampoco acredita que se hayan cubierto los riesgos no circunscritos al tratamiento de datos. La entidad debe documentar la conclusión aplicable al caso, la norma vigente utilizada y las lagunas que aún haya que resolver.

Caso práctico: evaluación de solicitudes de crédito

Supongamos que una entidad utiliza un sistema de alto riesgo para apoyar la evaluación de solicitudes de crédito. Este ejemplo es hipotético: no afirma que un sistema concreto exista, que una entidad determinada esté obligada ni que se hayan producido daños. Antes de aplicarlo, la organización tendría que confirmar la clasificación, su papel, el uso previsto y las condiciones legales del caso.

Primero se dibuja el proceso: qué información recibe el sistema, qué resultado genera, quién lo consulta y si ese resultado recomienda, ordena o determina una decisión. También se describe la frecuencia y el periodo de uso. Un análisis que solo diga «el modelo evalúa crédito» no aclara si el personal puede apartarse de la recomendación, si el resultado causa una denegación automática o si existe una segunda revisión.

A continuación, se identifican las personas afectadas —por ejemplo, solicitantes y personas cuyos datos influyen indirectamente en la evaluación— y se formulan hipótesis de daño que la entidad debe validar. Podrían examinarse la posibilidad de decisiones desfavorables asociadas a datos incompletos, efectos desproporcionados en determinados grupos, errores difíciles de corregir o barreras para entender y reclamar una decisión. No son conclusiones sobre un modelo real: requieren datos, pruebas y contexto.

Las medidas deben responder a las hipótesis. La entidad podría verificar la procedencia y calidad de los datos, probar resultados y diferencias pertinentes, impedir que una puntuación sea el único fundamento de decisiones adversas cuando el análisis indique que hace falta revisión, formar al personal, registrar las razones para apartarse de una recomendación y ofrecer un mecanismo accesible para corregir información o reclamar. Debe precisarse quién ejecuta cada control y qué resultado permitiría considerarlo insuficiente.

Antes de aprobar, la instancia responsable debería comprobar que las medidas existen y que la supervisión tiene autoridad efectiva. Si faltan resultados de pruebas, no hay canal de reclamaciones operativo o no se puede explicar qué información sustenta una decisión, la respuesta prudente puede ser aplazar, restringir o no autorizar el despliegue hasta resolverlo. Esa conclusión pertenece a la entidad a partir de evidencia propia; el ejemplo no sustituye su análisis.

Lista de control antes de aprobar el uso

Una lista de control es útil si lleva a una decisión y no se convierte en un trámite de casillas. Cada respuesta debe tener una fuente, un responsable y, cuando corresponda, una acción pendiente. Mantén separados los requisitos legales identificados en el texto vigente y las prácticas internas que la organización añade para hacer el análisis más sólido.

Antes de cerrar, verifica si el documento identifica con precisión el sistema, su versión, la finalidad, los procesos afectados, el calendario y la frecuencia de uso. Comprueba que las personas y grupos afectados están descritos de manera suficientemente concreta, que cada riesgo está ligado a un posible daño en ese contexto y que se han considerado las limitaciones y la información pertinente del proveedor.

Confirma también que la supervisión humana existe en la práctica, que las medidas tienen responsables y evidencia, y que se conocen los riesgos residuales. Revisa los mecanismos para detectar problemas, recibir reclamaciones y responder a incidentes. Si se consultó a personas afectadas o a especialistas, registra qué aportó la consulta y qué decisiones influyó. Si no se consultó, deja constancia de si esa ausencia limita el análisis.

Por último, comprueba la comunicación a la autoridad competente, las referencias con la DPIA cuando proceda, la fecha de revisión y las condiciones que obligan a reabrir la evaluación. La aprobación debería indicar qué versión de la documentación se examinó, qué condiciones acompañan el uso y quién tiene potestad para detenerlo.

Qué verificar antes de usar esta guía

La evaluación debe basarse en la versión consolidada del AI Act vigente en la fecha pertinente, no únicamente en resúmenes, borradores o textos anteriores. Las fuentes aportadas identifican una modificación legislativa de 2026 y una consolidación fechada en julio de 2026; también indican que la Comisión Europea actualizó sus preguntas frecuentes en agosto de 2026. Como las reglas y fechas pueden cambiar, confirma que esas versiones corresponden al momento y al caso de uso que estás evaluando.

Verifica en el texto oficial el alcance exacto de los desplegadores obligados, las categorías de sistemas incluidas, la excepción, los apartados exigidos, la comunicación a la autoridad y el efecto de las modificaciones sobre la DPIA. Consulta además si ya se han publicado formularios oficiales definitivos y cómo debe efectuarse la notificación en el Estado miembro pertinente. Una FAQ ayuda a orientarse, pero no prevalece sobre el acto legislativo.

El calendario de aplicación merece una comprobación aparte: la fecha relevante depende de las disposiciones vigentes y de la categoría concreta del sistema. No deduzcas una fecha general a partir de una noticia o de una versión previa del Reglamento. Si hay duda sobre el ámbito, la autoridad competente o la interacción con otras normas, solicita asesoramiento jurídico antes de autorizar el uso.

Para ampliar el análisis, conecta esta evaluación con los procedimientos internos de seguridad y gestión de riesgos de la entidad, con su proceso de comparación de sistemas y con la evaluación de alternativas antes de seleccionar una solución. Esas revisiones complementan la decisión, pero no sustituyen la evaluación legal cuando esta sea exigible.

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.