EU AI Act Alto Riesgo: Lo que Necesitas Construir Técnicamente

El EU AI Act es plenamente aplicable a los sistemas de IA de alto riesgo desde agosto de 2026. Para la mayoría de organizaciones europeas que usan IA en RRHH, scoring crediticio, control de acceso o infraestructuras críticas, el plazo de cumplimiento ya no es teórico.

El comentario legal es extenso. La orientación técnica es escasa. Esta es la parte de ingeniería.

Qué Hace que un Sistema de IA Sea “Alto Riesgo”

El Anexo III de la Ley de IA define ocho categorías de sistemas de IA de alto riesgo. Las que probablemente afecten a más empresas del mercado medio europeo:

• Empleo: IA usada para reclutamiento, selección, promoción, asignación de tareas, supervisión o decisiones de despido
• Acceso a servicios esenciales: scoring crediticio, evaluación de riesgo de seguros
• Identificación biométrica: sistemas que identifican individuos a partir de datos biométricos
• Infraestructuras críticas: IA gestionando redes de energía, agua o transporte
• Educación: IA que determina el acceso a instituciones educativas o evalúa a estudiantes
• Aplicación de la ley: IA usada por autoridades públicas para evaluaciones de riesgo

Si tu empresa usa un ATS con IA, scoring crediticio automatizado, o cualquier sistema de IA que informe decisiones que afecten a individuos en estas áreas — estás en ámbito.

Los Seis Requisitos Técnicos

La Ley define obligaciones técnicas específicas. Lo que significa cada una en la práctica:

1. Sistema de gestión de riesgos (Art. 9) Un proceso documentado y continuo para identificar, analizar y mitigar riesgos a lo largo del ciclo de vida del sistema. No es una evaluación única. Necesitas un registro de riesgos que se revise cuando el sistema se actualice, cuando se descubran nuevos modos de fallo, o cuando el contexto operativo cambie.

2. Gobernanza de datos (Art. 10) Los datos de entrenamiento deben ser relevantes, representativos, libres de errores y completos. Para la mayoría de organizaciones, esto significa auditar los datos de entrenamiento para detectar sesgos demográficos, documentar fuentes de datos y pasos de preprocesamiento, y mantener registros de validación de calidad de datos.

3. Documentación técnica (Art. 11 + Anexo IV) Un expediente técnico de 13 puntos que incluye: descripción del sistema y propósito previsto, elecciones de diseño y supuestos, metodología de entrenamiento, métricas de rendimiento en poblaciones relevantes, limitaciones conocidas y plan de seguimiento post-mercado. Esta documentación debe estar disponible para las autoridades supervisoras nacionales previa solicitud.

4. Registro y conservación de registros (Art. 12) El sistema debe generar automáticamente registros suficientes para rastrear eventos durante toda la vida del sistema. Mínimo: datos de entrada en el momento de inferencia, salidas, eventos de supervisión humana, fallos del sistema. Período de retención: al menos seis meses, o más si lo requiere la regulación sectorial específica.

5. Transparencia e información (Art. 13) Los sistemas de IA de alto riesgo deben ser interpretables por los desplegadores y, cuando sea relevante, por los individuos afectados. No obliga a la explicabilidad total de cada predicción — pero sí requiere la capacidad de explicar, en términos comprensibles para humanos, los principales factores que afectan a una decisión concreta.

6. Supervisión humana (Art. 14) Los sistemas de IA de alto riesgo deben estar diseñados para permitir una supervisión humana efectiva. En la práctica: un mecanismo para pausar o anular la IA, rutas claras de escalada para casos extremos, y formación para los operadores humanos sobre las limitaciones del sistema.

Las Brechas de Arquitectura Más Comunes

Basándonos en análisis de brechas realizados, los fallos técnicos más frecuentes son:

Sin logging de inferencia. El modelo produce salidas pero no se persisten con el contexto de entrada. Sin logs, no se puede investigar una reclamación, demostrar cumplimiento ni identificar deriva del modelo.

La documentación de datos de entrenamiento no existe. El modelo se entrenó con “datos del CRM” sin registro del rango de fechas, pasos de preprocesamiento o criterios de exclusión. Reconstruir esto es costoso y a veces imposible.

Sin mecanismo de anulación humana. La salida de la IA alimenta directamente un proceso downstream sin ningún punto donde un humano pueda intervenir. Esto es no conforme y también operativamente frágil.

Las métricas de rendimiento son solo a nivel de población. Se conoce la precisión global pero no si es significativamente peor para grupos demográficos específicos. El Anexo IV exige rendimiento en subpoblaciones relevantes.

Hoja de Ruta Práctica de Cumplimiento

Para organizaciones que parten de un despliegue típico de IA enterprise (API en la nube, documentación mínima):

Semanas 1-4: Inventario y definición del ámbito Listar todos los sistemas de IA en uso. Para cada uno, determinar si cae en categorías de alto riesgo. Priorizar los usados en RRHH, decisiones financieras o evaluaciones que afecten a clientes.

Semanas 5-8: Análisis de brechas por sistema Para cada sistema en ámbito, mapear el estado actual contra los seis requisitos técnicos. Documentar qué existe, qué falta, qué hay que construir.

Semanas 9-16: Remediación técnica Implementar logging, construir o documentar el proceso de gestión de riesgos, preparar la documentación técnica. La infraestructura de logging sola — capturar entradas, salidas y metadatos en el momento de inferencia, con una ventana de retención de 6 meses — es típicamente 2-4 semanas de trabajo de ingeniería para un sistema existente.

Continuo: Monitorización y revisión Monitorización post-despliegue para deriva del modelo, degradación del rendimiento y nuevos modos de fallo. Desencadenar una revisión cuando el sistema o su contexto cambie materialmente.