(Artículo dirigido, revisado y validado por Leocadio Marrero Trujillo, autor y responsable editorial. Se utilizaron herramientas de IA generativa como apoyo a la edición y al diseño gráfico)

Resumen

La sentencia del Tribunal de Distrito de La Haya de 29 de julio de 2026, relativa al uso del sistema Information Supporting Decision (IOB) en la tramitación de solicitudes de visado Schengen, ofrece un caso especialmente útil para examinar el alcance y las limitaciones de las evaluaciones de impacto aplicadas a sistemas algorítmicos. La resolución no considera acreditado que IOB determinara la decisión final sobre el visado ni que produjera discriminación en el caso concreto. Sin embargo, aprecia deficiencias en la motivación y transparencia del procedimiento porque la persona afectada no había sido informada de que el sistema había intervenido en su expediente ni conocía el resultado de esa intervención.

El interés del caso aumenta cuando la sentencia se contrasta con la documentación oficial publicada por la propia Administración neerlandesa. El Registro de Algoritmos describe IOB como un sistema de apoyo a la tramitación de visados de corta duración, identifica la existencia de una EIPD y una IAMA y lo presenta como un algoritmo actualmente en uso.

A partir de este caso, el artículo analiza la evaluación de impacto desde una perspectiva de ciclo de vida. El punto de partida es que toda evaluación realizada antes del despliegue constituye necesariamente una representación de una realidad que todavía no puede observarse por completo. Su calidad depende, por ello, no solo de la identificación inicial de riesgos y medidas, sino también de la capacidad para expresar las incertidumbres, comprobar el funcionamiento de los controles, obtener evidencia durante la operación y revisar las conclusiones cuando cambia el conocimiento disponible.

El análisis incorpora asimismo cuatro marcos europeos que observan dimensiones diferentes de una misma actuación —RGPD, Reglamento de Inteligencia Artificial, Carta de los Derechos Fundamentales y Código de Visados— y los relaciona con referencias metodológicas sobre evaluación de impacto y gestión del riesgo, en particular ISO/IEC 42005:2025, ISO/IEC 23894:2023 e ISO 31000:2018.

Palabras clave: evaluación de impacto, inteligencia artificial, riesgo algorítmico, incertidumbre, supervisión humana, transparencia, IOB, ciclo de vida.

1. Introducción

Una parte importante del debate sobre la utilización de algoritmos en la toma de decisiones se ha concentrado en determinar quién adopta finalmente la decisión: una persona o una máquina. La distinción resulta necesaria, pero no describe adecuadamente muchos de los sistemas que actualmente se utilizan en organizaciones públicas y privadas.

Entre una decisión íntegramente humana y una decisión completamente automatizada existe un espacio mucho más amplio. Hay sistemas que seleccionan información, asignan puntuaciones, construyen perfiles, priorizan expedientes, recomiendan actuaciones o determinan la intensidad con la que una solicitud será examinada. En estos casos puede mantenerse formalmente la competencia humana para decidir y, al mismo tiempo, modificarse de manera relevante el contexto informativo y organizativo en el que esa decisión se adopta.

El asunto resuelto por el Tribunal de Distrito de La Haya el 29 de julio de 2026 constituye un buen ejemplo. El litigio se origina en la denegación de un visado de corta duración solicitado por una ciudadana iraní para visitar a su hija y a la pareja de esta en los Países Bajos. La Administración consideró insuficientemente acreditados sus vínculos sociales y económicos con Irán y entendió que existían dudas razonables sobre su intención de abandonar el espacio Schengen dentro del plazo correspondiente. La resolución está identificada como ECLI:NL:RBDHA:2026:21628 y fue publicada el 3 de agosto de 2026.

Durante la tramitación se había utilizado IOB. Según explica la sentencia, el sistema operaba en una fase preliminar mediante comprobaciones frente a determinadas fuentes de información, un árbol de decisión para la construcción de perfiles y un modelo de ponderación. El resultado permitía asignar las solicitudes a una vía de tramitación rápida, regular o intensiva. Posteriormente, el funcionario consular continuaba el examen y adoptaba la decisión sustantiva correspondiente.

La documentación oficial neerlandesa confirma que el sistema está destinado a apoyar la tramitación de solicitudes de visado Schengen de corta duración y que se encuentra actualmente en uso. La ficha pública del sistema identifica además la existencia de una Evaluación de Impacto relativa a la Protección de Datos y de una evaluación IAMA.

La configuración de IOB permite situar el problema en un terreno especialmente interesante para la evaluación de impacto. El objeto que debe comprenderse no es únicamente el mecanismo que genera una puntuación o una clasificación. También forman parte del servicio los datos de entrada, las reglas utilizadas, la forma en que el resultado llega al funcionario, las condiciones en las que este lo utiliza, las actuaciones posteriores, la información facilitada a la persona y las posibilidades de conocer, corregir o cuestionar lo ocurrido.

La unidad de análisis es, por tanto, más amplia que el algoritmo. Estamos ante un servicio sociotécnico en el que tecnología, organización, personas y procedimiento interactúan.

Método y alcance del análisis

Este artículo diferencia deliberadamente tres niveles.

El primero corresponde a los hechos y circunstancias que constan en la sentencia y en la documentación oficial relativa a IOB. Cuando se describe el funcionamiento del sistema, los estudios realizados, las medidas adoptadas o las conclusiones del tribunal, se intenta mantener el alcance exacto de esas fuentes.

