La Oficina de IA empieza a enseñar los dientes: así está aterrizando Bruselas el AI Act

La parte más difícil de cualquier gran reglamento europeo no es aprobarlo. Es conseguir que alguien entienda qué demonios tiene que hacer el lunes por la mañana. Ahí está ahora la Oficina de IA de la Comisión Europea: traduciendo el AI Act a instrucciones utilizables, intentando evitar que el texto acabe convertido en una mezcla de pánico jurídico, presentaciones de PowerPoint y políticas internas que nadie aplicará.

La Comisión ha presentado cómo la Oficina de IA está apoyando la implementación del AI Act con directrices, consultas, herramientas prácticas y trabajo preparatorio para el ecosistema de gobernanza que debe acompañar al reglamento. La novedad no es que Bruselas publique guías. Lo hace siempre. Lo que sí importa aquí es otra cosa: el AI Act tiene un calendario escalonado, una arquitectura institucional todavía en construcción y varios conceptos clave que siguen necesitando interpretación operativa. Sin esa capa de implementación, el reglamento corre el riesgo de ser jurídicamente ambicioso y operacionalmente confuso. Europa tiene experiencia en ambas cosas.

El AI Act, adoptado formalmente en 2024 y publicado en el Diario Oficial de la Unión Europea como Reglamento (UE) 2024/1689, entró en vigor el 1 de agosto de 2024. Pero sus obligaciones no caen de golpe. Algunas empiezan antes que otras. La prohibición de determinadas prácticas de IA y las normas de alfabetización en IA empiezan a aplicar a los seis meses; las obligaciones para modelos de IA de uso general llegan a los 12 meses; y buena parte del régimen para sistemas de alto riesgo se activa a los 24 meses, con ciertos supuestos a 36 meses. Si una empresa esperaba “ya veremos cuando toque”, toca ir cambiando de guion. La Oficina de IA está ahí precisamente para cerrar el espacio entre la letra del reglamento y su ejecución real.

La pregunta no es si habrá más documentos. Los habrá. La pregunta útil es qué nos dice este despliegue sobre cómo piensa Bruselas aplicar el AI Act, dónde va a poner la presión y qué deberían estar haciendo ya proveedores, desplegadores, departamentos jurídicos, CISOs y responsables de compliance. Porque aquí no basta con saber que existe el reglamento. Hay que saber por dónde va a entrar.

La Oficina de IA no es un adorno institucional: es la pieza que decide cómo se interpreta el reglamento en la práctica

La Oficina de IA se creó dentro de la Comisión Europea para apoyar la aplicación coherente del AI Act en toda la UE, especialmente en lo relativo a modelos de IA de uso general. Su papel no sustituye a las autoridades nacionales de vigilancia del mercado ni al futuro ecosistema de autoridades competentes de los Estados miembros. Pero sí actúa como centro de gravedad técnico y regulatorio, algo bastante lógico cuando una parte relevante del reglamento afecta a actores transfronterizos y tecnologías que no encajan bien en supervisiones puramente nacionales.

Esto tiene consecuencias directas. La primera: buena parte de la interpretación práctica del AI Act se va a cocer en guías, plantillas, códigos de buenas prácticas, metodologías de evaluación y foros de coordinación. La segunda: quien espere una aplicación uniforme solo porque el texto es un reglamento europeo va tarde. La uniformidad no sale del Diario Oficial por arte de magia; sale de documentos secundarios, criterios supervisorios y decisiones repetidas en el tiempo. Eso es exactamente lo que la Oficina de IA intenta construir.

La Comisión ha ido avanzando varias líneas de trabajo: orientación sobre el concepto de sistema de IA, consultas sobre clasificación de alto riesgo, instrumentos para apoyar la conformidad y preparación del Código de Buenas Prácticas para modelos de IA de propósito general. Ese último punto es crucial porque el AI Act, en sus artículos 51 a 56, establece obligaciones específicas para proveedores de modelos GPAI y un régimen reforzado para aquellos que impliquen riesgo sistémico. En castellano llano: los grandes modelos fundacionales no van a quedarse mirando desde la barrera mientras el peso regulatorio recae solo sobre quien construye una aplicación sectorial.

