Resumen de las directrices para los modelos GPAI

30 Jul, 2025

El 18 de julio de 2025, la Comisión Europea publicó un proyecto de Directrices que aclaran las disposiciones clave de la Ley de IA de la UE aplicables a los modelos de IA de propósito general (GPAI). Las Directrices proporcionan orientación interpretativa sobre la definición y el alcance de los modelos GPAI, las obligaciones relacionadas con el ciclo de vida, los criterios de riesgo sistémico y las obligaciones de notificación para los proveedores. Una vez traducidas a todas las lenguas de la UE, las Directrices se adoptarán formalmente y tendrán relevancia jurídica y operativa para los proveedores de IA.


Definición y ámbito de aplicación

Definición de los modelos GPAI

Las Directrices amplían la definición legal de IPPAM de la Ley de AI, introduciendo umbrales y criterios clave para la clasificación:

Computar umbral:

  • Un modelo GPAI se define como cualquier modelo entrenado utilizando más de 10²³ FLOPS (operaciones en coma flotante por segundo) y capaz de generar salidas de lenguaje (texto/audio), de texto a imagen o de texto a vídeo.

Requisito de generalidad funcional:

  • Los modelos que superan el umbral de los 10²³ FLOPS pero son especializados (por ejemplo, para transcripción, ampliación de imágenes, predicción meteorológica o juegos) se excluyen si carecen de capacidades generales en una amplia gama de tareas.

Aclaraciones técnicas:

  • El cálculo se entiende como una medida combinada del tamaño del modelo (parámetros) y del tamaño del conjunto de datos de entrenamiento.
  • Un modelo con ~1.000 millones de parámetros entrenado en conjuntos de datos sustanciales cumpliría normalmente este umbral de computación.
  • La Comisión ha optado por un único umbral de cálculo estimable en lugar de enumerar tareas o capacidades específicas.

Ciclo de vida del modelo y obligaciones

Una vez que un modelo se califica como modelo GPAI, las obligaciones de todo el ciclo de vida en virtud de la Ley de IA se aplican desde el inicio de su ejecución previa al entrenamiento y se extienden a todas las fases de desarrollo posteriores, incluidas las modificaciones posteriores a la comercialización. 

Las obligaciones incluyen:

  • Documentación: Debe mantenerse y actualizarse, y facilitarse a los proveedores intermedios y, previa solicitud, a la Oficina de AI o a las autoridades nacionales competentes.
  • Resumen de los datos de formación: Los proveedores deben publicar un resumen utilizando la plantilla de la Oficina de AI aún por publicar.
  • Política de derechos de autor: Debe abordar el cumplimiento de los derechos de autor y puede aplicarse a todos los modelos.

Modelos GPAI con riesgo sistémico

Cualquier modelo entrenado usando ≥10²⁵ FLOPS se presume que tiene capacidades de alto impacto y puede ser clasificado como GPAI de riesgo sistémico.

Obligaciones adicionales:

  • Evaluación y mitigación exhaustivas de los riesgos durante todo el ciclo de vida, incluidas las evaluaciones de modelos.
  • Sólidas medidas de ciberseguridad
  • Seguimiento y notificación de incidentes graves

Vías de designación:

  • Presunción automática: Basada en el umbral de FLOPS
  • Designación discrecional: Por la Comisión, incluidas las alertas de la comisión científica

Notificaciones obligatorias:

  • Los proveedores deben notificar a la Comisión en el plazo de dos semanas la previsión razonable o el alcance del umbral de 10²⁵ FLOPS. Las notificaciones deben incluir:
    • Calcular estimaciones
    • Metodologías de estimación (incluidas las aproximaciones)

Proceso de refutación:

  • Los proveedores pueden impugnar la clasificación de riesgo sistémico aportando pruebas sólidas (por ejemplo, resultados de referencia, leyes de escalado) de que el modelo no presenta riesgo sistémico.
  • La Comisión podrá aceptar o rechazar motivadamente las impugnaciones.
  • Las obligaciones siguen vigentes durante la revisión.

Derechos de reevaluación:

  • Los proveedores pueden solicitar una reevaluación inicial seis meses después de la designación.
  • Se permite una segunda solicitud de reevaluación al cabo de otros seis meses si la primera no prospera.

Deber permanente de actualización:

  • Si la impugnación se basa en información sustancialmente modificada o incompleta/incorrecta, el proveedor debe volver a notificarlo a la Comisión.

Determinación del proveedor del modelo GPAI

Desarrollo de entidad única:

  • Si la entidad A desarrolla y comercializa un modelo GPAI en el mercado de la UE, la entidad A es el proveedor.
  • Si la Entidad B desarrolla el modelo para la Entidad A, pero la Entidad A lo comercializa, la Entidad A sigue siendo el proveedor.

