Quién manda de verdad en la AI Act: así funcionará la gobernanza y la aplicación del reglamento europeo de IA

La parte más infravalorada de la AI Act no es qué prohíbe ni qué exige a los sistemas de alto riesgo. Es quién va a vigilar todo eso, con qué poderes y con cuánta coherencia entre 27 Estados miembros. Ahí está el partido de verdad.

La Comisión Europea ha puesto negro sobre blanco cómo funcionará la gobernanza y la aplicación del reglamento. No es un detalle administrativo. Es la diferencia entre tener una norma que cambia el mercado y otra que acaba convertida en una colección de interpretaciones nacionales, guías voluntaristas y sustos regulatorios a destiempo. Si llevas tiempo siguiendo GDPR, ya sabes cómo termina esa película cuando la coordinación falla.

La AI Act, Reglamento (UE) 2024/1689, entró en vigor el 1 de agosto de 2024. Pero sus obligaciones no aterrizan de golpe: las prohibiciones del artículo 5 aplican desde el 2 de febrero de 2025; las reglas sobre modelos de IA de propósito general empezarán a aplicarse desde el 2 de agosto de 2025; y la mayor parte del régimen para sistemas de alto riesgo será exigible desde el 2 de agosto de 2026. Ese calendario escalonado tiene una consecuencia muy práctica: la gobernanza no puede improvisarse en 2026, porque las primeras decisiones sensibles llegan bastante antes.

Y sí, hay ironía regulatoria en esto: Europa ha dedicado años a discutir definiciones, categorías de riesgo y obligaciones documentales, pero el éxito real dependerá de algo mucho menos glamuroso. Autoridades competentes, reparto de funciones, vigilancia del mercado, sanciones, coordinación transfronteriza y capacidad técnica para entender modelos fundacionales. Nada de eso cabe bien en un eslogan institucional. Todo eso decide si la ley vive o si bosteza.

La arquitectura institucional: varias capas, no una superautoridad mágica

La Comisión no ha creado un sheriff único para toda la IA en Europa. Ha optado por una arquitectura multinivel. Tiene lógica política. También complica la ejecución.

El primer pilar son las autoridades nacionales competentes, que cada Estado miembro debe designar conforme a los artículos 70 y 74 de la AI Act. Dentro de ese esquema, al menos una autoridad nacional debe actuar como autoridad notificante y al menos una como autoridad de vigilancia del mercado. La primera gestiona, entre otras cosas, la notificación de organismos de evaluación de la conformidad; la segunda investiga incumplimientos, ordena medidas correctoras y retira o restringe sistemas cuando proceda.

El segundo pilar es el AI Office de la Comisión Europea, creado para desempeñar un papel central en la supervisión de los modelos de IA de propósito general, especialmente cuando se trata de modelos que pueden implicar systemic risk. Aquí la Comisión sí se reserva un asiento más prominente. No por capricho, sino porque los grandes modelos fundacionales no encajan bien en una supervisión puramente nacional. Si un modelo se despliega en toda la UE y sirve de base a miles de integradores, pretender que cada autoridad nacional resuelva sola los riesgos sería una receta estupenda para el caos.

El tercer pilar es el European Artificial Intelligence Board, previsto en el artículo 65. Su función es coordinar, emitir dictámenes, contribuir a la aplicación coherente del reglamento y asistir a la Comisión y a los Estados miembros. Suena familiar porque se parece, deliberadamente, a otros modelos europeos de gobernanza regulatoria. Otra cosa es que esa familiaridad garantice eficacia. El European Data Protection Board tampoco ha eliminado del todo las divergencias en GDPR, y eso debería servir de aviso.

El cuarto pilar lo forman los organismos notificados, que intervienen en determinados procedimientos de evaluación de conformidad para sistemas de alto riesgo, en línea con la lógica del nuevo marco legislativo europeo para productos. La AI Act no inventa desde cero la maquinaria de compliance industrial europea; la reutiliza. Lo cual aporta estructura, pero también traslada un problema conocido: no todos los organismos tienen la misma profundidad técnica, y en IA esa brecha puede ser brutal.