Si esto te suena a una batalla por la interpretación, lo es. La definición práctica de “sistema de IA”, la línea entre un componente accesorio y uno regulado, o la prueba de si un caso de uso entra en alto riesgo según el anexo III no son detalles académicos. De esas decisiones depende quién tiene que hacer evaluación de conformidad, documentación técnica, gobernanza de datos, supervisión humana, robustez, logging o vigilancia poscomercialización.

El primer campo de batalla es la definición: qué es IA y qué no lo es

Durante años, muchas empresas han jugado a una versión regulatoria del escondite. Si algo parece IA pero llamarlo IA complica las cosas, se le cambia la etiqueta: automatización avanzada, motor predictivo, analítica aumentada, optimización basada en reglas. El AI Act intenta cerrar esa puerta con una definición amplia en su artículo 3.1, vinculada a sistemas basados en máquinas diseñados para operar con distintos niveles de autonomía y capaces de generar resultados como predicciones, contenidos, recomendaciones o decisiones que influyen en entornos físicos o virtuales.

El problema, como siempre, no está en la frase. Está en los bordes. ¿Cuándo una lógica basada en reglas deja de ser simple software y entra en el perímetro del AI Act? ¿Qué ocurre con sistemas híbridos? ¿Y con productos donde el componente de IA es marginal pero afecta a una función sensible? La Comisión ha intentado despejar parte de esa niebla con directrices sobre la definición de sistema de IA. No resuelven todo, pero importan mucho porque reducen el margen para la interpretación oportunista y, al mismo tiempo, evitan que cualquier automatización banal quede atrapada por el reglamento.

Aquí hay una lección conocida para quien vivió el GDPR desde dentro. Las definiciones aparentemente abstractas acaban decidiendo presupuestos, arquitectura contractual, inventarios de sistemas y hasta organigramas. En protección de datos ocurrió con “responsable”, “encargado”, “datos personales” o “alto riesgo” en las evaluaciones de impacto del artículo 35 del GDPR. En IA pasará con “sistema de IA”, “proveedor”, “desplegador”, “modificación sustancial” y “uso previsto”.

Para las empresas, la implicación es inmediata: el inventario de IA no puede basarse solo en los productos que marketing llama “IA”. Necesita criterios jurídicos y técnicos trazables. Si tu organización aún no ha fijado un test interno para decidir cuándo algo entra en el alcance del AI Act, vas tarde. No por dramatismo. Por pura secuencia lógica: sin inventario fiable no puedes clasificar riesgos; sin clasificación no puedes priorizar controles; sin controles no tienes defensa cuando llegue el supervisor o el cliente diligente de turno.

La clasificación de alto riesgo es donde se juega el presupuesto

El AI Act distingue entre usos prohibidos, sistemas de alto riesgo, ciertas obligaciones de transparencia para categorías específicas y reglas para GPAI. De todo eso, la categoría que más cambia procesos internos es la de alto riesgo. Y también la que más dudas genera. El reglamento la articula principalmente a través del artículo 6 y del anexo III, además de los casos en que un sistema es componente de seguridad de un producto o está sometido a legislación sectorial armonizada del anexo I.

La Comisión ha abierto trabajo interpretativo precisamente aquí porque sabe dónde está el problema. Un ejemplo obvio: empleo. Los sistemas utilizados para selección, evaluación de candidatos o toma de decisiones que afecten a condiciones laborales pueden entrar en el anexo III. Otro: acceso a servicios esenciales. Otro más: educación, aplicación de la ley, migración, administración de justicia. El texto da categorías; la vida real da productos con funciones mezcladas, proveedores encadenados y responsabilidades distribuidas con bastante arte para diluir culpas.

