Saltar al contenido
Volver al Blog

compliance · 12 min de lectura

EU AI Act: las obligaciones GPAI entran en aplicación el 2 de agosto de 2025

Segundo escalón del Reglamento (UE) 2024/1689. Documentación técnica, training data summary, política de copyright y, para los modelos con riesgo sistémico, evaluaciones adversariales y reporte de incidentes. Code of Practice firmado por 26 proveedores; Meta queda fuera, xAI firma solo Safety & Security.

· Manuel López Pérez · compliance

Segundo escalón del Reglamento (UE) 2024/1689. Documentación técnica, training data summary, política de copyright y, para los modelos con riesgo sistémico, evaluaciones adversariales y reporte de incidentes. Code of Practice firmado por 26 proveedores; Meta queda fuera, xAI firma solo Safety & Security.

El 2 de agosto de 2025 entra en aplicación el segundo escalón del Reglamento (UE) 2024/1689 — el AI Act: las obligaciones del Capítulo V para proveedores de modelos de propósito general (GPAI). Cualquier modelo GPAI colocado en el mercado UE a partir de esa fecha tiene que cumplir desde el día uno. Los modelos colocados antes tienen hasta el 2 de agosto de 2027 para adaptarse (Art. 111).

Calendario previo cubierto en IRONHACKERS:

Este post se centra en lo que cambia operativamente el 2 de agosto para OpenAI, Anthropic, Google, Meta, Mistral, xAI, DeepSeek y cualquier otro provider con modelos accesibles desde la UE. Sin alarmismo: lo que dice el texto, qué se ha publicado en el Code of Practice y quién ha firmado.

Lectura: análisis de texto legal en vigor más documentos secundarios (Code of Practice for GPAI, guidelines de la Comisión). Para cualquier decisión vinculante, leer directamente el Reglamento.

Las obligaciones del Art. 53 — para todo GPAI

Todo proveedor de modelo GPAI (riesgo sistémico o no, abierto o cerrado, EU o no-EU si el modelo se ofrece en UE) tiene cuatro obligaciones materiales:

1. Documentación técnica del modelo (Art. 53.1.a, Anexo XI)

Documento mantenido al día sobre el modelo y disponible para la AI Office y autoridades nacionales bajo petición. Contenido del Anexo XI:

  • Tareas previstas y tareas que el modelo puede ejecutar; modalidades; arquitectura; número de parámetros; tamaño del input/output; licencia.
  • Proceso de entrenamiento: tipo y procedencia de los datos, métodos de curado, mitigación de sesgos, cómputo total estimado en FLOPs, consumo energético del entrenamiento.
  • Política de testing y resultados de evaluaciones internas.
  • Métricas relevantes para evaluar el modelo (accuracy en benchmarks, comportamiento bajo input adversarial, resistencia a degradación con perturbación).

El documento no se publica al público; queda como disclosable a regulador bajo petición.

2. Información para deployers downstream (Art. 53.1.b, Anexo XII)

Documento que el provider entrega al integrador comercial. Lo que tiene que contener:

  • Descripción de capacidades y limitaciones del modelo.
  • Casos de uso para los que está diseñado y casos para los que no.
  • Datos sobre los que se evaluó, métricas de rendimiento, sesgos identificados.
  • Recursos computacionales necesarios para inferencia.

El destinatario es el deployer que monta producto sobre el modelo. La obligación existe porque el deployer es responsable de su propio cumplimiento (Art. 26) y necesita información del provider para hacerlo.

3. Training data summary (Art. 53.1.d)

La obligación con más expectación pública. Resumen suficientemente detallado del contenido usado para entrenar el modelo, publicado conforme a la plantilla armonizada que la AI Office ha publicado.

La plantilla obliga a desclasificar a alto nivel:

  • Tamaño total del dataset (en tokens, ejemplos, o equivalente según modalidad).
  • Modalidades (texto, código, imagen, audio, vídeo) y proporción de cada una.
  • Datasets públicos grandes identificados por nombre (Common Crawl, Wikipedia, GitHub, LAION, etc.).
  • Descripción narrativa de fuentes licenciadas, datos privados, contenido scrapeado (incluyendo los dominios más relevantes), datos de usuario y datos sintéticos.

