El laberinto del Artículo 6: ¿Cuándo es realmente 'de alto riesgo' su sistema de IA?

La Comisión Europea tiene una curiosa forma de simplificar las cosas: publicando guías que requieren guías adicionales para ser entendidas. Con el AI Act ya en vigor desde el 1 de agosto de 2024, el sector tecnológico y los departamentos de compliance se encuentran ante el gran dilema existencial de la década: ¿es mi sistema de Inteligencia Artificial de 'alto riesgo'? La respuesta no es baladí, pues de ella depende que su empresa se enfrente a un régimen de obligaciones draconiano o a un plácido paseo por el parque regulatorio. Las recientes directrices de la Oficina de IA (AI Office) intentan arrojar luz sobre el Artículo 6 del Reglamento, pero lo que han hecho es construir un laberinto de excepciones que solo los más audaces —o los mejor asesorados— sabrán navegar.

El Artículo 6 y la arquitectura del riesgo: ¿Anexo I o Anexo III?

Para entender dónde estamos, hay que entender que el AI Act no clasifica la IA por lo que 'es', sino por lo que 'hace' y 'dónde' lo hace. El Artículo 6 establece dos vías principales para que un sistema sea etiquetado como de alto riesgo. La primera vía, recogida en el Artículo 6(1), es la más directa: si su IA es un componente de seguridad de un producto ya regulado por la legislación de armonización de la Unión (como juguetes, ascensores o dispositivos médicos listados en el Anexo I) y requiere una evaluación de conformidad por terceros, felicidades, ya está usted en el club del alto riesgo.

La segunda vía, el Artículo 6(2), es la que quita el sueño a las empresas de servicios. Aquí entran los sistemas que operan en las áreas críticas enumeradas en el Anexo III. Hablamos de biometría, gestión de infraestructuras críticas, educación, empleo, acceso a servicios públicos y privados esenciales (como el crédito), y administración de justicia. Si su algoritmo decide quién recibe una hipoteca o quién es preseleccionado para una entrevista de trabajo, el Reglamento le señala con el dedo. Sin embargo, la Comisión ha introducido un matiz que es, a la vez, una bendición y una trampa: el filtro del Artículo 6(3).

El 'escape hatch' del Artículo 6(3): La excepción que confirma la regla

Aquí es donde la ironía regulatoria alcanza su cénit. El Artículo 6(3) permite que un sistema de IA, a pesar de estar incluido en las categorías del Anexo III, no sea considerado de alto riesgo si no presenta un riesgo significativo de daño para la salud, la seguridad o los derechos fundamentales. Pero no basta con tener buena fe; hay que cumplir una de las cuatro condiciones tasadas que la Comisión ha intentado aclarar en sus directrices. Estas condiciones son el 'santo grial' para cualquier desarrollador que quiera evitar los costes de cumplimiento del Título III, Capítulo 2 del Reglamento.

La primera condición es que el sistema realice una 'tarea procedimental estrecha'. Esto no significa que la tarea sea sencilla, sino que su impacto en el resultado final sea limitado. Por ejemplo, una IA que solo clasifica documentos por formato de archivo en un proceso de selección de personal, sin analizar el contenido del CV, podría acogerse a esta excepción. La segunda condición se refiere a la mejora o optimización de una actividad humana previamente realizada. Aquí la clave es que la IA no sustituya el juicio humano, sino que lo haga más eficiente en aspectos puramente logísticos o de formato.

La tercera condición es quizás la más ambigua: el uso de la IA para detectar patrones de toma de decisiones o anomalías sin reemplazar ni influir en la evaluación humana previa. Y la cuarta, la realización de tareas preparatorias para una evaluación posterior. Si usted está pensando que estas definiciones son lo suficientemente elásticas como para que quepa un elefante, no es el único. Pero cuidado: la Comisión advierte que si la IA realiza 'perfilado' (profiling) de personas físicas, tal como se define en el Artículo 4(4) del GDPR, la excepción del Artículo 6(3) se desvanece instantáneamente. Si hay perfilado, hay alto riesgo. Punto.

La carga de la prueba: El Artículo 6(4) y la notificación obligatoria

Supongamos que su equipo legal está convencido de que su sistema de IA para evaluar el rendimiento de los empleados (una categoría del Anexo III, punto 5) es tan inofensivo que entra en la excepción del Artículo 6(3). ¿Puede simplemente seguir adelante y olvidarse del asunto? En absoluto. El Artículo 6(4) impone una obligación de documentación y, en muchos casos, de notificación que es pura burocracia preventiva.

Los proveedores que decidan acogerse a la excepción deben documentar su evaluación antes de comercializar el sistema o ponerlo en servicio. Esta documentación debe ser exhaustiva y estar a disposición de las autoridades nacionales competentes. Pero hay más: si usted es un proveedor que suministra IA a entidades públicas o a grandes empresas, es muy probable que deba registrar su sistema y su justificación de 'no alto riesgo' en la base de datos de la UE. Es, esencialmente, una confesión firmada. Si la autoridad de vigilancia del mercado decide un año después que su interpretación del Artículo 6(3) fue demasiado optimista, la documentación que usted mismo preparó será la prueba principal en su contra.