La Oficina de IA está intentando producir guías que ayuden a determinar cuándo un sistema cae dentro del alto riesgo y qué obligaciones se activan. Ese trabajo es menos vistoso que un gran anuncio político, pero mucho más relevante. Si un sistema entra en alto riesgo, se disparan exigencias concretas de los artículos 8 a 15: sistema de gestión de riesgos, gobernanza de datos y calidad de datasets cuando proceda, documentación técnica, registro automático de eventos, transparencia e instrucciones de uso, supervisión humana, y niveles adecuados de precisión, robustez y ciberseguridad. Después vienen las obligaciones de proveedores del artículo 16 y las de desplegadores del artículo 26. Dicho de otra forma: no es una etiqueta, es una cadena de trabajo permanente.

Y aquí aparece un detalle que muchos departamentos siguen infravalorando: la clasificación no es solo legal; es profundamente operativa. Si compras una solución de terceros para RR. HH., scoring, fraude, onboarding o priorización de casos, necesitas saber si el proveedor la ha diseñado para un uso que cae en alto riesgo, qué documentación puede entregarte y qué restricciones impone sobre el uso previsto. Si no lo haces, puedes descubrir demasiado tarde que has heredado obligaciones que el proveedor no estaba preparado para soportar o que te ha vendido “IA responsable” en el folleto y opacidad industrial en la práctica.

Los modelos de propósito general son el verdadero experimento regulatorio europeo

Donde la Oficina de IA tiene más protagonismo es en el régimen de modelos de IA de uso general, porque ahí la Comisión se ha reservado un rol especialmente central. Los artículos 51 a 56 del AI Act obligan a los proveedores de modelos GPAI a cumplir deberes de documentación técnica, información a quienes integran el modelo en sistemas posteriores, políticas de respeto al derecho de autor de la UE y publicación de un resumen suficientemente detallado del contenido usado para entrenamiento, entre otros requisitos. Cuando el modelo se considera de riesgo sistémico, el listón sube: evaluación de modelos, pruebas adversariales, mitigación de riesgos sistémicos, notificación de incidentes graves y medidas de ciberseguridad.

La parte interesante es que muchas de estas obligaciones necesitan metodología antes que retórica. ¿Qué debe contener una “documentación técnica” útil para downstream providers? ¿Qué nivel de granularidad se espera en el resumen de datos de entrenamiento? ¿Qué se considera una medida suficiente para identificar y mitigar riesgos sistémicos? ¿Qué formato tendrá la notificación de incidentes graves y en qué plazos concretos se exigirá? Sin guía, cada actor interpretaría el mínimo posible. Y, siendo francos, no sería la primera vez.

Por eso el Código de Buenas Prácticas para GPAI no es un apéndice simpático. Es la pista de aterrizaje. Si la Oficina de IA logra que ese código se convierta en referencia real antes de que muchas obligaciones sean plenamente exigibles, reducirá fricción para mercado y supervisores. Si fracasa, veremos dos cosas a la vez: grandes proveedores negociando cada palabra y empresas usuarias descubriendo que su dependencia contractual de esos proveedores es mucho mayor de lo que imaginaban.

Hay además una tensión política de fondo. Europa quiere regular sin matar la innovación, una frase ya tan usada que pide jubilación anticipada. Pero en GPAI la dificultad es tangible: si aprietas poco, te acusan de crear una coartada ética de escaparate; si aprietas mucho y llegas tarde con la guía, el cumplimiento se convierte en una lotería para quienes dependen de modelos ajenos. La Oficina de IA no puede resolver por sí sola esa contradicción, pero sí puede hacer algo más modesto y más útil: fijar expectativas verificables y evitar que el mercado convierta la ambigüedad en modelo de negocio.

La alfabetización en IA parece la obligación blanda. Error.

Entre las primeras exigencias que empiezan a aplicarse está la alfabetización en IA. El artículo 4 del AI Act obliga a proveedores y desplegadores a adoptar medidas para garantizar, en la medida de lo posible, un nivel suficiente de alfabetización en IA de su personal y de otras personas que operen y utilicen sistemas de IA en su nombre, teniendo en cuenta sus conocimientos técnicos, experiencia, educación y el contexto de uso.