No es un BOM completo, sino un resumen narrativo más estructurado. La intención política: dar a copyright holders y a reguladores de protección de datos información suficiente para evaluar si su material aparece en el corpus de entrenamiento.

Política documentada para identificar y respetar reservas de derechos ejercidas conforme al Art. 4(3) de la Directiva 2019/790 (CDSM Directive — text and data mining exception). En la práctica, mecanismos de respeto a opt-outs como:

  • robots.txt con disallows específicos para crawlers de entrenamiento.
  • TDM Reservation Protocol y similares.
  • Metadatos C2PA o markers equivalentes en contenido marcado como reservado.
  • Acuerdos contractuales de licencia cuando el material se obtiene fuera de scraping.

La política tiene que documentarse y operarse efectivamente; no basta con la cláusula en términos de uso.

Las obligaciones adicionales del Art. 55 — para GPAI con riesgo sistémico

El criterio del Art. 51.2: modelos entrenados con >10^25 FLOPs acumulados, o designados como sistémicos por la Comisión vía Art. 51.1.b. La Commission Guidelines for GPAI providers publicada en julio de 2025 aporta detalles operativos sobre el umbral:

  • El provider tiene que notificar a la Comisión en dos semanas desde el momento en que razonablemente prevea o supere el umbral.
  • La estimación del cómputo tiene que ser precisa al ±30 %, con documentación de hipótesis y márgenes de error.
  • Métodos aceptados: tracking de GPU/TPU (hardware-based) o estimación basada en arquitectura.
  • El provider puede contestar la clasificación aportando evidencia técnica (benchmarks, scaling laws) de que su modelo no presenta riesgo sistémico pese a superar el umbral.

Para referencia operativa: GPT-4 ~2·10^25 FLOPs (Epoch AI estimación), Llama-3.1-405B ~4·10^25, Gemini Ultra ~5·10^25, Claude 3.5 Sonnet por debajo aproximadamente, GPT-4o sobre 4·10^25. La frontera no es nítida porque los proveedores no publican FLOPs reales — es estimación de terceros.

Para los que caen en GPAI sistémico, además de las cuatro del Art. 53:

Evaluaciones del modelo (Art. 55.1.a)

Evaluaciones con metodología state-of-the-art, incluyendo adversarial testing estructurado (red teaming, capability evaluations). Los protocolos referenciados son los que ya operan los frontier labs internamente — RSP / Responsible Scaling Policy de Anthropic, Preparedness Framework de OpenAI, evals de DeepMind. Lo que cambia: la obligación legal de documentar y conservar.

Análisis y mitigación de riesgos sistémicos (Art. 55.1.b)

Documentar los riesgos a nivel UE (CBRN — chemical, biological, radiological, nuclear; ofensiva cyber; manipulación y desinformación; pérdida de control; autonomía no alineada) y las medidas de mitigación adoptadas.

Reporte de incidentes serios (Art. 55.1.c)

A la AI Office y autoridades nacionales. Sin plazos exactos en el Reglamento — el Code of Practice los operacionaliza. Incluye uso del modelo en serious incident con daño a salud, infraestructura crítica, derechos fundamentales o medio ambiente.

Ciberseguridad del modelo (Art. 55.1.d)

Nivel adecuado de protección para los pesos del modelo y para la infraestructura física de entrenamiento e inferencia. La AI Office tiene mandato de coordinarse con ENISA en guidelines específicas.

Tracking energético (incluido en Anexo XI bajo Art. 53)

Aplicable a todo GPAI pero con mayor escrutinio para los sistémicos. Consumo del entrenamiento documentado.

El Code of Practice — adequacy decision el 1 de agosto

La AI Office publica la versión final del Code of Practice for GPAI el 10 de julio de 2025. El 1 de agosto, la Comisión Europea y el AI Board lo endosan formalmente vía adequacy decisions. Firmar el CoP implica presunción de conformidad con las obligaciones de los Arts. 53 y 55 — no exime de la obligación, pero traslada al regulador la carga de probar incumplimiento.

Estructura del CoP — tres capítulos firmables por separado:

Transparency Chapter

Operacionaliza Art. 53.1.a y 53.1.b. Aporta un Model Documentation Form — formulario unificado que el provider rellena con la información técnica y la información para downstream. La firma vincula al provider a:

  • Mantener documentación al día desde el placement on market.
  • Publicar lo público y poner a disposición lo regulatorio en plazo cuando se solicite.
  • Cooperar con la AI Office.

