Cumplimiento · July 18, 2026 · 9 min de lectura

La EU AI Act y la contratación: qué significa el alto riesgo para ti

La EU AI Act clasifica la IA de contratación como de alto riesgo, con obligaciones sobre documentación, supervisión humana, registros y transparencia. Qué significa para tus evaluaciones.

← Parte de IA de contratación compliance-first: LL144 y la EU AI Act

Si evalúas a candidatos que viven en la Unión Europea, la EU AI Act sitúa tu software de contratación en su nivel de alto riesgo — el mismo nivel regulatorio que los dispositivos médicos y la calificación crediticia — y las obligaciones alcanzan a cualquier empleador que contrate candidatos en la UE, independientemente de dónde esté radicado ese empleador. Esto importa porque la clasificación de alto riesgo no es una distinción de la que se pueda salir con argumentos; se asigna según lo que hace el sistema, y conlleva obligaciones de documentación, supervisión humana, registro y transparencia que un PDF de políticas no puede satisfacer. Esta guía está escrita para el responsable de contratación o el líder de talento que necesita hacer que una plataforma de evaluación de competencias con IA nativa sea defendible antes del 2 de diciembre de 2027, y es un análisis en profundidad de nuestra guía más amplia sobre contratación compliance-first con IA.

Por qué la contratación es de alto riesgo por definición

La Ley adopta un enfoque escalonado por riesgo. La mayoría del software se sitúa en una banda de riesgo mínimo con pocas obligaciones; un conjunto reducido de prácticas está directamente prohibido; y entre medias está el nivel de alto riesgo, donde reside el verdadero trabajo de cumplimiento. El empleo encaja de lleno en esa banda intermedia. El Anexo III, Área 4 — «empleo, gestión de trabajadores y acceso al autoempleo» — menciona explícitamente la IA utilizada para reclutar, cribar, filtrar y evaluar candidatos, así como para tomar o apoyar decisiones sobre ascensos, bajas y asignación de tareas.

La consecuencia es contundente: si tu herramienta influye en quién es contratado, es de alto riesgo por clasificación, no por argumento. No existe ningún umbral de precisión que permita a un proveedor quedar exento, ni ningún encuadre de «solo asistimos al reclutador» que sitúe la herramienta en un nivel más ligero. Una puntuación de modelo segura en la que se apoya un reclutador es exactamente el escenario para el que está escrito el Anexo. Por eso la postura más segura trata el cumplimiento como una decisión de arquitectura adoptada temprano, con el mismo espíritu que reducir el sesgo en la contratación — algo que se incorpora, no que se añade a posteriori.

Las obligaciones principales, en términos sencillos

Los requisitos de alto riesgo se leen como una lista de comprobación de sistemas más que como una abstracción jurídica. Cubren todo el ciclo de vida del sistema, y cada uno se corresponde con algo que se puede señalar en un proceso de evaluación que funcione.

• Gestión de riesgos a lo largo del ciclo de vida del sistema — un proceso vivo, no una aprobación puntual
• Gobernanza de datos — datos de entrenamiento, validación y prueba gestionados en cuanto a relevancia, representatividad y tratamiento de errores
• Documentación técnica y mantenimiento automático de registros (logging) que permitan a otros reconstruir lo ocurrido
• Supervisión humana significativa — una persona que pueda comprender, monitorizar y anular el resultado
• Transparencia e información a los desplegadores, para que quienes ejecutan la herramienta conozcan sus límites
• Exactitud, robustez y ciberseguridad adecuadas al uso previsto

Leídas en conjunto, estas obligaciones recompensan un diseño en el que la evidencia se genera como subproducto del uso normal. Si la única forma de demostrar la supervisión humana es una política firmada que nadie puede probar que se siguió, los trámites se convierten en una carrera apresurada. Si cada evaluación de candidatos generada por IA deja un registro revisable y cada decisión del revisor queda registrada, la mayor parte de la documentación se escribe sola.

La supervisión humana como funcionalidad, no como política

El artículo 14 es inusualmente específico sobre lo que significa la supervisión. Las personas responsables deben poder comprender las capacidades y límites del sistema, monitorizarlo en busca de señales de anomalía o mal funcionamiento, interpretar correctamente sus resultados y — de forma crítica — mantenerse alerta ante el sesgo de automatización, la tendencia humana a confiar en exceso en una máquina segura. Deben conservar el poder de ignorar el resultado, anularlo o decidir no utilizar el sistema en absoluto en un caso concreto.