Suena razonable, casi inocuo. No lo es. Precisamente por su formulación abierta, esta obligación puede convertirse en uno de los primeros puntos de fricción para auditoría, procurement, compliance y recursos humanos. ¿Qué es “nivel suficiente”? ¿Sirve un curso genérico de una hora? ¿Debe diferenciarse entre quien compra, quien desarrolla, quien valida resultados y quien decide sobre personas? ¿Basta con una política o habrá que demostrar capacidades reales?

La Oficina de IA puede influir mucho en cómo se aterriza este deber. Si la Comisión publica orientación práctica creíble, la alfabetización en IA dejará de ser una casilla cosmética y pasará a parecerse a lo que ya ocurrió con seguridad de la información o privacidad: formación segmentada por rol, evidencias de asistencia, contenidos actualizados y conexión con riesgos concretos. Si no lo hace, veremos el festival habitual de cursos genéricos, certificados automáticos y la ficción corporativa de que todos “ya están sensibilizados”. Ya sabemos cómo acaba eso.

Para entidades financieras, aseguradoras, plataformas y grandes empleadores, el impacto es más serio de lo que parece. No porque el artículo 4 vaya a generar de inmediato una sanción multimillonaria, sino porque condiciona la defensa de la organización si algo sale mal. Cuando un sistema produzca decisiones sesgadas, recomendaciones engañosas o errores relevantes, una de las preguntas inevitables será quién supervisaba la herramienta y con qué formación. Si la respuesta es “hicimos un webinar”, mala suerte.

Lo que la Comisión está construyendo se parece bastante a DORA, GDPR y NIS2 en una cosa: gobernanza antes que tecnología

Una lectura superficial del AI Act lo reduce a controles técnicos sobre modelos y sistemas. Una lectura seria muestra otra cosa: se parece mucho a las grandes normativas europeas recientes en que lo decisivo no es solo el control técnico, sino la estructura de gobernanza que lo sostiene. Y la Oficina de IA lo está reforzando con su aproximación de implementación.

Piensa en las piezas que se repiten. Inventario de sistemas. Evaluación de riesgo. Asignación clara de roles. Documentación mantenible. Supervisión humana efectiva. Gestión de incidentes. Trazabilidad. Revisión posdespliegue. Contratos que permitan obtener información aguas arriba y cumplir aguas abajo. Nada de esto es exclusivo del AI Act. Su lógica conversa directamente con DORA para resiliencia operativa, con NIS2 en gestión de riesgos de ciberseguridad y reporting, y con GDPR cuando la IA trata datos personales o produce efectos significativos sobre individuos.

El cruce con GDPR es particularmente delicado. Si un sistema de IA usa datos personales, el responsable no se libra del Reglamento General de Protección de Datos porque ahora haya un AI Act en escena. Siguen vivos el artículo 5 sobre principios, el artículo 6 sobre base jurídica, el artículo 13 y 14 sobre información, el artículo 22 sobre decisiones automatizadas en ciertos supuestos y el artículo 35 sobre evaluaciones de impacto cuando haya alto riesgo para derechos y libertades. En la práctica, eso significa que una misma solución puede exigir simultáneamente clasificación bajo AI Act, DPIA bajo GDPR, evaluación contractual de proveedores y controles de seguridad alineados con NIS2 o con marcos internos inspirados en ISO 27001 o NIST CSF 2.0.

Esto no complica por gusto. Complica porque el riesgo es multidimensional. Un sistema puede ser técnicamente robusto y jurídicamente tóxico. Puede ser preciso en laboratorio y desastroso en producción. Puede cumplir requisitos de transparencia del AI Act y seguir incumpliendo minimización o limitación de finalidad bajo GDPR. Puede incluso no ser de alto riesgo según AI Act y, aun así, disparar riesgos reputacionales y de conducta que el regulador sectorial no perdonará.

