EU AI Act 2026: Qué deben cambiar los CTO y los equipos de producto antes de implantar la IA en Europa

Durante los dos últimos años, la mayoría de las conversaciones sobre la Ley de Inteligencia Artificial de la UE se han centrado en los equipos jurídicos, los responsables de cumplimiento y los especialistas en políticas. El 2 de agosto de 2026, esto cambiará de una forma mucho más práctica para los equipos de productos, ingeniería y plataformas.

Será entonces cuando empiecen a aplicarse la mayoría de las normas de la Ley de IA, incluido el marco para los sistemas de IA de alto riesgo del anexo III y las obligaciones de transparencia del artículo 50 para determinados sistemas de IA y contenidos generados por IA. La Ley entró en vigor el 1 de agosto de 2024. Las normas sobre prácticas de IA prohibidas y alfabetización en IA se aplican desde el 2 de febrero de 2025, y las obligaciones para los modelos de IA de uso general se aplican desde el 2 de agosto de 2025. Algunas obligaciones para la IA de alto riesgo integrada en productos regulados se aplican más tarde, el 2 de agosto de 2027.

No se trata de otro resumen sobre el cumplimiento. Es una guía práctica para los equipos que diseñan, construyen, integran y distribuyen sistemas de IA: qué revisar en su arquitectura, flujos de productos, registro, documentación, dependencias de proveedores y controles operativos antes de desplegar la IA en Europa.

Por qué es importante para los directores de tecnología y los equipos de producto, y no sólo para el departamento jurídico y de cumplimiento de la normativa.

La Ley de IA de la UE está estructurada como una normativa de seguridad de los productos aplicada a la IA. Las obligaciones que impone no son principalmente ejercicios de documentación o declaraciones políticas. Son requisitos de ingeniería.

En el caso de los sistemas de IA de alto riesgo, la Ley exige un registro automático de eventos integrado en el sistema desde el principio. Requiere mecanismos de supervisión humana que no sean características añadidas. Exige que se mantenga la documentación técnica durante todo el ciclo de vida del sistema. Requiere evaluaciones de conformidad realizadas antes de la comercialización. No son cosas que un equipo jurídico pueda hacer a posteriori. Son cosas que los equipos de ingeniería tienen que diseñar, construir y mantener.

Los fallos de cumplimiento que surjan de la aplicación de 2026 no procederán de equipos que redactaron una documentación imperfecta. Provendrán de equipos que nunca clasificaron sus sistemas, que los entregaron sin puertas de gobernanza en su proceso de desarrollo y que trataron a terceros como si no existieran. Integraciones de IA como dependencias de software en lugar de componentes de IA regulados.

Los equipos de producto están igualmente expuestos. Las obligaciones de transparencia del artículo 50 exigen que se informe a los usuarios cuando interactúan con la IA. Si su sistema genera contenidos, manipula medios o toma decisiones que afectan a los usuarios, es posible que sus flujos de productos tengan que cambiar. Los puntos de contacto de consentimiento, los mecanismos de divulgación, las vías de retroceso y las rutas de escalada humana son cuestiones de diseño de producto, y necesitan respuestas antes de su despliegue.

En resumen: El cumplimiento de la Ley de Inteligencia Artificial de la UE en 2026 es, en primer lugar, un problema de producto, ingeniería y adquisición. La revisión jurídica forma parte del proceso, pero no puede sustituir a las decisiones de diseño que deberían haberse tomado en la planificación del sprint.

Qué significa realmente la fecha límite de agosto de 2026

La Ley se ha ido desplegando por fases desde su entrada en vigor en agosto de 2024. Esta es la situación actual:

A finales de 2025, la Comisión Europea propuso un paquete “Digital Omnibus” que podría ampliar hasta 16 meses determinados plazos de alto riesgo, siempre que se dispusiera de normas armonizadas. Esa propuesta no se ha confirmado como ley. Una planificación prudente considera agosto de 2026 como la fecha límite vinculante.

La Ley se aplica extraterritorialmente. Al igual que el RGPD, sigue el alcance de los resultados de su sistema, no la dirección de registro de su empresa. Si su sistema de IA se despliega en la UE o afecta a residentes de la UE, se aplica la Ley, independientemente de si está construyendo en Londres, Austin o Dubái.

