EU AI Act: qué es, a quién obliga y qué significa para tu HR-tech

La mayoría de las empresas que están dentro del ámbito del AI Act no lo saben todavía. Casi todo lo que se ha escrito sobre la norma habla de modelos fundacionales y de riesgos existenciales, y muy poco del caso concreto que sí está en el texto: un software que filtra currículos. Esta guía va de eso.

Qué es el AI Act y a quién obliga

El AI Act es el Reglamento (UE) 2024/1689, adoptado en junio de 2024. Es el primer marco horizontal de inteligencia artificial del mundo: no regula un sector concreto, sino los sistemas de IA en función del riesgo que su uso genera para la salud, la seguridad y los derechos fundamentales de las personas. Al ser un reglamento, se aplica directamente en todos los Estados miembros sin necesidad de transposición.

La norma distingue dos papeles principales, definidos en el artículo 3, y las obligaciones cambian mucho según cuál te toque:

• Proveedor: quien desarrolla un sistema de IA y lo introduce en el mercado o lo pone en servicio bajo su propio nombre o marca. Soporta el grueso de las obligaciones cuando el sistema es de alto riesgo: gestión de riesgos, gobernanza de datos, documentación técnica, registros, supervisión humana y evaluación de conformidad.
• Responsable del despliegue (deployer): quien utiliza el sistema bajo su autoridad en su actividad profesional. Sus obligaciones son menos pesadas pero reales: usar el sistema conforme a las instrucciones, garantizar supervisión humana e informar a las personas afectadas.

El reglamento tiene alcance extraterritorial. Obliga también a empresas de fuera de la Unión Europea cuando introducen un sistema en el mercado de la UE, lo ponen en servicio aquí o cuando sus resultados se utilizan dentro de la Unión. Estar constituido en Delaware o en Londres no te saca del ámbito si tus clientes seleccionan personal en Europa.

Hay además una obligación que aplica a todos, proveedores y responsables del despliegue, sea cual sea el nivel de riesgo: el artículo 4 exige garantizar un nivel suficiente de alfabetización en IA del personal que se ocupa del funcionamiento y del uso de estos sistemas. Está en vigor desde el 2 de febrero de 2025.

Los cuatro niveles de riesgo

El AI Act no clasifica tecnologías, clasifica usos. El mismo modelo de lenguaje puede quedar en riesgo mínimo dentro de un asistente interno de documentación y en alto riesgo dentro de un producto que puntúa candidatos. La pirámide tiene cuatro niveles:

Un mismo producto puede tener piezas en niveles distintos. Un ATS con un chatbot de atención al candidato, un motor de matching y un generador de descripciones de puesto está tocando tres casillas de esa tabla a la vez. La clasificación se hace por sistema y por finalidad prevista, no por empresa.

Por qué la HR-tech está en el punto de mira

El empleo no es una lectura extensiva del reglamento: es una entrada expresa. El Anexo III, punto 4, incluye entre los sistemas de alto riesgo los destinados a la contratación o selección de personas físicas, en particular para publicar anuncios de empleo dirigidos, analizar y filtrar solicitudes y evaluar a los candidatos. El mismo punto cubre los sistemas destinados a tomar decisiones sobre promoción o terminación de relaciones contractuales, a asignar tareas y a supervisar y evaluar el rendimiento y el comportamiento de las personas.

Traducido a funcionalidades de producto, eso alcanza a cosas que hoy son estándar en cualquier HR-tech:

• Screening automático de currículos que descarta o marca solicitudes antes de que las vea un humano.
• Motores de matching que ordenan una lista de candidatos por encaje con la vacante.
• Copilotos de entrevista que transcriben, resumen y puntúan a la persona entrevistada.
• Publicación de anuncios dirigidos a segmentos concretos de población.
• Herramientas de evaluación continua del desempeño o de asignación de tareas ya dentro de la empresa.

La consecuencia es incómoda pero clara: si vendes software de selección con IA, la posición por defecto es que estás en el Anexo III. La pregunta relevante no es si te aplica, sino si puedes justificar documentalmente que un sistema concreto tuyo queda fuera.

La excepción del artículo 6.3 y por qué es más estrecha de lo que parece

El artículo 6.3 permite que un sistema listado en el Anexo III no se considere de alto riesgo cuando no plantea un riesgo importante de daño para la salud, la seguridad o los derechos fundamentales, y en particular cuando no influye sustancialmente en el resultado de la toma de decisiones. El propio artículo enumera los supuestos:

• El sistema realiza una tarea de procedimiento limitada.
• El sistema mejora el resultado de una actividad humana previamente realizada.
• El sistema detecta patrones de decisión o desviaciones respecto de patrones previos, sin sustituir ni influir en la valoración humana ya realizada.
• El sistema realiza una tarea preparatoria de una evaluación pertinente.

Hay dos motivos por los que esta puerta es más estrecha de lo que suele asumirse. El primero es el corte del profiling: la excepción no aplica en ningún caso si el sistema realiza elaboración de perfiles de personas físicas. Buena parte de los motores de matching construyen exactamente eso, un perfil inferido del candidato a partir de sus datos, aunque internamente lo llaméis scoring o encaje.

El segundo es el argumento del ranking. Es habitual defender que un motor de matching solo ordena y que la decisión sigue siendo del reclutador. En la práctica, si el sistema devuelve 400 candidatos ordenados y el reclutador abre los diez primeros, el orden ha decidido. La influencia sustancial en el resultado se mide por el efecto real sobre la decisión, no por dónde esté el botón final.