A esto se suman dos órganos con peso técnico y político: el panel científico de expertos independientes, llamado a apoyar la supervisión de modelos de propósito general, y un foro consultivo con participación de stakeholders. Traducido: Bruselas sabe que no puede regular IA avanzada con juristas y procedimientos administrativos solamente. Necesita gente que entienda capacidad de cómputo, evaluación de modelos, red teaming, riesgos emergentes y límites de la documentación que hoy se vende alegremente como “transparencia”.

Por qué la gobernanza importa más de lo que parece

Si eres proveedor, desplegador, CISO o responsable de compliance, la pregunta no es académica. Es operativa: ¿quién me inspecciona, quién me pide pruebas, quién interpreta una zona gris y quién puede ordenar que retire o modifique un sistema?

La AI Act reparte obligaciones entre varios actores: proveedores, importadores, distribuidores, deployers y autorizados. Ese reparto está en buena parte de los artículos 16 a 29, y se vuelve bastante concreto en alto riesgo. El problema llega cuando el mismo sistema toca varias piezas regulatorias a la vez. Un sistema biométrico en un banco puede activar la AI Act, GDPR, eIDAS 2.0 en determinados casos de identidad digital, normas sectoriales de la EBA o de EIOPA y, si además forma parte de un producto conectado, obligaciones del Cyber Resilience Act a medio plazo. Si las autoridades no hablan entre sí, la empresa se convierte en mesa camilla de supervisores.

La Comisión parece consciente de ese riesgo. Por eso insiste en mecanismos de cooperación entre autoridades y en una estructura europea de coordinación. El mensaje de fondo es claro: no quieren repetir exactamente la fragmentación de GDPR, donde una misma práctica puede recibir lecturas distintas según el Estado miembro y donde los tiempos de enforcement han sido, siendo benévolos, una prueba de paciencia espiritual.

Hay otra razón por la que esta gobernanza pesa tanto: la AI Act mezcla dos lógicas regulatorias que no siempre se llevan bien. Por un lado, el enfoque de seguridad de producto y vigilancia del mercado, muy propio del derecho europeo de productos. Por otro, una lógica de derechos fundamentales, especialmente visible en prohibiciones, transparencia y sistemas que afectan a personas en empleo, educación, acceso a servicios esenciales o aplicación de la ley. Un supervisor acostumbrado a revisar expedientes técnicos no necesariamente está preparado para valorar discriminación algorítmica, sesgos de datos o impacto en derechos. Y al revés también pasa.

Aquí está el quid: la AI Act no fallará solo por falta de normas. Puede fallar por falta de músculo institucional híbrido. Ni puramente técnico-industrial ni puramente jurídico-garantista. Híbrido.

El AI Office: el centro de gravedad para los modelos de propósito general

La novedad institucional más relevante es el papel del AI Office dentro de la Comisión. No es decoración. Es el intento explícito de centralizar la supervisión de los modelos de IA de propósito general, incluidos aquellos con riesgo sistémico.

La razón es sencilla. Los modelos fundacionales no operan como un software sectorial corriente. Se entrenan con enormes volúmenes de datos, se integran en múltiples productos y servicios, cambian con rapidez y generan riesgos en cadena. Un solo proveedor puede afectar a miles de empresas downstream. Si ese proveedor incumple obligaciones nucleares, el problema no se queda en un Estado miembro ni en un sector concreto.

La AI Act dedica los artículos 51 a 56 a los general-purpose AI models. Ahí aparecen obligaciones como elaborar y mantener documentación técnica, facilitar información a los proveedores que integran el modelo en sistemas posteriores, publicar resúmenes suficientemente detallados del contenido utilizado para el entrenamiento y, en el caso de modelos con riesgo sistémico, realizar evaluaciones, pruebas adversariales, mitigación de riesgos y notificación de incidentes graves a la Comisión y, cuando proceda, a las autoridades nacionales.

La referencia temporal aquí es clave: estas obligaciones empiezan a aplicar el 2 de agosto de 2025, un año antes de que la mayoría de las obligaciones de alto riesgo entren plenamente en vigor. No es casualidad. Bruselas ha decidido priorizar el control de la capa base del ecosistema antes de cerrar del todo la disciplina sobre muchas aplicaciones sectoriales.