Su papel en la cadena de suministro de la IA

Uno de los aspectos de la Ley más importantes desde el punto de vista operativo -y menos valorado- es que sus obligaciones dependen de su papel, no sólo su tecnología.

La Ley distingue entre:

• Proveedores - entidades que construyan o encarguen un sistema de IA y lo comercialicen en la UE con su propio nombre
• Distribuidores - entidades que utilizan un sistema de IA en un contexto profesional

Una empresa de SaaS que crea una herramienta de contratación impulsada por IA y la vende a empresas europeas es un proveedor. Una empresa que integra esa herramienta en su flujo de trabajo de RRHH es una desplegador. Ambos tienen obligaciones distintas.

Esta distinción es muy importante a la hora de integrar la IA de terceros:

• Si integra un modelo de terceros (a través de una API) en un producto que distribuye a clientes europeos, puede asumir obligaciones a nivel de proveedor para el sistema descendente, aunque no haya formado al modelo subyacente.
• Si afina, adapta o modifica sustancialmente un modelo de terceros, su postura de cumplimiento cambia.
• Si consume un modelo GPAI como un LLM a través de una API, el proveedor del modelo tiene obligaciones GPAI independientes, pero el sistema que construya sobre él es responsabilidad suya clasificarlo y gobernarlo.

En la práctica, muchos equipos de producto proveedores para los sistemas que construyen y desplegadores de las capacidades GPAI que integran. Pueden aplicarse ambos conjuntos de obligaciones.

Clasificación de riesgos: La pregunta que hay que responder primero

Las obligaciones de la Ley aumentan con el riesgo. Antes que cualquier otra cosa -antes que la documentación, antes que la infraestructura de registro, antes que el rediseño de productos- es necesario clasificar los sistemas de IA.

El punto crítico de decisión para la mayoría de los equipos de ingeniería es si un sistema entra dentro de Anexo III de alto riesgo. La Comisión tenía la obligación legal de publicar directrices sobre la clasificación del artículo 6 antes de febrero de 2026 y no cumplió ese plazo. Las directrices definitivas se esperan para los próximos meses. Si no está seguro de si su sistema cumple los requisitos, la ausencia de directrices oficiales no es motivo para esperar: es una razón para hacer su propia evaluación documentada y avanzar hacia la norma superior.

Lo que los equipos de ingeniería deben revisar antes de la implantación

Si su sistema está clasificado como de alto riesgo, las implicaciones de ingeniería son sustanciales. Aquí es donde los equipos suelen encontrar las mayores lagunas.

Registro y auditabilidad

El artículo 12 exige que los sistemas de IA de alto riesgo permitan técnicamente registro automático de eventos durante la vida útil del sistema. “Automático” significa que el sistema genera registros por sí mismo; la documentación manual no cumple este requisito. Por “vida útil” se entiende desde el despliegue hasta el desmantelamiento, no sólo la versión actual.

Los registros deben abarcar: situaciones en las que el sistema pueda presentar un riesgo o sufrir modificaciones sustanciales, datos para el seguimiento posterior a la comercialización y datos para el seguimiento operativo del implantador. El artículo 18 exige que los registros se conserven durante un mínimo de seis meses.

La mayoría de los conductos de registro capturan los resultados, pero no la lógica de decisión. En ese vacío es donde vive la exposición al cumplimiento.

En la práctica, los equipos deben revisar:

• Si los registros capturan entradas, salidas, pasos de decisión intermedios, marcas de tiempo e interacciones de los operadores.
• Si los flujos de trabajo multipaso de los agentes se rastrean de principio a fin.
• Si los registros se almacenan de forma que se demuestre que no han sido manipulados.

Documentación técnica

Para los sistemas de alto riesgo, el anexo IV especifica nueve categorías de documentación técnica obligatoria que debe prepararse antes de la comercialización y mantenerse durante todo el ciclo de vida del sistema, incluida la arquitectura del sistema, la metodología de formación, los parámetros de rendimiento, las limitaciones conocidas y la documentación de gestión de riesgos. El artículo 18 exige que esta documentación se conserve durante 10 años.

En la práctica, los equipos deben revisar:

