AI Act 2026: qué cambia y cómo preparar tu estrategia de IA

El calendario del AI Act ha cambiado. Con la entrada en vigor del nuevo AI Omnibus, algunas de las obligaciones para sistemas de inteligencia artificial de alto riesgo que estaban previstas para 2026 se han retrasado hasta 2027 y 2028. 

Para muchas organizaciones, supone un alivio. 

Pero también plantea una cuestión más importante: 

¿Qué deberían hacer las empresas con este tiempo adicional? 

Porque retrasar una obligación regulatoria no significa retrasar las decisiones de arquitectura, gobernanza y gestión de datos que harán posible cumplirla cuando llegue el momento. 

De hecho, para las organizaciones que están incorporando IA a procesos reales de negocio, este puede ser precisamente el momento de revisar cómo están construyendo sus sistemas. 

¿Qué ha cambiado con el AI Omnibus? 

El AI Omnibus introduce cambios para simplificar y facilitar la aplicación del AI Act, entre ellos una ampliación de los plazos para determinadas obligaciones relacionadas con los sistemas de IA de alto riesgo. El nuevo marco entró en vigor el 27 de julio de 2026. 

El cambio más relevante para muchas organizaciones afecta al calendario de aplicación de las obligaciones para sistemas de alto riesgo. 

Sistemas de alto riesgo del Anexo III: diciembre de 2027 

Las obligaciones establecidas para los sistemas clasificados como de alto riesgo bajo el artículo 6(2) y el Anexo III pasan a aplicarse a partir del 2 de diciembre de 2027. Esto incluye determinados usos de IA en ámbitos como biometría, infraestructuras críticas, educación, empleo, migración o control fronterizo. 

Sistemas de alto riesgo del Anexo I: agosto de 2028 

Para los sistemas clasificados como de alto riesgo bajo el artículo 6(1) y el Anexo I, la aplicación de las obligaciones correspondientes se retrasa hasta el 2 de agosto de 2028. 

Esta categoría está relacionada con sistemas de IA integrados en determinados productos regulados, como maquinaria, juguetes o ascensores, sujetos a legislación europea de armonización. 

No todo el AI Act se ha retrasado

Este punto es importante. 

El nuevo calendario no significa que el AI Act haya quedado en pausa. Algunas obligaciones ya son aplicables. Las prohibiciones de determinadas prácticas de IA y las obligaciones de alfabetización en IA comenzaron a aplicarse en febrero de 2025, mientras que las reglas de gobernanza y determinadas obligaciones para proveedores de modelos de IA de propósito general (GPAI) son aplicables desde agosto de 2025. 

Además, existen fechas específicas para determinadas obligaciones de transparencia. Por ejemplo, los proveedores de determinados sistemas que generan contenido sintético y que ya estaban en el mercado antes del 2 de agosto de 2026 deben adoptar las medidas necesarias para cumplir determinadas obligaciones de marcado antes del 2 de diciembre de 2026. 

Por eso, hablar simplemente de un “retraso del AI Act” puede resultar engañoso. 

El calendario ha cambiado, pero la regulación sigue avanzando. 

¿Qué significa el retraso del AI Act para las empresas? 

Para las organizaciones que estaban trabajando con plazos ajustados, tener más tiempo puede ser positivo. Pero existe un riesgo: interpretar ese tiempo adicional como una razón para esperar. Cuando una obligación regulatoria se retrasa, es fácil pensar: “Ya lo abordaremos cuando sea obligatorio.” 

El problema es que muchas de las decisiones necesarias para cumplir con el AI Act no se toman al final del proyecto. 

Se toman mucho antes. 

Por ejemplo: 

-¿Dónde se procesan los datos? 
-¿Quién puede acceder a ellos? 
-¿Qué información sale de la organización? 
-¿Podemos controlar cómo se utilizan los datos durante todo el ciclo de vida del sistema? 
-¿Tenemos trazabilidad sobre las decisiones y resultados del sistema? 
-¿Cómo se supervisa el sistema una vez está desplegado? 
-¿Qué ocurre cuando necesitamos cambiar o actualizar el modelo? 
-¿Dependemos de proveedores externos para componentes críticos de nuestra arquitectura? 

