AI Act key dates: qué debe hacer tu empresa en cada hito regulatorio

La línea temporal completa del AI Act

El Reglamento (UE) 2024/1689 entró en vigor el 1 de agosto de 2024, veinte días después de su publicación en el Diario Oficial. Pero la aplicación se estructuró de forma escalonada para dar tiempo a las empresas y a los Estados miembros a adaptarse. El resultado es un AI Act timeline con cuatro hitos principales que toda organización que opere en la UE debe tener interiorizado:

La clave es que los dos primeros hitos ya han pasado. Febrero y agosto de 2025 no son fechas futuras: son obligaciones que llevan meses en vigor y que las autoridades nacionales —AESIA y AEPD en España— pueden ya inspeccionar y sancionar.

Qué significa cada fecha para las empresas

2 de febrero de 2025: prohibiciones y alfabetización

Este fue el primer hito con consecuencias directas para cualquier organización que use IA. El artículo 5 prohíbe sin excepciones una serie de prácticas que el legislador consideró de riesgo inaceptable. No son sistemas de alto riesgo sujetos a cumplimiento; son sistemas directamente prohibidos:

• Sistemas de manipulación subliminal que exploten vulnerabilidades psicológicas.
• Social scoring por parte de poderes públicos.
• Identificación biométrica en tiempo real en espacios públicos por parte de fuerzas de seguridad, con excepciones tasadas muy específicas.
• Sistemas de inferencia de emociones en entornos laborales y educativos.
• Categorización biométrica para deducir raza, opiniones políticas, creencias religiosas o datos biométricos sensibles.

Junto a las prohibiciones, el artículo 4 estableció la obligación de alfabetización en IA: proveedores y desplegadores deben garantizar que las personas que trabajan con o bajo la supervisión de sistemas de IA tengan un nivel suficiente de conocimiento sobre su funcionamiento, capacidades y limitaciones. Esto es operativo desde febrero de 2025.

2 de agosto de 2025: GPAI y gobernanza institucional

El segundo hito activó el régimen completo para los modelos de propósito general (GPAI): GPT-4, Claude, Gemini y cualquier modelo de lenguaje, imagen o código de uso general. Los proveedores de estos modelos deben mantener documentación técnica actualizada, respetar la normativa de derechos de autor en los datos de entrenamiento, publicar resúmenes de los contenidos usados en el entrenamiento y cumplir políticas de uso aceptable. Para los modelos con riesgo sistémico (los de mayor capacidad), las obligaciones son adicionales e incluyen evaluaciones de riesgos y reporte de incidentes.

A nivel institucional, el AI Office de la Comisión Europea está plenamente operativo desde agosto de 2025, con competencias exclusivas sobre GPAI. En España, la AESIA lleva operativa desde 2024. Las autoridades existen, tienen mandato y tienen capacidad sancionadora. No es un escenario hipotético.

2 de agosto de 2026: aplicación general para alto riesgo

Este es el hito que más impacta a la mayoría de organizaciones. Los artículos 8 a 15 definen el régimen completo para los sistemas de IA de alto riesgo del Anexo III: ocho categorías que van desde biometría hasta administración de justicia, pasando por educación, empleo, servicios financieros y acceso a servicios esenciales. Para estos sistemas, las AI Act obligations 2026 incluyen:

• Sistema de gestión de riesgos de IA documentado y actualizado (art. 9).
• Gobernanza de datos sobre los datasets de entrenamiento, validación y prueba (art. 10).
• Documentación técnica completa antes del despliegue (art. 11).
• Registro automático de eventos durante el ciclo de vida del sistema (art. 12).
• Transparencia e información al usuario (art. 13).
• Supervisión humana efectiva y verificable (art. 14).
• Precisión, robustez y ciberseguridad (art. 15).

El artículo 50 sobre transparencia también entra en aplicación: chatbots y sistemas que generan o manipulan contenido deben informar al usuario de que está interactuando con IA o de que el contenido ha sido generado artificialmente.

2 de agosto de 2027: sistemas embebidos en productos regulados

