Del texto del EU AI Act al programa que lo ejecuta
Operacionalizar el EU AI Act significa montar y mantener la maquinaria que conserva tu conformidad siendo cierta mientras la organización sigue usando y cambiando sus sistemas de IA. El reglamento invita a leerse como un proyecto con fecha de fin: 113 artículos, 13 anexos, un hito de “cumplido” y a otra cosa. Pero el objeto que gobierna se mueve. Los modelos se reentrenan, los usos derivan, entran sistemas nuevos, y uno que hoy es riesgo bajo mañana es alto riesgo porque alguien le dio un uso que nadie volvió a categorizar. Por eso la conformidad con el EU AI Act se parece más a mantener un producto en iteraciones ágiles que a revelar una foto y enmarcarla: es una película en movimiento que hay que volver a rodar cada vez que cambia el plano. En la práctica, esa maquinaria tiene cuatro piezas que engranan todos los días y se revisan en ciclo: un inventario de sistemas, una categorización por riesgo con criterio, obligaciones con dueño asignado y una trazabilidad que aguante dinámicamente una auditoría. Leerse el reglamento es preparación. El trabajo empieza cuando esas cuatro piezas existen y alguien las mantiene vivas.
Llevo cinco años haciendo ese trabajo dentro de una aseguradora. Lo que vas a leer es lo que separa a las organizaciones que están operando el EU AI Act de las que creen que lo cumplen porque lo han leído, y de las que lo cumplieron una vez, para una foto, y hoy tienen un programa que ya no refleja los sistemas que usan.
El inventario es el primer entregable
No puedes categorizar por riesgo lo que no sabes que tienes. Y aún muchas organizaciones no lo saben. Tienen modelos en producción que compró un equipo hace dos años, funcionalidades de IA embebidas en herramientas SaaS que nadie registró como “IA”, y pruebas de concepto que se quedaron en producción sin que nadie lo decidiera formalmente.
El primer entregable de un programa de EU AI Act no es una política. Es un registro: qué sistemas de IA existen, quién los usa, sobre qué decisiones influyen y con qué datos. Sin ese inventario, cualquier categorización de riesgo es una ficción, porque estás categorizando la lista de sistemas que conoces, no la de los que tienes.
Este es el paso más tedioso y el que más gente se salta. Se salta porque no produce nada lucido: no hay comité, no hay presentación al Consejo, solo hay un Excel creciendo. Pero es el suelo sobre el que se apoya todo lo demás. Un programa de governance que empieza por la política y no por el inventario está construyendo el tejado antes que los cimientos.
Y el registro solo sirve si cada entrada identifica un sistema y solo uno. Conté en una nota aparte por qué levantar ese inventario se parece a hacerse distinguible para un buscador: el trabajo, en los dos casos, consiste en dejar escrito qué separa una entidad de las que se le parecen.
La categorización por riesgo condiciona todo lo que viene después
Uso categorización a propósito, y la palabra decide cómo entiende el problema todo el que lo escucha. Hablar de clasificar el riesgo invita a pensar en el análisis de riesgos clásico, donde evalúas un riesgo y lo bajas de nivel aplicando mitigaciones. El EU AI Act funciona de otra manera: agrupa los sistemas en categorías fijas según el uso que se les da, y ninguna mitigación mueve un sistema de alto riesgo a la casilla de al lado. Lo que cambian los controles es cómo cumples las obligaciones de tu categoría, con la categoría intacta. Deshacer esa confusión es el trabajo de gestión del cambio que más tiempo cuesta dentro de una organización, porque la primera reacción de cualquier equipo con cultura de riesgos es preguntar qué hay que poner encima para “bajar” el sistema a riesgo bajo.
El EU AI Act ordena los sistemas en cuatro niveles: prácticas prohibidas, alto riesgo o riesgo bajo, al margen de otras categorías intermedias dependiendo del sector. La pirámide sale en todas las diapositivas. Lo que no sale en ninguna es lo único que importa operativamente: quién categoriza y con qué criterio.
Porque la categorización no es un ejercicio de lectura del Anexo III. Es una decisión. Un sistema de scoring que ordena solicitudes puede ser alto riesgo o no serlo según el uso de negocio exacto que le des, según si la decisión final la toma una persona o el propio sistema, según a quién afecte. Esa determinación tiene consecuencias caras (documentación técnica, evaluación de conformidad, supervisión humana), así que hay un incentivo silencioso a categorizar a la baja. “Esto en realidad es riesgo bajo” es la frase con la que empieza el incumplimiento de más organizaciones.
Por eso la categorización necesita un responsable con autoridad, un criterio escrito y una traza de por qué cada sistema quedó donde quedó. Y necesita poder reabrirse: cuando un sistema recibe un uso nuevo, su nivel de riesgo vuelve a estar en juego. La misma lógica que aplico a un comité que decide en lugar de reunirse: si la decisión no tiene dueño ni deja huella, no es una decisión, es una opinión que alguien recordará distinto, o no recordará, dentro de seis meses.
Cada obligación de alto riesgo necesita un dueño
Cuando un sistema cae en alto riesgo, el Anexo III y el capítulo III abren una lista de obligaciones: gestión de riesgos, gobernanza de datos, documentación técnica, registro de eventos, transparencia hacia el usuario, supervisión humana, precisión y robustez. En la mayoría de las presentaciones esa lista aparece como un checklist. Un checklist es exactamente la forma equivocada de gestionarla.
Un checklist sugiere que cada línea es un tick que alguien marca una vez. La realidad es que cada una de esas obligaciones es una función continua que necesita un responsable nombrado. La gestión de riesgos no se “completa”; se mantiene mientras el sistema esté vivo. La supervisión humana no es una casilla; es una persona con tiempo, formación y autoridad para parar el sistema. La documentación técnica no se archiva; se actualiza cada vez que el modelo cambia.
Operacionalizar el alto riesgo consiste en convertir cada obligación en una responsabilidad asignada, con un nombre al lado. Cuando llega la pregunta, sea del regulador, del auditor o del cliente afectado, la respuesta útil no es “sí, lo cumplimos”. Es “responde Fulano, y aquí está la traza”. Todo lo demás es cumplimiento declarado, no demostrado.
La trazabilidad es lo que convierte una declaración en prueba
El EU AI Act pide, para los sistemas de alto riesgo, registros automáticos de eventos, documentación técnica y capacidad de reconstruir por qué un sistema produjo un resultado. Traducido a operación: tienes que poder demostrar lo que dices que haces.
Esta es la parte donde más organizaciones se descubren a sí mismas. Tienen una política de supervisión humana impecable en el papel y ni un solo registro de que un humano haya supervisado nada. Tienen un proceso de aprobación de modelos y ninguna traza de contra qué alternativa se aprobó cada uno. La declaración existe; la prueba no.
Y la distinción es la que sostiene todo el edificio, porque una auditoría no evalúa tus intenciones. Evalúa tus evidencias. Un programa operacionalizado genera esa evidencia como subproducto de funcionar: logs que se escriben solos, actas que registran la decisión y no la asistencia, versiones de documentación atadas a versiones del modelo. Si generar la prueba requiere un esfuerzo especial cada vez que alguien la pide, es que el programa no está operacionalizado. Está maquillado para la foto.
Las fechas ya vuelan
El EU AI Act entró en vigor en agosto de 2024 y se aplica por fases. No es un horizonte lejano; hay obligaciones que ya son exigibles hoy:
- 2 de febrero de 2025: prohibidas las prácticas del artículo 5 (manipulación, social scoring, ciertos usos biométricos) y exigible la obligación de alfabetización en IA del artículo 4. Esto ya venció, aunque el digital omnibus acaba de rebajar las necesidades de estas segunda.
- 2 de agosto de 2025: se aplican las reglas de los modelos de propósito general (GPAI), la estructura de gobernanza europea (AI Office, Consejo) y el régimen sancionador. También venció.
- 2 de diciembre de 2027: se aplica el grueso del reglamento, incluidos la mayoría de los sistemas de alto riesgo del Anexo III. Esta es la fecha que tienes delante, a la que han dado una patada adelante también estos días.
Lo operativo de este calendario es simple: lo que decidas hacer para el futuro se decide ahora, no después. Un inventario completo, una categorización con criterio y las obligaciones de alto riesgo asignadas no se levantan en dos meses. Se levantan a lo largo del año anterior.
Por qué el EU AI Act se gobierna como sistema vivo
Hasta aquí las cuatro piezas. Mantenerlas vivas es donde está el coste real, y donde casi todos los programas se rompen. El error más caro que veo es tratar el EU AI Act como un proyecto con fecha de fin: un hito de “cumplimiento conseguido” y a otra cosa. Pero un inventario deja de ser cierto en cuanto un equipo despliega un modelo sin avisar. Una categorización caduca en cuanto un sistema recibe un uso que nadie reabrió. Una obligación se queda huérfana en cuanto su dueño cambia de puesto y nadie reasigna la responsabilidad.
Por eso trato la conformidad como una pieza más del gobierno de IA entendido como sistema adaptativo: el inventario se revisa en ciclo, la categorización se reabre cuando cambia el uso, las obligaciones se reasignan cuando cambia el dueño, la trazabilidad se audita contra la realidad y no contra el papel. No es la disciplina de aprobar una foto. Es la disciplina de volver a rodar la película cada vez que la organización cambia el plano, que es constantemente.
Operacionalizar el EU AI Act, al final, consiste en aceptar eso desde el principio. No estás montando un proyecto para aprobar una foto. Estás montando la maquinaria que mantiene esa foto siendo cierta mientras la organización sigue usando IA. Esa maquinaria (inventario, categorización, obligaciones con dueño, trazabilidad) es el programa. Si además quieres darle una estructura de gestión reconocible, con su cadencia de revisión y su ciclo de auditoría, eso es justo lo que describe ISO/IEC 42001. El reglamento solo dice qué tiene que producir.
Preguntas frecuentes
¿Cuándo empieza a aplicarse el EU AI Act? Por fases desde su entrada en vigor en agosto de 2024. Las prácticas prohibidas y la obligación de alfabetización en IA aplican desde el 2 de febrero de 2025; las reglas de modelos de propósito general y el régimen sancionador desde el 2 de agosto de 2025; el grueso del reglamento, incluida la mayoría de los sistemas de alto riesgo, tras la modificación reciente del Digital Omnibus, desde el 2 de diciembre de 2027.
¿Qué es un sistema de IA de alto riesgo? Un sistema que cae en alguno de los usos del Anexo III (empleo, crédito, educación, servicios esenciales, biometría, justicia, migración, entre otros) o que actúa como componente de seguridad de un producto ya regulado bajo el Anexo I. La categorización depende del uso concreto, no solo de la tecnología: el mismo modelo puede ser o no ser de alto riesgo según la decisión sobre la que influya y sobre quién.
¿El EU AI Act solo obliga a quien desarrolla IA? No. Obliga tanto al proveedor, que desarrolla el sistema y lo pone en el mercado, como al responsable del despliegue (deployer), que es quien lo usa bajo su propia autoridad. Muchas organizaciones creen que, al no desarrollar IA, no les aplica. Si usas un sistema de alto riesgo de un tercero, eres deployer y tienes obligaciones propias.
¿Qué diferencia hay entre proveedor y responsable del despliegue? El proveedor responde del diseño, la documentación técnica y la evaluación de conformidad del sistema. El deployer responde del uso: supervisión humana real, uso conforme a las instrucciones, monitorización en operación y, en ciertos casos, información a las personas afectadas. Comprar el sistema no traslada toda la responsabilidad al proveedor; parte se queda contigo por el hecho de usarlo.
¿Necesito la norma ISO/IEC 42001 para cumplir el EU AI Act? No es obligatoria, pero un sistema de gestión de IA conforme a ISO/IEC 42001 te da buena parte de la maquinaria que el reglamento exige demostrar: inventario, gestión de riesgos, roles y trazabilidad. Una cosa es la ley que tienes que cumplir; la otra es el marco de gestión con el que la cumples de forma sostenible. El mapa pieza a pieza está en qué cubre cada uno y dónde se solapan.
¿Qué sanciones hay por incumplir? Hasta 35 millones de euros o el 7% del volumen de negocio mundial anual, lo que sea mayor, por incurrir en prácticas prohibidas. Hasta 15 millones o el 3% por incumplir otras obligaciones, y hasta 7,5 millones o el 1,5% por facilitar información incorrecta a las autoridades. Las cifras están calibradas para que el incumplimiento no salga barato ni a las grandes organizaciones.