El segundo nivel comprende las inferencias metodológicas que se formulan a partir del caso, especialmente en relación con la evaluación previa, la incertidumbre, la eficacia de los controles, la monitorización y la reevaluación. Estas conclusiones no se atribuyen al tribunal.

El tercer nivel contiene extrapolaciones al marco normativo europeo. En particular, se examina cómo un sistema de características semejantes podría relacionarse con el RGPD y con el Reglamento de Inteligencia Artificial. Este último no constituye el fundamento jurídico utilizado por el Tribunal de La Haya y se emplea aquí únicamente con finalidad prospectiva y comparativa. La eventual clasificación de IOB bajo ese Reglamento exigiría, además, comprobar que satisface la definición legal de sistema de IA y los restantes presupuestos de aplicación.

Esta separación pretende evitar dos errores: convertir una inferencia metodológica en un hecho supuestamente probado por la sentencia o proyectar retrospectivamente sobre el caso obligaciones que no formaban parte del marco aplicado por el tribunal.

2. Evaluar antes del despliegue: una representación construida bajo incertidumbre

Una cuestión que abordamos recientemente en la clausura del Curso de Riesgos y Evaluación de Impacto de GRCx3, en la masterclass Gobernar el riesgo bajo incertidumbre. Cómo fracasan las evaluaciones y cómo construir decisiones responsables y defendibles, dictada el viernes 7 de agosto, fue la relación entre evaluación, conocimiento e incertidumbre.

El punto de partida era sencillo: una evaluación no reproduce exactamente la realidad que pretende analizar. Construye una representación ordenada y necesariamente parcial de ella.

Para evaluar es necesario delimitar un alcance, seleccionar fuentes de información, identificar actores, formular escenarios, utilizar determinados criterios de probabilidad e impacto y decidir qué medidas deben considerarse. Esta simplificación no constituye un defecto metodológico. Es una condición para poder ordenar una realidad compleja y tomar decisiones. El problema aparece cuando se pierde de vista la diferencia entre esa representación y aquello que pretende representar.

Una evaluación puede ser formalmente completa y, sin embargo, materialmente insuficiente. Puede ocurrir cuando el alcance no refleja el tratamiento real, la información de partida es incompleta, los escenarios se han formulado de manera demasiado genérica, las personas afectadas apenas aparecen en el análisis o se atribuye eficacia a controles que todavía no han sido comprobados.

Esta limitación adquiere especial relevancia cuando la evaluación se realiza antes de poner en funcionamiento un sistema algorítmico.

En ese momento puede conocerse bastante sobre el diseño previsto. Es posible revisar los datos, analizar el modelo, realizar pruebas, estudiar determinadas diferencias entre grupos, diseñar procedimientos de revisión humana o establecer medidas técnicas y organizativas. Pero existen aspectos cuyo comportamiento real todavía no puede observarse con la misma calidad.

Una revisión humana puede parecer adecuada en el procedimiento escrito y funcionar de manera diferente cuando existe presión de tiempo o un volumen elevado de expedientes. Un modelo puede comportarse correctamente con los datos utilizados para su validación y evolucionar de manera distinta cuando cambian las poblaciones o las prácticas administrativas. Un mecanismo de reclamación puede estar formalmente disponible y resultar poco útil si las personas ni siquiera conocen la intervención del sistema que podrían necesitar cuestionar.

La evaluación previa trabaja, en consecuencia, con diferentes niveles de conocimiento. Hay hechos razonablemente comprobados, estimaciones, hipótesis, supuestos y aspectos sobre los que todavía existe incertidumbre. La metodología debería mantener visibles esas diferencias.

Una forma de hacerlo consiste en separar el nivel estimado de riesgo del grado de confianza existente en esa estimación. Una valoración media construida sobre evidencia suficiente y directamente relacionada con el escenario no proporciona la misma información que otra valoración media basada en datos parciales o en supuestos cuyo cambio podría alterar sustancialmente la conclusión.

La existencia de incertidumbre no convierte automáticamente un riesgo en alto. Pero tampoco permite tratarlo como bajo cuando todavía no existe una base suficiente para sostener esa conclusión.

Esta distinción modifica la función de la evaluación ex ante. No se le exige predecir con certeza cómo funcionará un servicio durante los años siguientes. Debe proporcionar una base suficientemente fundada para decidir si resulta razonable comenzar a operar, identificar las condiciones que deben cumplirse y señalar qué cuestiones permanecen abiertas y necesitarán ser comprobadas posteriormente.

El momento en el que se realiza cada análisis es, por ello, importante.

La sentencia señala que la solicitud de la demandante fue denegada el 9 de diciembre de 2024 y que la decisión sobre su objeción fue adoptada el 16 de julio de 2025. Más adelante indica que el Ministerio encargó una Impact Assessment Human Rights and Algorithms (IAMA) para IOB en diciembre de 2025.

De esa secuencia temporal puede inferirse, y solo respecto de esa IAMA concreta, que no pudo constituir la evaluación previa a la utilización de IOB en el expediente de la demandante. Esta inferencia no permite concluir que el sistema careciera de otros análisis, evaluaciones o controles anteriores. De hecho, la propia sentencia recoge investigaciones previas, entre ellas un experimento sobre la posible influencia de las etiquetas realizado en enero de 2024.