Alojamiento de repositorios:

  • Subir un modelo a un repositorio (por ejemplo, alojado por la Entidad C) no transfiere el estatus de proveedor. La entidad A sigue siendo el proveedor.

Desarrollo de consorcios:

  • En el caso de los modelos GPAI desarrollados por o para un consorcio, el proveedor suele ser el coordinador o el propio consorcio, dependiendo de los hechos y los acuerdos contractuales.

Asignación de responsabilidades previas y posteriores

Proveedores anteriores:

  • Si un agente anterior pone primero el modelo a disposición de cualquier agente posterior en el mercado de la UE, ese agente es el proveedor y debe cumplir las obligaciones de proveedor de la GPAI. 

Integradores de sistemas descendentes:

  • Si un agente posterior incorpora el modelo GPAI a un sistema de IA y lo comercializa en la UE, es un proveedor de sistemas y debe cumplir las obligaciones correspondientes a los sistemas de IA.

Modelos de origen no comunitario:

  • Si un modelo se comercializa fuera de la UE pero posteriormente se incorpora a un sistema comercializado en la UE, el modelo se considera comercializado en ese momento.
  • El agente anterior es el proveedor, a menos que haya excluido explícitamente el uso de la UE. En tal caso, el proveedor es el agente posterior.

Modificadores descendentes: Cuándo se convierten en proveedores

No todas las modificaciones desencadenan obligaciones de proveedor para los agentes posteriores. Los cambios menores no suelen reclasificar a un modificador como proveedor de GPAI.

Umbral de reclasificación:

  • Un actor posterior se convierte en el nuevo proveedor de GPAI si el cómputo de entrenamiento utilizado para la modificación supera un tercio del utilizado para entrenar el modelo original:
    • ≥ 1/3 de 10²³ FLOPS para todos los modelos GPAI.
    • ≥ 1/3 de 10²⁵ FLOPS para modelos GPAI con riesgo sistémico.

Alcance de las obligaciones:

  • Sólo se aplican las obligaciones específicas de la modificación: la documentación, el resumen de los datos de formación y la política de derechos de autor sólo se refieren al cálculo y los datos adicionales.
  • Sin embargo, si se modifica un modelo GPAI de riesgo sistémico, el agente posterior debe cumplir plenamente todas las obligaciones en materia de riesgo sistémico, incluida la notificación a la Comisión.

Modelos de código abierto: Exenciones y condiciones

Los proveedores de GPAI de código abierto se benefician de exenciones limitadas en virtud de la Ley de AI:

  • No hay obligación de facilitar documentación a los proveedores intermedios ni, previa solicitud, a la Oficina de AI o a las autoridades nacionales.

Requisitos no exentos:

  • Debe cumplir los requisitos del resumen de datos de formación y de la política de derechos de autor.

Si son designados como modelo GPAI con riesgo sistémico, deben cumplir plenamente todas las obligaciones aplicables, incluida la gestión del riesgo sistémico, las evaluaciones de modelos, la notificación de incidentes y la ciberseguridad.

Para que la Ley de IA lo considere código abierto, el modelo debe publicarse bajo una licencia libre y de código abierto que:

  • Permite el uso, el acceso, la modificación y la redistribución.
  • No impone restricciones como:
    • Uso no comercial o exclusivo para investigación
    • Prohibición de redistribución
    • Umbrales de tamaño de usuario
    • Licencias comerciales obligatorias para determinados usos
  • Restricciones permitidas:
    • Requisitos de créditos y atribuciones
    • Distribución bajo la misma licencia o una licencia compatible
    • Salvaguardias razonables y proporcionadas contra el uso de alto riesgo (por ejemplo, seguridad pública), siempre que no sean discriminatorias.

Monetización y pérdida del estatus de código abierto

Un modelo GPAI pierde las exenciones de código abierto si existe monetización. Los indicadores de monetización incluyen:

  • Modelos de licencia comercial:
    • Doble licencia (por ejemplo, gratuita para uso académico y de pago para uso comercial)
    • Asistencia, mantenimiento o actualizaciones de pago
    • Acceso alojado sujeto a tasas o ingresos publicitarios
  • Dependencia funcional de los servicios de pago:
    • Si los usuarios deben pagar para acceder a funciones esenciales o características de seguridad.
  • Tratamiento de datos personales:
    • El tratamiento de los datos de los usuarios en relación con el acceso, el uso o la modificación puede constituir monetización, a menos que se haga exclusivamente con fines de seguridad no comerciales.

No se considera monetización:

  • Ofrecer servicios o asistencia premium opcionales sin restringir el libre acceso al modelo y su funcionalidad básica.

Aplicación