El último gran hito afecta a los sistemas de IA incorporados en productos cubiertos por legislación armonizada de la UE: maquinaria, productos sanitarios, vehículos, equipos de radio, juguetes y otros productos regulados por directivas o reglamentos específicos. También aplica a los modelos GPAI puestos en el mercado antes de agosto de 2025, que tienen un año adicional de margen de adaptación.

Obligaciones según el tipo de sistema: prohibido, GPAI y alto riesgo

Sistemas prohibidos: riesgo inaceptable

La lista del artículo 5 no admite matices ni excepciones comerciales. Si tu organización opera un sistema de inferencia de emociones en entornos laborales —algo que algunos proveedores de herramientas de RRHH y videovigilancia ofrecían hasta hace poco— ese sistema debe estar retirado. El cumplimiento aquí no es un programa de preparación; es una verificación de que el sistema no existe en producción.

Modelos GPAI: obligaciones para proveedores

Si tu empresa desarrolla o fine-tunea modelos de lenguaje, imagen o código de propósito general y los comercializa o pone a disposición de terceros en la UE, estás sujeto al Capítulo V. Las obligaciones van desde documentación técnica hasta políticas de uso aceptable y, para los modelos con riesgo sistémico, evaluaciones de capacidades y reporte de incidentes al AI Office.

Si usas modelos GPAI de terceros (OpenAI, Anthropic, Google) pero no los desarrollas, tus obligaciones son las del desplegador, no las del proveedor. Pero debes poder acreditar que el proveedor cumple con el Reglamento, lo que en la práctica implica revisar contratos y documentación técnica de los modelos que integras.

Sistemas de alto riesgo: el núcleo del AI Act compliance

Los AI Act high-risk requirements son el bloque más exigente del Reglamento. Un sistema entra en la categoría de alto riesgo si pertenece a una de las ocho áreas del Anexo III o si está embebido en un producto regulado del Anexo I. La clasificación es responsabilidad del proveedor, y equivocarse en la clasificación — asumir que un sistema no es de alto riesgo cuando sí lo es— tiene las mismas consecuencias que no cumplir.

Para estos sistemas, el cumplimiento no es un documento: es un sistema de gestión operativo con registros, revisiones periódicas y evidencia auditab. Consulta el artículo Cómo implementar un Data Governance Framework efectivo en la era del AI Act para ver cómo estructurar la capa de datos que los sustenta.

Qué deben hacer las empresas en cada hito: visión operativa

Lo que debería estar hecho ya (feb y ago 2025)

Si no está hecho, es urgente. No en el sentido de "hay que planificarlo": en el sentido de que ya es auditable. Las AI Act obligations 2025 que deberían estar operativas son:

• Inventario de sistemas de IA con clasificación de riesgo. Listado exhaustivo de todos los sistemas con componente de IA que la organización desarrolla, despliega o usa, incluyendo herramientas SaaS con IA embebida.
• Verificación de sistemas prohibidos. Revisión específica de si algún sistema en producción entra en el artículo 5. Si la respuesta es sí, retirada inmediata.
• Programa de alfabetización en IA documentado. Formación adaptada al rol, registrable y verificable para todo el personal que trabaja con sistemas de IA.
• Gobernanza interna con responsables designados. Un AI Governance Officer, comité ad hoc o extensión del DPO con mandato claro sobre el cumplimiento del Reglamento.
• Revisión de contratos con proveedores GPAI. Validar que los modelos de terceros que se integran cumplen con el Capítulo V y documentarlo.

Lo que debe estar listo para agosto de 2026

Para los sistemas clasificados como de alto riesgo, el cumplimiento completo de los artículos 8 a 15 debe estar operativo el 2 de agosto de 2026. Los pasos críticos son:

• Sistema de gestión de riesgos de IA documentado, iterativo y vinculado al ciclo de vida del sistema.
• Gobernanza de datos sobre datasets (art. 10): origen, transformaciones, criterios de selección, análisis de sesgos, métricas de representatividad.
• Documentación técnica previa al despliegue (art. 11): arquitectura, datos de entrenamiento, métricas de rendimiento y limitaciones conocidas.
• Logging automático de eventos (art. 12): registro de decisiones, inputs y outputs durante el ciclo de vida del sistema.
• Mecanismos de supervisión humana efectivos y verificables (art. 14).
• Registro en la base de datos de la UE para los sistemas de alto riesgo que así lo requieran.