La precisión es relevante porque permite diferenciar tres funciones que no deberían confundirse: la evaluación antes de iniciar un determinado tratamiento o uso, la monitorización durante su funcionamiento y la reevaluación posterior utilizando la evidencia acumulada.

Una evaluación posterior puede disponer de información mucho más rica que la existente al comienzo. Pero esa ventaja no la convierte retrospectivamente en una evaluación previa. Del mismo modo, una evaluación ex ante razonablemente construida tampoco debería inmunizar el sistema frente a revisiones posteriores cuando aparecen nuevos datos.

El RGPD recoge esta lógica. Su artículo 35 exige una EIPD antes del tratamiento cuando sea probable que este entrañe un alto riesgo, y su apartado 11 prevé la revisión cuando resulte necesario, al menos cuando cambie el riesgo representado por las operaciones. Las directrices WP248 rev.01 sobre EIPD, posteriormente respaldadas por el Comité Europeo de Protección de Datos, constituyen además una referencia interpretativa relevante sobre este instrumento.

ISO/IEC 42005:2025 refuerza igualmente una perspectiva de ciclo de vida al orientar la evaluación hacia la identificación, evaluación y documentación de los impactos que un sistema de IA y sus usos previsibles pueden generar sobre personas, grupos y sociedad.

No se trata, por tanto, de elegir entre evaluación previa y evaluación posterior. Cada una responde a una pregunta distinta. La primera permite decidir antes de actuar; la segunda permite comprobar si aquella decisión sigue siendo razonable cuando la realidad comienza a aportar evidencia que antes no estaba disponible.

3. Del riesgo identificado a la evidencia: lo que permite observar el caso IOB

El expediente es especialmente interesante porque IOB no aparece como un sistema sobre el que nunca se hubiera reflexionado. La sentencia describe estudios sobre posibles sesgos, análisis sobre la relación entre la clasificación y la decisión humana, medidas de formación y recalibración y mecanismos de monitorización.

Entre las cuestiones identificadas por los estudios considerados por el tribunal aparece una señal especialmente sensible relacionada con la nacionalidad.

Al referirse al análisis de SigmaRed, la sentencia utiliza literalmente la expresión “an indication of bias for Yemeni nationality”. Explica que la nacionalidad yemení aparecía en los perfiles de riesgo en una proporción superior a la que podía explicarse mediante las tasas de rechazo.

La formulación debe conservarse con cuidado. El tribunal habla de una indicación de sesgo, no de una constatación de discriminación. Tampoco considera demostrada una relación causal. La propia resolución señala inmediatamente después que el estudio encontraba una correlación entre el perfil y el resultado de las solicitudes, pero que “there is no evidence of causality”.

SigmaRed planteaba además otra preocupación. El modelo utilizaba tasas de rechazo dentro de su ponderación y, si quienes adoptaban las decisiones posteriores se apoyaban en el resultado de IOB, podía generarse un mecanismo de retroalimentación negativa mediante el cual el sistema terminara reforzando sus propios patrones. La sentencia presenta esta posibilidad como un riesgo, no como un fenómeno cuya materialización hubiera quedado demostrada.

Este aspecto permite observar una cuestión importante de la interacción humano-algoritmo. La existencia de una persona que adopta formalmente la decisión final no demuestra por sí sola que exista una supervisión efectiva. Un resultado previo puede influir en la forma de interpretar el resto de la información, generar anclaje o facilitar una dependencia excesiva respecto de la recomendación.

La sentencia recoge precisamente investigaciones dirigidas a comprobar esa posible influencia. El experimento realizado en enero de 2024 examinó si la etiqueta o vía asignada a un caso modificaba la valoración posterior. Según lo recogido por el tribunal, la puntuación media de la decisión final no difería entre las distintas etiquetas y tampoco se observó que estas incrementaran el grado de certeza declarado por el funcionario. Con la evidencia entonces disponible, el tribunal no encontró motivos para concluir que IOB influyera en la decisión final.

También aquí conviene contener la conclusión. El experimento aporta evidencia favorable respecto del efecto concreto estudiado y en las condiciones en las que fue realizado. No demuestra de manera general que cualquier forma de sesgo de automatización, anclaje o dependencia sea imposible durante toda la operación del sistema.

La sentencia añade otra precisión. Frente al riesgo de un ciclo de retroalimentación, el Ministerio explicó que IOB no era entonces autoaprendente y que la clasificación en perfiles se realizaba mediante un árbol de decisión fijo. El tribunal considera que, en esas condiciones, ese riesgo no se estaba produciendo.

Esta secuencia muestra bien la necesidad de distinguir entre riesgo, evidencia y conclusión. Identificar un escenario de riesgo no significa que el daño se haya materializado. Encontrar evidencia favorable tampoco significa que el riesgo haya desaparecido de forma definitiva.

La evaluación necesita mantener trazabilidad entre la hipótesis formulada, la evidencia utilizada para examinarla y el grado de confianza que esa evidencia permite atribuir a la conclusión.

El Ministerio había adoptado además medidas como formación de los funcionarios, recalibración del proceso, modificaciones en determinados datos de entrada y un protocolo de monitorización continuada de posibles sesgos.

Aquí resulta útil diferenciar cuatro situaciones posibles de un control. Una medida puede encontrarse declarada, haber sido implantada, estar realmente operativa y disponer finalmente de evidencia suficiente para considerarse eficaz frente al escenario concreto para el que fue diseñada.