La Oficina de IA, al publicar guías e intentar armonizar criterios, está enviando una señal que muchos comités de dirección deberían leer mejor: esto no se resolverá dejando “la IA” en manos de innovación o de IT. El reglamento está diseñado para obligar a una gobernanza transversal. Y eso, en bastantes organizaciones, sigue siendo la pieza menos madura.

Qué deberían hacer ya las empresas, sin esperar a que Bruselas publique la guía perfecta

Esperar a una claridad absoluta es una forma elegante de no empezar nunca. El AI Act aún necesita bastante implementación secundaria, sí. Pero eso no impide avanzar en frentes donde la incertidumbre es menor. De hecho, la Oficina de IA está orientando precisamente esas áreas.

El primer paso serio es construir un inventario vivo de sistemas y casos de uso de IA con metadatos suficientes para clasificar. No un Excel ornamental. Un registro que identifique proveedor, finalidad, datos usados, grado de autonomía, impacto potencial sobre personas, integración en procesos críticos, posibilidad de revisión humana, dependencia de modelos GPAI y cambios relevantes desde la puesta en producción. Si mañana tuvieras que decidir qué entra en la definición del artículo 3, qué puede caer en el artículo 6 y dónde hay obligaciones de transparencia, ese inventario debería darte una respuesta razonable en días, no en meses.

Después viene la clasificación jurídica y operativa. No basta con preguntar al proveedor si “cumple el AI Act”. Esa respuesta, por sí sola, tiene el mismo valor que un folleto de gimnasio en enero. Hace falta un análisis interno: uso previsto, contexto real de despliegue, usuarios afectados, decisiones soportadas, posibilidad de modificar sustancialmente el sistema y dependencia de componentes de terceros. Aquí procurement, legal, negocio y seguridad tienen que hablar el mismo idioma, o por lo menos intentarlo con dignidad.

El tercer frente es contractual. El AI Act va a castigar la ingenuidad en la cadena de suministro. Si dependes de proveedores de modelos, plataformas de IA o soluciones verticales, necesitas cláusulas que cubran acceso a documentación, actualización de información relevante, notificación de incidentes, límites del uso previsto, soporte para evaluaciones de conformidad cuando aplique, derechos de auditoría razonables y obligaciones sobre ciberseguridad y gestión de vulnerabilidades. Quien haya pasado por DORA reconocerá el patrón: el problema no es tener un proveedor; el problema es descubrir demasiado tarde que no tienes palancas contractuales suficientes.

El cuarto es la gobernanza de cambios. Muchos sistemas de IA evolucionan con ajustes de modelo, fine-tuning, nuevos datasets o parámetros de operación. Eso obliga a decidir cuándo un cambio altera la clasificación, el nivel de riesgo o la documentación requerida. El AI Act introduce la idea de modificación sustancial, y la Oficina de IA probablemente tendrá un papel relevante afinando su interpretación práctica. Si tu proceso de change management trata igual un parche menor que un reentrenamiento con nuevas fuentes de datos, estás mezclando cosas que el regulador no va a mezclar.

Y el quinto, que suele olvidarse hasta que arde, es el canal de incidentes. Los sistemas de IA pueden fallar de formas distintas a las del software tradicional: salidas engañosas, degradación silenciosa, drift, sesgos emergentes, abuso por prompt injection, exfiltración de datos vía interacción, o dependencia excesiva de operadores que dejan de cuestionar resultados. No todo eso está definido aún con precisión supervisora, pero esperar a que lo esté para diseñar reporting interno sería una torpeza considerable. Si ya tienes marcos de incident management por ciberseguridad o resiliencia operativa, intégralos. No inventes otro silo.

Para bancos, aseguradoras y fintech europeas, esto no va de “ética de la IA”; va de control interno exigible

