EU AI Act Anexo III: a tres meses del 2 de agosto, con el Digital Omnibus de Bruselas en aire

El 2 de agosto de 2026 debería ser el tercer escalón real del Reglamento (UE) 2024/1689 — el AI Act. Aplicación general del Capítulo III, sección 2: obligaciones para sistemas de alto riesgo del Anexo III, evaluación de conformidad, marcado CE, registro en la base de datos UE, FRIA, post-market monitoring, régimen sancionador completo. Veinticuatro meses desde la entrada en vigor del 1 de agosto de 2024.

Tres meses antes de la fecha, el calendario está sometido al Digital Omnibus on AI de la Comisión — un paquete de simplificación publicado el 19 de noviembre de 2025 que propone, entre otras cosas, mover el deadline a 2 de diciembre de 2027 para los sistemas Anexo III stand-alone y a 2 de agosto de 2028 para los sistemas integrados en productos del Anexo I. El 28 de abril de 2026 el segundo trílogo cierra sin acuerdo tras doce horas. Hay un tercer trílogo programado para mediados de mayo. Mientras tanto, la ley vigente sigue diciendo 2 de agosto de 2026.

El calendario previo cubierto en IRONHACKERS:

• Diciembre 2023 — acuerdo político del trilogue de los Three Days in Brussels.
• Agosto 2024 — entrada en vigor del Reglamento y calendario completo.
• Febrero 2025 — Art. 5 en aplicación: ocho prácticas prohibidas.
• Agosto 2025 — GPAI Capítulo V en aplicación: documentación, training data summary, Code of Practice.

Este post es el siguiente del arco. Producto real afectado, no paráfrasis del Boletín. Para un CISO / DPO / responsible AI con sistemas Anexo III en el inventario, qué hay encima de la mesa y qué hacer en el worst case “el Omnibus no llega a tiempo”.

Lectura: texto consolidado del Reglamento en EUR-Lex, proposal del Digital Omnibus de noviembre de 2025, mandato revisado del Consejo de 17 de abril de 2026, briefings del EP Think Tank y reporting técnico-legal. Para decisión vinculante, leer el texto del Reglamento y el mandato negocial de la institución correspondiente.

La fecha y por qué importa

El Art. 113 del Reglamento marca el 2 de agosto de 2026 como fecha por defecto: aplica el texto completo salvo las excepciones de las letras (a), (b) y (c). La (a) cubre prohibiciones del Art. 5 desde febrero de 2025. La (b) cubre GPAI desde agosto de 2025. La (c) difiere Anexo I (productos regulados) hasta agosto de 2027. Todo lo demás, incluidos los sistemas Anexo III del bloque entero del Capítulo III, sección 2, entra el 2 de agosto de 2026:

El régimen sancionador del Art. 99 completa el cuadro el mismo día: hasta 15 millones de euros o el 3 % de la facturación anual mundial para incumplimiento de obligaciones high-risk; hasta 7,5 millones o el 1 % por información incorrecta a autoridades. Régimen menor que el del Art. 5 (35 M€ / 7 %) pero todavía bien por encima del baseline GDPR para obligaciones equivalentes. Para PYMEs y startups, importe menor de los dos (Art. 99.6).

El Anexo III, ocho categorías

El Art. 6.2 define como alto riesgo cualquier sistema de IA que esté listado en el Anexo III. La lista (con las subcategorías agregadas por la Comisión vía actos delegados) es:

1. Biometría

• 1.a Identificación biométrica remota. Excepción: verificación biométrica para confirmar identidad alegada de una persona concreta.
• 1.b Categorización biométrica por atributos sensibles que no caigan en la prohibición del Art. 5.1.g.
• 1.c Reconocimiento de emociones fuera del puesto de trabajo y centros educativos (que están en prohibición Art. 5.1.f).

2. Infraestructuras críticas

Componentes de seguridad de gestión y operación de infraestructura digital crítica, tráfico rodado, y suministro de agua, gas, calefacción o electricidad.