Cómo preparar controles, linaje, roles y documentación

Gestionar el cumplimiento del AI Act en entornos complejos —múltiples sistemas, múltiples equipos, múltiples jurisdicciones dentro de la UE— requiere una infraestructura de gobernanza que va más allá de un checklist. En la práctica, los cuatro pilares que sostienen el cumplimiento son:

Roles con mandato claro

El AI Act distingue entre proveedores (quienes desarrollan o ponen en el mercado el sistema), desplegadores (quienes lo usan en un contexto específico) e importadores y distribuidores. Esta distinción tiene consecuencias en las obligaciones concretas de cada parte. Internamente, la organización necesita asignar responsabilidades claras: quién clasifica los sistemas, quién mantiene la documentación técnica, quién gestiona los logs de auditoría y quién responde ante AESIA o la AEPD en una inspección.

En organizaciones con sistemas de IA gestionados en entornos multi-entidad, como los grupos empresariales con varias filiales, esta asignación de roles debe contemplar tanto el nivel corporativo —políticas y estándares— como el nivel local —implementación y evidencia por entidad.

Linaje de datos como base de la auditoría

El artículo 10 del AI Act es, en esencia, un requisito de data governance: los datos de entrenamiento deben ser conocidos, documentados y trazables. Esto no se improvisa en el momento de la inspección. El linaje debe existir antes de que el sistema entre en producción, y debe mantenerse actualizado durante toda su vida operativa.

En entornos donde los datos de entrenamiento provienen de múltiples fuentes —datos operacionales, datos históricos, datos de terceros— el linaje end-to-end desde la fuente original hasta el modelo es el documento de trazabilidad que el regulador puede solicitar. Sin él, la documentación técnica del artículo 11 está incompleta por definición.

Documentación técnica mantenida, no creada en el último momento

Uno de los errores más frecuentes en la preparación para el AI Act es tratar la documentación técnica como un entregable puntual. El Reglamento la concibe como un documento vivo que se actualiza cuando el sistema cambia: nuevas versiones del modelo, cambios en los datos de entrenamiento, nuevos casos de uso o nuevas limitaciones identificadas en producción.

La documentación mínima por sistema de alto riesgo incluye: descripción del propósito y alcance, arquitectura técnica, descripción y métricas de los datasets usados, proceso de validación y prueba, métricas de rendimiento y umbrales de aceptación, análisis de sesgos, limitaciones conocidas y proceso de supervisión humana.

Logging y auditoría continua

El artículo 12 exige que los sistemas de alto riesgo generen automáticamente registros de eventos durante su ciclo de vida. Estos logs deben ser suficientes para reconstruir las circunstancias de cualquier decisión relevante del sistema: qué input recibió, qué output produjo, en qué contexto y con qué nivel de confianza. En la práctica, esto requiere integrar el logging en el propio diseño del sistema, no añadirlo como una capa posterior.

Para los desplegadores, los logs deben conservarse durante el periodo que establezca el proveedor y, en cualquier caso, un mínimo de seis meses o hasta la resolución de cualquier investigación regulatoria en curso.

Lo que he visto en entornos complejos y auditables

Caso 1 — Clasificación de riesgo en un grupo multi-entidad

En entornos con múltiples unidades de negocio —como los grupos de transporte aéreo con operaciones en distintos mercados europeos— el inventario de sistemas de IA revela invariablemente sistemas que nadie había clasificado formalmente. Herramientas de optimización de rutas, sistemas de pricing dinámico, modelos de predicción de demanda y plataformas de gestión de recursos humanos con componente analítico pueden entrar en el Anexo III dependiendo de cómo se usen y qué decisiones apoyen.

