La Comisión Europea publica el borrador de directrices para los modelos de IA de propósito general
La Comisión Europea publicó el 18 de julio de 2025 un borrador de directrices para aclarar la aplicación de la Ley de IA a los modelos de propósito general (GPAI). El documento define los umbrales técnicos y las obligaciones legales que deberán cumplir los desarrolladores en la Unión Europea.

La Comisión Europea ha presentado el 18 de julio de 2025 un conjunto de directrices preliminares diseñadas para interpretar y aplicar las disposiciones de la Ley de IA de la UE específicamente a los modelos de inteligencia artificial de propósito general (GPAI). Este documento actúa como una hoja de ruta operativa para los proveedores de tecnología, estableciendo criterios precisos sobre qué constituye un modelo GPAI, cuáles son sus obligaciones a lo largo de su ciclo de vida y cómo se clasificarán aquellos que presenten un riesgo sistémico.
Para determinar si un modelo entra en la categoría de GPAI, la Comisión ha establecido un umbral de computación basado en las operaciones de coma flotante (FLOPs). Un modelo se clasificará como GPAI si ha sido entrenado utilizando más de 10²³ FLOPs y posee la capacidad de generar salidas de texto, audio, imágenes o vídeo. La computación se entiende aquí como una medida combinada del tamaño del modelo, referido a sus parámetros, y el volumen del conjunto de datos utilizado para el entrenamiento. Como referencia técnica, un modelo con aproximadamente mil millones de parámetros entrenado con conjuntos de datos sustanciales alcanzaría habitualmente este límite.
No obstante, el cumplimiento del umbral de computación no es el único requisito. Las directrices introducen el concepto de requisito de generalidad funcional. Esto implica que aquellos modelos que superen los 10²³ FLOPs pero estén diseñados para tareas altamente especializadas —como la predicción meteorológica, el escalado de imágenes, la transcripción o el desarrollo de videojuegos— quedarán excluidos de la clasificación GPAI si carecen de capacidades transversales aplicables a una amplia gama de tareas.
Una vez que un modelo es calificado como GPAI, el proveedor debe cumplir con una serie de obligaciones que abarcan todo el ciclo de vida del producto, comenzando desde la fase de preentrenamiento y extendiéndose a cualquier modificación posterior a su comercialización. Entre estas responsabilidades destaca la gestión de una documentación técnica detallada que debe mantenerse actualizada y entregarse a los proveedores downstream (aquellos que integran el modelo en sus propios sistemas) o a la Oficina de IA y las autoridades nacionales competentes cuando sea requerido.
Además de la documentación, los desarrolladores de modelos GPAI están obligados a publicar un resumen de los datos utilizados para el entrenamiento. Para garantizar la uniformidad, este resumen deberá seguir una plantilla específica que la Oficina de IA emitirá próximamente. Asimismo, es imperativo implementar una política de cumplimiento de derechos de autor que aborde la legalidad de los datos utilizados, la cual puede aplicarse de manera transversal a todos los modelos de la compañía.
El marco normativo introduce una categoría más restrictiva para los modelos de IA de propósito general con riesgo sistémico. La presunción de riesgo sistémico se activa automáticamente para cualquier modelo entrenado con un volumen de computación igual o superior a 10²⁵ FLOPs, considerándose que poseen capacidades de alto impacto. Estos modelos están sujetos a obligaciones adicionales mucho más estrictas, que incluyen la realización de evaluaciones del modelo y la implementación de medidas de mitigación de riesgos exhaustivas durante todo su ciclo de vida.
En el ámbito de la seguridad, los modelos con riesgo sistémico deben integrar medidas de ciberseguridad robustas y establecer sistemas de seguimiento y reporte de incidentes graves. Los proveedores tienen la obligación legal de notificar a la Comisión Europea en un plazo de dos semanas desde el momento en que prevean razonablemente que alcanzarán el umbral de los 10²⁵ FLOPs. Dicha notificación debe incluir las estimaciones de computación y las metodologías de cálculo empleadas, incluso si se trata de aproximaciones.
Para evitar clasificaciones erróneas, la Comisión ha previsto un proceso de refutación. Los proveedores pueden impugnar la designación de riesgo sistémico aportando pruebas sólidas, tales como resultados de benchmarks (pruebas de rendimiento estandarizadas) o leyes de escalado que demuestren que el modelo no representa un riesgo para la sociedad. Mientras la Comisión revisa estas pruebas, las obligaciones del riesgo sistémico siguen vigentes. Tras la designación, el proveedor puede solicitar una reevaluación inicial a los seis meses y una segunda solicitud seis meses después si la primera fue denegada.
El documento también clarifica quién ostenta la responsabilidad legal como proveedor. Si una entidad desarrolla y lanza un modelo en el mercado de la UE, es la proveedora. En casos donde una entidad externa desarrolle el modelo para un tercero que luego lo comercialice, la responsabilidad recae en quien lo pone en el mercado. El hecho de alojar un modelo en un repositorio externo no transfiere la condición de proveedor; la entidad creadora sigue siendo la responsable legal.
En el caso de consorcios, la responsabilidad recae generalmente en el coordinador o en el propio consorcio, dependiendo de los acuerdos contractuales. Respecto a los modelos de origen no perteneciente a la UE, se consideran puestos en el mercado europeo en el momento en que se integran en un sistema comercializado en la Unión. El actor upstream (creador original) es el proveedor, a menos que haya excluido explícitamente el uso en la UE, en cuyo caso la responsabilidad pasa al actor downstream que integra la tecnología.
Las directrices abordan la situación de los modificadores downstream, aclarando que no cualquier cambio en el modelo convierte al modificador en un nuevo proveedor de GPAI. Para que ocurra esta reclasificación, la computación utilizada para la modificación debe superar un tercio de la computación original del modelo. Específicamente, debe ser igual o superior a un tercio de 10²³ FLOPs para modelos GPAI estándar, o un tercio de 10²⁵ FLOPs para aquellos con riesgo sistémico.
En estos casos de modificación sustancial, las obligaciones de documentación, resumen de datos de entrenamiento y política de copyright se aplican únicamente a la computación y los datos adicionales añadidos. Sin embargo, si se modifica un modelo ya clasificado con riesgo sistémico, el modificador debe cumplir plenamente con todas las obligaciones de riesgo sistémico, incluyendo la notificación obligatoria a la Comisión Europea.
Los modelos de código abierto (open source) cuentan con exenciones parciales para reducir la carga administrativa. Los proveedores de modelos GPAI bajo licencias libres y abiertas no están obligados a proporcionar documentación técnica a los proveedores downstream ni a las autoridades nacionales. No obstante, deben seguir cumpliendo con la publicación del resumen de datos de entrenamiento y la política de derechos de autor.
Es fundamental señalar que las exenciones de código abierto desaparecen si el modelo es designado como un GPAI con riesgo sistémico. En ese escenario, el proveedor deberá cumplir la totalidad de las obligaciones, incluyendo la gestión de riesgos, las evaluaciones del modelo, el reporte de incidentes y las medidas de ciberseguridad, independientemente de que la licencia sea abierta.
Para calificar como código abierto bajo la Ley de IA, la licencia debe permitir libremente el uso, acceso, modificación y redistribución. No se admitirán restricciones que limiten el uso a fines exclusivamente de investigación, prohibiciones de redistribución, licencias comerciales obligatorias para ciertos usos o restricciones de uso no comercial. Se permiten, sin embargo, requisitos de atribución, la distribución bajo licencias compatibles y salvaguardas proporcionales y no discriminatorias contra usos de alto riesgo que afecten a la seguridad pública.
Este borrador de directrices representa la transición de un marco legal teórico a una implementación técnica concreta. Al definir los FLOPs como la métrica principal, la Unión Europea evita depender de listas cerradas de capacidades o tareas, que quedarían obsoletas rápidamente debido a la velocidad de avance de la IA. La adopción formal de estas directrices ocurrirá una vez que el texto haya sido traducido a todos los idiomas oficiales de la Unión, adquiriendo entonces plena relevancia operativa y legal para todas las empresas de IA que operen en el territorio comunitario.
Fuentes
1. artificialintelligenceact.eu: https://artificialintelligenceact.eu/gpai-guidelines-overview/?utm_source=rss&utm_medium=rss&utm_campaign=gpai-guidelines-overview | 2. Google: https://deepmind.google/blog/gemini-4-argon-our-next-era-of-frontier-intelligence/ | 3. AI Now Institute: https://ainowinstitute.org/news/press/how-the-bad-science-of-ai-doomerism-is-good-for-big-business
Artículos relacionados
El umbral de los 10²³ FLOPs y la delimitación técnica del control regulatorio europeo
La Comisión Europea busca materializar la Ley de IA mediante criterios técnicos cuantificables. El uso de la capacidad de cómputo como filtro define quién queda sujeto a la supervisión comunitaria y quién escapa a ella mediante la especialización funcional.
AnálisisLa gestión del silencio en el parcheo de Zimbra y el riesgo de la superficie expuesta
La explotación de la vulnerabilidad CVE-2026-73570 en Zimbra Collaboration Suite evidencia un fallo sistémico en la comunicación de seguridad de Synacor. Este incidente pone de relieve la peligrosidad de mantener activos componentes opcionales y el impacto de las ventanas de exposición prolongadas.
HerramientasMistral migra 40.000 líneas de código Fortran 77 a C++ para un operador energético
Mistral ha utilizado agentes de IA para trasladar 40.000 líneas de código de un simulador de yacimientos de un operador energético europeo. El proceso ha transformado un sistema obsoleto en Fortran 77 a C++, demostrando la viabilidad de modernizar software crítico en sectores industriales.
AnálisisTony Fadell analiza el fracaso de los primeros dispositivos de IA y la clave de su éxito
Tony Fadell, creador del iPod, ha señalado durante el MIT Future Fest que la primera generación de dispositivos de IA falló por no resolver problemas reales. El experto sostiene que la confianza del usuario y el procesamiento local son las únicas vías hacia la viabilidad comercial.