3. Educación y formación profesional

• 3.a Acceso y admisión.
• 3.b Evaluación de resultados de aprendizaje que conduzcan a orientación del proceso.
• 3.c Evaluación del nivel apropiado de educación al que la persona accede.
• 3.d Detección de comportamiento prohibido durante exámenes.

4. Empleo y gestión de trabajadores

• 4.a Reclutamiento — publicación dirigida de ofertas, filtrado de CVs, evaluación de candidatos.
• 4.b Decisiones que afectan a la relación laboral, promoción, terminación, asignación de tareas, monitorización de rendimiento y comportamiento.

5. Acceso a servicios esenciales

• 5.a Asistencia pública esencial, incluida sanidad.
• 5.b Evaluación de solvencia crediticia y scoring de crédito (excepción: detección de fraude financiero).
• 5.c Evaluación de riesgo y precio en seguros de vida y salud.
• 5.d Triaje de llamadas de emergencia y dispatch.

6. Aplicación de la ley

• 6.a Evaluación de riesgo de victimización.
• 6.b Polígrafos y herramientas similares.
• 6.c Evaluación de fiabilidad de pruebas durante investigación o instrucción.
• 6.d Riesgo de reincidencia.
• 6.e Profiling de personas durante investigación criminal.

7. Migración, asilo y control de fronteras

• 7.a Polígrafos y herramientas similares.
• 7.b Evaluación de riesgo (seguridad, migración irregular, sanitario).
• 7.c Asistencia al examen de solicitudes de asilo, visado, residencia.
• 7.d Detección, reconocimiento, identificación de personas (excepción: verificación de documentos de viaje).

8. Administración de justicia y procesos democráticos

• 8.a Asistencia a autoridad judicial en investigación e interpretación de hechos y aplicación del Derecho.
• 8.b Sistemas que pretenden influir en el resultado de elecciones o referenda o en el comportamiento electoral (excepción: herramientas administrativas o logísticas sin impacto sobre el voto).

El paso operativo: para cada sistema del inventario, primero confirmar si cae en una subcategoría. Si cae, segundo, comprobar la excepción del Art. 6.3 — un provider puede documentar que el sistema, pese a estar listado, no afecta materialmente al resultado de la toma de decisiones. La excepción es estrecha (cuatro supuestos, todos relativos a tareas procedimentales acotadas), pero existe y hay que documentarla con criterio.

Lo que el provider tiene que tener listo

Asumiendo que un sistema cae como Anexo III y no aplica la excepción 6.3, el paquete del provider a 2 de agosto de 2026 es:

Documentación técnica — Anexo IV

Documento de hasta nueve secciones (Anexo IV del Reglamento) que el provider mantiene y entrega bajo petición a market surveillance authorities:

1. Descripción general del sistema — propósito, versión, intended use, foreseeable misuse, hardware y software, modelo de despliegue, formularios de marca CE.
2. Descripción detallada de los elementos y del proceso de desarrollo — métodos, fechas, modelos de IA pre-entrenados usados, validación, test.
3. Descripción de las capacidades y limitaciones de performance, incluyendo personas o grupos sobre los que el sistema está diseñado para operar y, en su caso, limitaciones por contexto geográfico.
4. Descripción del sistema de gestión de riesgos (Art. 9).
5. Descripción de los cambios significativos planificados o realizados durante el ciclo de vida.
6. Lista de estándares armonizados aplicados o, si no se aplican, descripción de las soluciones técnicas adoptadas para cumplir el Reglamento.
7. Copia de la declaración UE de conformidad (Art. 47).
8. Descripción del sistema de post-market monitoring (Art. 72), incluyendo el plan.
9. Lista de la documentación complementaria (informes de validación, data sheets, etc.).

Es el documento más voluminoso del cumplimiento. La práctica industrial que está apareciendo en Q1 2026 (gracias a las guías AESIA y a templates que están publicando CEN-CENELEC y firmas legales): technical file de 100–300 páginas por sistema, mantenido en CMS con versionado. El provider que pretenda mantenerlo en un Notion sin trazabilidad va a tener una conversación incómoda.