Y aunque concluyas que la excepción aplica, no es una autoexención silenciosa: el proveedor debe documentar su evaluación antes de introducir el sistema en el mercado. El artículo 6.3 no elimina el trabajo de análisis, lo convierte en un documento que tendrás que enseñar.

Proveedor o responsable del despliegue: el artículo 25

Muchos equipos técnicos asumen que, como el modelo es de otro, las obligaciones también. El artículo 25 dice otra cosa. Un responsable del despliegue, distribuidor o importador pasa a considerarse proveedor de un sistema de alto riesgo, con todas las obligaciones que eso arrastra, en tres supuestos:

• Pone su nombre comercial o su marca en un sistema de alto riesgo ya introducido en el mercado.
• Realiza una modificación sustancial de un sistema de alto riesgo que ya está en el mercado o en servicio.
• Modifica la finalidad prevista de un sistema de IA, incluido uno de uso general, de modo que pase a ser de alto riesgo.

El caso típico en HR-tech es el de "nosotros solo llamamos a la API de OpenAI". Si envuelves ese modelo en tu producto, lo vendes bajo tu marca y le das una finalidad de cribado o evaluación de candidatos, estás en el primer y en el tercer supuesto a la vez. Las obligaciones más pesadas viajan entonces contigo y no con el laboratorio que entrenó el modelo, y necesitarás de él información técnica suficiente para poder cumplirlas.

El calendario real, incluido el diferimiento del Digital Omnibus

El AI Act no entró en vigor de golpe: cada bloque de obligaciones tiene su propia fecha, y en 2026 ese calendario se movió. Este es el estado actual:

El acuerdo provisional del Digital Omnibus, de 7 de mayo de 2026, introdujo las primeras enmiendas al AI Act y difirió las obligaciones del Anexo III dieciséis meses, del 2 de agosto de 2026 al 2 de diciembre de 2027. El motivo fue técnico: las normas armonizadas que CEN y CENELEC preparan a través del comité JTC 21 no estaban listas, y podrían no estarlo antes de diciembre de 2026. Sin norma publicada no hay presunción de conformidad.

Esa presunción se malinterpreta a menudo. Quien desarrolle conforme a una norma armonizada disfruta de presunción de conformidad con los requisitos correspondientes del reglamento, pero solo cuando esa norma esté publicada en el Diario Oficial de la Unión Europea. Trabajar sobre un borrador es prudente y ahorra rehacer el trabajo, pero no otorga presunción alguna.

En España, la Agencia Española de Supervisión de la Inteligencia Artificial (AESIA) tiene plena capacidad para inspeccionar, requerir evidencias y sancionar desde el 2 de agosto de 2026. La ley española reparte competencias entre la AESIA y otras autoridades según el ámbito: AEPD, Consejo General del Poder Judicial, Banco de España y CNMV. Las multas del tramo más alto alcanzan los 35 millones de euros.

Qué significa esto para tu HR-tech en la práctica

Aquí está el punto que suele pasarse por alto. El diferimiento del Omnibus movió la fecha de la obligación legal, pero no la fecha en la que tu cliente pregunta. Los cuestionarios de procurement y las due diligence de compradores corporativos ya incluyen preguntas sobre el AI Act, porque el comprador necesita responder a su vez ante su propia función de riesgos. Un contrato parado por un cuestionario sin responder es un problema de este trimestre; una sanción de 2027 se puede planificar.

Lo que se pregunta en esos cuestionarios es bastante consistente:

• Clasificación de riesgo del sistema y justificación escrita, incluida la evaluación del Art. 6.3 si alegas la excepción.
• Tu papel en cada sistema, proveedor o responsable del despliegue, y cómo lo has determinado a la luz del Art. 25.
• Inventario de modelos y versiones en producción, incluidos los de terceros y las dependencias de sus APIs.
• Qué datos se usan para entrenar o ajustar y qué pruebas de sesgo se han hecho sobre los resultados.
• Cómo se implementa la supervisión humana: qué ve la persona, qué puede cambiar y si queda registrado.
• Trazabilidad: qué eventos se registran, cuánto se conservan y si permiten reconstruir una decisión meses después.
• Qué se informa al candidato y cuándo, y cómo encaja con el RGPD: base jurídica, artículo 22 y evaluación de impacto.

La diferencia entre responder bien o mal a eso rara vez es tecnológica. Es documental. Los equipos que se atascan no tienen un sistema peor, tienen la misma información repartida entre la cabeza de dos ingenieros, un Notion desactualizado y un repositorio sin inventario. Lo que hay que producir es evidencia verificable, no declaraciones de intenciones.

Lo que el AI Act no es

Tres malentendidos aparecen en casi todas las conversaciones, y los tres llevan a gastar dinero en el sitio equivocado:

• No es una certificación. No existe un sello de "empresa certificada AI Act" que puedas comprar y colgar en la web. Para el alto riesgo lo que existe es una evaluación de conformidad y el marcado CE, y la vía técnica para acreditarla serán las normas armonizadas cuando se publiquen.
• No prohíbe la IA en recursos humanos. Prohíbe prácticas concretas del Art. 5, como inferir emociones de una persona en el lugar de trabajo salvo fines médicos o de seguridad, y somete el resto de usos de selección a requisitos de calidad, documentación y supervisión. Seguir usando IA para contratar es legal si se hace con los controles que la norma exige.
• No sustituye al RGPD. Se aplican en paralelo. En un proceso de selección hay datos personales de candidatos, con frecuencia una decisión individual automatizada en el sentido del artículo 22 del RGPD y, casi siempre, necesidad de evaluación de impacto. En España conviven la AESIA, que supervisa el AI Act, y la AEPD, que supervisa la protección de datos.