Código de buenas prácticas 

  • La firma del Código de Buenas Prácticas es voluntaria, pero puede ayudar a los proveedores a demostrar el cumplimiento de las obligaciones que la Ley de IA impone a los modelos GPAI.
  • El Código no es una norma armonizada, por lo que su firma no crea una presunción automática de cumplimiento.
  • La Comisión supervisará el cumplimiento del Código por parte de los signatarios. La exclusión voluntaria de cualquier capítulo (transparencia, derechos de autor o seguridad) significa que los proveedores no pueden confiar en el Código para demostrar el cumplimiento en ese ámbito.
  • Los firmantes pueden beneficiarse de una mayor confianza y de multas potencialmente más bajas.
  • Los no firmantes deben demostrar el cumplimiento de forma independiente, incluso mediante explicaciones detalladas o análisis de deficiencias, y deben esperar un mayor escrutinio por parte de la Oficina de IA, especialmente en lo que respecta a los cambios en el ciclo de vida y las modificaciones de los modelos.

Ejecución y supervisión

  • La Oficina de AI adoptará un modelo de aplicación colaborativo y basado en los riesgos. Se fomenta la cooperación informal durante las fases de formación.
  • Se espera que los proveedores de modelos GPAI de riesgo sistémico informen proactivamente y se comprometan con la Oficina de IA.
  • Aunque las obligaciones entran en vigor el 2 de agosto de 2025, la Oficina de AI no tiene plenos poderes de ejecución hasta el 2 de agosto de 2026, fecha en la que podrá solicitar información, ordenar la retirada de modelos, imponer medidas paliativas o imponer multas.
  • Para los modelos colocados antes del 2 de agosto de 2025, los proveedores tendrán hasta el 2 de agosto de 2027 para cumplir la normativa. No se exigirá reciclaje o "desaprendizaje" si es técnica o económicamente inviable, siempre que se justifique documentalmente.
  • Los modelos colocados después del 2 de agosto de 2025 deben tratar de cumplir la normativa en el momento de la colocación. Los proveedores deben colaborar activamente con la Oficina de IA. Los nuevos participantes, en particular los creadores de modelos de riesgo sistémico, recibirán apoyo para facilitar el cumplimiento.
  • Reconociendo el estado inmaduro de los ecosistemas de evaluación externa, la Oficina de AI puede intervenir para coordinar el desarrollo de normas coherentes.

Revisión de las directrices

  • La Comisión podrá actualizar o retirar estas directrices en función de:
    • Experiencia en la aplicación
    • Resultados de la aplicación
    • Evolución tecnológica y del mercado
    • Sentencias del Tribunal de Justicia de la UE (TJUE)
  • Se invitará a las partes interesadas (proveedores, reguladores, investigadores y sociedad civil) a contribuir a las actualizaciones mediante consultas y talleres.

Anexo: Cálculo de la formación - definiciones y métodos de estimación

Definición:

  • El cómputo de entrenamiento es el cómputo total utilizado para entrenar un modelo y evaluar si cumple los umbrales GPAI de riesgo sistémico:
    • Para los modelos de riesgo no sistémico: cálculo utilizado para la actualización de los parámetros.
    • Para la evaluación del riesgo sistémico: todos los cómputos acumulativos de formación.

Incluye:

  • Todos los cálculos que contribuyen a las capacidades del modelo, incluidos los pases hacia delante para la generación de datos sintéticos (incluso los datos descartados).
  • Cálculo para la fusión o inicialización de pesos utilizando modelos preentrenados.

Exclusiones:

  • Computa para:
    • Datos sintéticos disponibles públicamente
    • Tareas de diagnóstico/evaluación
    • Experimentos fallidos o sólo de investigación
    • Formación de modelos auxiliares (por ejemplo, modelos de recompensa)
    • Recálculo de la activación para ahorrar memoria

Métodos de estimación:

  • Abarca enfoques basados tanto en hardware como en arquitectura.
  • La estimación debe tener una precisión de ±30%, con documentación de los supuestos e incertidumbres.
Este post ha sido publicado el 30 Jul, 2025

Artículos relacionados

Visión general del Código de buenas prácticas

El Código de buenas prácticas ofrece un marco claro para ayudar a los desarrolladores de modelos de IA de propósito general (GPAI) a cumplir los requisitos de la Ley de IA de la UE. Aunque los proveedores pueden optar por seguir el Código, también son libres de demostrar su cumplimiento a través de otros métodos apropiados.....

¿Por qué unirse a la Comisión Científica de la UE sobre IA?

La Comisión Europea ha publicado una convocatoria de candidaturas para un panel científico de expertos independientes. El panel se centra en los modelos y sistemas de IA de propósito general (GPAI). Sus tareas incluyen asesorar a la Oficina de IA de la UE y a las autoridades nacionales sobre riesgos sistémicos,...