No se trata de una taxonomía oficial del RGPD o de ISO, sino de una herramienta analítica. Su utilidad consiste en evitar que la mera presencia de una medida dentro de una evaluación produzca automáticamente una reducción del riesgo residual.

La formación es un buen ejemplo. Haber impartido formación acredita que una medida se ha ejecutado, pero no necesariamente que las personas hayan comprendido las limitaciones del sistema o que su comportamiento haya cambiado. Algo parecido ocurre con la revisión humana: su existencia formal no demuestra que quien revisa disponga de suficiente tiempo, información, competencia y autoridad para modificar realmente el resultado.

En IOB, algunas medidas avanzaron más allá de su mera declaración porque existió un intento de obtener evidencia sobre el comportamiento de los funcionarios y sobre determinados riesgos de sesgo. Esto constituye un elemento relevante del sistema de gobierno descrito en la resolución.

Sin embargo, la controversia judicial muestra también los límites de esa representación.

En el expediente concreto, la demandante había sido clasificada en la vía regular, con una puntuación de cero. La sentencia señala que no existía coincidencia con las fuentes consultadas y que no había un perfil activo que coincidiera con las características de su solicitud.

El problema que finalmente adquiere relevancia judicial aparece en otra parte del servicio.

La solicitante no sabía que IOB había sido utilizado en su expediente ni conocía el resultado producido. La existencia general del algoritmo podía ser conocida públicamente, pero esa transparencia institucional no permitía comprender qué había ocurrido en el procedimiento individual.

El tribunal relaciona esta situación con las exigencias de motivación y transparencia. Considera necesario que la persona pueda conocer suficientemente la utilización del sistema y su función para verificar y, en su caso, cuestionar los datos, presupuestos y elementos relevantes del procedimiento. Incluso aceptando que IOB no hubiera modificado el resultado final, su intervención debía ser explicada.

Esta conclusión abre una cuestión metodológica de especial interés.

Un sistema puede ser técnicamente trazable, disponer de reglas fijas, haber sido objeto de análisis sobre sesgo y figurar en un registro público y, sin embargo, seguir existiendo un problema de transparencia para la persona concreta que ha sido sometida a su utilización.

No todas esas dimensiones son equivalentes.

La transparencia sobre la existencia del sistema, la capacidad de la Administración para reconstruir su funcionamiento, la explicabilidad técnica y la información que necesita una persona para comprender lo ocurrido en su expediente son manifestaciones relacionadas, pero diferentes.

El caso muestra así por qué el alcance de la evaluación resulta decisivo. Si el análisis termina en el momento en que el algoritmo genera una clasificación, pueden quedar fuera riesgos que aparecen en las fases posteriores: cómo se utiliza el resultado, cómo afecta a la intensidad de la tramitación, qué sabe la persona y qué posibilidades reales tiene de cuestionarlo.

El alcance no es, por tanto, un aspecto meramente documental. Forma parte del propio riesgo. Las exclusiones relevantes deben poder explicarse y revisarse si la evidencia posterior demuestra que la representación inicial era demasiado estrecha.

4. Cuatro marcos jurídicos sobre distintos planos de un mismo servicio

El caso permite analizar cómo diferentes marcos europeos pueden converger sobre una misma actuación sin tener el mismo objeto.

La distinción resulta importante porque una evaluación integrada no significa convertir normas diferentes en una única lista de controles.

RGPD: el tratamiento de datos y el riesgo para derechos y libertades

El RGPD proporciona una primera capa evidente. IOB utiliza datos personales y, según la descripción de la sentencia, incorpora perfiles dentro de su funcionamiento. El tribunal conecta expresamente la controversia sobre transparencia con el artículo 5.1 del RGPD.

La relevancia del Reglamento no debería reducirse al artículo 22. Ese precepto contiene garantías específicas para decisiones basadas únicamente en tratamiento automatizado que producen efectos jurídicos o efectos similares significativos. El propio caso muestra por qué no resulta adecuado construir toda la gobernanza algorítmica alrededor de ese umbral: el tribunal acepta que el funcionario consular adoptaba la decisión sustantiva y, pese a ello, siguen existiendo cuestiones relacionadas con perfilado, transparencia, diseño y evaluación del riesgo.

Desde la perspectiva de este artículo, el artículo 35 resulta especialmente importante. La EIPD exige atender a la naturaleza, alcance, contexto y finalidades del tratamiento, analizar los riesgos para los derechos y libertades y establecer las medidas destinadas a afrontarlos. Su apartado 11 incorpora además la revisión posterior cuando cambian las condiciones de riesgo.

Reglamento de Inteligencia Artificial: el sistema y su contexto de uso

La utilización del Reglamento de IA en este análisis exige una doble cautela.

En primer lugar, la sentencia de La Haya no aplicó las obligaciones de alto riesgo del Reglamento como fundamento de su decisión. En segundo lugar, no debe darse por supuesto que IOB sea jurídicamente un “sistema de IA” a efectos del Reglamento únicamente porque la sentencia o la Administración lo califiquen como algoritmo. Esa clasificación requeriría comprobar la definición del Reglamento y el resto de los presupuestos de aplicación.

Hecha esa salvedad, el paralelismo normativo resulta relevante. El Anexo III incluye dentro del ámbito de migración, asilo y gestión de fronteras los sistemas de IA destinados a asistir a las autoridades competentes en el examen de solicitudes de asilo, visados o permisos de residencia y de los recursos asociados.