Ese estándar es difícil de satisfacer con un documento de política y fácil de satisfacer con el flujo de trabajo adecuado. Una cola de revisión de reclutadores en la que una persona aprueba, edita o rechaza cada resultado — con cada acción con marca de tiempo y atribuida — es el artículo 14 hecho concreto. La supervisión que se puede demostrar supera a la supervisión que simplemente se afirma. La distinción importa más cuando un candidato rechazado pregunta cómo se tomó la decisión, o cuando un regulador hace la misma pregunta dos años después.

El sesgo de automatización es el modo de fallo que hay que combatir

La Ley menciona el sesgo de automatización porque es la forma predecible en que la supervisión humana colapsa en la práctica. Un revisor que se enfrenta a cien candidatos y una puntuación segura derivará hacia la aprobación automática. Las contramedidas son estructurales: muestra el razonamiento detrás de un resultado en lugar de un número solo, haz que el revisor registre un juicio en lugar de hacer clic en «aceptar», y calibra la carga de trabajo para que la supervisión sea realista. La misma disciplina sustenta la evaluación estructurada y defendible en general — la consistencia del proceso es lo que hace que una decisión sea revisable.

Transparencia para las personas evaluadas

La clasificación de alto riesgo también conlleva deberes de transparencia orientados al candidato, no solo al auditor. Las personas que interactúan con un sistema de IA en un contexto de alto riesgo necesitan ser informadas de que esto está ocurriendo, de una manera que puedan realmente comprender, y los desplegadores deben dar a la persona afectada la información que necesita para entender cómo encaja el sistema en una decisión sobre ella. Para la contratación, esto significa decir claramente a los candidatos que se utiliza IA en la evaluación, qué evalúa y que un humano revisa el resultado antes de que tenga efecto.

La transparencia es barata de incorporar y cara de añadir a posteriori. Un aviso breve y honesto en el momento en que un candidato inicia una evaluación satisface el espíritu del requisito y, en nuestra experiencia, mejora las tasas de finalización en lugar de perjudicarlas — las personas están más dispuestas a ser evaluadas por una máquina cuando se les dice que una persona respalda la decisión. Las divulgaciones vagas o enterradas tienen el efecto contrario e invitan exactamente a la queja que la norma está diseñada para prevenir. La misma franqueza sustenta una sólida experiencia del candidato — la transparencia y la confianza avanzan en la misma dirección.

Proveedor frente a desplegador: quién debe qué

La Ley divide las obligaciones entre dos roles. Un proveedor desarrolla el sistema de IA, o lo tiene desarrollado, y lo coloca en el mercado bajo su propio nombre. Un desplegador utiliza ese sistema bajo su propia autoridad — en el caso de una herramienta de contratación, suele ser el empleador. Si compras una plataforma de evaluación y la ejecutas con tus candidatos, eres un desplegador; el proveedor es el fabricante.

Los proveedores soportan la mayor carga en el lado de la construcción: gestión de riesgos, gobernanza de datos, documentación técnica, logging, evaluación de conformidad y monitorización poscomercialización. Los desplegadores tienen un conjunto de obligaciones más ligero pero real — utilizar el sistema según las instrucciones del proveedor, ejecutar la supervisión humana en la práctica, mantener los registros que genera el sistema e informar a las personas afectadas donde sea necesario. La posición cómoda para un desplegador es elegir un proveedor cuyo producto ya genere los registros que ambos roles necesitan, de modo que tus obligaciones se cumplan utilizando la herramienta según lo previsto en lugar de añadiendo una capa de cumplimiento encima.

Hay una razón práctica para importar qué rol ocupas más allá de repartir culpas. Tus obligaciones de evidencia difieren, y también lo que puedes externalizar. Un desplegador no puede delegar la supervisión humana — la ejercen tus personas, sobre tus candidatos, independientemente de lo que haga el producto del proveedor. Pero un desplegador puede, y debe, exigir que el proveedor suministre la documentación, el logging y las instrucciones que hacen que la supervisión y el mantenimiento de registros sean factibles. Si un proveedor no puede mostrarte cómo su herramienta genera los registros que necesitarás, es una señal de cuánta carga de cumplimiento está dejando silenciosamente en tu mesa.

El plazo: 2 de diciembre de 2027

Las obligaciones de alto riesgo para los sistemas del Anexo III se vuelven ejecutables el 2 de diciembre de 2027. El Reglamento Ómnibus Digital las aplazó desde la fecha original del 2 de agosto de 2026, una medida incondicional que otorga a los empleadores aproximadamente dieciséis meses adicionales. Esa fecha de agosto de 2026 no ha desaparecido — es cuando entran en vigor los deberes de transparencia del artículo 50, que cubren la divulgación de que la IA está implicada y el etiquetado de contenido generado por IA, y cuando la Oficina de IA de la UE comienza a hacer cumplir las obligaciones sobre IA de propósito general. Las normas que prohíben un conjunto reducido de prácticas prohibidas se aplicaron antes, desde febrero de 2025. Las sanciones por las infracciones más graves alcanzan decenas de millones de euros o una parte del volumen de negocio anual global, el que sea mayor — cifras deliberadamente lo suficientemente grandes como para importar a un empleador global, no solo una multa que se pueda absorber.