El AI Office deberá además elaborar orientaciones, coordinar enforcement y apoyarse en expertos científicos. Es una señal interesante: la Comisión asume que no basta con publicar FAQs y esperar que el mercado se autorregule. Después de varios años viendo promesas de gobernanza ética que se evaporan al llegar a producción, el romanticismo tecnológico ya cotiza poco.

Ahora bien, conviene no exagerar. El AI Office no sustituye a todas las autoridades nacionales ni monopoliza la ejecución de toda la AI Act. Su protagonismo se concentra en los modelos de propósito general. Para muchos sistemas de alto riesgo usados por entidades financieras, aseguradoras, empleadores o administraciones, el primer contacto seguirá siendo nacional o sectorial.

Los Estados miembros tienen mucho poder. Y eso trae oportunidades y dolores de cabeza

Cada Estado miembro debe designar a sus autoridades competentes antes del 2 de agosto de 2025. Esa fecha importa mucho más de lo que parece. Desde ese momento empezará a definirse el carácter real del enforcement: más técnico, más legalista, más cercano a consumo, más vinculado a ciberseguridad, más sectorial o más disperso.

España, por ejemplo, ya se ha movido con la Agencia Española de Supervisión de la Inteligencia Artificial, la conocida AESIA, aunque la convivencia práctica entre AESIA, AEPD, autoridades sectoriales y órganos de vigilancia del mercado requerirá algo más que una foto institucional y una nota de prensa. Queda por ver cómo se distribuirán competencias concretas, especialmente cuando un caso mezcle IA, protección de datos, derechos de consumidores y seguridad de productos.

En otros países el paisaje también será desigual. Algunos optarán por autoridades digitales específicas. Otros reciclarán estructuras existentes de mercado, protección de datos o telecomunicaciones. Esa diversidad puede aportar especialización local. También puede disparar el coste de cumplimiento para empresas paneuropeas si las interpretaciones divergen en puntos críticos: qué documentación basta, cuándo existe una modificación sustancial del sistema, qué cuenta como supervisión humana eficaz o qué pruebas son suficientes para demostrar robustez bajo el artículo 15.

Si tu organización opera en varios Estados miembros, la pregunta incómoda es esta: ¿estás diseñando tu programa de cumplimiento para resistir la lectura más laxa o la más exigente? Apostar por la laxa sale barato hasta que deja de salir barato.

La comparación inevitable con GDPR: la UE intenta aprender, pero no parte de cero

La sombra del GDPR planea sobre toda la AI Act, aunque Bruselas no siempre lo diga en voz alta. La experiencia sirve de aviso en tres frentes.

Primero, la coordinación transfronteriza. El modelo de ventanilla única en protección de datos no ha evitado retrasos prolongados ni críticas por asimetrías entre autoridades. La AI Act intenta blindarse con un mayor protagonismo de la Comisión en determinadas áreas, sobre todo en GPAI. Tiene sentido, porque los principales modelos no conocen fronteras internas. Aun así, la coordinación entre autoridades nacionales seguirá siendo un punto vulnerable.

Segundo, la capacidad técnica. Muchas autoridades de protección de datos han tenido que correr para entender adtech, aprendizaje automático y prácticas de tratamiento complejas. La AI Act llega en un terreno aún más exigente. Supervisar un sistema de scoring o una herramienta de clasificación de candidatos ya es complejo. Supervisar un modelo fundacional multimodal, sus capacidades emergentes, su cadena de suministro y sus riesgos de uso abusivo es otro deporte.

Tercero, el riesgo de enforcement selectivo. En toda gran norma europea existe la tentación de concentrarse en casos emblemáticos y dejar zonas grises sin resolver durante años. Eso da titulares, pero no siempre da seguridad jurídica. La AI Act necesitará algo más aburrido y más útil: decisiones interpretativas consistentes, criterios sobre evidencia aceptable y capacidad para actuar también en casos menos mediáticos.

La diferencia positiva respecto a GDPR es que aquí la Comisión ha reservado para sí un papel más visible desde el principio en el segmento más difícil del mercado. La diferencia peligrosa es que el objeto regulado evoluciona mucho más rápido que el tratamiento de datos tradicional. Cuando el regulador publique una guía, medio mercado ya habrá cambiado de arquitectura.

Cómo encaja la AI Act con otras piezas del puzle regulatorio