Estas no son únicamente preguntas de compliance. Son decisiones de arquitectura. 

Y cuanto más integrada está la IA en procesos reales, más difícil y costoso puede ser modificar esa arquitectura después. 

AI compliance también es una cuestión de arquitectura 

Prepararse para el AI Act no debería consistir únicamente en añadir documentación o controles cuando se acerca una fecha límite. 

Para muchas organizaciones, el reto empieza mucho antes: cómo diseñar sistemas de IA que permitan mantener el control sobre los datos, documentar su funcionamiento y gestionar los riesgos durante todo su ciclo de vida. 

Esto es especialmente relevante en sectores donde los sistemas de IA trabajan con información sensible o participan en procesos críticos. 

En sanidad, por ejemplo, los datos pueden incluir información clínica y personal especialmente sensible. 

En banca y servicios financieros, los sistemas pueden trabajar con información económica y utilizarse en procesos relacionados con decisiones relevantes para las personas. 

En industria, la IA puede estar conectada a procesos operativos, infraestructuras o sistemas productivos. 

Y en la administración pública, puede formar parte de servicios que afectan directamente a ciudadanos. 

En estos contextos, la gobernanza de los datos no puede ser una capa que se añade al final. 

Tiene que formar parte del diseño. 

¿Qué deberían hacer las empresas antes de 2027? 

El nuevo calendario ofrece algo que muchas organizaciones necesitan: tiempo. 

La cuestión es cómo utilizarlo. 

1. Identificar los casos de uso de IA

Antes de hablar de compliance, es necesario entender dónde se está utilizando —o se quiere utilizar— IA dentro de la organización. 

-¿Qué sistemas existen actualmente? 

-¿Qué proyectos están en desarrollo? 

-¿Qué casos de uso están previstos para los próximos 12-24 meses? 

Y, sobre todo, ¿qué impacto pueden tener esos sistemas sobre datos, procesos y personas? 

2. Mapear los datos y su recorrido

Una estrategia de IA necesita algo más que conocer qué datos utiliza un modelo. 

Es necesario entender dónde están los datos, dónde se procesan, quién puede acceder a ellos y qué información debe salir de la organización. 

Este mapa puede revelar dependencias y riesgos que no son evidentes cuando se analiza únicamente el modelo. 

3. Revisar la arquitectura de IA

La arquitectura condiciona muchas de las decisiones posteriores. 

– ¿Los datos necesitan centralizarse? 

– ¿Es necesario mover información sensible para entrenar un modelo? 

– ¿Dónde se ejecuta la inferencia? 

– ¿Cómo se actualizan los modelos? 

– ¿Qué ocurre si participan varias organizaciones en el entrenamiento? 

Responder estas preguntas antes del despliegue puede evitar cambios estructurales más adelante. 

4. Diseñar la trazabilidad y la gobernanza desde el principio

La capacidad de demostrar cómo se utiliza un sistema de IA es tan importante como su capacidad para generar buenos resultados. 

Por eso, la trazabilidad, la documentación, los controles de acceso y los mecanismos de supervisión deberían formar parte del sistema desde el principio. 

5. Prepararse para colaborar sin perder el control de los datos

En muchos sectores, los mejores modelos necesitan datos procedentes de diferentes organizaciones. 

Pero compartir esos datos no siempre es una opción. 

Esto plantea una cuestión estratégica diferente: 

¿Cómo podemos colaborar para desarrollar mejores sistemas de IA sin tener que centralizar los datos? 

Aquí es donde arquitecturas como Federated Learning pueden desempeñar un papel relevante. 

Sherpa AI: entrenar IA sin centralizar los datos 

Federated Learning permite entrenar modelos de machine learning de forma distribuida: los datos permanecen en los entornos donde ya se encuentran y el entrenamiento se realiza localmente. 