Sistema de gestión de calidad — Art. 17

Análogo en estructura a ISO 9001 + ISO/IEC 42001 (la norma específica para AI management systems, publicada en diciembre de 2023). Cubre el ciclo de vida del sistema, no solo el desarrollo. Los puntos del Art. 17:

• Estrategia de cumplimiento con el Reglamento, incluida la conformity assessment elegida.
• Técnicas, procedimientos y acciones sistemáticas para el diseño, control de calidad, verificación, validación y test del sistema.
• Procedimientos para examinar, testar, validar y documentar antes de y después del desarrollo.
• Sistemas y procedimientos para la gestión de datos.
• Sistema de gestión de riesgos (cross-referenciado al Art. 9).
• Reporting de eventos serios.
• Manejo de la comunicación con autoridades nacionales y notified bodies.
• Sistemas y procedimientos para el archivo de toda la documentación.
• Gestión de recursos, incluyendo medidas de seguridad relacionadas con el suministro.
• Accountability framework que defina responsabilidades del management.

Las firmas que ya tienen ISO 9001 o ISO 27001 maduros pueden extender el QMS existente. Las que no, tienen que montar uno desde cero, y montar un QMS desde cero en tres meses no es realista. Esta es una de las razones políticas reales del Omnibus.

Evaluación de conformidad — Art. 43

El régimen depende del tipo de sistema Anexo III:

• Identificación biométrica remota (Anexo III punto 1): conformity assessment con intervención de notified body (Anexo VII del Reglamento).
• Resto de Anexo III: conformity assessment basada en control interno (Anexo VI del Reglamento). El provider audita su propio QMS y su propio technical file y emite la declaración UE de conformidad.

La excepción biométrica importa: notified bodies designadas operativamente para AI Act a 1 de mayo de 2026 son muy pocas — el proceso de designación nacional sigue abierto en la mayoría de los Estados miembros. Para un provider de identificación biométrica remota que necesita conformity assessment de tercero, encontrar notified body con disponibilidad real antes de agosto es ejercicio. Para deployers públicos que dependan de esos sistemas (transporte, control fronterizo), la cadena de cumplimiento sigue rota.

Para el resto de sistemas Anexo III (la mayor parte del mercado en empleo, educación, crédito, seguros, scoring público), el control interno baja la barrera procesal, pero no la sustantiva. El provider firma la declaración UE de conformidad bajo su responsabilidad. Si el sistema no cumple los Arts. 9–15, la responsabilidad es directa.

Marcado CE y registro

• Marcado CE (Art. 48). Físico cuando el sistema sea producto físico o componente de uno; digital en la interfaz del software cuando sea standalone. La declaración UE de conformidad (Art. 47) referencia el marcado.
• Registro en la base de datos UE de sistemas de alto riesgo (Art. 49 y Anexo VIII). Antes del placement on market. Información pública del registro: provider, sistema, descripción, instrucciones de uso, declaración de conformidad, datos relativos a market surveillance. Hay un subset de información confidencial accesible solo a autoridades.

La base de datos la gestiona la Comisión. Para mayo de 2026 está operativa en versión preliminar; la versión definitiva con todos los flujos de envío masivo aún no está abierta al público. Esto es otro punto que el Omnibus aborda — la propuesta de noviembre añade flexibilidad sobre qué información se publica.

Lo que el deployer tiene que tener listo

El deployer, la entidad que usa el sistema y no la que lo desarrolla, tiene su propio paquete del Art. 26:

• Uso conforme a las instrucciones del provider. Documentar el intended use específico de la organización.
• Supervisión humana efectiva, con personal con competencia, formación y autoridad para revertir o detener el sistema.
• Gestión de input data apropiada al contexto del deployer.
• Monitorización del funcionamiento del sistema y suspensión cuando se detecte funcionamiento anómalo.
• Retención de logs automáticos generados por el sistema durante al menos seis meses (Art. 26.6).
• Notificación al provider y a la autoridad de market surveillance de cualquier serious incident.
• Información al trabajador afectado por un sistema Anexo III en su entorno laboral antes del despliegue (Art. 26.7).
• Cooperación con autoridades.

Y, para deployers específicos del Anexo III, la FRIA — Fundamental Rights Impact Assessment (Art. 27). Aplica a:

• Cualquier public body o entidad privada que preste servicios públicos.
• Cualquier deployer de sistemas del Anexo III, puntos 5.b (credit scoring) y 5.c (insurance risk).

Contenido obligatorio de la FRIA:

• Descripción del proceso en el que se va a usar el sistema.
• Periodo de uso y frecuencia.
• Categorías de personas y grupos afectados.
• Riesgos específicos para los derechos fundamentales, sobre la base del intended use comunicado por el provider.
• Medidas de supervisión humana implementadas.
• Medidas a tomar en caso de materialización del riesgo, incluyendo procedimientos internos de queja y reparación.

La FRIA debe completarse antes del primer uso del sistema. La autoridad de market surveillance puede requerir su entrega. El formato será probablemente templating armonizado de la AI Office; al cierre de abril de 2026 sigue pendiente.

El Digital Omnibus on AI — qué propone y dónde está

Esta es la pieza que cambia toda la conversación operativa en Q2 de 2026.

El 19 de noviembre de 2025 la Comisión publica el Digital Omnibus on AI — proposal COM(2025)/X. No es un paquete que toque solo el AI Act; el omnibus paralelo amenta también GDPR, ePrivacy, NIS2 y Data Act. La parte AI propone, en lo esencial:

Cambio de fechas (artículo 113 modificado)

• Anexo III stand-alone: aplicación 2 de diciembre de 2027 (en lugar de 2 de agosto de 2026).
• Anexo I (productos regulados con AI integrada): aplicación 2 de agosto de 2028 (en lugar de 2 de agosto de 2027).
• Sandboxes regulatorios nacionales (Art. 57): deadline de operatividad pasado de 2 de agosto de 2026 a 2 de agosto de 2027, con sandbox UE adicional operada por la AI Office.
• Transparencia y watermarking generativo (Art. 50): postponed por la Comisión a 2 de febrero de 2027; el Parlamento defiende 2 de noviembre de 2026; el Consejo se queda en 2 de diciembre de 2026 (compromiso intermedio).

Cambios sustantivos en sistemas Anexo III

• Mayor flexibilidad en el registro de la base de datos UE — qué subset se publica y bajo qué condiciones.
• Procesamiento de categorías especiales de datos (Art. 9 GDPR) ampliado para entrenamiento y detección de sesgos en sistemas que no son alto riesgo. EDPB y EDPS publican opinión conjunta en marzo de 2026 advirtiendo del impacto sobre el purpose limitation.
• Ajustes sobre la clasificación Anexo III — la Comisión introduce vía acto delegado la posibilidad de excluir intended use cases que solo procesan tareas estrictamente procedimentales sin influencia material en la decisión.

Cambios procesales

• Eliminación de la obligación de registro en base de datos UE para sistemas Anexo III cuando aplique la excepción del Art. 6.3 (cambio del Reglamento original).
• Postura intermedia sobre obligaciones de alfabetización IA (Art. 4) — el Parlamento defiende mantenerlas; Consejo y Comisión abren puerta a flexibilización.

Nueva prohibición — nudification apps

El Omnibus añade al Art. 5 una nueva práctica prohibida: sistemas cuyo propósito principal es generar imágenes íntimas no consentidas (deepfake nudifiers). La prohibición no es retroactiva — los productos actuales tienen hasta el 2 de diciembre de 2026 para retirarse del mercado UE.

Postura crítica desde la sociedad civil