Trata el aplazamiento como margen de maniobra, no como una amnistía. Dieciséis meses son suficientes para construir documentación, pruebas de sesgo y supervisión humana de forma adecuada y sin precipitación, pero solo si empiezas ahora — diciembre de 2027 es una fecha firme, y los deberes de transparencia llegan en agosto de 2026 independientemente. La postura segura es la misma para proveedores y desplegadores, y es la misma postura hacia la que ya empujan las normas de auditoría de sesgo de la ciudad de Nueva York y las emergentes leyes estatales de EE. UU. como la Ley de IA de Colorado: un humano genuinamente en el bucle y registros que lo demuestren. Construye para la generación de evidencia y el mantenimiento de registros ahora, y el hilo conductor entre todas las jurisdicciones — mantén a una persona responsable, mantén un rastro — significa que la misma arquitectura responde a la mayoría de las preguntas a la vez.

Qué aspecto tiene realmente una documentación defendible

La palabra «documentación» hace mucho trabajo silencioso en la Ley, y merece la pena ser concreto sobre lo que exige. Para un sistema de contratación de alto riesgo, la documentación técnica pretende que un tercero competente pueda entender qué hace el sistema, los datos sobre los que fue construido, cómo rinde y cuáles son sus limitaciones conocidas. El logging captura entonces lo que realmente ocurrió en uso: qué candidato fue evaluado cuándo, qué produjo el sistema y qué hizo el revisor humano con ello.

Para un desplegador, la prueba honesta es simple: si un candidato se quejara ante un regulador dentro de dieciocho meses, ¿podrías reconstruir su evaluación de principio a fin a partir de registros que ya existen? Si la respuesta requiere conjeturas, reconstrucción de memoria o pedirle al proveedor que busque algo, la documentación aún no hace su trabajo. Los sistemas que superan esta prueba son aquellos en los que el registro es un subproducto de ejecutar la evaluación, no un informe que alguien tiene que acordarse de escribir. Esa es la misma razón por la que un proceso de contratación riguroso con IA nativa mantiene un rastro revisable para cada resultado por defecto.

Cómo encaja la EU AI Act con el RGPD

La Ley de IA no reemplaza la legislación de protección de datos; se superpone a ella. Para un equipo de contratación en Europa, el RGPD sigue rigiendo cómo se recopilan, almacenan y eliminan los datos de los candidatos, y la Ley de IA añade obligaciones sobre cómo se construye, documenta y supervisa el propio sistema de IA. Los dos se solapan más visiblemente en torno a la supervisión humana: el artículo 22 del RGPD ya restringe las decisiones basadas únicamente en el procesamiento automatizado, y el artículo 14 de la Ley de IA detalla cómo es un control humano significativo. Cumple uno correctamente y estás a la mayor parte del camino de cumplir el otro.

La consecuencia práctica es que no deberías ejecutar dos proyectos de cumplimiento separados. Los datos del candidato que minimizas bajo el RGPD son los mismos que cubren las obligaciones de gobernanza de datos de tu sistema de IA. El consentimiento y el aviso que das bajo el RGPD es donde vive naturalmente tu divulgación de transparencia de IA. Tratarlos como un solo programa, en lugar de dos, es la diferencia entre un proceso coherente y un montón de papeleo superpuesto. Nuestra guía sobre el RGPD para la contratación recorre la mitad de protección de datos del mismo panorama.

Qué hacer antes del plazo

Empieza por mapear dónde toca la IA tu embudo de contratación — sourcing, cribado, evaluación, ranking — y marca cada punto como suministrado por el proveedor o construido internamente, porque tu rol determina tus obligaciones. Luego confirma tres cosas sobre cada punto de contacto de alto riesgo: que una persona designada puede anular el resultado, que cada decisión queda registrada de una forma que podrías entregar a un auditor y que se informa a los candidatos de que un sistema de IA está involucrado donde la Ley lo exija. Si alguna de las tres falta, ahí es donde está el trabajo de corrección.

Por último, mantén el registro legible para humanos. El punto de la documentación no es satisfacer un requisito de archivo; es permitir que un revisor, un auditor o un candidato rechazado reconstruya cómo se tomó una decisión. Un enfoque compliance-first trata esa reconstituibilidad como el producto, y el certificado de cumplimiento como un efecto secundario. Consulta cómo funcionan la supervisión y el logging en la práctica en una demo en directo.