El artículo 6 añade otra precisión importante: para los sistemas incluidos en el Anexo III existe una excepción que permite considerar determinados usos como no altos riesgos cuando no influyen materialmente en la decisión, pero esa excepción no opera si el sistema realiza perfilado de personas físicas.

El artículo 14 resulta especialmente interesante para el caso IOB porque aborda expresamente la supervisión humana y exige prestar atención a la tendencia a confiar automática o excesivamente en el resultado del sistema, lo que el Reglamento denomina automation bias. También contempla la capacidad para interpretar el resultado y, cuando proceda, ignorarlo, anularlo o revertirlo.

La proximidad conceptual con el experimento descrito en la sentencia es clara. Ambos observan un mismo problema: la posibilidad de que una decisión formalmente humana termine condicionada por el resultado previo del sistema. Esto no significa que el Ministerio neerlandés estuviera aplicando el artículo 14; significa únicamente que el riesgo que investigó coincide con uno de los problemas que el Reglamento europeo incorpora expresamente a la supervisión humana.

El Reglamento introduce además obligaciones relevantes desde la perspectiva de la transparencia individual. Para los sistemas de alto riesgo del Anexo III que adopten decisiones o ayuden a adoptar decisiones relacionadas con personas, el artículo 26.11 exige a quien despliega el sistema informar a las personas de que están sometidas a su utilización.

Existe aquí un paralelismo material evidente con la deficiencia observada por el Tribunal de La Haya, aunque las bases jurídicas y los momentos temporales sean diferentes.

El artículo 27 incorpora, por su parte, una evaluación de impacto sobre derechos fundamentales para determinados responsables del despliegue. La evaluación debe realizarse antes del uso y atender, entre otros aspectos, al proceso en el que se integrará el sistema, las personas y grupos afectados, los riesgos concretos de daño, la supervisión humana y las medidas previstas si esos riesgos se materializan. También debe actualizarse cuando los elementos relevantes dejan de estar al día.

La reforma introducida mediante el Reglamento (UE) 2026/1744 refuerza además la coordinación con las evaluaciones de protección de datos. Cuando obligaciones del artículo 27 ya hayan sido abordadas mediante una EIPD conforme al artículo 35 RGPD —o al instrumento equivalente de la Directiva 2016/680—, quien despliega el sistema puede utilizar referencias cruzadas o incorporar las partes pertinentes de aquella evaluación.

Esta previsión no convierte la EIPD y la evaluación sobre derechos fundamentales en el mismo instrumento. Sí favorece una arquitectura en la que distintas obligaciones puedan apoyarse sobre una base común de conocimiento y evidencia.

Finalmente, debe mantenerse una precisión temporal especialmente importante. La reforma de julio de 2026 modificó el artículo 113 del Reglamento de IA. Las secciones 1, 2 y 3 del capítulo III —salvo el artículo 6.5— serán aplicables desde el 2 de diciembre de 2027 para los sistemas clasificados como de alto riesgo conforme al artículo 6.2 y el Anexo III, y desde el 2 de agosto de 2028 para los clasificados conforme al artículo 6.1 y el Anexo I.

Por ello, no sería preciso afirmar genéricamente que “el Reglamento de IA no era aplicable” al caso. Distintas disposiciones tienen diferentes calendarios. Lo que sí puede afirmarse es que el régimen de alto riesgo del capítulo III utilizado aquí para realizar la comparación prospectiva no constituyó el marco jurídico aplicado por el Tribunal de La Haya y, para los sistemas del artículo 6.2 y el Anexo III, las secciones relevantes no serán aplicables hasta el 2 de diciembre de 2027.

Carta de los Derechos Fundamentales: los derechos afectados

La Carta añade un tercer plano de observación. En una actuación de estas características adquieren especial relevancia el respeto a la vida privada, la protección de datos, la igualdad y no discriminación y el derecho a un recurso efectivo. La Carta vincula a los Estados miembros cuando aplican Derecho de la Unión.

La relación con el derecho a un recurso efectivo resulta especialmente significativa. Si una persona desconoce que un sistema ha intervenido en su expediente, puede resultarle más difícil identificar un posible error, solicitar la información pertinente o construir adecuadamente una impugnación.

Desde esta perspectiva, la transparencia adquiere una función que va más allá de proporcionar información. Puede convertirse en una condición para el ejercicio efectivo de otras garantías.

Debe utilizarse con mayor prudencia el artículo 41 de la Carta. Su tenor reconoce el derecho a una buena administración respecto de las instituciones, órganos y organismos de la Unión. En un procedimiento desarrollado por una autoridad nacional, resulta preferible no trasladar automáticamente ese precepto como si tuviera idéntico ámbito subjetivo y fundamentar las garantías administrativas en las normas y principios que correspondan al procedimiento concreto.

Código de Visados: la decisión que el sistema está ayudando a tramitar

El cuarto plano lo proporciona la regulación sectorial.

El Código de Visados exige que el examen de las solicitudes tenga en cuenta, entre otros aspectos, el riesgo de inmigración irregular y la intención del solicitante de abandonar el territorio antes de la expiración del visado.

El artículo 32 regula las causas de denegación, la notificación de la decisión y el derecho del solicitante a recurrir.

Esta dimensión resulta esencial para evitar que una evaluación de impacto quede absorbida por las características técnicas del sistema. La pregunta no es únicamente si una clasificación es estadísticamente adecuada o reproducible. También debe analizarse si la forma en que se utiliza preserva las garantías y criterios de la decisión administrativa que pretende apoyar.