La clasificación de riesgo no es un ejercicio técnico: es un ejercicio jurídico-técnico que requiere cruzar la descripción funcional del sistema con los criterios del Reglamento. En la práctica, los equipos legales y los equipos de datos deben trabajar juntos en este inventario, y el resultado debe estar documentado con evidencia de la metodología usada. Un sistema clasificado como de bajo riesgo sin justificación documentada es casi tan problemático como uno de alto riesgo sin cumplimiento.

Caso 2 — Workflows de acceso y logging en Snowflake para sistemas auditables

Gestionar datos en entornos auditables con múltiples aerolíneas enseña rápidamente que la trazabilidad no es un requisito del AI Act: es una necesidad operativa. Los workflows de acceso a los datos de entrenamiento —quién extrajo qué dato, cuándo, con qué propósito y bajo qué aprobación— son exactamente el tipo de evidencia que el artículo 10 del AI Act formaliza como obligación.

Implementar RBAC granular en Snowflake con logging de queries y workflows de aprobación documentados no solo cumple con el Reglamento: también reduce el tiempo de respuesta ante cualquier auditoría interna o externa. La infraestructura de gobernanza de datos que se construye para operar bien es la misma que se necesita para demostrar cumplimiento.

Caso 3 — Linaje de datos como evidencia de cumplimiento del art. 10

En proyectos de BI para equipos comerciales, el linaje de datos suele ser el primer elemento que se sacrifica cuando hay presión de tiempo. El resultado es que, meses después, nadie puede explicar de dónde viene un campo específico en un modelo de scoring o en una segmentación de clientes. Para el AI Act, esa situación es inaceptable en sistemas de alto riesgo.

Establecer el linaje end-to-end desde el principio —fuente transaccional, transformación en dbt, modelo semántico, dataset de entrenamiento— convierte la documentación técnica del artículo 11 en un artefacto que se genera casi automáticamente a partir de lo que ya existe en el catálogo de metadatos, en lugar de ser un documento creado ad hoc para el regulador.

Errores frecuentes en la preparación para el AI Act

El AI Act enforcement ya es una realidad, y los patrones de error que se observan en el mercado tienen un coste que va más allá de las multas. Estos son los más frecuentes:

• Tratar agosto de 2026 como la única fecha que importa. Las obligaciones de febrero y agosto de 2025 ya están en vigor. Empresas que todavía no tienen el inventario de sistemas hecho, ni el programa de alfabetización documentado, están ya en incumplimiento.
• Asumir que el tamaño exime. El AI Act aplica por tipo de uso, no por tamaño de empresa. Una pyme que use un sistema de scoring de crédito o de evaluación de candidatos tiene las mismas obligaciones que una gran corporación para ese sistema específico.
• Delegar toda la responsabilidad en el proveedor tecnológico. Si tu empresa despliega un sistema de IA de alto riesgo desarrollado por un tercero, eres el desplegador y tienes obligaciones propias que no desaparecen porque el proveedor cumpla con las suyas. Ambas responsabilidades coexisten.
• Clasificar todos los sistemas como de bajo o mínimo riesgo por defecto. La clasificación de riesgo debe hacerse con criterios documentados y cruzando la funcionalidad del sistema con el Anexo III. Una clasificación sin justificación es una clasificación sin valor ante el regulador.
• Crear la documentación técnica justo antes de la inspección. El artículo 11 exige documentación previa al despliegue. Una documentación redactada a posteriori, aunque sea técnicamente correcta, es difícilmente defendible como evidencia de cumplimiento real.
• Ignorar la AEPD como segunda autoridad. En España, la AEPD puede actuar sobre sistemas de IA que traten datos personales incluso antes de la aplicación plena del AI Act, bajo el RGPD. Muchos sistemas de alto riesgo tratan datos personales. Esto significa dos autoridades con capacidad de inspección, no una.

Conclusión: el AI Act no es un proyecto, es una fecha con consecuencias

Las AI Act compliance deadlines no esperan. Los dos primeros hitos ya han pasado y las obligaciones que activaron son auditables hoy. Agosto de 2026 está a meses, no a años. Y la preparación para el artículo 10 —gobernanza de datos de entrenamiento— requiere infraestructura que no se construye en semanas.