Más de 40 organizaciones firman a mediados de abril de 2026 una carta abierta a las instituciones europeas argumentando que el Omnibus debilita protecciones del Reglamento original. Las objeciones principales:

• El retraso opera como deregulación de facto para sistemas que se despliegan en el período intermedio sin obligaciones vinculantes.
• Las modificaciones al procesamiento de datos sensibles para detección de sesgos rompen el purpose limitation del GDPR.
• La eliminación de obligaciones de registro y FRIA en casos del Art. 6.3 reduce la transparencia.

Acceso Now, EDRi, Article 19, Center for Democracy and Technology son firmantes. La carta pide al Parlamento mantener algunas obligaciones vinculantes durante el período intermedio. Que esto se incorpore al texto final dependerá del balance trílogo.

La cronología del trílogo en Q2 2026

Para entender por qué a 30 de abril el calendario operativo sigue siendo el original:

El punto que bloquea el 28 de abril no es la fecha del Anexo III: sobre eso hay convergencia tripartita en torno al 2 de diciembre de 2027. Lo que bloquea es la arquitectura de conformity assessment para Anexo I, es decir, cómo se articulan las obligaciones AI con la legislación sectorial existente (Machinery Regulation, MDR, IVDR, vehículos a motor). El Parlamento, vía McNamara, advierte que rutar el cumplimiento AI vía la legislación sectorial podría ser “deregulatorio antes que simplificador”. Council y Comisión defienden carve-outs amplios.

El tercer trílogo de mediados de mayo es la última ventana realista para llegar a tiempo. Si no se adopta antes del 2 de agosto de 2026, el texto original aplica. Si se adopta justo después, queda la incertidumbre de los sistemas colocados entre el 2 de agosto y la fecha de publicación del Omnibus modificado.

Producto real afectado — tres escenarios

Escenario 1 — Provider de scoring de crédito (Anexo III punto 5.b)

Una fintech española que opera credit decisioning para entidades financieras de la UE.

• 2-ago-2026 sin Omnibus: technical file completo, QMS conforme Art. 17, conformity assessment por control interno, declaración UE de conformidad, marcado CE, registro en base de datos UE. Cada cliente bancario (deployer) tiene además que hacer FRIA antes del primer uso. Use case típico: cinco bancos clientes, cinco FRIA distintas con resultados similares pero documentación separada.
• 2-dic-2027 con Omnibus: dieciséis meses extra para tener el technical file y el QMS auditados externamente, alinearse con ISO/IEC 42001, y publicar model cards públicas. Tiempo suficiente para que CEN-CENELEC publique los harmonised standards de Art. 9 y Art. 10 (en draft a abril 2026, publicación esperada Q3-Q4 2026).
• Plan operativo a 30 de abril: ejecutar como si fuera 2 de agosto. Si el Omnibus pasa, la ventaja competitiva es estar listo antes que la competencia. Si no pasa, no haber empezado tarde.

Escenario 2 — Deployer público de sistema de reclutamiento (Anexo III punto 4.a)

Una administración autonómica que usa AI para filtrar candidatos en oposiciones.

• Provider en US: cliente UE depende del cumplimiento del provider. Si el provider no se prepara, el deployer no puede operar legalmente desde el 2 de agosto sin asumir riesgo personal — el sistema sin marcado CE en mercado UE es non-compliant por defecto.
• FRIA: aplica por ser entidad pública (Art. 27). Documento separado para cada convocatoria. Plantilla estandarizada de AI Office aún no publicada — el deployer trabaja con borradores de DG CONNECT y guías AESIA.
• Plan operativo: contacto con provider para confirmar timeline de CE marking, plan B de selección humana si el provider no llega.

Escenario 3 — Provider de identificación biométrica remota (Anexo III punto 1.a)

Una empresa española vendiendo face recognition a operadores de transporte público.

