La mayoria de empresas medianas espanolas han recibido ya una propuesta de “auditoria EU AI Act” de alguna consultora. El documento de 80 paginas llega, se archiva, y la empresa sigue igual.
El EU AI Act no es RGPD. No va a esperarte tres anos mientras organizas un workshop.
El Reglamento (UE) 2024/1689 entro en vigor el 1 de agosto de 2024. Los plazos son escalonados. Algunos ya vencieron. Otros llegan en agosto y octubre de 2026. Si tu empresa usa sistemas de IA en procesos de RRHH, scoring de credito, clasificacion de seguros, priorizacion de servicios publicos o cualquier interaccion automatizada con empleados o clientes — hay algo que debes hacer este trimestre.
Este post no es un resumen del Reglamento. Es una lista de las cinco acciones concretas que un CEO de empresa mediana espanola puede ejecutar antes de octubre sin contratar un ejercito de consultores.
Contexto: que plazos importan en 2026
El calendario del EU AI Act para 2026 tiene tres fechas criticas:
-
Febrero 2026: prohibicion de practicas IA de riesgo inaceptable (Articulo 5). Esto incluye sistemas de puntuacion social, manipulacion subliminal y explotacion de vulnerabilidades. Si algo de esto corre en tu empresa, deberia estar ya parado.
-
Agosto 2026: aplicacion de obligaciones para sistemas de IA de proposito general (GPAI) con impacto sistemico. Esto afecta principalmente a proveedores de modelos grandes, pero tambien a empresas que los integran en productos propios.
-
Agosto 2026 tambien: los organos de supervision nacional (en Espana, la AESIA — Agencia Espanola de Supervision de Inteligencia Artificial) tienen que estar operativos. Las primeras inspecciones formales pueden empezar en otono.
El plazo de agosto 2026 para sistemas de alto riesgo (Articulo 6 y Anexo III) es el que mas probabilidad tiene de afectar a empresa mediana. Evaluacion de empleados, scoring de candidatos, sistemas de concesion de credito, gestion de seguros, infraestructura critica.
Accion 1: inventario de sistemas IA con clasificacion de riesgo
El Articulo 6 del Reglamento define los sistemas de alto riesgo. La lista es concreta. Algunos ejemplos directamente relevantes para empresa mediana espanola:
- Software de seleccion de personal o evaluacion de candidatos (Anexo III, punto 4a)
- Sistemas de gestion y evaluacion del desempeno de empleados (punto 4b)
- Scoring de solvencia o evaluacion de riesgo crediticio de personas fisicas (punto 5b)
- Sistemas que determinan acceso a servicios o priorizan solicitudes (punto 5c)
Si usas Workday, SAP SuccessFactors, HireVue, Factorial, o cualquier herramienta con algoritmos de evaluacion o scoring — tienes que saber si ese sistema entra en la definicion de alto riesgo.
La accion practica: crea una hoja de calculo con todos los sistemas de software que toman o influyen en decisiones sobre personas (empleados, candidatos, clientes, proveedores). Para cada uno, responde: usa un modelo de IA o ML? Que decision influye? Sobre quien? Con que frecuencia?
No necesitas un consultor para hacer esto. Necesitas dos horas con tu CTO o IT manager y acceso a los contratos de software.
Accion 2: Decision Rights Map para oversight humano
El Articulo 22 establece el derecho a que las decisiones significativas sobre personas no sean tomadas exclusivamente por sistemas automatizados, con la posibilidad de revision humana.
El Articulo 14 va mas alla: para sistemas de alto riesgo, obliga a que haya supervision humana efectiva. No supervision performativa. Supervision que puede intervenir, corregir y anular la decision del sistema.
El problema en la mayoria de empresas medianas: nadie sabe exactamente que decisiones toma un sistema y cuales toma un humano basandose en la recomendacion del sistema. Son preguntas distintas con respuestas distintas.
La accion practica: para cada sistema identificado en el paso anterior, documenta quien tiene autoridad para anular la recomendacion del sistema, en que tiempo, con que proceso. Si la respuesta es “nadie sabe” o “no hay proceso”, eso es un gap de compliance concreto.
Un Decision Rights Map para AI no es un organigrama. Es una lista de decisiones, con su sistema IA asociado, su owner humano responsable, y el proceso de override. Puede ser una tabla de 20 filas. No necesita ser un framework metodologico.
Accion 3: log y audit trail por output de sistema IA
El Articulo 12 obliga a los sistemas de alto riesgo a tener capacidades de registro automatico de logs suficientes para auditar su funcionamiento. El Articulo 13 exige transparencia: documentacion tecnica accesible.
Para empresa mediana, la interpretacion practica es esta: si un sistema IA toma o influye en una decision sobre una persona, debe existir un registro de que input recibio el sistema, que output produjo, cuando, y que decision humana siguio.
Esto no es solo proteccion legal. Es operativamente util. Si un candidato rechazado pregunta por que, o si un empleado impugna una evaluacion, la empresa necesita poder reconstruir el proceso.
La accion practica: revisa los contratos con tus proveedores de software. Pregunta explicitamente: el sistema genera logs auditables de sus outputs con timestamp? Quien tiene acceso? Durante cuanto tiempo se retienen? Si el proveedor no puede responder estas preguntas, eso es un riesgo que debes documentar.
Para sistemas internos o desarrollados a medida, la obligacion recae directamente sobre tu empresa como desplegadora.
Accion 4: DPIA actualizado con interaccion AI Act mas RGPD
Esta es la que mas empresas medianas ignoran porque requiere entender como interactuan dos regulaciones distintas.
El EU AI Act no reemplaza el RGPD. Los coexisten. Cuando un sistema de IA procesa datos personales — y casi todos lo hacen — aplican simultaneamente las obligaciones del AI Act y las del RGPD.
El Considerando 10 del Reglamento explicita que AI Act y RGPD son complementarios. La Evaluation de Impacto en la Proteccion de Datos (DPIA/EIPD) que tu empresa hizo en 2018-2019 para el RGPD probablemente no contempla los sistemas de IA actuales, no documenta el riesgo de sesgo algoritmico, y no incluye los derechos especificos del AI Act.
La accion practica: toma la lista de sistemas IA del paso uno y verifica si cada uno tiene una DPIA vigente que mencione explicitamente el uso de IA, el riesgo de sesgo, y los mecanismos de supervision humana. Si no existe, o si la existente tiene mas de dos anos y no menciona IA — actualiza.
Esto no es tarea de una manana, pero si es tarea que tu DPO o asesor legal puede gestionar en semanas, no meses, si tiene la lista de sistemas del paso uno.
Accion 5: clausulas vendor en contratos de software IA
Esta accion es la mas ignorada y potencialmente la mas importante.
El EU AI Act distribuye responsabilidades entre proveedores de sistemas IA y desplegadores. Cuando compras un sistema de alto riesgo, hay obligaciones que recaen sobre el proveedor — pero hay otras que recaen sobre ti como empresa que lo despliega.
El Articulo 16 lista las obligaciones del proveedor. El Articulo 25 aplica algunas de esas obligaciones al desplegador cuando el proveedor no esta establecido en la UE o cuando el sistema se modifica sustancialmente.
La accion practica: para cada contrato de software con sistema IA de potencial alto riesgo, verifica que incluye:
- Declaracion explicita de si el sistema es clasificado de alto riesgo bajo el Reglamento
- Compromiso del proveedor de mantener documentacion tecnica accesible (Articulo 11)
- Procedimiento de notificacion si el sistema cambia de forma que altere su clasificacion de riesgo
- Clausula de data sovereignty: donde se procesan los datos, bajo que jurisdiccion, con que garantias para datos de ciudadanos europeos
- Acceso a logs de auditoria suficientes para cumplir obligaciones del desplegador
Si tu contrato actual no tiene estas clausulas, el proximo ciclo de renovacion es el momento para negociarlas. Si el proveedor no acepta incluirlas, eso es informacion relevante para la decision de renovar o no.
Lo que no te protege
Un PDF de “politica de uso de IA” colgado en la intranet no es compliance.
Un workshop de sensibilizacion sobre el AI Act no es compliance.
Un informe de auditoria de 80 paginas que describe riesgos pero no cambia ningun proceso no es compliance.
Compliance real es: saber que sistemas IA tiene tu empresa, clasificarlos, documentar quien supervisa sus outputs, asegurar que los contratos de proveedor cubren tus obligaciones como desplegador, y mantener logs auditables.
Son cinco acciones. Ninguna requiere un programa de transformacion de 18 meses. Requieren tiempo, voluntad y claridad sobre que sistema hace que.
Next action
Empieza por el inventario. Una hoja de calculo con todos los sistemas de software que usan IA o ML, la decision que influyen y sobre quien. Dos horas con tu CTO. Sin eso, todo lo demas es teorico.
Si necesitas un marco de clasificacion de riesgo en castellano alineado con el Anexo III del Reglamento, o quieres revisar si tus contratos de software cubren las obligaciones como desplegador, abre un diagnostico.