Nadie cumple la AI Act en una vitrina aislada. El cumplimiento real se juega en la intersección con otras normas. Y ahí empieza el trabajo serio.

Con GDPR, el cruce es obvio. Si un sistema de IA trata datos personales, siguen aplicando los principios del artículo 5, la base jurídica del artículo 6, las restricciones sobre categorías especiales del artículo 9 y, en su caso, la evaluación de impacto del artículo 35. La AI Act no sustituye nada de eso. Lo complica, porque añade requisitos sobre gestión de riesgos, gobernanza de datos, documentación técnica, transparencia, supervisión humana y robustez. Un sistema puede ser conforme con una parte del expediente AI Act y seguir estrellándose contra GDPR por falta de minimización o por una lógica de tratamiento opaca.

Con NIS2, la conexión aparece en seguridad y gobernanza. El artículo 21 de la Directiva (UE) 2022/2555 exige medidas técnicas, operativas y organizativas apropiadas, incluidas políticas de análisis de riesgos, gestión de incidentes, continuidad y seguridad en la cadena de suministro. Si una entidad esencial o importante despliega IA en procesos críticos, la seguridad del sistema ya no es solo una cuestión de “robustez algorítmica”; también es una cuestión de ciberhigiene, logging, autenticación, gestión de vulnerabilidades y respuesta a incidentes. Dicho sin poesía: si tu modelo es excelente pero tu MLOps es un colador, el regulador no se va a impresionar.

Con DORA, la intersección interesa especialmente al sector financiero. El Reglamento (UE) 2022/2554 exige gestión del riesgo ICT, notificación de incidentes, pruebas de resiliencia y control de terceros tecnológicos, entre otras obligaciones. Si una entidad financiera usa IA en funciones críticas o importantes, la conversación ya no va solo de sesgo o explicabilidad. Va también de dependencia de proveedores cloud, subprocesadores, continuidad operativa, concentración tecnológica y cláusulas contractuales sobre terceros ICT, especialmente a la luz de DORA artículos 28 a 30. La AI Act puede obligarte a documentar el sistema; DORA te obliga a demostrar que no se cae el castillo si falla el proveedor.

Con el Cyber Resilience Act, el vínculo surgirá sobre todo cuando la IA forme parte de productos con elementos digitales. El CRA introduce deberes de ciberseguridad por diseño, gestión de vulnerabilidades y obligaciones a lo largo del ciclo de vida del producto. Para fabricantes que integren IA en dispositivos o software comercializado, la gobernanza dejará de ser un ejercicio de silos. Ingeniería, legal, seguridad y producto tendrán que compartir mesa. Mala noticia para quienes aún creen que compliance se resuelve con una policy en PDF.

Qué significa “enforcement” en la práctica: investigaciones, medidas correctoras y multas muy poco decorativas

La AI Act no es un código ético voluntario con buen diseño gráfico. Tiene dientes. Y algunos son caros.

El régimen sancionador está en el artículo 99. Las infracciones por prácticas prohibidas del artículo 5 pueden acarrear multas administrativas de hasta 35 millones de euros o el 7% del volumen de negocios anual mundial total del ejercicio financiero anterior, la cifra que sea mayor. Para incumplimientos de otras obligaciones, incluidas ciertas exigencias aplicables a operadores y organismos notificados, el tope puede llegar a 15 millones de euros o el 3%. Y para suministro de información incorrecta, incompleta o engañosa, hasta 7,5 millones o el 1,5%.

El reglamento prevé importes máximos más proporcionados para pymes y startups en determinados supuestos, pero conviene no vender eso como salvoconducto. Una startup no necesita una multa multimillonaria para tener un problema existencial. Le basta una orden de retirada, una prohibición de comercialización o un conflicto con clientes empresariales que no quieran cargar con riesgo regulatorio ajeno.

Las autoridades de vigilancia del mercado podrán requerir documentación, realizar evaluaciones, ordenar correcciones y restringir o retirar sistemas no conformes. Para sistemas de alto riesgo, la trazabilidad documental no es burocracia ornamental. Si no puedes demostrar cumplimiento con expediente técnico, registros, métricas de rendimiento, controles de supervisión humana y gestión de riesgos, la discusión se acaba bastante rápido.