Operacionaliza Art. 53.1.c. Las medidas concretas:

  • Respeto a robots.txt y mecanismos equivalentes de opt-out de TDM.
  • Crawlers identificados (User-Agent estable y documentado, no spoofeable).
  • Excluir del corpus contenido marcado como reservado por el rightsholder donde sea técnicamente factible.
  • Mecanismo de comunicación con titulares de derechos para queries específicas.
  • Comportamiento ante contenido obviamente pirateado (e.g., dominios conocidos de shadow libraries).

Safety and Security Chapter

Operacionaliza Art. 55. Aplica solo a providers de modelos GPAI con riesgo sistémico. Las medidas:

  • Safety and Security Framework documentado: amenazas evaluadas, capability thresholds, safety mitigations, security measures para pesos.
  • Evaluaciones pre-deployment con state-of-the-art red teaming.
  • Programa de reporte de incidentes con plazos definidos.
  • Auditorías externas periódicas.
  • Protección de pesos del modelo con medidas técnicas y organizativas alineadas con el Frontier Model Forum baseline y guidance ENISA.

Quién firma y quién no — situación a 2 de agosto

A la fecha de aplicación, 26 proveedores firman el CoP completo. La lista incluye los frontier labs estadounidenses y europeos, más providers especializados:

ProviderOrigenChapters firmados
OpenAIUSCompleto (Transparency + Copyright + Safety)
AnthropicUSCompleto
Google (DeepMind)USCompleto
MicrosoftUSCompleto
AmazonUSCompleto
IBMUSCompleto
Mistral AIFRCompleto
Aleph AlphaDECompleto
Black Forest LabsDECompleto
CohereCACompleto
ServiceNowUSCompleto
WRITERUSCompleto
(otros 14, mayormente europeos especializados)Completo
xAIUSSolo Safety and Security
MetaUSNo firma
DeepSeekCNNo firma

Las dos excepciones cuentan una historia.

Meta — no firma, declaración pública contra el CoP

Meta anuncia el 18 de julio de 2025, vía LinkedIn post del Chief Global Affairs Officer Joel Kaplan, que no firmará. Argumento: el CoP “introduce un número de incertidumbres legales para los model developers, así como medidas que van más allá del alcance del AI Act”. La frase opera dos niveles — uno técnico-legal (alegación de ultra vires del CoP respecto al Reglamento) y uno político (Meta hace gesto público de oposición a la regulación europea, alineado con la posición US post-toma de posesión Trump).

Consecuencia operativa: Meta tiene que demostrar cumplimiento de Arts. 53 y 55 via alternative adequate means — sin la presunción de conformidad que da el CoP, el regulador puede pedirle documentación específica con cualquier nivel de detalle. La AI Office puede iniciar investigaciones más fácilmente. La carga procesal en cualquier disputa cae del lado de Meta.

xAI — firma solo Safety and Security

xAI, fundada por Elon Musk, firma únicamente el capítulo de Safety and Security. No firma Transparency ni Copyright. Para esos dos, también opera via alternative adequate means.

Lectura: xAI acepta el régimen de safety (donde el alineamiento con frontier labs es operativo — los evaluations y capability thresholds son ya un lenguaje común) pero rechaza las obligaciones de transparencia documental y de respeto a opt-outs de copyright. Coherente con su modelo público de pasar por encima de muchas reservas de uso de Twitter/X como dataset.

DeepSeek y otros providers chinos

DeepSeek no firma. Tampoco firma ningún provider chino. La AI Office no ha publicado actuación específica al respecto. La pregunta operativa: ¿qué modelos de origen chino están colocados en el mercado UE? Los pesos están en Hugging Face, accesibles a deployers UE, pero el placement on market formal cuando el provider no tiene establecimiento ni representante en UE es un punto operativo abierto. El Art. 22 obliga a designar representante autorizado en UE para providers establecidos fuera — sin él, el deployer puede heredar obligaciones del provider de facto.

Lectura para Trust & Safety teams