La noticia no menciona específicamente al sector financiero como destinatario exclusivo, pero sería un error leerla como algo periférico para bancos, aseguradoras o fintech. En estas entidades, la IA no está en un laboratorio simpático; está entrando en procesos materiales: prevención de fraude, AML, scoring, atención al cliente, análisis documental, onboarding, reclamaciones, marketing, recursos humanos, detección de anomalías, ciberseguridad y gestión operativa. Eso multiplica el efecto del AI Act porque convive con capas regulatorias ya muy cargadas.

En banca y seguros europeos, cualquier herramienta de IA que afecte a clientes, empleados, continuidad operativa o outsourcing termina chocando con varias mesas a la vez: compliance, riesgo operacional, protección de datos, seguridad, modelo interno, auditoría y, a menudo, conducta. La Oficina de IA puede no ser el supervisor sectorial de referencia para todas esas cuestiones, pero su trabajo de implementación condicionará qué preguntas empiezan a hacer esos equipos dentro de la entidad y qué esperan luego los supervisores indirectamente.

Tomemos un caso concreto. Un banco utiliza un proveedor externo de IA generativa para asistir a agentes de atención al cliente en reclamaciones. El sistema resume expedientes, propone respuestas y prioriza casos. Puede que no sea alto riesgo por sí mismo según el anexo III. Puede incluso parecer un uso relativamente contenido. Pero la entidad sigue necesitando evaluar tratamiento de datos personales, riesgos de confidencialidad, precisión de respuestas, supervisión humana real, sesgos en priorización, logging suficiente, continuidad del proveedor y límites contractuales sobre uso de prompts y datos para reentrenamiento. Si el proveedor además usa un modelo GPAI sujeto a los artículos 51 y siguientes, la calidad de la información que el banco reciba aguas arriba dependerá en buena medida de cómo la Oficina de IA consiga estandarizar expectativas.

Otro ejemplo: selección de personal. Aquí la probabilidad de caer en alto riesgo es bastante más tangible, dado el encaje potencial en el anexo III. Eso dispara requisitos mucho más duros. En entidades financieras, donde la trazabilidad y la defensa ante auditoría son ya obsesiones conocidas, el AI Act introduce una exigencia adicional: no basta con poder explicar la política de contratación; hay que poder defender técnicamente y documentalmente el comportamiento del sistema dentro del uso previsto.

La implicación para España y para la UE es clara. Las entidades que ya han madurado gobierno de terceros bajo DORA, mapas de datos bajo GDPR y reporting de riesgos bajo NIS2 parten con ventaja relativa. No porque el AI Act sea una extensión simple de esas normas. No lo es. Pero comparten músculo organizativo: inventario, clasificación, evidencia, supervisión, escalado y disciplina contractual. Quien aún no tenga eso ordenado no tiene un problema de IA; tiene un problema estructural de control interno.

El gran riesgo de implementación no es la falta de ley, sino la falsa sensación de cumplimiento

Cuando una regulación llega con conceptos amplios y guías graduales, aparece una tentación muy corporativa: crear un marco interno presentable antes de haber resuelto lo esencial. Un comité, una política, un formulario y unas sesiones de formación genérica. Todo muy elegante. Todo muy insuficiente.

La Oficina de IA puede mitigar ese riesgo si publica orientación concreta y usable. Pero no lo va a eliminar. Muchas organizaciones van a intentar traducir el AI Act en burocracia de baja intensidad, especialmente en usos que perciben como no críticos. Ese enfoque puede funcionar a corto plazo para aparentar orden. A medio plazo es un problema, porque deja sin resolver tres preguntas básicas.

Primera: ¿qué sistemas de IA tienes realmente? Segunda: ¿qué decisiones relevantes soportan o influyen? Tercera: ¿qué evidencias podrías poner encima de la mesa si un regulador, un auditor interno o un cliente institucional te exigiera demostrar control? Si no hay respuesta sólida a esas tres, el resto es decoración regulatoria.