La buena noticia es que las organizaciones que ya operan con data governance real —linaje documentado, roles con autoridad, acceso controlado y calidad medida— tienen una base sólida para adaptarse. El cumplimiento del AI Act no es un proyecto paralelo: es la extensión natural de una gobernanza de datos madura hacia los sistemas de inteligencia artificial que esa gobernanza alimenta.

Las que no tienen esa base deben empezar ya, con una priorización clara: primero el inventario y la clasificación de riesgo, después la gobernanza de datos de los sistemas de alto riesgo, después la documentación técnica y el logging. No todo a la vez, pero todo antes de que el regulador llame.

Checklist: preparación por hito del AI Act

• Inventario completo de sistemas de IA (propios, desplegados y SaaS con IA embebida).
• Clasificación de riesgo de cada sistema con justificación documentada (Anexo III).
• Verificación de ausencia de sistemas prohibidos del artículo 5 en producción.
• Programa de alfabetización en IA documentado, adaptado al rol y verificable (art. 4).
• Gobernanza interna con responsables designados (AI Governance Officer o equivalente).
• Contratos con proveedores GPAI revisados y cumplimiento del Capítulo V acreditado.
• Sistema de gestión de riesgos de IA operativo para sistemas de alto riesgo (art. 9).
• Gobernanza de datasets de entrenamiento: origen, transformaciones y análisis de sesgos (art. 10).
• Documentación técnica completa y previa al despliegue para sistemas de alto riesgo (art. 11).
• Logging automático de eventos durante el ciclo de vida de sistemas de alto riesgo (art. 12).
• Mecanismos de supervisión humana efectivos y verificables (art. 14).
• Registro en la base de datos de la UE para los sistemas que lo requieran.

Preguntas frecuentes sobre las fechas clave del AI Act

¿Cuáles son las fechas clave del AI Act que toda empresa debe conocer?

Las cuatro fechas principales son: 2 de febrero de 2025 (prohibiciones del art. 5 y alfabetización en IA), 2 de agosto de 2025 (modelos GPAI y gobernanza institucional), 2 de agosto de 2026 (aplicación general para sistemas de alto riesgo del Anexo III y transparencia del art. 50) y 2 de agosto de 2027 (sistemas de alto riesgo embebidos en productos regulados por legislación armonizada). Los dos primeros ya están en vigor.

¿Qué empresas están obligadas por el AI Act?

El AI Act aplica a cualquier organización que desarrolle, despliegue o use sistemas de IA en la Unión Europea, independientemente de dónde esté establecida. El criterio es el mercado donde opera el sistema, no la sede de la empresa. Esto incluye empresas de fuera de la UE cuyos sistemas afecten a personas en territorio europeo.

¿Qué son los sistemas de IA de alto riesgo según el AI Act?

Son sistemas de IA que pueden afectar derechos fundamentales o la seguridad de las personas. El Anexo III define ocho categorías: biometría, infraestructuras críticas, educación, empleo y RRHH, acceso a servicios esenciales (crédito, seguros, vivienda), aplicación de la ley, gestión de fronteras y migración, y administración de justicia y procesos democráticos.

¿Qué es la alfabetización en IA que exige el AI Act?

El artículo 4 obliga a proveedores y desplegadores a garantizar que el personal que trabaja con sistemas de IA tenga un nivel suficiente de conocimiento sobre su funcionamiento, limitaciones y riesgos. La formación debe ser documentada, adaptada al rol y verificable. El envío de un PDF informativo no cumple con el espíritu de la norma según la interpretación de la Comisión y la AEPD.

¿Qué multas prevé el AI Act por incumplimiento?

Las sanciones se gradúan por tipo de infracción: hasta 35 millones de euros o el 7% de la facturación global anual por vulnerar las prohibiciones del artículo 5; hasta 15 millones o el 3% de la facturación por incumplir obligaciones de proveedores o desplegadores; y hasta 7,5 millones o el 1,5% por proporcionar información incorrecta a las autoridades. Se aplica siempre el importe mayor entre la cifra fija y el porcentaje de facturación.