Los cuatro marcos no proporcionan cuatro evaluaciones alternativas. Observan dimensiones diferentes del mismo servicio: el tratamiento de datos, el sistema y su utilización, los derechos afectados y el procedimiento concreto.

5. Qué lecciones metodológicas pueden extrapolarse

El valor del caso IOB no consiste en convertir una sentencia concreta en una metodología universal. Su utilidad es diferente: permite contrastar con una situación real algunas de las hipótesis que suelen darse por sentadas cuando se realizan evaluaciones de impacto.

La primera cuestión es el objeto de evaluación.

Cuando un algoritmo interviene en un procedimiento que afecta a personas, el modelo aislado resulta una unidad de análisis demasiado estrecha. La evaluación debe seguir el proceso desde la obtención de los datos hasta las consecuencias y garantías posteriores.

Esto implica analizar no solo qué calcula el sistema, sino cómo se utiliza el resultado. Una misma clasificación puede adquirir efectos distintos según la interfaz en la que se presenta, el tiempo disponible para revisarla, el grado de confianza que inspire, la capacidad de modificarla o las consecuencias procedimentales asociadas.

El riesgo deja entonces de formularse únicamente como “el algoritmo puede clasificar incorrectamente”. Puede adoptar formas más concretas: una clasificación puede aumentar la intensidad de una revisión; una recomendación puede adquirir un peso superior al previsto; un dato incorrecto puede permanecer invisible; una persona puede desconocer la intervención del sistema; o una sucesión de decisiones individualmente razonables puede producir un patrón desigual a escala agregada.

La segunda lección afecta a la evaluación ex ante.

Su importancia no disminuye por reconocer sus límites. Ocurre justamente lo contrario. Antes del lanzamiento es cuando mayor capacidad existe para cambiar el diseño, reducir finalidades, modificar datos, reforzar garantías o detener un proyecto.

Pero esa posición temporal implica trabajar con información incompleta.

La evaluación debería identificar con claridad qué aspectos están suficientemente comprobados y cuáles permanecen abiertos. Allí donde la incertidumbre pueda afectar de manera significativa a la conclusión, debería determinarse cómo se reducirá.

Esto puede exigir pruebas adicionales antes del lanzamiento, un piloto, un ámbito de aplicación limitado o un despliegue progresivo. La decisión dependerá de la gravedad de las consecuencias posibles, del nivel de incertidumbre y de la capacidad para revertir los efectos si las hipótesis iniciales resultan equivocadas.

La tercera lección afecta a la relación entre medidas y riesgo residual.

Una medida prevista no debería reducir automáticamente el riesgo. Debe existir una relación trazable entre el escenario identificado, la finalidad del control y la evidencia disponible sobre su funcionamiento.

La supervisión humana lo demuestra bien. No basta con que una persona figure en el diagrama del proceso. Es necesario analizar si comprende el sistema, dispone de información suficiente, tiene tiempo, competencia y autoridad para apartarse del resultado y puede detectar cuándo debe hacerlo.

El experimento descrito en la sentencia resulta interesante porque intenta precisamente pasar de la afirmación “existe decisión humana” a una pregunta más exigente: si la etiqueta algorítmica está influyendo realmente en esa decisión.

La cuarta lección es que la monitorización debería comenzar a diseñarse dentro de la evaluación inicial.

Cada riesgo importante debería llevar asociada, cuando sea posible, una pregunta que pueda ser observada durante la operación.

Si preocupa el sesgo de automatización, será necesario analizar la relación entre las recomendaciones y las decisiones posteriores. Si preocupa una diferencia entre grupos, habrá que definir indicadores capaces de detectarla de manera legítima y metodológicamente válida. Si la transparencia constituye un control, deberá comprobarse no solo que existe información, sino también que llega a la persona adecuada y en el momento en que puede necesitarla.

ISO/IEC 42005:2025 resulta especialmente útil en este punto porque estructura la evaluación de impactos de IA dentro del ciclo de vida. ISO/IEC 23894:2023, por su parte, proporciona orientación para integrar la gestión de riesgos relacionados con IA en las actividades y funciones organizativas.

La quinta lección afecta a la interpretación de la evidencia favorable.

Un resultado negativo en una prueba —no encontrar una diferencia o un efecto— puede aportar información valiosa. Pero su fuerza depende de la calidad de la prueba y de aquello que realmente era capaz de detectar.

Esta cautela resulta útil para interpretar el experimento sobre IOB. El tribunal considera que, con los datos disponibles, no existía base para afirmar que las etiquetas estuvieran influyendo en la decisión final. Esa conclusión debe respetarse. Lo que metodológicamente no procede es convertirla en una afirmación distinta y mucho más amplia según la cual el sistema queda definitivamente libre de cualquier riesgo de dependencia humana.

Lo mismo ocurre en sentido contrario con la señal relativa a la nacionalidad yemení. Una indicación de sesgo justifica investigación, monitorización y, cuando sea necesario, mitigación. No equivale por sí misma a demostrar discriminación.

Esta disciplina en el lenguaje es una parte importante del gobierno del riesgo. La evaluación debe evitar tanto exagerar la evidencia adversa como convertir la evidencia favorable en certeza.

La sexta lección se refiere a la ausencia de incidentes o reclamaciones.

