Imagen generada por IALa Unión Europea ha pisado el freno. Las obligaciones más delicadas del AI Act para sistemas laborales de alto riesgo ya no apuntan al 2 de agosto de 2026, sino al 2 de diciembre de 2027. Suena a alivio. No lo es tanto. Lo que Bruselas ha concedido no es una amnistía, sino tiempo para que las empresas arreglen una casa que en muchos casos sigue montada sobre hojas de cálculo, contratos vagos con proveedores y una fe casi religiosa en que “hay una persona en el circuito” bastará para esquivar problemas.
Reuters lo resumía bien el 17 de julio de 2026: la prórroga no reduce el riesgo, solo cambia el momento del cumplimiento. Esa es la lectura correcta. La equivocada sería pensar que, como el reloj se ha movido, ya habrá tiempo más adelante para decidir si el sistema que filtra candidatos, puntúa desempeño o reparte turnos entra o no en el perímetro de alto riesgo. Más adelante suele llegar con auditoría, comité de empresa enfadado y vendor incapaz de producir la documentación que prometió en preventa.
Hay otro detalle que merece atención: la Comisión Europea ya publicó a finales de mayo de 2026 un borrador de directrices sobre clasificación de sistemas de IA de alto riesgo. Ese texto no es un simple folleto interpretativo. Es la señal más clara hasta la fecha de cómo va a mirar Bruselas el uso de IA en empleo, reclutamiento, evaluación y gestión de plantilla. Traducido al castellano operativo: quien siga confiando en la etiqueta comercial del proveedor va tarde. Lo que importa es la función real del sistema y su efecto sobre la trayectoria laboral de una persona.
Ese es el eje de esta pieza: la prórroga cambia el calendario, pero no la dirección. Y para empresas con operaciones en la UE, especialmente multinacionales y entidades financieras, el trabajo difícil empieza ahora. No en 2027. Ahora.
La prórroga del AI Act para sistemas laborales de alto riesgo es una mala noticia para quien esperaba claridad inmediata, pero una buena noticia para quien entienda cómo funciona de verdad el cumplimiento serio: primero se construye gobernanza, luego se discute la clasificación fina.
Mi tesis es simple. El debate jurídico sobre si una herramienta concreta es o no “alto riesgo” importa, claro, pero se está llevando demasiada atención frente al problema de fondo: la mayoría de los empleadores aún no controla con precisión qué sistemas de IA usa en RRHH, qué datos procesan, qué submodelos incorporan, qué decisiones influyen y qué proveedor asume qué obligación. Sin ese inventario y sin esa trazabilidad, la discusión legal es decorativa.
La ironía es evidente. Muchas organizaciones han dedicado dos años a pulir políticas éticas sobre IA mientras siguen comprando herramientas de sourcing, scoring, analítica de productividad o “people intelligence” con anexos contractuales que apenas superan el nivel de folleto de marketing. Y luego llega la sorpresa: que el proveedor diga que su herramienta “solo asiste” al decisor no significa gran cosa si el sistema rankea, filtra, recomienda o empuja decisiones sobre contratación, promoción, asignación de tareas o terminación de la relación laboral.
Eso enlaza con una de las advertencias más útiles del debate actual: en el AI Act, la mera existencia de revisión humana no neutraliza por sí sola la calificación de alto riesgo. En GDPR, la conversación sobre decisiones automatizadas del artículo 22 gira precisamente alrededor del efecto jurídico o similarmente significativo y del grado de intervención humana. Aquí el eje es distinto. Si la IA da forma material a la decisión laboral, el análisis cambia. Quien mezcle ambos marcos como si fueran lo mismo va a construir controles equivocados.
El dato verificable es este: las reglas clave para sistemas laborales de alto riesgo se desplazan del 2 de agosto de 2026 al 2 de diciembre de 2027. La noticia importa porque afecta justo a uno de los usos donde Bruselas ha sido menos ambigua: empleo y acceso al trabajo por cuenta propia.
La lógica legal del AI Act lleva tiempo apuntando hacia ahí. Los sistemas utilizados para reclutamiento, selección de personas candidatas, toma de decisiones que afecten a condiciones de trabajo, promoción, terminación, asignación de tareas, seguimiento del rendimiento o evaluación del comportamiento están en la zona caliente del reglamento. No porque Europa tenga una teoría abstracta sobre la IA, sino porque esos sistemas alteran oportunidades vitales: quién entra, quién progresa, quién cobra mejor y quién sale.
El retraso tiene tres efectos prácticos inmediatos.
Primero, da margen para madurar las directrices de clasificación y reducir el riesgo de cumplimiento a ciegas. A nadie le convenía un aterrizaje acelerado con criterios aún discutidos sobre sistemas embebidos en suites de RRHH, ATS, plataformas de productividad o software de gestión de plantilla.
Segundo, traslada el foco desde la reacción jurídica a la preparación operativa. Eso significa inventario, governance, due diligence de terceros, diseño documental y revisión de procesos internos. No es la parte glamourosa del compliance, pero es la que evita problemas caros.
Tercero, aumenta la presión sobre las decisiones de compra que se tomen en 2026 y 2027. Todo contrato firmado ahora con un proveedor de IA para empleo es potencialmente un problema diferido. Si el acuerdo no fija documentación, actualizaciones regulatorias, cooperación para evaluaciones, trazabilidad de datasets, logging, incident reporting o responsabilidades ante reclamaciones, el coste lo pagará el comprador. El proveedor, salvo excepciones, seguirá vendiendo la siguiente versión.
Aquí aparece el auténtico riesgo de la prórroga: el falso confort. En regulación tecnológica, los retrasos suelen generar dos tipos de respuesta. La sensata: aprovechar el tiempo para cerrar brechas estructurales. La peligrosa: congelar el proyecto y esperar a que el regulador “aclare más cosas”. Esa segunda reacción es comprensible y pésima.
La clasificación no depende del nombre del producto, ni del pitch comercial, ni del hecho de que la herramienta venga “integrada” dentro de una plataforma mayor. Depende de lo que hace y de cómo se usa.
Si una herramienta se utiliza para publicidad dirigida de vacantes, cribado de candidaturas, ranking, shortlist, entrevistas automatizadas, scoring de pruebas, evaluación de competencias o inferencias sobre adecuación al puesto, la probabilidad de entrar en alto riesgo es muy alta. Lo mismo ocurre con sistemas que apoyan decisiones de promoción, terminación, distribución de tareas, medición de rendimiento, vigilancia del comportamiento o asignación de trabajo en tiempo real.
Hay un criterio práctico que conviene repetir porque corta mucho ruido: cuanto más evalúa, puntúa, clasifica, filtra, recomienda o direcciona la decisión sobre una persona, más cerca está del régimen de alto riesgo. Cuanto más se limite a una función administrativa genuina —organizar información sin perfilar ni priorizar personas—, más argumentos hay para situarlo fuera.
El problema es que el mercado del software laboral se ha especializado en difuminar esa frontera. Un ATS puede “solo organizar candidatos”, hasta que uno mira la configuración y descubre funcionalidades de matching, ranking semántico, scoring predictivo o alertas sobre “fit” cultural. Una herramienta de workforce management puede “optimizar turnos”, hasta que se usa para premiar perfiles, castigar disponibilidad o detectar supuesta baja productividad. Un copiloto corporativo puede “resumir evaluaciones”, hasta que empieza a sugerir ratings o redactar argumentos disciplinarios.
La clasificación, por tanto, exige bajar al caso de uso. No basta con catalogar producto por producto. Hay que catalogar producto, módulo, feature y contexto de uso. Dos empresas pueden comprar la misma plataforma y quedar en posiciones regulatorias distintas según cómo la configuren, qué datos le den y qué decisiones permita influir.
Esa exigencia de granularidad es incómoda. También inevitable. Y aquí es donde muchas organizaciones pinchan: tienen inventario de aplicaciones, pero no inventario de funcionalidades de IA ni de decisiones afectadas. Sin ese mapa, cualquier autoevaluación será poco más que optimismo con membrete.
En el discurso corporativo sobre IA hay una frase que aparece con la frecuencia de un pop-up molesto: “la decisión final siempre la toma una persona”. A veces es verdad. Casi nunca basta.
En protección de datos, el artículo 22 del GDPR se activa en escenarios de decisiones basadas únicamente en tratamiento automatizado que produzcan efectos jurídicos o significativamente similares. Esa arquitectura ha llevado a muchas empresas a pensar que introducir una capa humana —aunque sea ritual— basta para rebajar el riesgo. El problema es que el AI Act no hace descansar la calificación de alto riesgo en ese punto.
Si la salida del sistema influye materialmente en la decisión, por ejemplo mediante ranking, scoring, recomendación, priorización o señalización, la presencia formal de un humano no elimina el análisis de alto riesgo. Dicho de otra forma: si el revisor humano se limita a refrendar una lista ya moldeada por el sistema, el “human in the loop” puede ser más teatro que control.
Esto tiene dos consecuencias muy concretas para compliance y auditoría interna.
La primera: habrá que demostrar qué capacidad real tiene el decisor humano para entender, cuestionar y apartarse del resultado del sistema. No un “puede hacerlo” abstracto, sino evidencia de diseño, formación, interfaz, umbrales de revisión y tasa de override cuando proceda.
La segunda: habrá que vigilar sesgos de automatización y dependencia cognitiva. Si los managers o reclutadores aceptan sistemáticamente la sugerencia de la herramienta, la revisión humana pierde valor práctico aunque exista en el procedimiento. Ese fenómeno no es solo ético; puede convertirse en munición regulatoria y procesal si una persona afectada impugna una decisión.
Por eso la gobernanza útil no consiste en insertar a una persona al final del flujo, como quien firma sin leer. Consiste en rediseñar el flujo para que la intervención humana tenga contexto, criterio, facultad de corregir y trazabilidad de por qué corrige o confirma.
La noticia de Reuters acierta en algo que suele quedar enterrado bajo doctrinas: para muchos empleadores, el mayor problema no será interpretar la ley, sino entender qué demonios hace exactamente cada herramienta y conseguir de sus proveedores la documentación necesaria.
Esto afecta de lleno a procurement. Y procurement, seamos honestos, rara vez recibe el protagonismo que merece hasta que el regulador aparece con preguntas incómodas.
Quien despliega IA laboral no puede seguir comprando con el esquema clásico de software as a service: ficha técnica, demo brillante, DPA genérico, cláusula de limitación de responsabilidad musculosa y a producir. Para herramientas que puedan caer en alto riesgo, el comprador necesita algo bastante menos decorativo.
Necesita saber, como mínimo, qué modelos o componentes de IA incorpora la solución; para qué tareas concretas se utilizan; qué datos de entrada requiere; si procesa datos personales o categorías especiales del artículo 9 GDPR; qué mecanismos de logging existen; qué métricas de rendimiento, error o sesgo puede aportar el proveedor; cómo gestiona cambios de versión; qué controles de seguridad aplica; qué subencargados intervienen; y qué soporte dará para responder a solicitudes regulatorias, litigios, consultas de comités de empresa o ejercicios de derechos.
Eso obliga a reescribir cuestionarios de due diligence, anexos contractuales y procesos de aprobación de compras. También obliga a admitir una verdad incómoda: no todos los vendors están preparados. Muchos proveedores de HR tech han incorporado IA a velocidad de mercado y con documentación de laboratorio, no de cumplimiento. Si tu organización espera a 2027 para descubrirlo, el bloqueo vendrá en el peor momento: con despliegues ya hechos, dependencia operativa creada y negocio presionando para no retirar herramientas.
Hay, además, una asimetría de responsabilidad que conviene no maquillar. Aunque el proveedor sea desarrollador del sistema, el empleador como deployer no queda fuera de foco. La empresa que usa la herramienta en procesos de empleo tendrá que responder por su propia base jurídica, su transparencia, su DPIA cuando proceda, su gestión de derechos, su relación laboral y sus decisiones de uso. No sirve levantar el dedo y señalar al fabricante.
El AI Act no aterriza en un vacío. Aterriza encima de un suelo ya lleno de normas, algunas complementarias y otras francamente mal alineadas. Ese mosaico es justo lo que va a volver más difícil el cumplimiento en IA laboral, sobre todo para grupos multinacionales y para sectores regulados.
El GDPR sigue siendo central. El artículo 5 impone principios de minimización, limitación de finalidad y exactitud; el artículo 6 exige base jurídica; el artículo 9 restringe categorías especiales; el artículo 13 obliga a informar; el artículo 22 regula ciertas decisiones automatizadas; y el artículo 35 exige evaluación de impacto cuando el tratamiento entrañe alto riesgo para derechos y libertades.
En empleo, esa combinación es explosiva. Muchas herramientas de IA infieren rasgos sensibles a partir de datos aparentemente banales: patrones de escritura, voz, vídeo, productividad, horarios, metadatos de colaboración o incluso señales de salud inferida. No hace falta que el sistema pregunte por discapacidad, afiliación sindical o estado emocional para generar un problema de artículo 9. Basta con que los datos o inferencias apunten allí.
La diferencia clave es esta: el AI Act clasifica sistemas y les impone obligaciones técnicas y organizativas en función del riesgo; el GDPR regula el tratamiento de datos personales y los derechos de la persona afectada. Una empresa puede creer que su proceso no cae en artículo 22 porque hay revisión humana y, aun así, tener un sistema de alto riesgo bajo AI Act. También puede ocurrir a la inversa: una funcionalidad no ser alto riesgo pero sí generar un problema grave de transparencia, base jurídica o DPIA.
Para entidades financieras, DORA añade una capa decisiva. El Reglamento (UE) 2022/2554 no regula la IA laboral como tal, pero sí la gestión del riesgo TIC, los incidentes, la resiliencia operativa y, de manera especialmente relevante, el riesgo de terceros TIC. Los artículos 28 a 30 de DORA obligan a gestionar de forma estricta las relaciones contractuales con proveedores TIC, con requisitos sobre funciones, localización de datos, acceso, auditoría, terminación y cooperación con autoridades.
¿Dónde se cruzan DORA y AI Act? En la práctica, en el proveedor. Si un banco o aseguradora contrata una plataforma de IA para reclutamiento, evaluación o asignación de personal, no solo debe preguntarse si el uso entra en alto riesgo bajo AI Act. Debe preguntarse también si el proveedor TIC y la dependencia operativa creada exigen controles reforzados bajo DORA, especialmente si el servicio se integra en procesos críticos o sensibles.
El resultado es bastante menos poético que cualquier estrategia de “people transformation”. Harán falta inventarios alineados, due diligence contractual más dura, pruebas de resiliencia, seguimiento de incidencias y salida ordenada del proveedor. Sí, incluso para herramientas de RRHH, si afectan a funciones relevantes o concentran datos y procesos sensibles.
La Directiva (UE) 2022/2555, conocida como NIS2, exige medidas de gestión de riesgos de ciberseguridad en su artículo 21. No todas las empresas usuarias de IA laboral estarán dentro del ámbito de NIS2, pero muchas grandes organizaciones sí lo estarán directa o indirectamente a través de su cadena de suministro o de sectores cubiertos.
La lección aquí es obvia pero a veces se olvida: un sistema de IA en empleo no es solo una cuestión de sesgo o privacidad. También es una superficie de ataque. Exposición de CV, expedientes de desempeño, credenciales, evaluaciones internas, modelos conectados a SaaS externos, integraciones con correo, videollamadas y suites colaborativas. Un incidente en ese stack no generará solo un debate ético; activará incident response, posible notificación bajo GDPR artículo 33 y, en entornos cubiertos, obligaciones sectoriales adicionales.
EIDAS 2.0 no suele entrar de primeras en la conversación sobre IA laboral, pero debería aparecer más. Cuanto más dependan los procesos de contratación o firma de decisiones sensibles de flujos digitales, más relevante será la integridad de la identidad, la autenticación y la prueba electrónica. Si una empresa quiere demostrar quién validó una recomendación de IA, qué versión del modelo se usó, qué evidencia documental se firmó y con qué garantías, los servicios de confianza no son un lujo jurídico: son una forma de reducir discusiones probatorias futuras.
Para multinacionales con presencia en Estados Unidos, el NIST Cybersecurity Framework 2.0 puede servir como columna vertebral operativa para gobierno, identificación, protección, detección, respuesta y recuperación. No sustituye al AI Act ni al GDPR, claro. Pero ayuda a ordenar controles que luego pueden mapearse a requisitos europeos. Donde más valor aporta es en la disciplina de gobernanza y de cadena de suministro, dos áreas donde muchas iniciativas de IA corporativa siguen bastante verdes.
La respuesta útil no es “crear un comité de IA” y hacer una presentación bonita. La respuesta útil es más áspera y bastante más concreta.
Lo primero es construir un inventario real de sistemas de IA en empleo. Real significa incluir herramientas compradas, módulos activados por defecto, pilotos, funciones experimentales y capacidades generativas embebidas en suites existentes. Si tu mapa solo recoge “la plataforma de talento X” pero no distingue ranking de candidatos, resumen automático, scoring, entrevistas asistidas o recomendación de promociones, no tienes inventario. Tienes branding.
Lo segundo es mapear decisiones afectadas. Para cada sistema hay que responder: qué hace, a quién afecta, qué datos usa, qué inferencias produce, si prioriza o excluye personas, quién revisa el resultado y con qué margen real de discreción. Ese mapa permite una primera clasificación y, sobre todo, detecta usos que nadie había elevado a Legal o Compliance porque “solo ayudan al negocio”.
Lo tercero es rehacer el intake de compras. Ninguna adquisición de tecnología para RRHH debería pasar sin preguntas específicas sobre IA. Y no me refiero a “¿usa usted inteligencia artificial?”. Esa pregunta ya solo sirve para que marketing responda “sí, con enfoque responsable”. Hace falta pedir documentación de arquitectura, funcionalidades, entrenamiento o ajuste si aplica, tipos de datos, mecanismos de control, explicabilidad disponible, auditorías, certificaciones de seguridad, subprocesadores, soporte contractual y procedimiento de change management.
Lo cuarto es revisar las bases jurídicas y la transparencia. En empleo, el consentimiento suele ser mala idea por el desequilibrio inherente de poder. Eso empuja a analizar con más rigor la base de legitimación utilizada, los límites del interés legítimo y la necesidad de información clara al personal y a candidatos. Además, si existe posibilidad de impacto significativo, la organización debería revisar de forma seria la aplicabilidad del artículo 22 GDPR y la obligación de hacer una DPIA bajo el artículo 35.
Lo quinto es trabajar con relaciones laborales. Este punto suele llegar tarde y llegar tarde aquí sale especialmente mal. En muchos Estados miembros, la introducción de herramientas que monitorizan, evalúan o afectan a condiciones de trabajo puede activar deberes de información o consulta con representantes de los trabajadores. Ignorarlo no solo aumenta el riesgo de conflicto interno; también debilita la posición de la empresa si el despliegue termina judicializado.
Lo sexto es diseñar evidencias antes de que las pidan. Cada decisión de clasificación, cada evaluación de impacto, cada override humano relevante, cada incidencia de calidad del sistema, cada actualización material del proveedor debería dejar rastro utilizable. Cuando un regulador, un tribunal o un comité de empresa pregunte por qué se usó una determinada herramienta y con qué garantías, la respuesta no puede ser “está en Teams, creo”.
El boom de IA generativa entre 2024 y 2026 ha dejado una situación curiosa: numerosas organizaciones creen estar evaluando “nuevos sistemas de IA”, cuando en realidad llevan meses usando capacidades de IA ya incrustadas en herramientas de productividad, colaboración y recursos humanos. El riesgo no es solo no clasificar un sistema nuevo; es no detectar una funcionalidad activada por actualización de producto.
Esto importa porque la frontera entre IA laboral directa e indirecta se está difuminando. Un asistente de redacción que sugiere feedback de desempeño, una función que resume entrevistas, un analizador que destaca señales de “engagement”, un motor que prioriza tareas o un dashboard que clasifica equipos por productividad pueden terminar afectando decisiones laborales aunque no se vendan como “software de IA para RRHH”.
La buena noticia es que la prórroga da tiempo para limpiar esa niebla. La mala es que esa limpieza exige coordinación de verdad entre RRHH, IT, Legal, Procurement, Seguridad, Compliance y, en multinacionales, equipos locales. No es un proyecto de política corporativa. Es un proyecto de gobierno del dato, del software y de la decisión.
Quien no quiera verlo así corre un riesgo muy concreto: llegar a 2027 con una gobernanza central impecable sobre el papel y un subsuelo lleno de herramientas activadas por negocios regionales, equipos de talento o managers entusiastas. Esa brecha entre policy y realidad es donde suelen nacer los casos feos.
Para banca, seguros, gestoras y fintech en España, la prórroga del AI Act tiene una lectura algo más severa que para otras industrias. No porque el reglamento de IA les trate peor, sino porque operan con una densidad regulatoria superior y con ecosistemas de terceros más vigilados.
Primero, porque la gestión de personal en entidades financieras ya convive con exigencias de idoneidad, controles internos, auditoría y modelos de tres líneas de defensa. Si la IA entra en selección, evaluación, movilidad interna o asignación de funciones de control, el impacto no es solo laboral: puede tocar gobierno interno, segregación de funciones y calidad del control.
Segundo, porque DORA ya está obligando a profesionalizar inventarios TIC, contratos de terceros, testing y reporting. Aprovechar esa maquinaria para incorporar IA laboral sería lo inteligente. Montar una gobernanza paralela, separada de la gestión de riesgo tecnológico y de terceros, sería duplicar costes y crear incoherencias. Justo lo que luego detectan auditoría interna o el supervisor.
Tercero, porque las entidades financieras suelen ser compradoras intensivas de software global. Eso significa plantillas, ATS, monitoring, productividad, contact center, workforce allocation y analítica de personas procedentes de proveedores multinacionales que ajustan producto a gran velocidad. Si el banco no introduce cláusulas específicas sobre funciones de IA, cambios de versión, documentación y cooperación regulatoria, será rehén del roadmap del proveedor. Y los proveedores, conviene recordarlo, optimizan ventas antes que comodidad regulatoria del cliente.
Cuarto, porque la litigiosidad reputacional es distinta. Un error en un sistema de scoring de candidaturas o evaluación de desempeño dentro de un banco puede acabar siendo visto no solo como conflicto laboral, sino como síntoma de gobernanza deficiente en una entidad obligada a estándares reforzados de control interno. Eso cambia la gravedad del asunto y la atención del consejo.
Si una entidad española quiere adelantarse de verdad, el movimiento sensato en 2026 es incorporar IA laboral al mapa de riesgo no financiero y al gobierno de terceros, no dejarla flotando como una iniciativa de innovación de RRHH.
Hay cuatro escenarios donde la IA laboral puede generar problemas serios en entidades financieras y aseguradoras.
Uno: reclutamiento y movilidad interna. Sistemas que puntúan CV, filtran personas candidatas o recomiendan promociones pueden reproducir sesgos históricos, introducir inferencias opacas o penalizar trayectorias no lineales. Control recomendado: validación previa del caso de uso, revisión de variables empleadas, pruebas de impacto por colectivos, trazabilidad del criterio final y capacidad demostrable de override humano.
Dos: asignación de tareas y gestión de plantilla. Herramientas que optimizan turnos, cargas o cartera comercial pueden terminar afectando incentivos, oportunidades o exposición a objetivos más duros. Control recomendado: límites al uso de variables sensibles o proxys, revisión por relaciones laborales, monitorización de resultados por área y documentación de las reglas de negocio que acompañan al modelo.
Tres: performance management. Si la herramienta resume feedback, sugiere ratings, detecta “low performers” o monitoriza productividad digital, el riesgo de decisiones injustas y de vigilancia desproporcionada se dispara. Control recomendado: DPIA robusta, minimización de datos, exclusión de métricas irrelevantes, transparencia reforzada y revisión periódica de falsos positivos.
Cuatro: atención al cliente y front line. En banca y seguros, la IA laboral no solo decide sobre empleados; también condiciona cómo los empleados tratan al cliente. Un sistema que asigna prioridades, sugiere respuestas o mide rendimiento puede sesgar la conducta comercial. Control recomendado: gobierno conjunto entre cumplimiento, conducta y RRHH, además de pruebas de que la herramienta no incentiva prácticas contrarias al interés del cliente.
En todos los casos, hay un patrón común: el control útil no es una política ética genérica. Es una mezcla de clasificación jurídica, documentación técnica, validación operativa, seguridad, formación y capacidad de parar el uso si el caso de uso deriva.
Hay una tentación muy corporativa en este tipo de transiciones regulatorias: retrasar decisiones hasta que exista certeza total. El problema es que en tecnología regulada esa certeza casi nunca llega de una pieza. Llega por capas: reglamento, directrices, práctica supervisora, litigios, enforcement y aprendizaje de mercado.
Esperar a “ver cómo se interpreta” tiene algo de sensato cuando lo que está en juego es una obligación muy específica. Aquí no. Aquí lo principal ya se entiende bastante bien: los usos de IA que moldean decisiones de empleo van a estar sometidos a una presión regulatoria intensa; GDPR seguirá aplicando con toda su fuerza; la seguridad y los terceros no pueden tratarse como anexos; y los contratos actuales de muchos proveedores no bastan.
La empresa que use este año y el siguiente para mapear, clasificar, renegociar, documentar y entrenar llegará a diciembre de 2027 con opciones. La que lo use para esperar una guía más definitiva llegará con dependencia tecnológica, prisa y negocio exigiendo excepciones. Y el compliance con prisa suele terminar en compliance cosmético.
Hay, además, un factor político nada menor. La prórroga demuestra que Bruselas ha escuchado las dificultades de implementación, pero no ha retirado la ambición regulatoria sobre IA en empleo. Quien lea el movimiento como una señal de desinflado ideológico está leyendo mal. Lo que hay es reconocimiento del atasco operativo, no renuncia al control.
Si se mira con algo menos de dramatismo, esta prórroga ofrece una oportunidad extraña pero valiosa: profesionalizar de una vez el gobierno corporativo de la IA donde más daño puede hacer a personas concretas.
La IA en marketing tolera más experimentación. La IA en empleo, no. Porque ahí cada ranking, cada recomendación y cada automatismo se proyecta sobre derechos, carrera, salario, dignidad y acceso al trabajo. El regulador lo ha entendido. Las empresas deberían entenderlo también, y no solo para evitar sanciones.
La oportunidad consiste en usar estos 16 meses adicionales para hacer tres cosas bien. Una, sacar la IA laboral de la zona de sombra y convertirla en inventario gobernado. Dos, tratar a procurement y a gestión de terceros como piezas estratégicas, no como trámites. Tres, dejar de pensar que privacidad, ciberseguridad, relaciones laborales y cumplimiento de IA son equipos que se avisan al final.
Si algo revela este episodio es que el cumplimiento serio en IA no va de escribir principios. Va de controlar sistemas reales, decisiones reales y proveedores reales. Menos manifiestos. Más trazabilidad.
Porque diciembre de 2027 parece lejos hasta que uno empieza a revisar contratos firmados en 2025, pilotos lanzados en 2026 y plataformas que se actualizan solas cada dos semanas. Entonces el calendario deja de ser una abstracción y se convierte en lo que siempre fue: una cuenta atrás bastante corta.
Nota editorial
Resumen semanal gratis
Suscríbete al resumen semanal y te avisamos de cada cambio en AI Act: clasificación de riesgo de tus sistemas de IA y obligaciones por nivel.
¿Necesitas priorizar acciones ya? Empieza un GAP Assessment AI Act.
Aporta contexto, plantea una duda o responde a la conversación. Los comentarios son públicos y moderables.
Cargando comentarios…