Qué significa ‘riesgo alto’ en el AI Act: cómo decide la ley si tu sistema de IA es un problema serio

El AI Act no clasifica sistemas por lo sofisticados que son, sino por dónde se usan y qué pueden hacerle a una persona: esa distinción cambia todo el análisis de cumplimiento.

El error de partida: pensar que ‘riesgo alto’ es una valoración subjetiva

Cuando un directivo escucha “riesgo alto” tiende a hacer una lectura intuitiva: mi sistema no parece peligroso, luego no aplica. Esa lectura es incorrecta. El AI Act define la categoría con criterios objetivos distribuidos en el artículo 6 y los Anexos I y III del Reglamento. No hay margen para la intuición: o tu sistema encaja en esas listas, o no encaja.

El artículo 6 establece dos vías de entrada al perímetro de riesgo alto. La primera: un sistema de IA que sea componente de seguridad de un producto ya regulado por la legislación europea listada en el Anexo I (maquinaria, equipos médicos, vehículos, ascensores, entre otros) y que esté sujeto a evaluación de conformidad de terceros. La segunda, y la que afecta a la mayoría de las empresas de servicios: los sistemas que caen directamente en alguna de las ocho categorías del Anexo III. Esas categorías son las que conviene memorizar.

Las ocho categorías del Anexo III: aquí está el perímetro real

El Anexo III enumera los ámbitos en los que un sistema de IA se presume de riesgo alto por definición:

1. Infraestructuras críticas (gestión de redes de energía, agua, transporte).
2. Educación y formación profesional: sistemas que determinan el acceso o la evaluación de estudiantes.
3. Empleo y gestión de trabajadores: selección de personal, evaluación del rendimiento, decisiones sobre promoción o despido.
4. Acceso a servicios privados esenciales y públicos: scoring crediticio, evaluación de solicitudes de préstamo, seguros, servicios sociales.
5. Aplicación de la ley: análisis de riesgos individuales, evaluación de pruebas, predicción de comportamientos delictivos.
6. Migración, asilo y control fronterizo.
7. Administración de justicia y procesos democráticos.
8. Biometría: identificación remota, categorización biométrica, reconocimiento de emociones en determinados contextos.

Tres de estas categorías concentran la mayoría de los casos empresariales en España: empleo (número 3), scoring y acceso a servicios financieros (número 4) y biometría (número 8). Si usas IA para filtrar currículums, asignar turnos basándote en rendimiento calculado automáticamente, puntuar la solvencia de un cliente o identificar personas en vídeo, estás en el perímetro. Sin excepciones por tamaño de empresa.

El malentendido del proveedor: “yo solo pongo la infraestructura”

Uno de los argumentos más frecuentes para justificar la inacción —visible en el tercio de grandes empresas españolas que aún no ha tomado ninguna medida ante el AI Act— es trasladar la responsabilidad al proveedor del modelo. “Usamos el modelo de un tercero, el cumplimiento es su problema.”

El AI Act distingue dos roles con obligaciones distintas: proveedor (quien desarrolla o pone en el mercado el sistema) y deployer (quien lo despliega en un contexto concreto). Un deployer no queda eximido por el hecho de usar un modelo de un tercero. Sus obligaciones incluyen, entre otras: usar el sistema conforme a las instrucciones del proveedor, realizar una evaluación de impacto sobre los derechos fundamentales cuando el sistema afecta al público, mantener registros de uso y garantizar supervisión humana.

Si tu empresa toma un modelo de lenguaje de un proveedor y lo integra en un flujo de selección de personal, el proveedor tiene sus obligaciones y tú tienes las tuyas como deployer. No son excluyentes. El análisis de qué tienen que hacer ya las empresas que usan IA en RRHH, scoring o atención al cliente detalla exactamente qué corresponde a cada rol.

El malentendido del modelo propio: “solo aplica si desarrollamos nosotros”

El argumento inverso también circula: “solo somos proveedores si entrenamos nuestros propios modelos, y nosotros solo usamos APIs.” Falso. El Reglamento considera proveedor a quien pone en el mercado un sistema de IA con su nombre o marca, independientemente de si el modelo subyacente lo ha entrenado un tercero. Una empresa que construye una aplicación de análisis de riesgo crediticio usando la API de OpenAI y la comercializa es, a efectos del AI Act, proveedora de ese sistema.

La distinción relevante no es dónde está el modelo, sino quién controla el propósito del sistema y quién lo pone en manos del usuario final.

Lo que convierte un sistema en riesgo alto: las dos condiciones simultáneas

Para los sistemas del Anexo III —los más habituales en entornos corporativos— la clasificación requiere que se cumplan dos condiciones al mismo tiempo: el sistema opera en uno de los ámbitos listados y sus resultados influyen materialmente en decisiones que afectan a derechos o intereses significativos de personas físicas.

El segundo criterio es el que más se subestima. Un sistema de recomendación interno que ayuda a un equipo de RRHH a ordenar candidatos, pero donde la decisión final la toma siempre un humano con criterio propio, puede estar o no en el perímetro dependiendo de cuánto peso real tiene la recomendación. Si el sistema filtra antes de que el humano vea nada, la supervisión humana es nominal y el sistema probablemente sea de riesgo alto. Si el humano recibe todos los candidatos y el sistema solo añade una puntuación orientativa que puede ignorar, el análisis cambia.

Esto es relevante porque el diseño del flujo de trabajo —no solo el modelo— determina la clasificación. Y porque el Reglamento de IA exige revisar el uso que ya hace tu empresa de IA, no solo los sistemas que planeas desarrollar.

La excepción que el Reglamento sí contempla: el artículo 6.3

El AI Act incluye una válvula de escape explícita para el Anexo III. Un proveedor puede argumentar que su sistema, aunque opera en un ámbito listado, no representa riesgo alto porque no influye materialmente en decisiones sobre personas. Para acogerse a esta excepción, debe documentarlo y registrarlo antes de poner el sistema en el mercado. No es una declaración informal: es un procedimiento con trazabilidad.

Este matiz importa porque los vendors que prometen “compliance de serie” raramente documentan este análisis por ti. La carga de justificar que tu sistema no es de riesgo alto, cuando opera en un ámbito del Anexo III, recae sobre quien lo pone en el mercado o lo despliega.

Mi lectura

La clasificación de riesgo alto en el AI Act es técnica y relativamente determinista: tomas el Anexo III, miras si tu caso de uso encaja, y analizas si el sistema influye materialmente en decisiones sobre personas. No requiere un jurista para el primer filtro. Requiere que alguien en la organización se haya leído los anexos, que es exactamente lo que el 31,7% de grandes empresas españolas todavía no ha hecho.

Los dos malentendidos que más retrasan el cumplimiento —“el proveedor es el responsable” y “solo aplica si entrenamos modelos propios”— son cómodos porque desplazan la carga hacia fuera. El Reglamento los desmonta en sus primeros artículos. Cuanto más tarde en hacerse esa lectura una organización, menos tiempo tendrá para rediseñar los flujos de trabajo donde la supervisión humana es hoy solo cosmética.

$ qué es riesgo alto en el AI Act
· Criterio: ámbito de uso (Anexo III) + influencia material en decisiones sobre personas
· Roles: proveedor y deployer tienen obligaciones separadas y acumulables
· Excepción: art. 6.3 permite argumentar que un sistema del Anexo III no es de riesgo alto, pero requiere documentación formal
· Fuente: Reglamento (UE) 2024/1689, artículo 6 y Anexos I y III
· Estado: obligaciones Anexo III aplicables desde agosto 2026 en la mayoría de casos