Implicaciones operativas: Del diseño a la auditoría

Para un CISO o un Director de Compliance, estas directrices significan que el inventario de activos de IA ya no puede ser una simple lista de Excel. Cada sistema debe ser mapeado contra los casos de uso del Anexo III y, si se pretende evitar la etiqueta de alto riesgo, debe someterse a un test de estrés legal basado en los criterios de la Comisión. Esto implica cambios en el ciclo de vida de desarrollo de software (SDLC). Ya no basta con que el modelo sea preciso; ahora debe ser 'explicable' incluso para decidir que no es peligroso.

Un punto crítico que a menudo se pasa por alto es la interacción con otras normativas. Para las entidades financieras, por ejemplo, la clasificación de una IA como de alto riesgo bajo el AI Act se solapa con las obligaciones de resiliencia operativa de DORA (Digital Operational Resilience Act). Si su IA de detección de fraude en pagos (Anexo III, punto 5.b) es considerada de alto riesgo, los requisitos de gobernanza de datos del Artículo 10 del AI Act —que exige datos de entrenamiento libres de sesgos y representativos— se vuelven obligatorios. Esto no es solo compliance; es gestión de datos a un nivel de granularidad que muchas empresas aún no han alcanzado.

El coste de equivocarse: El Artículo 99 y las multas de infarto

Hablemos de dinero, que es lo que suele mover las voluntades en las juntas directivas. El régimen sancionador del AI Act es, sencillamente, aterrador. Según el Artículo 99, el incumplimiento de las obligaciones relativas a los sistemas de IA de alto riesgo puede acarrear multas de hasta 15 millones de euros o el 3% del volumen de negocios total anual mundial del ejercicio anterior, si esta cifra es superior. Pero si usted intenta engañar a la autoridad diciendo que su sistema no es de alto riesgo cuando claramente lo es, las sanciones por proporcionar información engañosa pueden llegar a los 7,5 millones de euros.

La ironía aquí es que el coste de implementar los controles de un sistema de alto riesgo (registro de eventos, transparencia, supervisión humana, ciberseguridad según el Artículo 15) puede ser menor que el riesgo reputacional y financiero de una sanción. El regulador europeo ha diseñado un sistema donde la prudencia es la opción más barata a largo plazo. No se trata solo de evitar la multa, sino de evitar el cese de la actividad: las autoridades tienen el poder de ordenar la retirada del sistema del mercado, lo que para una startup de IA o una fintech podría significar el fin del trayecto.

Hoja de ruta para la clasificación: Pasos concretos

1. Inventario técnico y funcional: Identifique no solo qué hace el algoritmo, sino en qué proceso de negocio se inserta. ¿Toca alguna fibra del Anexo III?
2. Análisis de la excepción 6(3): Si está en el Anexo III, ¿realiza una tarea puramente preparatoria? ¿Hay perfilado de personas? Si la respuesta a lo segundo es sí, deje de buscar excepciones.
3. Documentación técnica proactiva: No espere a que la autoridad pregunte. Elabore el dossier de justificación siguiendo los estándares de las directrices de la Comisión. Incluya métricas de impacto y descripción de la arquitectura.
4. Revisión de terceros: Si su IA entra por la vía del Artículo 6(1) (seguridad de productos), contacte ya con su Organismo Notificado. La lista de espera para evaluaciones de conformidad va a ser legendaria.
5. Integración con el Marco de Gestión de Riesgos: Alinee su clasificación con el NIST CSF 2.0 (especialmente la función GV.RM) y con sus políticas de privacidad bajo GDPR. La coherencia entre departamentos es su mejor defensa.

Conclusión: La claridad es un objetivo móvil

Las directrices de la Comisión son un intento loable de dar seguridad jurídica, pero en la práctica han trasladado la responsabilidad del juicio al eslabón más débil: la empresa. El mensaje entre líneas es claro: 'Si cree que no es de alto riesgo, demuéstrelo, pero si se equivoca, las consecuencias serán suyas'. En este escenario, la figura del CISO y del Responsable de IA emerge no solo como un guardián técnico, sino como un estratega legal que debe decidir cuánta ambigüedad puede permitirse la organización.

El AI Act no es una norma de 'marcar casillas'. Es un cambio de paradigma en cómo entendemos la responsabilidad del software. A medida que nos acercamos a agosto de 2026, cuando la mayoría de estas obligaciones sean plenamente aplicables para los sistemas del Anexo III, la ventana para la experimentación sin supervisión se cierra. La pregunta ya no es si la IA es inteligente, sino si es lo suficientemente segura como para que el regulador le permita seguir funcionando.