En modelos de propósito general con riesgo sistémico, la supervisión puede incluir solicitudes de información, evaluaciones del modelo y seguimiento de medidas de mitigación. No estamos todavía ante un equivalente exacto a la supervisión prudencial bancaria, pero la lógica se aproxima más a una vigilancia continua que a una simple certificación ex ante.

El punto ciego del mercado: casi todo el mundo habla del modelo, pocos hablan de la evidencia

La mayor parte de las organizaciones están discutiendo qué herramientas de IA usan, si son de alto riesgo o si un modelo fundacional del proveedor X encajará en la categoría de riesgo sistémico. Está bien. Pero hay una conversación menos vistosa y mucho más decisiva: qué evidencia documental tendrán disponible cuando llegue el supervisor o el cliente diligente.

Para sistemas de alto riesgo, los artículos 9 a 15 exigen una disciplina bastante concreta: sistema de gestión de riesgos, gobernanza de datos y calidad de datasets cuando proceda, documentación técnica, logging, transparencia e instrucciones de uso, supervisión humana, y precisión, robustez y ciberseguridad. Los proveedores deben además implantar un sistema de gestión de calidad según el artículo 17.

La pregunta que de verdad separa a las organizaciones maduras del resto no es si han leído esos artículos. Es si han traducido cada obligación a artefactos verificables. Por ejemplo:

• Mapa de sistemas de IA con clasificación jurídica razonada, no solo inventario de herramientas.
• Evaluación de si existe alto riesgo por uso previsto, sector y función, con referencia al Anexo III cuando aplique.
• Procedimientos de control de cambios para detectar una “modificación sustancial”.
• Registros de validación, métricas de rendimiento y pruebas de robustez.
• Evidencia de supervisión humana real, no una frase genérica en el manual.
• Trazabilidad contractual con proveedores de modelos, datasets, cloud e integradores.

Esto enlaza directamente con la gobernanza. Una autoridad con pocos recursos tenderá a apoyarse mucho en la calidad de la evidencia presentada. Una autoridad técnicamente fuerte irá más allá y cuestionará supuestos, metodologías y umbrales. En ambos casos, improvisar es mala estrategia.

Para banca, seguros y fintech, la gobernanza de la AI Act llega con equipaje regulatorio pesado

Las entidades financieras europeas no van a recibir la AI Act como una norma aislada. Les llega montada sobre una pila ya muy seria de obligaciones en riesgo tecnológico, outsourcing, modelo interno, protección del consumidor y gobernanza.

Si un banco utiliza IA para scoring crediticio, detección de fraude, onboarding, prevención de blanqueo o priorización de alertas de seguridad, la primera tentación será mirar si el caso entra o no en el Anexo III de alto riesgo. Correcto, pero insuficiente. Hay al menos cuatro capas adicionales.

La primera es gobierno interno. El consejo y la alta dirección ya tienen deberes robustos bajo DORA y bajo marcos prudenciales sectoriales. Si la IA entra en procesos materiales, la conversación no puede quedarse en innovación o eficiencia operativa. Tiene que entrar en apetito de riesgo, validación de modelos, continuidad y dependencia de terceros.

La segunda es terceros tecnológicos. Muchos bancos no entrenarán modelos fundacionales propios; consumirán APIs, servicios cloud, plataformas de ML y soluciones empaquetadas. El problema es obvio: la AI Act asigna obligaciones al proveedor, pero el banco carga con riesgo operacional, reputacional y, en ciertos casos, con obligaciones propias como deployer. DORA, además, no se conforma con que “el proveedor diga que cumple”. Exige gobernar el riesgo de terceros de forma contractual y operativa.

La tercera es protección de datos y no discriminación. En crédito y seguros, las variables de entrenamiento, proxies y sesgos históricos son terreno minado. El sistema puede funcionar muy bien estadísticamente y, aun así, generar resultados difíciles de defender ante supervisor, litigio o prensa.

La cuarta es explicabilidad útil para negocio y control. No la explicabilidad como concepto de conferencia, sino la que permite a segunda línea, auditoría interna, validación de modelos y atención al cliente entender qué hace el sistema y cuándo no debe fiarse de él.