Hay además un ángulo incómodo para la alta dirección. El AI Act no se limita a poner obligaciones sobre desarrolladores. Su arquitectura alcanza a quienes ponen sistemas en el mercado, los modifican, los integran y los utilizan. Eso redistribuye responsabilidad dentro de la empresa. Legal no puede resolver solo un problema de arquitectura de datos o supervisión humana. IT no puede decidir solo un uso permitido cuando el impacto sobre derechos o acceso a servicios es sustancial. Riesgos no puede mapear un sistema que negocio no le ha contado. La Oficina de IA, con cada guía práctica que publique, irá cerrando huecos para que esa descoordinación sea menos defendible.

Lo que cabe esperar ahora de Bruselas, y lo que no

Conviene rebajar dos fantasías. La primera es pensar que la Comisión emitirá una guía perfecta que convierta el AI Act en un manual sin zonas grises. No ocurrirá. La tecnología cambia demasiado rápido, los casos de uso son demasiado heterogéneos y el propio reglamento deja espacio a interpretación supervisora. Habrá documentos útiles, sí, pero la ambigüedad no va a desaparecer.

La segunda fantasía es la contraria: asumir que, como aún hay cuestiones abiertas, el mercado puede seguir improvisando sin coste. Tampoco. El calendario del reglamento avanza, la presión política para demostrar aplicación real existe y la Oficina de IA ha dejado claro que su papel será activo en el apoyo a la implementación. Eso significa más guías, más consultas, más coordinación institucional y, probablemente, más expectativa de que las empresas documenten por qué han tomado determinadas decisiones de clasificación y control.

Lo sensato es esperar un patrón ya conocido en regulación tecnológica europea. Primero, orientaciones interpretativas para definiciones y perímetro. Después, instrumentos prácticos para obligaciones concretas. Más tarde, consolidación mediante códigos, estándares, decisiones supervisoras y primeras acciones de enforcement que, aunque sean selectivas, marcarán el tono del mercado. Quien conozca la historia del GDPR reconocerá el guion. Quien haya seguido DORA o NIS2 reconocerá también otra cosa: los textos legales se citan mucho; lo que cambia organizaciones son las expectativas operativas que vienen después.

La Oficina de IA está justo en esa fase fundacional. No está escribiendo otra nota informativa irrelevante. Está montando la maquinaria que decidirá si el AI Act se convierte en disciplina empresarial o en teatro regulatorio con mucho logo europeo y poco control real.

La conclusión incómoda: el AI Act ya no es un debate político, es un problema de ejecución

La noticia de la Comisión importa menos por lo que anuncia que por lo que confirma. El AI Act ha salido de la fase de gran relato y ha entrado en la fase ingrata: definiciones, guías, códigos, taxonomías, preguntas frecuentes, coordinación entre autoridades y presión para que las empresas conviertan principios en procesos. Es justo la fase donde se decide si una norma sirve para algo.

La Oficina de IA será observada por dos públicos a la vez. Las empresas quieren certidumbre suficiente para no construir controles inútiles. Los críticos del reglamento quieren comprobar si Europa puede regular IA sin producir un atasco burocrático del que luego nadie se haga responsable. Ambos tienen motivos para desconfiar. Y, sin embargo, el trabajo que está haciendo la Comisión ahora es el que de verdad cuenta.

Si diriges cumplimiento, seguridad, riesgo, datos o compras tecnológicas, esta es la lectura práctica: deja de tratar el AI Act como un proyecto para “más adelante”. Revisa tu inventario. Clasifica usos. Habla con proveedores. Endurece contratos. Define criterios de escalado. Vincula IA con privacidad, ciberseguridad y continuidad. Y documenta. Documenta mucho mejor de lo que crees necesario. Porque cuando la Oficina de IA acabe de perfilar sus guías, la excusa de “no estaba claro” irá perdiendo valor bastante deprisa.

Bruselas ya ha hecho lo fácil: aprobar el reglamento. Ahora empieza lo difícil y, por una vez, también lo verdaderamente interesante.