• Conformity assessment con notified body: obligatorio (Art. 43, Anexo VII). Lista de notified bodies designadas para AI Act publicada por la Comisión vía NANDO database. A 1 de mayo de 2026, las designaciones específicas para AI Act siguen abiertas en la mayoría de Estados miembros — la situación práctica es que muchos sistemas Anexo III punto 1.a están bloqueados procesalmente.
• Plan operativo: si la notified body asignada no puede entregar antes del 2 de agosto, el sistema no puede colocarse en mercado en esa fecha. Las empresas en este pillar son las que más beneficio operativo sacan del Omnibus.

Triaje operativo a 30 de abril de 2026

Sin alarmismo. El trabajo operacional para un CISO / DPO / responsible AI hasta el 1 de agosto:

1. Inventario AI completo. Si la respuesta a “qué sistemas IA tenemos” no ha terminado de mapearse desde febrero de 2025 (Art. 5), el trabajo se ha quedado atrás. Antes del 1 de junio, inventario cerrado.
2. Re-clasificación contra Anexo III. Para cada sistema, comprobar las ocho categorías y subcategorías. Documentar la decisión y la base.
3. Excepción Art. 6.3 documentada cuando proceda. Son cuatro supuestos alternativos (basta con que el sistema entre en uno), pero existe un override: cualquier sistema que haga profiling de personas físicas es alto riesgo por defecto, sin excepción posible. El provider que aplique la excepción tiene que sostenerla en inspección.
4. Role check — provider / deployer / importer / distributor. Para fine-tunes sustantivos sobre GPAI, comprobar si la operación dispara cambio de rol (Art. 25).
5. Brecha contra Anexo IV. Para cada sistema clasificado como alto riesgo, gap analysis del technical file vs lo que ya existe. Priorizar Arts. 9 (gestión de riesgos), 10 (datos), 14 (supervisión humana), 15 (precisión, robustez y ciberseguridad) — los cuatro con mayor distancia entre práctica industrial actual y exigencia regulatoria.
6. QMS — gap analysis vs ISO/IEC 42001. Para organizaciones con ISO 9001 / 27001 maduros, mapear los controles existentes y extender. Para las que no, decisión: certificar ISO/IEC 42001 (timeline real 6–12 meses) o construir QMS específico AI Act sin certificación externa.
7. Para Anexo III punto 1.a: contacto con notified body desde ya. La capacidad del ecosistema está limitada.
8. FRIA cuando aplique — sector público y deployers de 5.b/5.c. Plantilla en draft.
9. Plan dual — preparar como si el Omnibus no llegase (deadline 2 de agosto de 2026); ejecutar a velocidad sostenible bajo el supuesto de que sí llega (deadline 2 de diciembre de 2027). El plan dual es lo que están haciendo los Big Four legal y las grandes consultoras AI compliance que están publicando playbooks en Q2 2026.

Coordinación con el resto del compliance stack

El AI Act no vive solo. La coordinación a 2 de agosto de 2026 con normas existentes:

• GDPR (2016/679): cualquier sistema Anexo III que procese datos personales tiene también obligaciones GDPR. El Art. 27 FRIA y el Art. 35 GDPR DPIA tienen significativo overlap conceptual; los data controllers están consolidando templates que cubren ambas — lo coordinado por EDPB en marzo de 2026 es el state of the art.
• NIS2 (Directiva 2022/2555): la ciberseguridad del Art. 15 AI Act se coordina con NIS2 para entidades esenciales. España aprueba la transposición vía LO X/2025 a finales de 2025. Para entidades NIS2 que sean además provider o deployer de sistemas Anexo III, el threat model unifica.
• DORA (2022/2554): para entidades financieras que sean deployer de Anexo III 5.b o 5.c (crédito, seguros), el ICT risk management del Art. 6 DORA y el risk management del Art. 9 AI Act se montan en el mismo ICT risk framework.
• EU AI Liability Directive: propuesta en septiembre de 2022, retirada por la Comisión en febrero de 2025. La responsabilidad civil por daño de sistemas IA queda en manos del derecho nacional + Directiva de productos defectuosos. Para Anexo III, los hooks de responsabilidad son las obligaciones del Capítulo III, no un régimen específico de strict liability.