Para una entidad financiera española o europea, la gobernanza de la AI Act importa porque añade un supervisor potencial más a un entorno ya abarrotado. Y porque, si la coordinación falla, el coste lo pagará la entidad en forma de remediaciones duplicadas, peticiones cruzadas de información y tensiones contractuales con proveedores globales.

Lo que deberían hacer ya las empresas, antes de que el calendario las atropelle

No hace falta esperar a 2026 para empezar en serio. De hecho, esperar sería una mala idea. Las empresas con exposición relevante a IA deberían llegar a 2025 con cuatro decisiones ya encarriladas.

La primera es definir un modelo interno de gobernanza que no dependa de la etiqueta legal final de cada caso. Si solo organizas tu programa alrededor de “alto riesgo sí/no”, vas tarde. Necesitas un inventario funcional de casos de uso, una taxonomía interna de criticidad y un circuito de aprobación donde participen negocio, seguridad, legal, privacidad y riesgo.

La segunda es revisar la cadena contractual con proveedores de modelos y plataformas. Para GPAI, las obligaciones de los artículos 53 y 55 van a generar una demanda intensa de documentación, resúmenes de datos de entrenamiento, compromisos de soporte y garantías sobre incidentes. Si tu proveedor no puede darte la información mínima para tu expediente, tu problema no desaparece por admirar mucho la marca del proveedor.

La tercera es alinear IA con controles ya existentes. En lugar de crear una “AI governance” teatral y separada, integra los controles en marcos que ya conoces: gestión de terceros, desarrollo seguro, validación de modelos, DPIA, continuidad, registro de incidentes, control de cambios y auditoría interna. La regulación se multiplica; los equipos no.

La cuarta es preparar evidencia para interlocutores distintos. No solo para el regulador. También para clientes corporativos, comités internos, auditores y, llegado el caso, litigios. El mercado está entrando en una fase donde el due diligence sobre IA dejará de ser una casilla de procurement para convertirse en una exigencia comercial seria.

Si quieres una prueba de que esto ya está pasando, mira las RFP y anexos contractuales de grandes entidades financieras y administraciones. La pregunta ya no es “usáis IA”. La pregunta es “qué tipo de IA, con qué controles, con qué proveedor y con qué base documental”. Mucho menos glamuroso. Mucho más real.

La gran incógnita: ¿habrá coherencia europea suficiente?

La Comisión ha diseñado una estructura más robusta de lo que algunos esperaban. El AI Office aporta centralidad para GPAI. El Board introduce coordinación. Las autoridades nacionales mantienen capacidad de vigilancia de mercado. Sobre el papel, el esquema es razonable.

La duda no está en el organigrama. Está en la ejecución.

Harán falta perfiles técnicos escasos, procedimientos de cooperación rápidos, criterios consistentes sobre riesgos emergentes y una relación funcional con otras autoridades, desde protección de datos hasta supervisores sectoriales. Hará falta, además, resistir dos tentaciones. La primera: producir guías ambiguas para mantener contentos a todos. La segunda: utilizar casos ejemplares mediáticos como sustituto de una estrategia sostenida de enforcement.

Europa no necesita otra norma brillante en la exposición de motivos y borrosa en la práctica. Necesita una aplicación creíble. Eso implica sancionar cuando toque, sí, pero también resolver dudas de forma utilizable por el mercado. Si no, el resultado será el de siempre: los grandes proveedores navegarán la incertidumbre con equipos jurídicos enormes y las empresas medianas pagarán la factura en retrasos, dependencia y miedo a innovar donde sí podrían hacerlo bien.

La AI Act ha entrado en la fase menos vistosa y más decisiva. Gobernanza, supervisión, coordinación y enforcement. En otras palabras: la parte en la que se descubre si la regulación era una estrategia o solo una escenografía.

Tu organización no necesita adivinar hoy todas las respuestas que darán Bruselas y las autoridades nacionales. Pero sí necesita dejar de tratar la gobernanza como apéndice y empezar a verla como infraestructura de cumplimiento. Porque cuando empiecen a llegar las primeras investigaciones serias, el debate filosófico sobre la IA responsable habrá terminado. Lo que quedará será algo bastante más prosaico: expedientes, contratos, registros, controles y decisiones que alguien tendrá que defender con su firma.