La mayoría de empresas medianas españolas han recibido ya una propuesta de “auditoría EU AI Act” de alguna consultora. El documento de 80 páginas llega, se archiva, y la empresa sigue igual.
El EU AI Act no es RGPD. No va a esperarte tres años 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 crédito, clasificación de seguros, priorización de servicios públicos o cualquier interacción 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 española 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 críticas:
-
Febrero 2026: prohibición de prácticas IA de riesgo inaceptable (Artículo 5). Esto incluye sistemas de puntuación social, manipulación subliminal y explotación de vulnerabilidades. Si algo de esto corre en tu empresa, debería estar ya parado.
-
Agosto 2026: aplicación de obligaciones para sistemas de IA de propósito general (GPAI) con impacto sistémico. Esto afecta principalmente a proveedores de modelos grandes, pero también a empresas que los integran en productos propios.
-
Agosto 2026 también: los órganos de supervisión nacional (en España, la AESIA — Agencia Española de Supervisión 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 (Artículo 6 y Anexo III) es el que más probabilidad tiene de afectar a empresa mediana. Evaluación de empleados, scoring de candidatos, sistemas de concesión de crédito, gestión de seguros, infraestructura crítica.
Acción 1: inventario de sistemas IA con clasificación de riesgo
El Artículo 6 del Reglamento define los sistemas de alto riesgo. La lista es concreta. Algunos ejemplos directamente relevantes para empresa mediana española:
- Software de selección de personal o evaluación de candidatos (Anexo III, punto 4a)
- Sistemas de gestión y evaluación del desempeño de empleados (punto 4b)
- Scoring de solvencia o evaluación de riesgo crediticio de personas físicas (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 evaluación o scoring — tienes que saber si ese sistema entra en la definición de alto riesgo.
La acción práctica: crea una hoja de cálculo 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 decisión 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.
Acción 2: Decisión Rights Map para oversight humano
El Artículo 22 establece el derecho a que las decisiones significativas sobre personas no sean tomadas exclusivamente por sistemas automatizados, con la posibilidad de revisión humana.
El Artículo 14 va más allá: para sistemas de alto riesgo, obliga a que haya supervisión humana efectiva. No supervisión performativa. Supervisión que puede intervenir, corregir y anular la decisión del sistema.
El problema en la mayoría de empresas medianas: nadie sabe exactamente que decisiones toma un sistema y cuales toma un humano basándose en la recomendación del sistema. Son preguntas distintas con respuestas distintas.
La acción práctica: para cada sistema identificado en el paso anterior, documenta quien tiene autoridad para anular la recomendación 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 Decisión 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 metodológico.
Acción 3: log y audit trail por output de sistema IA
El Artículo 12 obliga a los sistemas de alto riesgo a tener capacidades de registro automático de logs suficientes para auditar su funcionamiento. El Artículo 13 exige transparencia: documentación técnica accesible.
Para empresa mediana, la interpretación práctica es esta: si un sistema IA toma o influye en una decisión sobre una persona, debe existir un registro de que input recibió el sistema, que output produjo, cuando, y que decisión humana siguió.
Esto no es solo protección legal. Es operativamente útil. Si un candidato rechazado pregunta por que, o si un empleado impugna una evaluación, la empresa necesita poder reconstruir el proceso.
La acción práctica: revisa los contratos con tus proveedores de software. Pregunta explícitamente: 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 obligación recae directamente sobre tu empresa como desplegadora.
Acción 4: DPIA actualizado con interacción AI Act más RGPD
Esta es la que más empresas medianas ignoran porque requiere entender como interactúan 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 simultáneamente las obligaciones del AI Act y las del RGPD.
El Considerando 10 del Reglamento explícita que AI Act y RGPD son complementarios. La Evaluation de Impacto en la Protección 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 algorítmico, y no incluye los derechos específicos del AI Act.
La acción práctica: toma la lista de sistemas IA del paso uno y verifica si cada uno tiene una DPIA vigente que mencione explícitamente el uso de IA, el riesgo de sesgo, y los mecanismos de supervisión humana. Si no existe, o si la existente tiene más de dos años y no menciona IA — actualiza.
Esto no es tarea de una mañana, 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.
Acción 5: clausulas vendor en contratos de software IA
Esta acción es la más ignorada y potencialmente la más 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 Artículo 16 lista las obligaciones del proveedor. El Artículo 25 aplica algunas de esas obligaciones al desplegador cuando el proveedor no está establecido en la UE o cuando el sistema se modifica sustancialmente.
La acción práctica: para cada contrato de software con sistema IA de potencial alto riesgo, verifica que incluye:
- Declaración explícita de si el sistema es clasificado de alto riesgo bajo el Reglamento
- Compromiso del proveedor de mantener documentación técnica accesible (Artículo 11)
- Procedimiento de notificación si el sistema cambia de forma que altere su clasificación de riesgo
- Clausula de data sovereignty: donde se procesan los datos, bajo que jurisdicción, con que garantías para datos de ciudadanos europeos
- Acceso a logs de auditoría suficientes para cumplir obligaciones del desplegador
Si tu contrato actual no tiene estas clausulas, el próximo ciclo de renovación es el momento para negociarlas. Si el proveedor no acepta incluirlas, eso es información relevante para la decisión de renovar o no.
Lo que no te protege
Un PDF de “política de uso de IA” colgado en la intranet no es compliance.
Un workshop de sensibilización sobre el AI Act no es compliance.
Un informe de auditoría de 80 páginas que describe riesgos pero no cambia ningún 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 transformación de 18 meses. Requieren tiempo, voluntad y claridad sobre que sistema hace que.
Next action
Empieza por el inventario. Una hoja de cálculo con todos los sistemas de software que usan IA o ML, la decisión que influyen y sobre quien. Dos horas con tu CTO. Sin eso, todo lo demás es teórico.
Si necesitas un marco de clasificación 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 diagnóstico.
Relacionado
- AI Governance Sprint 14 días: del caos de casos de uso al sistema operativo
- Decisión Rights Map: quien decide que en un sistema IA
- Governance vs Compliance: por que tu política no decide nada
Relacionado
- Proyecto de Ley de IA en España 2026: la multa no es el problema, el inventario sí — El Proyecto de Ley de IA en España convierte el compliance en operación: inventario, owners, supervisión humana, evidencias y….
- EO 14409: el texto oficial no confirma una prohibición de modelos abiertos — La orden estadounidense EO 14409 crea benchmarking y un marco voluntario para modelos frontera; no autoriza licencias ni….
- AI Content Labels: de aviso legal a infraestructura de confianza — Las etiquetas de contenido IA ya no son solo disclosure: conectan confianza, recomendación, monetización, compliance y procedencia….