• Si la documentación se versiona junto con las versiones de los modelos
• Si cubre el rendimiento en conjuntos de datos representativos, incluidos los casos extremos.
• Si está estructurado para permitir a un regulador evaluar el cumplimiento sin necesidad de aplicar ingeniería inversa al modelo.

Procedencia del modelo y dependencias de terceros

Si su sistema depende de un modelo base de terceros, debe comprender qué documentación suministra ese proveedor y dónde empiezan sus obligaciones. Cuando usted construye una aplicación sobre un modelo GPAI y la despliega en un contexto de alto riesgo, las obligaciones del proveedor a nivel de aplicación recaen sobre usted.

En la práctica, los equipos deben revisar:

• La documentación relativa a la gobernanza de la IA facilitada por cada proveedor externo de modelos
• Los límites contractuales de la responsabilidad
• Si su caso de uso está dentro del ámbito de lo documentado por el proveedor del modelo.

Mecanismos de supervisión humana

Los sistemas de IA de alto riesgo deben diseñarse de modo que los responsables de su despliegue puedan aplicar la supervisión humana. Se trata de un requisitos de arquitectura, no una declaración de proceso. El sistema debe poder ser detenido, anulado o marcado por un operador humano.

En la práctica, los equipos deben revisar:

• Si su sistema dispone de umbrales de confianza configurables que activan la revisión humana.
• Si existen vías de anulación en la interfaz de usuario y en el backend
• Si se registran las intervenciones de supervisión humana

Controles de acceso y responsabilidad por funciones

La Ley exige implícitamente que se pueda identificar quién tomó las decisiones, modificó el sistema o aprobó las implantaciones. La IA en la sombra -empleados que utilizan herramientas de IA externas que tocan los datos de producción sin visibilidad central- crea una exposición al cumplimiento que la mayoría de los equipos de ingeniería no están midiendo actualmente.

En la práctica, los equipos deben revisar:

• Si todos los componentes de IA de su pila de producción están inventariados de forma centralizada.
• Si los controles de acceso basados en funciones regulan quién puede desplegar, modificar o desactivar componentes de IA
• Si su proceso de gestión de incidentes cubre específicamente los fallos del sistema de IA

Lo que los equipos de producto deben revisar antes de la implantación

Transparencia y divulgación

Las obligaciones de transparencia del artículo 50 se aplican a determinados sistemas de IA, incluidos algunos sistemas interactivos de IA, sistemas de contenido sintético, sistemas de reconocimiento de emociones/categorización biométrica y determinados usos relacionados con deepfake -no solo de alto riesgo- a partir de agosto de 2026. Si su producto interactúa con los usuarios a través de una interfaz conversacional, genera contenido o toma decisiones visibles que afectan a los usuarios, es posible que tenga que revelar que la IA está involucrada.

En la práctica, los equipos deben revisar:

• Si los contenidos generados por IA se identifican como tales en la interfaz.
• Si se informa a los usuarios cuando interactúan con un chatbot o un asistente de IA
• Si los puntos de contacto para la divulgación son visibles y claros, y no están ocultos en las condiciones de servicio.

Escalada humana y vías de retroceso

En los sistemas de alto riesgo, los usuarios necesitan una vía para acudir a un humano cuando el sistema de IA tome una decisión que les afecte. Esto no es opcional.

En la práctica, los equipos deben revisar:

• Si cada decisión impulsada por la IA que pueda afectar a un usuario cuenta con la correspondiente vía de escalado o revisión.
• Si las rutas alternativas funcionan cuando el componente AI no está disponible.
• Si la reserva está documentada como parte de los requisitos operativos del sistema.

Consentimiento y prácticas en materia de datos

Para los equipos que despliegan IA que procesa datos personales, las obligaciones del RGPD y de la Ley de IA se solapan significativamente. La toma de decisiones automatizada, la base jurídica de los datos de formación y los derechos de los interesados se aplican simultáneamente.

En la práctica, los equipos deben revisar:

• Si los flujos de consentimiento están alineados con la forma en que el componente de IA procesa los datos.
• Si los interesados pueden ejercer derechos (acceso, supresión, oposición) que se propagan a través de su canal de IA.
• Si su sistema puede dar cabida a la retirada del consentimiento sin dejar datos de formación obsoletos en la producción.