Lo que sigue abierto a 30 de abril

• Adopción del Omnibus. Si el trílogo del 13 de mayo no llega, fecha del Anexo III es 2 de agosto. Si llega, depende del texto final y la transición.
• Harmonised standards. CEN-CENELEC JTC 21 está en draft de los estándares de Arts. 9, 10, 12, 13, 14, 15. Publicación esperada Q3 2026 — exactamente cuando aplica. Los providers que se apoyen en estándares armonizados para presunción de conformidad pueden trabajar con drafts, pero no tienen la cobertura procesal completa hasta la publicación oficial en DOUE.
• Notified bodies designadas para AI Act. Bottleneck para Anexo III punto 1.a. AESIA, ENAC y Estados miembros con AI Act bodies designadas están publicando designaciones provisionales, pero el NANDO database a 30 de abril sigue con números muy bajos.
• Régimen sancionador español. Anteproyecto de Ley para el ejercicio del régimen sancionador AI Act aprobado por Consejo de Ministros en marzo de 2025; trámite parlamentario activo durante Q1-Q2 2026. AESIA tiene capacidad de inspección pero no de imponer sanciones AI Act hasta que la ley nacional pase. Equivalente al hueco que tuvo NIS2 en España hasta finales de 2025.
• Guidance específica de AESIA sobre Anexo III. La agencia publicó 16 guías técnicas durante 2025-2026; Guía 13 (post-market monitoring) y Guía 14 (incident reporting) se confirman el 28 de abril de 2026. Los toolkits con templates aplicables a Anexo III están en versión beta — la versión final dependerá del texto del Omnibus si pasa.

Referencias

• Texto oficial Reglamento (UE) 2024/1689 (DOUE 12-jul-2024): https://eur-lex.europa.eu/eli/reg/2024/1689/oj
• Art. 6 — Clasificación de alto riesgo: https://artificialintelligenceact.eu/article/6/
• Anexo III — Lista de sistemas de alto riesgo: https://artificialintelligenceact.eu/annex/3/
• Anexo IV — Documentación técnica: https://artificialintelligenceact.eu/annex/4/
• Art. 27 — FRIA: https://artificialintelligenceact.eu/article/27/
• Art. 43 — Evaluación de conformidad: https://artificialintelligenceact.eu/article/43/
• Art. 99 — Sanciones: https://artificialintelligenceact.eu/article/99/
• Comisión Europea, Digital Omnibus on AI Regulation Proposal (19 nov 2025): https://digital-strategy.ec.europa.eu/en/library/digital-omnibus-ai-regulation-proposal
• EP Think Tank, Digital Omnibus on AI, briefing EPRS_BRI(2026)782651: https://www.europarl.europa.eu/RegData/etudes/BRIE/2026/782651/EPRS_BRI(2026)782651_EN.pdf
• Consejo UE, mandato revisado de negociación 8260/26 (17 abr 2026): https://table.media/assets/documents/20260417_revised-mandate-for-negotiations_omnibus-on-ai.pdf
• Bird & Bird, Digital Omnibus on AI Trilogue Stalls Ahead of the AI Act Deadline: https://www.twobirds.com/en/insights/2026/digital-omnibus-on-ai-trilogue-stalls-ahead-of-the-ai-act-deadline
• AESIA — Guías prácticas para el cumplimiento del AI Act: https://aesia.digital.gob.es/en/present/resources/practical-guides-for-ai-act-compliance
• Carta abierta de la sociedad civil sobre Omnibus (EDRi, Access Now, Article 19): https://edri.org/our-work/open-letter-eu-lawmakers-must-safeguard-the-ai-act/
• ISO/IEC 42001:2023 — AI management systems: https://www.iso.org/standard/81230.html
• Posts previos IRONHACKERS: acuerdo político · en vigor · Art. 5 prohibiciones · GPAI obligaciones