Para un equipo de Trust & Safety con responsabilidad sobre deployment de GPAI en producto, el 2 de agosto introduce tres cambios materiales en el calendario:

  1. Pivote del “responsible disclosure interno” a “documentación regulable”. Las evaluaciones de seguridad y los red teaming que se hacían ya como parte de la RSP / Preparedness Framework pasan a ser disclosable bajo Art. 55. Cambia el formato (más estructurado, en Model Documentation Form), cambia el destinatario (autoridad regulatoria UE), no cambia mucho el contenido para quien ya operaba con marcos internos serios.

  2. Pipeline de copyright operativo. El respeto a opt-outs deja de ser “best effort” para convertirse en política documentada con métricas. Para el deployer que monta producto sobre GPAI: pregunta al provider qué dominios excluye, cómo opera el opt-out, qué mecanismo tiene para revisión de reclamaciones. Cualquier provider que diga “lo gestionamos a nivel de proceso” sin ofrecer documentación concreta es un riesgo trasladable.

  3. Threat model “weights theft” formalizado. Art. 55.1.d obliga a ciberseguridad adecuada de los pesos. ENISA y AI Office publicarán guidelines durante 2025-2026. La conversación que ya existía en frontier labs sobre Security Level 3 / Security Level 4 (Frontier Model Forum baseline) pasa a tener correspondencia regulatoria. Para deployers que reciben copia de pesos para fine-tuning o on-prem, el supply chain del peso se vuelve auditable.

Las tensiones que conviene anticipar:

  • Secretos comerciales vs documentación regulable. El detalle del Anexo XI puede tocar terreno que los providers consideran propietary. Las Commission Guidelines aclaran que el access es on request por autoridades, con duty of confidentiality, pero la línea es fina. Esperar litigation pública sobre alcance de disclosable to regulator.
  • Copyright holders vs scope del training data summary. La plantilla pide “dominios más relevantes” — The New York Times y similar ya han pedido más detalle. Habrá presión durante 2025-2026 para expandir la plantilla.
  • DeepSeek y modelos chinos en UE. ¿La AI Office persigue actuación contra deployers UE que sirven DeepSeek-V3 / R1 en producto sin que el provider tenga representante? Material para el segundo semestre.

Lo que NO cambia el 2 de agosto

Es útil acotar:

  • Sistemas de alto riesgo del Anexo III entran en aplicación general el 2 de agosto de 2026 (Art. 113.b). Hasta entonces, las obligaciones del Capítulo III sobre high-risk son guía, no exigible.
  • Productos del Anexo I (juguetes, dispositivos médicos, vehículos, etc.) con componente AI entran el 2 de agosto de 2027 (Art. 113.c).
  • Aplicación de sanciones a GPAI: el Art. 101 entra en aplicación general el 2 de agosto de 2026. Durante el primer año, la AI Office puede iniciar investigaciones y publicar findings, pero la imposición de multas a providers GPAI se difiere a 2026.
  • Modelos GPAI pre-existentes (los colocados antes del 2-ago-2025): plazo hasta 2 de agosto de 2027 para adaptarse (Art. 111.3). Esto incluye GPT-4, Claude 3.5, Gemini 1.5/2.0, Llama 3, Mistral Large, etc.

Referencias

Volver al Blog

Posts Relacionados

Ver Todos los Posts »
EU AI Act en vigor: Reglamento (UE) 2024/1689 y el calendario operativo

compliance · 12 min

EU AI Act en vigor: Reglamento (UE) 2024/1689 y el calendario operativo

El 1 de agosto entra en vigor el AI Act tras publicación en DOUE el 12 de julio. La aplicación es escalonada: prohibiciones del Art. 5 a 6 meses, GPAI a 12, alto riesgo Anexo III a 24, productos Anexo I a 36. Lo que un CISO/DPO necesita poner en marcha ahora.

· Manuel López Pérez

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

compliance · 20 min

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

El tercer escalón del Reglamento (UE) 2024/1689 entra en aplicación el 2 de agosto de 2026: sistemas de alto riesgo del Anexo III, FRIA, post-market monitoring, marcado CE, registro UE. El Digital Omnibus de la Comisión propone retrasarlo a 2 de diciembre de 2027, pero el trílogo del 28 de abril cierra sin acuerdo. Qué tener listo el 2 de agosto si Bruselas no llega.

· Manuel López Pérez