En lugar de trasladar todos los datos a un repositorio central, se intercambian actualizaciones del modelo que pueden agregarse para mejorar el sistema global. 

El principio es sencillo: 

la IA va a los datos, no los datos a la IA. 

Este enfoque puede ser especialmente relevante en entornos donde varias organizaciones necesitan colaborar pero no pueden o no deberían centralizar información sensible. 

Por ejemplo, diferentes hospitales pueden querer colaborar para desarrollar modelos de IA utilizando información clínica procedente de distintas fuentes. 

Un banco puede necesitar entrenar modelos con información distribuida entre diferentes entidades o entornos. 

Una organización industrial puede querer aprovechar datos procedentes de diferentes plantas sin trasladar todos sus datos operativos a un único repositorio. 

En estos casos, la cuestión no es simplemente cómo conseguir más datos. 

Es cómo aprovechar más datos manteniendo el control sobre ellos. 

 

El retraso del AI Act puede ser una oportunidad 

El nuevo calendario ofrece a las organizaciones más tiempo para prepararse. 

Pero ese tiempo no debería utilizarse únicamente para esperar a que llegue la próxima fecha regulatoria. 

Puede utilizarse para tomar decisiones que serán mucho más difíciles de cambiar después: 

definir una arquitectura de IA adecuada; 
establecer políticas de acceso y gobernanza; 
mejorar la trazabilidad; 
identificar y clasificar los casos de uso; 
evaluar los riesgos asociados a cada sistema; 
revisar cómo se procesan los datos; 
y explorar formas de colaborar sin centralizar información sensible. 

El objetivo no debería ser simplemente estar preparado para cumplir con el AI Act. 

Debería ser construir una infraestructura de IA que pueda seguir funcionando a medida que cambien la regulación, los modelos y las necesidades del negocio. 

¿Por qué Sherpa.ai? 

En Sherpa.ai trabajamos con organizaciones que necesitan incorporar inteligencia artificial en entornos donde los datos no pueden tratarse como una variable secundaria. 

Nuestra aproximación parte de una idea sencilla: 

Las organizaciones deberían poder innovar con IA sin perder el control sobre sus datos. 

El retraso de determinadas obligaciones del AI Act ofrece una oportunidad para hacerlo bien desde el principio. 

Para explorar casos de uso. 

Para validar arquitecturas. 

Para establecer mecanismos de control. 

Y para entender cómo incorporar IA en procesos reales sin tener que elegir entre innovación y control sobre los datos. 

Porque el objetivo no debería ser llegar a 2027 o 2028 y empezar entonces a resolver estos problemas. 

Debería ser llegar a esas fechas con sistemas que ya hayan sido diseñados teniendo en cuenta cómo queremos utilizar la IA a largo plazo. 

Por eso, quizá la pregunta no debería ser: 

“¿Cuánto tiempo tenemos hasta que sea obligatorio?” 

Sino: 

“¿Estamos construyendo hoy una IA que podremos seguir utilizando cuando esas obligaciones sean aplicables?” 

Si estás revisando tu estrategia de IA de cara a 2027 y quieres compartir cómo estáis abordando estos retos en tu organización, hablemos. 

Preguntas frecuentes sobre el AI Act 


¿Cuándo se aplican las obligaciones para sistemas de IA de alto riesgo? 

Con el nuevo calendario, las obligaciones para sistemas clasificados como de alto riesgo bajo el Anexo III se aplican desde el 2 de diciembre de 2027. Para los sistemas de alto riesgo integrados en determinados productos regulados bajo el Anexo I, la fecha es el 2 de agosto de 2028. 

¿Significa el nuevo calendario que las empresas pueden esperar para prepararse? 

No necesariamente. Algunas obligaciones del AI Act ya son aplicables y, además, muchas de las decisiones necesarias para cumplir con las futuras obligaciones afectan a la arquitectura, los datos, la trazabilidad y la gobernanza de los sistemas. 

¿Qué es el AI Omnibus? 

El AI Omnibus es el Re 

Scroll al inicio