Análisis jurídico completo para empresas y administraciones públicas. La guía oficial de la AESIA más el criterio de iusia para el asesoramiento práctico.
La precisión mide si el sistema produce outputs correctos en condiciones normales de operación. La solidez y la robustez miden si el sistema mantiene un comportamiento aceptable cuando las condiciones no son normales: cuando los datos de entrada tienen errores, cuando las condiciones han cambiado respecto al entrenamiento, o cuando alguien intenta deliberadamente engañar al sistema. El artículo 15 del AI Act exige los tres requisitos — precisión, solidez y ciberseguridad — de forma conjunta, porque un sistema que es preciso bajo condiciones normales pero que se colapsa ante cualquier perturbación no es suficientemente fiable para un sistema de alto riesgo.
La Guía 10 de la AESIA distingue tres dimensiones de la solidez y la robustez. La primera es la robustez frente a entradas inesperadas o erróneas. La segunda es la solidez frente al cambio gradual de las condiciones de operación (distributional shift). La tercera es la resistencia frente a intentos deliberados de manipulación (ataques adversariales). El art. 15.5 del AI Act se refiere explícitamente a la resistencia frente a intentos de manipulación por parte de terceros no autorizados.
Para los operadores de sistemas de alto riesgo, la robustez no es solo un requisito regulatorio — es una característica de negocio crítica. Un sistema de diagnóstico médico que produce resultados incorrectos cuando las imágenes tienen ruido técnico puede generar diagnósticos erróneos con consecuencias para la salud del paciente. Un sistema de scoring crediticio que es vulnerable a la manipulación puede ser explotado por clientes que modifican deliberadamente su perfil para obtener mejores puntuaciones sin una mejora real de su solvencia.
Los sistemas de alto riesgo operan en entornos reales donde los datos de entrada no siempre tienen la calidad y el formato que el sistema espera. Los formularios tienen campos vacíos, las imágenes tienen baja calidad, los textos tienen errores ortográficos, los sensores producen lecturas anómalas. Un sistema robusto debe gestionar estas situaciones de forma segura — producir un output de baja confianza y activar la supervisión humana — en lugar de producir un output incorrecto con alta confianza o colapsar.
La guía establece que las pruebas de robustez frente a entradas inesperadas deben ser parte del proceso de prueba y validación del sistema antes de su comercialización. Estas pruebas deben incluir: entradas con campos faltantes o inválidos, entradas en formatos no esperados, entradas con valores extremos o atípicos, y entradas que son intencionalmente ambiguas o contradictorias. El sistema debe demostrar que gestiona todas estas situaciones de forma segura.
El mecanismo de "graceful degradation" — la capacidad del sistema de degradar su comportamiento de forma segura cuando no puede producir un output fiable, en lugar de fallar de forma abrupta — es una de las características de robustez que la guía identifica como especialmente relevante para sistemas de alto riesgo. Un sistema que reconoce que no puede procesar una entrada determinada y lo comunica claramente al supervisor es más seguro que uno que produce un output con baja fiabilidad sin señalarlo.
El distributional shift es el cambio gradual en las características estadísticas de los datos de entrada del sistema en producción respecto a los datos de entrenamiento. Es uno de los riesgos más difíciles de gestionar porque ocurre de forma silenciosa — el sistema no "sabe" que los datos han cambiado, y puede continuar produciendo outputs con alta confianza aunque esos outputs sean cada vez menos fiables.
Los ejemplos de distributional shift son numerosos en la práctica. Un sistema de detección de fraude entrenado con datos de 2022 puede no detectar los patrones de fraude nuevos que han surgido en 2025. Un sistema de scoring crediticio entrenado durante el período pre-pandemia puede producir evaluaciones incorrectas cuando las condiciones macroeconómicas han cambiado significativamente. Un sistema de reconocimiento de emociones entrenado en vídeos de alta calidad puede degradar su rendimiento cuando se usa con las cámaras de menor calidad de los dispositivos móviles.
La guía recomienda diseñar sistemas de monitorización del distributional shift que detecten automáticamente cuando las características estadísticas de los datos de entrada en producción se alejan significativamente de las del conjunto de entrenamiento. Cuando se detecta un drift significativo, el sistema debe alertar al desplegador y, en su caso, activar el proceso de vigilancia poscomercialización del art. 72 para evaluar si el rendimiento del sistema se ha degradado de forma inaceptable.
Los ataques adversariales son modificaciones deliberadas y calculadas de los datos de entrada de un sistema de IA con el objetivo de alterar su comportamiento de forma deseada por el atacante. Son especialmente relevantes para sistemas biométricos, sistemas de detección de fraude y sistemas de toma de decisiones con consecuencias económicas, donde existe un incentivo claro para manipular el output del sistema.
La guía describe los principales tipos de ataques adversariales relevantes para sistemas de alto riesgo. Los ataques de evasión buscan modificar un input real para que el sistema lo clasifique de forma distinta a la correcta: por ejemplo, modificar mínimamente una imagen para que un sistema de reconocimiento facial no identifique a una persona o la identifique como otra persona diferente. Los ataques de envenenamiento buscan modificar los datos de entrenamiento para que el modelo aprenda un comportamiento incorrecto en situaciones específicas. Los ataques de extracción del modelo buscan reconstruir el modelo a partir de sus outputs, lo que puede revelar datos sensibles de entrenamiento o permitir diseñar ataques de evasión más efectivos.
El artículo 15.5 del AI Act establece que los sistemas de alto riesgo deben ser resistentes a los intentos de modificación de su uso o rendimiento por parte de terceros no autorizados. La guía traduce este requisito en un conjunto de medidas técnicas: validación robusta de los inputs para detectar modificaciones adversariales, mecanismos de detección de anomalías en los patrones de uso del sistema, y controles de acceso a la API que prevengan el abuso del sistema para realizar ataques de extracción del modelo.
El artículo 15 del AI Act exige que los sistemas de alto riesgo incluyan mecanismos de fall-back — procedimientos que permiten al sistema responder de forma segura cuando detecta que no puede funcionar correctamente. La guía detalla los requisitos de estos mecanismos de contingencia.
El primer nivel de fall-back es la indicación de incertidumbre: cuando el sistema detecta que no puede generar un output fiable — porque la entrada está fuera de la distribución de entrenamiento, porque ha detectado una posible manipulación adversarial, o porque el nivel de confianza del modelo está por debajo del umbral establecido — debe comunicarlo claramente al supervisor en lugar de presentar el output poco fiable como si fuera definitivo.
El segundo nivel de fall-back es la activación de la supervisión humana adicional: cuando el sistema detecta una situación de incertidumbre, debe activar automáticamente un proceso de revisión humana más exhaustivo. Esto puede implicar el enrutamiento del caso a un revisor con mayor nivel de competencia, la solicitud de información adicional al usuario o al desplegador, o la suspensión temporal del procesamiento hasta que se complete la revisión.
El tercer nivel de fall-back es la parada de emergencia del sistema: cuando el sistema detecta un problema grave que puede comprometer la seguridad o los derechos de las personas afectadas, debe poder detenerse completamente. Este mecanismo debe poder activarse tanto automáticamente por el sistema como manualmente por el supervisor humano, y su activación debe producir un estado seguro del sistema — no un estado de fallo que genere problemas adicionales.
La guía establece que las pruebas de solidez y robustez deben ser parte del proceso de validación del sistema antes de su comercialización, no una verificación posterior. El proveedor debe ejecutar pruebas específicas para cada una de las tres dimensiones de robustez: pruebas de entradas adversariales para verificar la robustez frente a datos erróneos o inesperados, pruebas de distributional shift para verificar el comportamiento del sistema cuando los datos de entrada se desvían gradualmente de los datos de entrenamiento, y pruebas de ataques adversariales básicos para verificar la resistencia del sistema frente a manipulaciones deliberadas.
Los resultados de estas pruebas deben documentarse en la documentación técnica del Anexo IV y, cuando sean relevantes para el uso correcto del sistema, comunicarse al desplegador en las instrucciones de uso del art. 13. Un sistema que es vulnerable a ciertos tipos de entradas adversariales pero no a otros puede ser comercializable si el proveedor comunica esas limitaciones claramente y el desplegador toma las medidas organizativas adecuadas para gestionar el riesgo residual.
La guía proporciona orientación detallada sobre las metodologías de prueba de robustez que los proveedores pueden usar para demostrar el cumplimiento del art. 15. Para las pruebas de robustez frente a entradas inesperadas, la guía recomienda el uso de conjuntos de datos de prueba específicamente diseñados para incluir casos difíciles: datos con ruido artificial, datos con valores faltantes sistemáticos, datos con distribuciones diferentes a las del entrenamiento, y datos que corresponden a casos límite donde la clasificación correcta es ambigua.
Para las pruebas de distributional shift, la guía recomienda el uso de técnicas de detección de drift que monitoricen continuamente las características estadísticas de los datos de entrada en producción. Las métricas más usadas incluyen la distancia de Kolmogorov-Smirnov para comparar distribuciones univariadas, la distancia de Wasserstein para distribuciones multivariadas, y el Population Stability Index (PSI) que es especialmente popular en el sector financiero para monitorizar la estabilidad de los modelos de scoring a lo largo del tiempo.
Para las pruebas de ataques adversariales, la guía recomienda usar herramientas de evaluación de robustez adversarial como IBM Adversarial Robustness Toolbox (ART) o Foolbox, que permiten ejecutar un amplio catálogo de ataques adversariales conocidos contra el sistema y medir su resistencia. Los resultados de estas pruebas deben documentarse en la documentación técnica del Anexo IV y comunicarse al desplegador en las instrucciones de uso cuando sean relevantes para el correcto uso del sistema.
La robustez no es una característica estática del sistema — evoluciona con el tiempo a medida que el sistema opera en producción y el entorno cambia. El plan de vigilancia poscomercialización del art. 72 debe incluir indicadores de robustez que permitan detectar degradaciones antes de que produzcan consecuencias. La guía recomienda dos enfoques complementarios para monitorizar la robustez en producción.
El primero es el monitoreo reactivo: el análisis de los incidentes y anomalías reportados por los desplegadores para identificar patrones que puedan indicar vulnerabilidades de robustez. Si varios desplegadores reportan que el sistema produce outputs anómalos ante determinados tipos de inputs, puede ser indicio de una vulnerabilidad de robustez que no fue detectada durante las pruebas previas a la comercialización.
El segundo es el monitoreo proactivo: la ejecución periódica de pruebas de robustez sobre el sistema en producción, usando los mismos conjuntos de prueba adversariales que se usaron antes de la comercialización, para detectar si la robustez del sistema ha cambiado. Cuando el sistema es re-entrenado con nuevos datos, las pruebas de robustez deben repetirse porque el re-entrenamiento puede introducir nuevas vulnerabilidades aunque mejore la precisión general del sistema.
La guía incluye varios casos hipotéticos que ilustran cómo los fallos de robustez pueden traducirse en consecuencias jurídicas para proveedores y desplegadores. Un sistema de scoring crediticio que falla ante solicitudes en lenguas distintas al castellano — porque fue entrenado principalmente con solicitudes en castellano — puede estar discriminando a solicitantes de habla catalana, vasca o gallega que presenten documentación en su lengua oficial. Este fallo de robustez (distribución de entrenamiento no representativa de las lenguas cooficiales) es simultáneamente un incumplimiento del art. 10 AI Act (datos no representativos) y una potencial discriminación por razón de lengua prohibida por la Constitución Española.
Un sistema de reconocimiento facial que falla con mayor frecuencia ante personas con piel oscura que ante personas con piel clara — porque fue entrenado con conjuntos de datos con sesgo de representación racial — puede estar generando una tasa de falsos positivos diferencial que equivale a discriminación algorítmica. Este fallo, documentado en varios estudios académicos sobre sistemas de reconocimiento facial comerciales, es exactamente el tipo de problema que los requisitos de precisión diferencial y representatividad de datos del AI Act pretenden prevenir.
La guía proporciona orientación detallada sobre las metodologías de prueba de robustez que los proveedores pueden usar para demostrar el cumplimiento del art. 15. Para las pruebas de robustez frente a entradas inesperadas, la guía recomienda el uso de conjuntos de datos de prueba específicamente diseñados para incluir casos difíciles: datos con ruido artificial, datos con valores faltantes sistemáticos, datos con distribuciones diferentes a las del entrenamiento, y datos que corresponden a casos límite donde la clasificación correcta es ambigua.
Para las pruebas de distributional shift, la guía recomienda el uso de técnicas de detección de drift que monitoricen continuamente las características estadísticas de los datos de entrada en producción. Las métricas más usadas incluyen la distancia de Kolmogorov-Smirnov para comparar distribuciones univariadas, la distancia de Wasserstein para distribuciones multivariadas, y el Population Stability Index (PSI) que es especialmente popular en el sector financiero para monitorizar la estabilidad de los modelos de scoring a lo largo del tiempo.
Para las pruebas de ataques adversariales, la guía recomienda usar herramientas de evaluación de robustez adversarial como IBM Adversarial Robustness Toolbox (ART) o Foolbox, que permiten ejecutar un amplio catálogo de ataques adversariales conocidos contra el sistema y medir su resistencia. Los resultados de estas pruebas deben documentarse en la documentación técnica del Anexo IV y comunicarse al desplegador en las instrucciones de uso cuando sean relevantes para el correcto uso del sistema.
La robustez no es una característica estática del sistema — evoluciona con el tiempo a medida que el sistema opera en producción y el entorno cambia. El plan de vigilancia poscomercialización del art. 72 debe incluir indicadores de robustez que permitan detectar degradaciones antes de que produzcan consecuencias. La guía recomienda dos enfoques complementarios para monitorizar la robustez en producción.
El primero es el monitoreo reactivo: el análisis de los incidentes y anomalías reportados por los desplegadores para identificar patrones que puedan indicar vulnerabilidades de robustez. Si varios desplegadores reportan que el sistema produce outputs anómalos ante determinados tipos de inputs, puede ser indicio de una vulnerabilidad de robustez que no fue detectada durante las pruebas previas a la comercialización.
El segundo es el monitoreo proactivo: la ejecución periódica de pruebas de robustez sobre el sistema en producción, usando los mismos conjuntos de prueba adversariales que se usaron antes de la comercialización, para detectar si la robustez del sistema ha cambiado. Cuando el sistema es re-entrenado con nuevos datos, las pruebas de robustez deben repetirse porque el re-entrenamiento puede introducir nuevas vulnerabilidades aunque mejore la precisión general del sistema.
La guía incluye varios casos hipotéticos que ilustran cómo los fallos de robustez pueden traducirse en consecuencias jurídicas para proveedores y desplegadores. Un sistema de scoring crediticio que falla ante solicitudes en lenguas distintas al castellano — porque fue entrenado principalmente con solicitudes en castellano — puede estar discriminando a solicitantes de habla catalana, vasca o gallega que presenten documentación en su lengua oficial. Este fallo de robustez (distribución de entrenamiento no representativa de las lenguas cooficiales) es simultáneamente un incumplimiento del art. 10 AI Act (datos no representativos) y una potencial discriminación por razón de lengua prohibida por la Constitución Española.
Un sistema de reconocimiento facial que falla con mayor frecuencia ante personas con piel oscura que ante personas con piel clara — porque fue entrenado con conjuntos de datos con sesgo de representación racial — puede estar generando una tasa de falsos positivos diferencial que equivale a discriminación algorítmica. Este fallo, documentado en varios estudios académicos sobre sistemas de reconocimiento facial comerciales, es exactamente el tipo de problema que los requisitos de precisión diferencial y representatividad de datos del AI Act pretenden prevenir.
Más recursos: calendario del AI Act tras el Ómnibus Digital · análisis del AI Act en 2026 · servicios para administraciones públicas (LexQuark).
Newsletter gratuita · Empresas y administraciones públicas · En español