No observar un daño puede significar que no se está produciendo, pero también puede significar que el sistema de observación no permite detectarlo. Algunos efectos son acumulativos, afectan a grupos y no a expedientes individuales o permanecen invisibles para las personas.

La diferencia entre ausencia de evidencia y evidencia de ausencia resulta especialmente importante en este contexto. Para que la falta de señales constituya evidencia útil debe existir una capacidad razonable para observar aquello que se pretende descartar.

El caso IOB proporciona un ejemplo especialmente interesante. Si una persona no sabe que el sistema ha intervenido en su expediente, la ausencia de una reclamación específica sobre el algoritmo tendría un valor limitado para demostrar que la transparencia funciona correctamente.

La séptima lección afecta a la reevaluación.

Reevaluar no debería ser una reacción reservada a un gran incidente. Puede resultar necesario cuando cambia el modelo, los datos, la finalidad, el contexto de utilización, la población afectada o la evidencia sobre la eficacia de las medidas.

Una resolución judicial puede ser también una fuente de nueva evidencia.

La sentencia de La Haya no demuestra que toda la representación previa de IOB fuera incorrecta. Sí pone de manifiesto una dimensión que debe incorporarse al conocimiento posterior del servicio: la transparencia institucional sobre la existencia del algoritmo no garantizaba, en ese caso, que una persona pudiera conocer suficientemente su intervención dentro de su propio procedimiento.

Una evaluación que permanece viva durante el ciclo de vida debería poder incorporar esa información y revisar, cuando proceda, sus controles y conclusiones.

Finalmente, el caso obliga a revisar el significado de la decisión de despliegue.

Autorizar un sistema no debería interpretarse necesariamente como una declaración definitiva de que todos sus riesgos se conocen y están controlados. Dependiendo de la incertidumbre existente, la autorización puede estar sujeta a condiciones, límites, indicadores o requisitos de revisión.

La evaluación previa puede entonces expresarse de manera más precisa: con la evidencia actualmente disponible, la organización considera razonable operar bajo determinadas condiciones y mientras continúen siendo válidos ciertos supuestos.

Este enfoque resulta más exigente que producir una puntuación residual y cerrar el expediente. Obliga a determinar qué hechos futuros podrían cambiar la decisión.

6. De varias evaluaciones a una base común de conocimiento y evidencia

La coexistencia de diferentes marcos de evaluación plantea también un problema organizativo.

Un mismo servicio puede requerir una EIPD, procesos de gestión de riesgos de IA, una evaluación de impacto sobre derechos fundamentales y análisis derivados de la normativa sectorial. Estos instrumentos tienen objetos diferentes y no deberían fusionarse hasta perder su identidad.

Pero tampoco resulta razonable que cada uno describa una realidad diferente.

Si la EIPD utiliza un alcance, el expediente de gestión de riesgos otro y la evaluación de derechos fundamentales un tercero, el problema no es solamente documental. La organización puede terminar gestionando representaciones incompatibles del mismo servicio.

La integración metodológica debería producir, por ello, algo diferente a un gran formulario común: una base compartida de conocimiento y evidencia.

Esa base debería permitir mantener una descripción coherente de las finalidades, los datos, el funcionamiento del sistema, los actores, los grupos afectados, las hipótesis de riesgo, los controles, la evidencia existente, las incertidumbres y los cambios producidos durante la operación.

Cada instrumento utilizará después la parte de esa base que necesite y aplicará sus criterios propios.

La reforma de 2026 del artículo 27 del Reglamento de IA resulta significativa en este sentido. La posibilidad de utilizar referencias cruzadas a las partes pertinentes de una EIPD cuando ya cubren obligaciones de la evaluación sobre derechos fundamentales apunta hacia una mayor reutilización y trazabilidad de la evidencia, sin eliminar la autonomía jurídica de los instrumentos.

Desde una perspectiva de gestión, este planteamiento permite además vincular mejor los controles con la evidencia.

La organización debería poder saber no solo qué riesgo fue identificado y qué medida se aprobó, sino cuándo se implantó, quién es responsable de ella, qué indicadores permiten observarla, qué evidencia existe sobre su eficacia y qué condiciones obligarían a revisarla.

La calidad de una evaluación deja así de depender principalmente del volumen del documento y pasa a depender de su capacidad para sostener decisiones y mantenerlas conectadas con la realidad.

Conclusiones

El caso IOB resulta especialmente útil porque no describe una situación en la que la Administración hubiera ignorado por completo los riesgos de su sistema. La sentencia recoge estudios sobre posibles sesgos, preocupaciones sobre mecanismos de retroalimentación, experimentación respecto de la influencia de las etiquetas y medidas de formación, recalibración y monitorización.

Precisamente por ello permite estudiar un problema más complejo.

Una organización puede disponer de análisis razonables, controles y evidencia sobre algunas dimensiones del riesgo y, aun así, descubrir durante el funcionamiento que otra parte del servicio no había sido suficientemente comprendida.

La señal relativa a la nacionalidad yemení muestra la importancia de diferenciar entre una indicación que debe investigarse y una discriminación demostrada. El análisis sobre las etiquetas muestra, en sentido inverso, la necesidad de distinguir entre no observar un efecto en una prueba concreta y demostrar que ese efecto nunca puede producirse. La sentencia sobre transparencia aporta una tercera clase de evidencia: un problema que no se encuentra necesariamente en el comportamiento interno del modelo, sino en la relación entre el procedimiento y la persona afectada.