Lista de comprobación práctica para directores de tecnología y equipos de producto

Esta lista de comprobación refleja recomendaciones prácticas basadas en los requisitos de la Ley, no en una interpretación jurídica establecida. Utilícela como punto de partida para la evaluación interna, no como sustituto de una revisión jurídica formal.

Inventario y clasificación de sistemas

• [ ] Se han inventariado todos los componentes de IA en producción y en la hoja de ruta.
• [ ] Cada sistema dispone de una evaluación documentada del nivel de riesgo
• [Los sistemas próximos al territorio del anexo III se han evaluado con arreglo a criterios específicos de uso.
• [ ] Se han identificado las integraciones de IA de terceros y se ha revisado su grado de cumplimiento.
• [ ] Se ha determinado la función de proveedor frente a la de implantador para cada componente de IA.

Ingeniería y Arquitectura

• [La infraestructura de registro captura entradas, salidas, pasos de decisión, marcas de tiempo y acciones del operador.
• [ ] Los registros se conservan durante al menos seis meses y se almacenan de forma inviolable.
• [Existe documentación técnica para cada sistema, cuyas versiones coinciden con las de los modelos.
• [La arquitectura del sistema incorpora mecanismos de anulación humana.
• [Los controles de acceso basados en funciones regulan quién puede desplegar, modificar o desactivar componentes de IA.
• [ ] Se revisan y almacenan la procedencia de los modelos y la documentación de modelos de terceros.
• [El proceso de gestión de incidentes cubre los fallos del sistema de IA y los resultados adversos.

Producto y UX

• [Existen puntos de contacto para la divulgación de información cuando la Ley exige transparencia.
• [Existen vías de escalado humano para las decisiones impulsadas por la IA que afectan a los usuarios.
• [Los flujos de retorno funcionan cuando el componente AI no está disponible.
• [ ] Los flujos de consentimiento se ajustan a las prácticas de tratamiento de datos de AI
• [La documentación del producto cubre las capacidades, limitaciones y uso previsto de los componentes de IA.

Gobernanza y procesos

• [En su organización existe un responsable del cumplimiento de la IA.
• [La gobernanza de la IA está integrada en el proceso de desarrollo, no se trata como una revisión legal de última fase.
• [ ] Existe un plan de seguimiento postcomercialización para los sistemas de alto riesgo
• [ ] Se ha realizado (o está previsto realizar) la evaluación de la conformidad de los sistemas de alto riesgo.
• [ ] Está previsto el registro en la base de datos de la UE de los sistemas de alto riesgo aplicables

La conexión entre arquitectura y gobernanza

Hay un patrón que merece la pena destacar: los equipos más expuestos al riesgo de cumplimiento de la Ley de IA de la UE no son necesariamente los que crean la IA más sofisticada. Son los que se movieron con rapidez, integraron las capacidades de IA de forma oportunista y nunca construyeron la arquitectura subyacente para apoyar la observabilidad, la trazabilidad y la gobernanza a nivel de sistema.

Infraestructura de registro que produce pruebas de auditoría. Canalizaciones de orquestación de modelos con rutas de decisión rastreables. Marcos de documentación que acompañan al sistema a lo largo de su ciclo de vida. Ganchos de supervisión humana integrados en el flujo principal. No se trata de características de cumplimiento, sino de buenas prácticas de ingeniería aplicadas a los sistemas de IA. En muchos aspectos, la Ley codifica lo que los sistemas de IA de nivel de producción deben cumplir. Despliegue de la IA debería ser así.

Los equipos que invirtieron en la disciplina de la plataforma descubrirán que la preparación para el cumplimiento es en gran medida un ejercicio de documentación y evaluación, no una reconstrucción. Los equipos que no lo hicieron se enfrentarán a un camino más difícil.

Esta es la diferencia sustancial entre experimentando con la IA y implantación de la IA. La experimentación es de bajo riesgo por diseño. El despliegue de la producción en mercados regulados significa que cada componente del sistema tiene un propietario, un propósito, un límite y un registro de auditoría.

Preguntas antes de implantar la IA en Europa

Se trata de recomendaciones prácticas, no de una lista de comprobación jurídica definitiva.

1. ¿Hemos clasificado este sistema? ¿Es de alto riesgo según el anexo III? ¿Hemos documentado nuestra evaluación?
2. ¿Somos el proveedor, el implantador o ambos? ¿Comprendemos nuestras obligaciones en cada función?
3. ¿De qué IA de terceros depende este sistema? ¿Dónde acaba su responsabilidad y empieza la nuestra?
4. ¿Podemos reconstruir lo que hizo el sistema y por qué? ¿Produce nuestra infraestructura de registro pruebas que satisfagan a un auditor?
5. Si este sistema toma una decisión que afecta a un usuario, ¿qué ocurre a continuación? ¿Existe una vía de escalada humana? ¿Funciona?
6. ¿Divulga nuestro producto la participación de la IA cuando es necesario? ¿Se reflejan las obligaciones de transparencia en la interfaz de usuario, no sólo en la política de privacidad?
7. ¿Hemos realizado una DPIA o una FRIA? Para los sistemas de alto riesgo que manejan datos personales, pueden ser necesarios ambos.
8. ¿Está actualizada y versionada nuestra documentación técnica? ¿Podría un regulador evaluar el cumplimiento a partir de ella?
9. ¿Incluye nuestro proceso de desarrollo una puerta de gobernanza para el despliegue de la IA? ¿O se sigue pensando en el cumplimiento de la normativa en el momento de la publicación?

¿Tenemos un plan de seguimiento postcomercialización? ¿Qué desencadena una revisión o un informe de incidente?

Errores comunes de las empresas

Tratar el cumplimiento como una revisión legal de última fase. Los requisitos que impone la Ley (registro, documentación, supervisión humana, transparencia) son decisiones de diseño. No pueden incorporarse a un producto ya comercializado sin una modificación significativa.

Ignorar las obligaciones del modelo de terceros. Integración de un LLM vía API no transfiere sus responsabilidades de cumplimiento al proveedor del modelo. Si está creando un producto sobre un modelo GPAI y desplegándolo en un contexto de alto riesgo, las obligaciones del proveedor de alto riesgo recaen sobre usted.

Confundir la alfabetización en IA con la gobernanza de la IA. Saber lo que dice la Ley no es lo mismo que disponer de la infraestructura necesaria para demostrar su cumplimiento. La documentación, el registro, los mecanismos de supervisión y las evaluaciones de conformidad son resultados operativos, no posiciones políticas.

A la espera de la ampliación del Ómnibus Digital. La propuesta existe. Puede que se apruebe. Pero no ha sido confirmada como ley, y no elimina las obligaciones de cumplimiento subyacentes - sólo ajusta potencialmente el calendario para categorías específicas del Anexo III.

Aplicando la lógica del GDPR y asumiendo que es suficiente. Los marcos se solapan pero no son idénticos. La Ley de IA añade requisitos específicos -registro, documentación técnica, supervisión humana, evaluación de la conformidad- que el RGPD no contempla.

Cómo puede ayudar un socio de implantación dirigido por ingenieros

Pasar de la experimentación con IA a la implantación en producción en mercados regulados es un reto de ingeniería, no solo un ejercicio de verificación del cumplimiento. El trabajo es concreto: crear una infraestructura de registro que produzca pruebas de auditoría; diseñar mecanismos de supervisión humana que funcionen a nivel de arquitectura; establecer marcos de documentación que acompañen al sistema a lo largo de su ciclo de vida; revisar los sistemas de inteligencia artificial para garantizar que se cumplen los requisitos de la legislación. orquestación de modelos la trazabilidad, la evaluación de las dependencias de terceros y la integración de puertas de gobernanza en los flujos de trabajo de desarrollo.

En Carmatec, este es el trabajo que hemos estado haciendo con los clientes a través de la integración de la IA, ingeniería de plataformas, y sistemas empresariales. Hemos construido Tuberías RAG, aplicado Automatización basada en IA, y ha ayudado a las empresas a pasar de la prueba de concepto a la producción. Los requisitos de infraestructura que conlleva el cumplimiento de la Ley de Inteligencia Artificial de la UE no son una nueva categoría de trabajo: son lo que parece un despliegue de Inteligencia Artificial de nivel de producción cuando se hace correctamente.

Si su equipo está creando sistemas de IA para el mercado europeo y está trabajando en las cuestiones de preparación anteriores, estamos bien posicionados para ayudarle a evaluar dónde se encuentra, identificar lo que necesita cambiar y crear sistemas desplegables con la arquitectura para apoyar el cumplimiento.

Preguntas más frecuentes

¿Se aplica a mi empresa la Ley de AI de la UE si tenemos nuestra sede fuera de la UE?

La Ley se aplica extraterritorialmente. Si su sistema de IA está implantado en la UE o sus resultados afectan a residentes de la UE, la Ley se aplica, independientemente de dónde esté constituida su empresa o dónde esté alojado el modelo. Esto refleja el modelo territorial del GDPR.

¿Qué se considera un sistema de IA de alto riesgo según la Ley de IA de la UE?

En el anexo III se enumeran los sistemas de alto riesgo, que abarcan casos de uso específicos como la selección de personal y de CV, la calificación crediticia, la gestión de infraestructuras críticas, la categorización biométrica y las herramientas de evaluación educativa. Si su sistema se encuentra dentro o cerca de estas categorías, debe realizar un ejercicio documentado de clasificación de riesgos.

Si utilizamos un LLM de terceros vía API, ¿tenemos obligaciones de cumplimiento?

Sí. Si crea una aplicación sobre un modelo GPAI y la implanta en un contexto de alto riesgo, las obligaciones del proveedor de alto riesgo son suyas. El cumplimiento del proveedor del modelo no sustituye al suyo como creador de la aplicación.

¿Cuál es la exposición a multas por incumplimiento?

En caso de infracción del sistema de IA de alto riesgo, las sanciones pueden alcanzar los 15 millones de euros o 3% del volumen de negocios anual global, según cuál sea el importe más elevado. Para las prácticas de IA prohibidas, el límite máximo es de 35 millones de euros o 7% del volumen de negocios anual global. Además de estas cantidades, puede aplicarse la exposición al RGPD por la toma de decisiones automatizada.

La propuesta de Ómnibus Digital podría retrasar algunos plazos. ¿Hay que esperar?

No. La propuesta no ha sido confirmada como ley, e incluso si se aprueba, sólo ajusta potencialmente el calendario para categorías específicas del Anexo III - no elimina las obligaciones subyacentes. Lo prudente es planificar hasta la fecha límite de agosto de 2026.

¿Se aplica la Ley a las herramientas internas de IA, no sólo a los productos orientados al cliente?

Depende del caso de uso. Las herramientas internas de IA que toman decisiones que afectan a los trabajadores -evaluación del rendimiento, asignación de tareas, supervisión del lugar de trabajo- pueden entrar en las categorías de alto riesgo del anexo III y justificar una revisión de la clasificación.

Conclusión

La Ley de IA de la UE no es una carga de cumplimiento futura. Es un requisito de ingeniería actual con fecha de entrada en vigor el 2 de agosto de 2026.

Las organizaciones que lo manejarán con mayor eficacia son las que lo traten como lo que realmente es: una normativa de seguridad de los productos que exige el mismo rigor técnico que cualquier sistema de producción. La clasificación de sistemas, el registro de grado de auditoría, la documentación versionada, la arquitectura de supervisión humana, los flujos de productos transparentes y la gobernanza integrada en el proceso de desarrollo son los componentes básicos de una implantación de IA conforme a la normativa. También son, no por casualidad, los componentes básicos de los sistemas de IA que son fiables, mantenibles y dignos de confianza en la producción.

Si su equipo está llevando a cabo el despliegue europeo de las funciones de IA y aún no ha realizado un ejercicio sistemático de clasificación, revisado su infraestructura de registro o evaluado las dependencias de modelos de terceros, ahora es el momento de empezar.

Acerca de Carmatec

Carmatec lleva 23 años creando plataformas de software. Trabajamos con empresas tecnológicas de Reino Unido, Europa, Norteamérica, Oriente Medio e India para llevar la IA de la experimentación a la producción, con la arquitectura, la capacidad de observación y la disciplina de entrega que requieren los sistemas de producción.

Si está preparando sistemas de IA para su implantación en Europa y necesita un socio de ingeniería que le ayude a evaluar la preparación, revisar la arquitectura y preparar la entrega conforme a la normativa, hable con nuestro equipo.