La evaluación de impacto debe ser capaz de trabajar con esas diferencias.

Antes del despliegue necesita construir una representación suficientemente sólida para decidir. Esa representación debe identificar escenarios, valorar riesgos, estudiar alternativas, establecer controles y reconocer los límites del conocimiento disponible.

Durante el funcionamiento comienza otra fase. Las hipótesis pueden contrastarse con datos reales. Los controles pueden demostrar, o no, su eficacia. Pueden aparecer consecuencias que no se habían previsto o cambiar las condiciones sobre las que se construyó la decisión inicial.

La monitorización y la reevaluación mantienen conectados ambos momentos.

Desde esta perspectiva, una evaluación de impacto no debería entenderse como una certificación anticipada de que el riesgo ha quedado definitivamente controlado. Su función es organizar el conocimiento necesario para decidir responsablemente bajo incertidumbre y establecer cómo se revisará esa decisión cuando cambie la evidencia.

El caso muestra también por qué el objeto de la evaluación debe ser el servicio sociotécnico completo. Los datos, el modelo, la clasificación, la interfaz, las personas que utilizan el resultado, las consecuencias del procedimiento, la información facilitada y los mecanismos de recurso pertenecen a una misma realidad operacional.

Los cuatro marcos europeos examinados refuerzan esa visión desde perspectivas diferentes. El RGPD observa principalmente el tratamiento de datos y los riesgos para los derechos y libertades; el Reglamento de IA añade la gobernanza del sistema y de su utilización; la Carta sitúa los derechos fundamentales potencialmente afectados; y el Código de Visados conserva los criterios y garantías propios de la decisión administrativa concreta.

No es necesario convertir esos marcos en una única evaluación. Sí resulta necesario que todos ellos partan de una representación coherente del servicio y compartan evidencia cuando observan los mismos hechos.

La principal lección metodológica que puede extraerse del caso IOB reside, finalmente, en la relación entre representación, evidencia y revisión.

Toda evaluación construye una representación con el conocimiento disponible en un momento determinado. Esa representación puede ser rigurosa y suficiente para decidir sin llegar a agotar la realidad. Cuando el sistema entra en funcionamiento, la experiencia comienza a confirmar algunas hipótesis, cuestionar otras y revelar aspectos que antes no eran visibles.

Gobernar el riesgo consiste en mantener abierta esa relación.

La calidad de una evaluación no depende únicamente de lo bien que describa el riesgo antes de actuar, sino también de su capacidad para reconocer cuándo la realidad empieza a aportar evidencia que obliga a modificar la representación sobre la que se adoptó la decisión.

Referencias

Resolución objeto de análisis

Rechtbank Den Haag [Tribunal de Distrito de La Haya]. Sentencia de 29 de julio de 2026, asunto NL25.36357, ECLI:NL:RBDHA:2026:21628, publicada el 3 de agosto de 2026.

Documentación oficial relativa a IOB

Ministerio de Asuntos Exteriores de los Países Bajos. Information Supported Processing – Short-Stay (Schengen) Visa (KVV/IOB). Registro neerlandés de Algoritmos.

Ministerio de Asuntos Exteriores de los Países Bajos. Impact Assessment Mensenrechten en Algoritmes – Informatie Ondersteund Behandelen Schengenvisa (IAMA IOB), diciembre de 2025, complementada en julio de 2026.

Marco normativo europeo

Parlamento Europeo y Consejo. Reglamento (UE) 2016/679, General de Protección de Datos, especialmente arts. 5, 12–15, 22, 25, 35 y 36.

Grupo de Trabajo del Artículo 29 / Comité Europeo de Protección de Datos. Guidelines on Data Protection Impact Assessment (DPIA) and determining whether processing is “likely to result in a high risk”, WP248 rev.01.

Parlamento Europeo y Consejo. Reglamento (UE) 2024/1689 por el que se establecen normas armonizadas en materia de inteligencia artificial, especialmente arts. 6, 14, 26 y 27 y Anexo III.

Parlamento Europeo y Consejo. Reglamento (UE) 2026/1744, de 8 de julio de 2026, por el que se modifica, entre otros, el Reglamento (UE) 2024/1689.

Unión Europea. Carta de los Derechos Fundamentales de la Unión Europea, especialmente arts. 7, 8, 21, 47 y 51.

Parlamento Europeo y Consejo. Reglamento (CE) n.º 810/2009 por el que se establece un Código comunitario sobre visados, especialmente arts. 21 y 32.

Referencias metodológicas

ISO/IEC. ISO/IEC 42005:2025, Artificial intelligence (AI) — AI system impact assessment.

ISO/IEC. ISO/IEC 23894:2023, Information technology — Artificial intelligence — Guidance on risk management.

ISO. ISO 31000:2018, Risk management — Guidelines.

Autor y responsable editorial: Leocadio Marrero Trujillo.
El enfoque, la arquitectura, los criterios de análisis y las conclusiones de este artículo han sido definidos y validados por el autor. Durante su elaboración se han utilizado herramientas de inteligencia artificial generativa como apoyo para la estructuración, reformulación, edición y creación de determinados elementos gráficos.

El contenido ha sido sometido a revisión humana sustantiva, comprobación de fuentes y validación jurídica y técnica. El autor ha aprobado la versión definitiva y asume íntegramente la responsabilidad editorial sobre su contenido