Última actualización: 20 de agosto de 2026
¿Qué es un modelo de IA de propósito general o GPAI?
Un modelo de inteligencia artificial de propósito general —GPAI, por sus siglas en inglés General-Purpose AI— es un modelo capaz de realizar de forma competente una amplia variedad de tareas y que puede integrarse posteriormente en numerosos sistemas o aplicaciones diferentes.
La idea es sencilla.
Una IA tradicional puede haber sido diseñada específicamente para:
detectar fraude bancario.
Un modelo de propósito general puede servir para:
- escribir;
- resumir;
- traducir;
- programar;
- analizar documentos;
- generar imágenes;
- responder preguntas;
- extraer información;
- razonar sobre distintos problemas;
- integrarse en chatbots;
- alimentar agentes de IA;
- formar parte de software empresarial.
Por eso el AI Act no los trata simplemente como:
“otro sistema de IA más”.
Los modelos GPAI ocupan una posición especial en la cadena de valor de la inteligencia artificial.
Un único modelo puede terminar detrás de miles de aplicaciones posteriores.
La Comisión explica precisamente que esta capacidad de integrarse en multitud de sistemas hace que sus proveedores tengan responsabilidades específicas frente a quienes construyen productos sobre ellos.
Respuesta rápida
| Pregunta | Respuesta |
|---|---|
| ¿Qué significa GPAI? | General-Purpose AI / IA de propósito general |
| ¿Es una categoría jurídica del AI Act? | Sí |
| ¿Es lo mismo GPAI que IA generativa? | No exactamente |
| ¿Es lo mismo GPAI que LLM? | No necesariamente |
| ¿ChatGPT es un modelo GPAI? | ChatGPT es un sistema/servicio; puede apoyarse en modelos GPAI |
| ¿GPT, Gemini, Claude o Mistral pueden ser modelos GPAI? | Sus modelos de propósito amplio son ejemplos típicos del fenómeno regulado |
| ¿Toda GPAI es de alto riesgo? | No |
| ¿Toda GPAI tiene riesgo sistémico? | No |
| ¿Cuándo se aplican las obligaciones GPAI? | Desde 2 agosto 2025 para nuevos modelos |
| ¿Cuándo puede multar la Comisión? | Desde 2 agosto 2026 |
| ¿Y modelos anteriores al 2 agosto 2025? | Deben adaptarse antes del 2 agosto 2027 |
| ¿Quién los supervisa? | Principalmente la AI Office / Comisión Europea |
| ¿Existe un Código de Buenas Prácticas? | Sí, voluntario |
| ¿Open source queda fuera? | Solo parcialmente y bajo determinadas condiciones |
| ¿Una empresa que usa ChatGPT pasa a ser proveedor GPAI? | Normalmente no |
1. GPAI no es lo mismo que ChatGPT
Ésta es probablemente la distinción más importante de toda la guía.
Tenemos que separar:
Modelo
La tecnología subyacente capaz de procesar información y generar resultados.
de:
Sistema de IA
La aplicación que utiliza uno o varios modelos para ofrecer una funcionalidad concreta.
Y de:
Producto o interfaz
La herramienta con la que interactúa el usuario.
Por ejemplo, de forma simplificada:
MODELO GPAI
↓
se integra en
SISTEMA DE IA
↓
que puede ofrecerse mediante
CHATBOT / APP / API / AGENTE
Por eso decir:
“ChatGPT es un GPAI”
puede ser útil coloquialmente, pero jurídicamente resulta impreciso.
Lo correcto es distinguir entre:
el modelo de propósito general
y:
el sistema o servicio construido sobre ese modelo.
2. Un mismo modelo puede acabar detrás de cientos de productos
Imaginemos un modelo llamado:
Modelo X.
La empresa que lo desarrolla permite utilizarlo mediante API.
Después:
Empresa A lo integra en atención al cliente.
Empresa B lo integra en Recursos Humanos.
Empresa C crea un asistente jurídico.
Empresa D crea un tutor educativo.
Empresa E crea un agente que gestiona pedidos.
El modelo de base puede ser exactamente el mismo.
Pero los sistemas finales pueden tener:
- riesgos distintos;
- usuarios distintos;
- finalidades distintas;
- obligaciones distintas.
Ésta es la razón por la que el AI Act crea una regulación específica para la capa del modelo y otra para la capa del sistema.
3. GPAI tampoco es exactamente lo mismo que “modelo fundacional”
Durante los primeros años de la regulación europea se utilizó mucho la expresión:
foundation model — modelo fundacional.
Sigue siendo frecuente en el sector tecnológico.
Pero el texto definitivo del AI Act utiliza como categoría jurídica:
general-purpose AI model
o:
modelo de IA de propósito general.
Por tanto, para una guía jurídica conviene utilizar:
GPAI
y dejar “modelo fundacional” como concepto técnico o histórico aproximado.
4. ¿GPAI significa inteligencia artificial generativa?
No necesariamente.
Existe un enorme solapamiento, porque muchos de los principales modelos GPAI actuales son capaces de generar:
- texto;
- audio;
- imágenes;
- vídeo.
Pero jurídicamente son conceptos diferentes.
IA generativa
Describe principalmente una capacidad:
generar nuevo contenido.
GPAI
Describe la generalidad del modelo y su capacidad para realizar múltiples tareas e integrarse en diferentes sistemas.
Una IA puede ser generativa pero estar especializada en una tarea extremadamente concreta.
Y un modelo de propósito general puede tener capacidades más amplias que la mera generación de contenido.
5. ¿Un LLM es siempre un GPAI?
Tampoco automáticamente.
LLM significa:
Large Language Model.
Describe una arquitectura o familia tecnológica centrada en lenguaje.
Un LLM suficientemente general puede ser un GPAI.
Pero la clasificación jurídica no depende simplemente de que alguien lo denomine:
“LLM”.
El AI Act mira sus capacidades y generalidad.
6. ¿Cómo sabemos si un modelo es realmente GPAI?
La definición legal se basa en ideas como:
- generalidad significativa;
- capacidad para realizar competentemente una amplia variedad de tareas;
- posibilidad de integrarse en multitud de aplicaciones y sistemas.
Para hacer esta definición más operativa, la Comisión publicó en 2025 unas Directrices específicas para proveedores de GPAI.
Como criterio indicativo, considera que un modelo probablemente entra en GPAI cuando:
- ha sido entrenado utilizando más de 10²³ FLOP;
- y puede generar lenguaje —texto o audio—, texto a imagen o texto a vídeo.
Pero 10²³ FLOP no es una frontera jurídica absoluta
Esto es muy importante.
La propia Comisión aclara que el criterio es indicativo.
Un modelo que supera ese volumen de computación podría excepcionalmente no ser GPAI si carece de suficiente generalidad.
Y un modelo por debajo podría ser GPAI si realmente muestra:
- una generalidad significativa;
- capacidad competente para muchas tareas diferentes.
Por tanto:
10²³ FLOP no funciona como un interruptor automático de “regulado / no regulado”.
Ayuda a interpretar la definición.
La definición jurídica sigue prevaleciendo.
7. No confundas 10²³ con 10²⁵ FLOP
Este error es bastante fácil de cometer.
Existen dos cifras muy diferentes.
10²³ FLOP
Es el criterio indicativo de las Directrices de la Comisión para ayudar a identificar un modelo GPAI.
10²⁵ FLOP
Es la presunción legal del AI Act para considerar que un modelo GPAI dispone de capacidades de alto impacto y puede quedar clasificado como:
GPAI con riesgo sistémico.
El artículo 51 establece expresamente esa presunción cuando la cantidad acumulada de computación utilizada para entrenar el modelo supera 10²⁵ FLOP.
Ésta es una diferencia fundamental.
Dos niveles regulatorios
Podemos visualizarlo así:
MODELO GPAI
↓
obligaciones generales del artículo 53
↓
¿presenta riesgo sistémico?
↓
SÍ
↓
obligaciones adicionales del artículo 55.
No todos los GPAI llegan al segundo nivel.
8. ¿Qué es un GPAI con riesgo sistémico?
El AI Act reserva esta categoría para los modelos de propósito general más avanzados o de mayor impacto potencial.
El Reglamento habla de:
capacidades de alto impacto.
Puede clasificarse como riesgo sistémico si:
- presenta capacidades de alto impacto evaluadas mediante herramientas, indicadores y benchmarks apropiados;
- o la Comisión determina que tiene capacidades o impacto equivalentes atendiendo a los criterios del Anexo XIII.
La computación superior a 10²⁵ FLOP crea una presunción de capacidades de alto impacto.
Pero la Comisión también puede actuar aunque un modelo no cruce mecánicamente esa cifra.
9. ¿Qué significa “riesgo sistémico”?
No significa simplemente:
“el modelo puede equivocarse”.
Estamos hablando de riesgos capaces de producir impactos de gran escala a nivel europeo o social.
La Comisión menciona ejemplos relacionados con:
- seguridad;
- derechos fundamentales;
- ciberseguridad;
- riesgos químicos o biológicos;
- uso indebido avanzado;
- autonomía;
- pérdida de control;
- propagación a gran escala.
La lógica es:
cuanto mayor es la capacidad de un modelo y más ampliamente puede desplegarse, mayor puede ser el impacto de un fallo o uso malicioso.
10. Superar 10²⁵ FLOP tampoco implica necesariamente una condena irreversible
Cuando un modelo alcanza la condición correspondiente, su proveedor debe notificarlo a la Comisión:
sin demora y, en cualquier caso, dentro de las dos semanas siguientes a que se cumpla el requisito o se sepa que se cumplirá.
El proveedor puede presentar argumentos suficientemente fundamentados para demostrar que, excepcionalmente, pese a alcanzar el umbral, el modelo no presenta riesgo sistémico por sus características particulares.
La Comisión decide si acepta esa argumentación.
11. La Comisión también puede designar un modelo por iniciativa propia
No todo depende de que el proveedor diga:
“hemos cruzado el umbral.”
La Comisión puede designar un modelo como GPAI con riesgo sistémico:
- de oficio;
- o después de una alerta cualificada del panel científico;
utilizando los criterios del Anexo XIII.
Por eso el régimen no pretende quedarse obsoleto si la tecnología mejora y:
un modelo consigue enormes capacidades utilizando menos computación.
12. ¿Quién es el “proveedor GPAI”?
Éste es el siguiente concepto esencial.
No basta con preguntar:
“¿quién utiliza el modelo?”
El proveedor GPAI es, en términos generales, quien:
- desarrolla;
- o hace desarrollar;
el modelo y lo pone en el mercado bajo:
- su nombre;
- o su marca.
Esto puede afectar a empresas establecidas fuera de la Unión cuando ponen sus modelos a disposición del mercado europeo.
13. “Poner en el mercado” no significa venderlo físicamente
Puede ocurrir mediante:
- API;
- descarga;
- servicio cloud;
- integración en aplicaciones;
- otras formas de disponibilidad.
La Comisión ha confirmado que esta interpretación puede incluir modelos ofrecidos dentro de sistemas o incluso determinados usos internos esenciales para prestar productos o servicios a terceros o afectar derechos de personas dentro de la UE.
Por tanto:
ofrecer una API en Europa puede ser suficiente para entrar en el ámbito del Reglamento.
14. ¿Si mi empresa utiliza ChatGPT soy proveedor GPAI?
Normalmente no.
Imaginemos una pyme que utiliza:
ChatGPT para redactar emails.
No ha desarrollado el modelo.
No lo pone en el mercado bajo su propia marca.
Es simplemente usuaria de un sistema.
Por tanto:
no se convierte por ello en proveedor del modelo GPAI.
Pero puede tener otras obligaciones.
Por ejemplo:
- gobernanza;
- protección de datos;
- artículo 4;
- transparencia;
- alto riesgo;
dependiendo de cómo utilice el sistema.
15. ¿Y si integro GPT o Claude en mi propia aplicación?
Tampoco significa automáticamente que seas proveedor GPAI.
Imaginemos:
OpenAI / Anthropic / otro proveedor
↓
modelo GPAI
↓
tu empresa lo integra
↓
crea un chatbot para clientes.
Tú puedes convertirte en:
proveedor del sistema de IA final
sin convertirte necesariamente en:
proveedor del modelo GPAI subyacente.
Esta distinción es crucial.
Ejemplo
Una empresa llamada:
ViajesBot SL
utiliza mediante API un modelo GPAI para crear:
asistente de viajes ViajesBot.
Las responsabilidades podrían separarse así:
Proveedor del modelo GPAI
Responsable de las obligaciones propias del modelo.
ViajesBot SL
Responsable del sistema final y del uso que ha diseñado.
Por ejemplo:
- transparencia ante usuarios;
- finalidad;
- protección de datos;
- controles del sistema.
16. ¿Y si modifico o hago fine-tuning de un GPAI?
Aquí la frontera se vuelve mucho más interesante.
La Comisión distingue entre:
modificaciones menores
y:
modificaciones suficientemente significativas.
Las Directrices aclaran expresamente que no todo fine-tuning convierte automáticamente al modificador en proveedor GPAI.
Solo determinadas modificaciones importantes pueden trasladarle las obligaciones correspondientes.
Esto es especialmente relevante para:
- startups;
- laboratorios;
- proveedores verticales;
- empresas que ajustan modelos open source.
Ejemplo sencillo
Descargas un modelo abierto.
Lo ajustas con:
5.000 documentos jurídicos
para mejorar determinados resultados internos.
No significa automáticamente que hayas creado un nuevo GPAI regulatoriamente equivalente al modelo original.
Pero si realizas una modificación mucho más profunda y relevante, la posición jurídica puede cambiar.
17. ¿Qué obligaciones tiene un proveedor GPAI?
El artículo 53 es el núcleo de las obligaciones generales.
En términos prácticos, existen cuatro grandes bloques:
| Obligación | Objetivo |
|---|---|
| Documentación técnica | Permitir supervisión del modelo |
| Información a proveedores downstream | Permitir que quienes integran el modelo puedan cumplir |
| Política de copyright | Cumplir Derecho europeo de propiedad intelectual |
| Resumen público del entrenamiento | Aumentar transparencia sobre el contenido utilizado |
La Comisión ha publicado además:
- Directrices;
- plantilla de resumen;
- Código de Buenas Prácticas
para ayudar a cumplir estas obligaciones.
18. Primera obligación: documentación técnica
El proveedor debe elaborar y mantener actualizada documentación técnica sobre el modelo.
Puede incluir información sobre:
- arquitectura;
- entrenamiento;
- pruebas;
- validación;
- recursos computacionales;
- consumo energético;
- características relevantes.
La documentación debe poder ponerse a disposición de la AI Office cuando corresponda.
Esto crea una diferencia fundamental entre:
“hemos entrenado un modelo”
y:
“podemos demostrar qué hemos entrenado, cómo y con qué características”.
19. Segunda obligación: informar a quienes integran el modelo
Ésta es quizá la obligación más importante desde la perspectiva de toda la industria.
El proveedor GPAI debe proporcionar documentación suficiente a:
los proveedores de sistemas de IA que quieran integrar ese modelo.
¿Por qué?
Porque la empresa downstream necesita entender:
- capacidades;
- limitaciones;
- funcionamiento relevante;
- requisitos técnicos;
- características de entrada y salida;
para poder cumplir sus propias obligaciones.
El AI Act intenta evitar un problema de caja negra en la cadena de suministro
Imaginemos:
Proveedor GPAI
↓
no explica nada
↓
Startup
↓
crea aplicación médica
↓
no sabe cuáles son las limitaciones reales del modelo.
Sería muy difícil exigir a la startup:
“evalúa correctamente tu sistema”
si el proveedor del modelo le oculta toda la información necesaria.
Por eso el Reglamento crea obligaciones aguas arriba.
20. Esta obligación es muy relevante para empresas que compran IA
Aunque tu empresa no sea proveedor GPAI, debería preguntar al proveedor:
¿Qué documentación proporciona sobre el modelo?
¿Cuáles son sus limitaciones?
¿Qué actualizaciones puede realizar?
¿Cómo cambia el comportamiento entre versiones?
¿Qué garantías ofrece?
El AI Act está convirtiendo progresivamente la relación:
“compramos una API”
en:
“gestionamos una dependencia tecnológica regulada”.
21. Tercera obligación: política de copyright
Éste es uno de los aspectos más controvertidos del régimen GPAI.
Los proveedores deben establecer una política destinada a cumplir la normativa europea sobre propiedad intelectual.
Esto incluye específicamente respetar las reservas de derechos relacionadas con la excepción de:
text and data mining — TDM
prevista por la legislación europea.
La Comisión explica que los modelos GPAI suelen entrenarse con enormes cantidades de contenido potencialmente protegido y que por eso el AI Act incorpora obligaciones específicas sobre copyright.
¿Significa que el AI Act decide si todo entrenamiento es legal?
No.
El AI Act no resuelve por sí solo todo el debate europeo sobre copyright y entrenamiento de IA.
Lo que hace el artículo 53 es imponer una obligación de:
tener una política para cumplir el Derecho europeo de propiedad intelectual.
Las cuestiones concretas sobre:
- licencias;
- excepciones;
- reservas de derechos;
- responsabilidad;
siguen dependiendo también de la legislación de copyright.
22. Cuarta obligación: publicar un resumen del contenido de entrenamiento
Los proveedores deben publicar un:
resumen suficientemente detallado del contenido utilizado para entrenar el modelo.
No significa:
publicar cada documento del dataset.
La Comisión ha creado una plantilla específica para armonizar estos resúmenes.
La finalidad es permitir mayor transparencia sobre:
- fuentes;
- tipos de contenido;
- procedencia general de los datos.
No equivale a publicar el dataset completo
Esto también conviene aclararlo.
La obligación busca transparencia sin exigir necesariamente revelar:
- todos los archivos;
- secretos empresariales;
- cada URL individual;
- información confidencial.
De nuevo aparece un equilibrio entre:
transparencia
y:
protección de activos empresariales.
23. ¿Qué ocurre con modelos open source?
Ésta es una de las partes que más confusión genera.
La respuesta correcta no es:
“El open source está exento del AI Act.”
Eso es falso.
El AI Act contempla exenciones parciales para determinados modelos GPAI publicados bajo licencias libres y de código abierto cuando se cumplen las condiciones correspondientes.
En particular, pueden quedar exentos de determinadas obligaciones de documentación e información downstream.
Pero siguen existiendo obligaciones relacionadas con:
- política de copyright;
- resumen público de entrenamiento.
Y si el modelo open source tiene riesgo sistémico, la excepción se reduce todavía más
El Reglamento es especialmente claro en este punto.
Los modelos GPAI de riesgo sistémico siguen sometidos a las obligaciones adicionales aunque sean open source.
Por tanto:
open source ≠ fuera del AI Act.
24. ¿Qué condiciones tiene que cumplir un modelo open source?
No basta con colocar en GitHub:
“Open source”.
La regulación tiene en cuenta cuestiones como la disponibilidad de:
- pesos;
- arquitectura;
- información sobre uso;
- modificación;
- distribución;
bajo una licencia libre y abierta adecuada.
Por eso la etiqueta comercial del proveedor no determina por sí sola el régimen jurídico.
25. Proveedores de fuera de la UE
El AI Act también alcanza a proveedores no establecidos en Europa cuando introducen sus modelos GPAI en el mercado europeo.
En determinados casos deben designar un:
representante autorizado en la Unión Europea.
La Comisión incluye expresamente esta obligación dentro de sus orientaciones GPAI.
Es la misma lógica que aparece en otras grandes regulaciones europeas:
si quieres participar en el mercado europeo, necesitas una estructura capaz de responder ante el supervisor europeo.
26. ¿Qué obligaciones adicionales tiene un GPAI con riesgo sistémico?
Aquí entra el artículo 55.
Además de cumplir las obligaciones generales, el proveedor debe desarrollar un programa mucho más exigente de:
evaluación del modelo;
pruebas adversariales;
identificación y mitigación de riesgos sistémicos;
seguimiento y comunicación de incidentes graves;
ciberseguridad.
El artículo 55 establece expresamente esas cuatro grandes obligaciones.
27. Evaluación y red teaming
El proveedor debe realizar evaluaciones utilizando protocolos y herramientas adecuados al estado de la técnica.
Eso incluye:
adversarial testing / red teaming
para intentar descubrir:
- vulnerabilidades;
- comportamientos peligrosos;
- formas de eludir protecciones;
- capacidades de riesgo.
La lógica es sencilla:
no esperar a que alguien descubra el problema después de desplegar el modelo.
28. Riesgo sistémico durante todo el ciclo de vida
La obligación tampoco termina el día en que el modelo sale al mercado.
El artículo 55 exige identificar y mitigar riesgos sistémicos derivados:
- del desarrollo;
- de la comercialización;
- del uso del modelo.
Esto implica una lógica continua.
No:
“evaluamos una vez y archivamos el informe.”
Sino:
evaluar → desplegar → monitorizar → aprender → mitigar.
29. Comunicación de incidentes graves
Los proveedores de GPAI con riesgo sistémico deben:
- registrar;
- documentar;
- comunicar
información relevante sobre incidentes graves y posibles medidas correctoras.
La comunicación se realiza a:
- AI Office;
- y, cuando corresponda, autoridades nacionales.
La Comisión dispone además de mecanismos específicos para enviar esta documentación a través de EU SEND.
30. Ciberseguridad del modelo y de su infraestructura
El artículo 55 exige también un nivel adecuado de protección de:
MODELO
INFRAESTRUCTURA FÍSICA.
Esto es especialmente importante porque los modelos más potentes pueden convertirse en objetivos de:
- robo de pesos;
- ataques;
- manipulación;
- exfiltración;
- sabotaje.
La seguridad no se limita, por tanto, a:
proteger una web con contraseña.
31. ¿Qué es el Código de Buenas Prácticas GPAI?
La Comisión publicó el General-Purpose AI Code of Practice el 10 de julio de 2025.
Es un instrumento:
voluntario
diseñado para ayudar a los proveedores a demostrar cumplimiento de sus obligaciones del AI Act.
No sustituye al Reglamento.
Ayuda a aterrizarlo en medidas prácticas.
32. El Código tiene tres capítulos
Transparencia
Ayuda a documentar la información requerida sobre los modelos.
Copyright
Desarrolla medidas prácticas para la política de cumplimiento de propiedad intelectual.
Safety & Security
Dirigido específicamente a los proveedores de modelos con riesgo sistémico.
Los capítulos de Transparencia y Copyright se relacionan principalmente con el artículo 53.
El de Safety & Security con el artículo 55.
33. ¿Es obligatorio firmar el Código?
No.
Un proveedor puede:
adherirse al Código
o:
demostrar el cumplimiento mediante otros medios adecuados.
Pero la Comisión considera que adherirse puede:
- reducir carga administrativa;
- proporcionar mayor seguridad jurídica;
- facilitar la demostración de cumplimiento.
Por tanto:
no firmarlo no significa incumplir el AI Act.
Significa que tendrás que demostrar el cumplimiento por otra vía.
34. ¿Quién ha firmado el Código GPAI?
A 31 de julio de 2026, la Comisión enumera entre los signatarios a empresas como:
- Amazon;
- Anthropic;
- Google;
- IBM;
- Microsoft;
- Mistral AI;
- OpenAI;
- Cohere;
- ServiceNow;
- WRITER;
entre otras.
La lista se actualiza.
Un caso particular es xAI, que figura adherida al capítulo de Safety & Security, pero debe demostrar mediante otros medios adecuados el cumplimiento de las obligaciones de transparencia y copyright.
Firmar el Código tampoco equivale a “certificado legal”
Esto merece destacarse.
El hecho de que una empresa sea signataria no significa:
“la Unión Europea certifica que todo lo que hace cumple perfectamente el AI Act”.
Significa que utiliza un mecanismo reconocido para demostrar cumplimiento de determinadas obligaciones.
El enforcement sigue existiendo.
35. El calendario GPAI es distinto del calendario de alto riesgo
Esto está generando bastante confusión tras el AI Omnibus.
Las obligaciones GPAI no se han trasladado a 2027 junto con el Anexo III.
El calendario es:
| Fecha | GPAI |
|---|---|
| 2 agosto 2025 | Aplicación de obligaciones para nuevos proveedores/modelos GPAI |
| 2 agosto 2026 | Comisión empieza a ejercer poderes de enforcement, incluidas multas |
| 2 agosto 2027 | Fecha límite para adaptar modelos GPAI puestos en mercado antes del 2/8/2025 |
La propia Comisión confirma expresamente este calendario.
Por tanto, a agosto de 2026 el régimen GPAI ya está vivo
Éste es un titular importante.
Mientras parte de las obligaciones de alto riesgo se han desplazado a:
2027 y 2028,
las obligaciones para proveedores GPAI:
ya se están aplicando.
Y desde el 2 de agosto de 2026 el enforcement de la Comisión ya está operativo.
36. ¿Quién supervisa los GPAI?
Principalmente:
European AI Office
dentro de la Comisión Europea.
Éste es uno de los grandes ámbitos donde el enforcement se concentra a escala europea en lugar de depender exclusivamente de cada autoridad nacional.
La Comisión puede:
- pedir información;
- solicitar documentación;
- evaluar modelos;
- requerir medidas;
- investigar incumplimientos.
El AI Act dedica los artículos 88 a 94 específicamente a supervisión, investigación y enforcement sobre proveedores GPAI.
AESIA y la AI Office no hacen lo mismo
Por ejemplo:
OpenAI desarrolla un modelo GPAI
La supervisión de sus obligaciones como proveedor del modelo corresponde fundamentalmente a:
AI Office.
Una empresa española utiliza ese modelo para crear un chatbot
El sistema final puede quedar además sometido a:
AESIA u otra autoridad española
según finalidad y obligación.
Consulta nuestra guía:
AESIA: qué controla y cuándo acudir a ella
37. El Digital Omnibus ha reforzado el papel europeo
El AI Omnibus de 2026 modificó también determinadas reglas de supervisión para reducir fragmentación cuando un mismo proveedor desarrolla tanto:
- el modelo GPAI;
- como el sistema construido sobre él.
Esto refuerza la posición central de la AI Office en determinados supuestos relacionados con sistemas basados en GPAI.
Pero no significa que:
“todo sistema que usa GPT pasa automáticamente a ser supervisado por Bruselas”.
La distribución depende de:
- proveedor;
- sistema;
- finalidad;
- papel de cada operador.
38. ¿Cómo puede actuar la AI Office?
Entre sus herramientas se encuentran:
solicitudes de información;
acceso a documentación;
evaluaciones;
requerimientos de medidas correctoras;
enforcement;
multas.
Desde agosto de 2026 la Comisión ha activado además mecanismos específicos de:
- reclamaciones;
- whistleblowing;
- reclamaciones de proveedores downstream respecto de GPAI.
Esto último resulta especialmente interesante.
39. Los desarrolladores downstream también pueden reclamar
Imaginemos una startup que integra un modelo GPAI.
Necesita determinada documentación para cumplir el AI Act.
El proveedor del modelo:
no se la facilita.
La Comisión dispone actualmente de un canal específico para que proveedores downstream puedan comunicar posibles problemas relacionados con las obligaciones de los artículos 53 a 55.
Eso demuestra hasta qué punto Europa considera importante la transparencia de la cadena de suministro.
40. ¿Cuáles son las multas para proveedores GPAI?
El artículo 101 permite a la Comisión imponer multas de hasta:
15 millones de euros
o:
3 % del volumen de negocios mundial anual
del ejercicio anterior, aplicando el importe superior, cuando el proveedor incurre de forma deliberada o negligente en determinados incumplimientos.
Puede incluir:
- incumplir disposiciones aplicables;
- no entregar información requerida;
- entregar información incorrecta o engañosa;
- no adoptar una medida requerida;
- impedir determinadas evaluaciones del modelo.
No confundamos estas multas con los 35 millones / 7 %
Los:
35 millones o 7 %
corresponden a otro nivel sancionador del AI Act, especialmente relacionado con prácticas prohibidas.
Las multas específicas del artículo 101 para proveedores GPAI tienen su propio régimen:
15 M€ / 3 %.
41. ¿Una GPAI puede ser al mismo tiempo “alto riesgo”?
Aquí hay que hilar fino.
Un:
modelo GPAI
no se convierte automáticamente en:
sistema de alto riesgo.
Son dos capas regulatorias diferentes.
Por ejemplo:
modelo GPAI
↓
se utiliza para crear
chatbot turístico
Probablemente no es alto riesgo por esa finalidad.
Pero el mismo modelo:
↓
se integra en
sistema para seleccionar trabajadores
puede formar parte de un sistema clasificado como alto riesgo cuando resulte aplicable el régimen correspondiente.
Por tanto:
el riesgo de la aplicación downstream depende de su finalidad.
42. GPAI con riesgo sistémico y sistema de alto riesgo tampoco son sinónimos
Otro concepto que suele confundirse.
GPAI con riesgo sistémico
Se refiere al modelo y a riesgos potenciales de gran escala.
Sistema de alto riesgo
Se refiere a determinadas aplicaciones o finalidades concretas reguladas por el AI Act.
Puede existir:
GPAI sin riesgo sistémico
integrado en:
sistema de alto riesgo.
Y:
GPAI con riesgo sistémico
utilizado en:
aplicación cotidiana que no es alto riesgo.
Son ejes diferentes.
Ejemplo
Un modelo extremadamente potente podría utilizarse para:
resumir recetas.
El modelo puede tener obligaciones sistémicas por sus capacidades globales.
Pero la aplicación:
“resumidor de recetas”
no se convierte por ello en un sistema de alto riesgo.
Al contrario:
un modelo relativamente modesto podría utilizarse para:
seleccionar candidatos a empleo.
El sistema final puede ser de alto riesgo por su finalidad, aunque el modelo base no sea GPAI sistémico.
43. ¿Qué pasa con los agentes de IA?
Los agentes son un ejemplo perfecto de cómo interactúan estas capas.
Un agente puede utilizar:
uno o varios modelos GPAI
para:
- razonar;
- planificar;
- llamar herramientas;
- acceder a sistemas;
- ejecutar acciones.
Pero:
“agente de IA” no es una categoría jurídica independiente dentro del AI Act.
Debemos analizar:
- el modelo;
- el sistema;
- la finalidad;
- las acciones que puede ejecutar;
- el contexto.
Consulta:
Agentes de IA: riesgos y obligaciones del AI Act
44. Una empresa que compra GPAI debería pensar en la cadena de suministro
Hasta ahora muchas compañías compraban servicios de IA mirando principalmente:
- precio;
- calidad;
- velocidad.
El AI Act añade preguntas nuevas.
Por ejemplo:
¿Quién es el proveedor real del modelo?
¿Qué versión utilizamos?
¿Puede cambiar sin avisarnos?
¿Qué documentación recibimos?
¿Qué limitaciones declara?
¿Cómo informa de incidentes?
¿Qué garantías de seguridad ofrece?
¿Qué ocurre si deja de prestar el modelo?
¿Qué pasa si nuestro sistema es alto riesgo?
Esto convierte la selección de proveedor de IA en una cuestión de:
compliance + compras + tecnología.
45. “Powered by GPT” no debería ser toda la documentación de un sistema
Una empresa debería ser capaz de distinguir:
PROVEEDOR DEL MODELO
↓
MODELO / VERSIÓN
↓
PROVEEDOR DEL SISTEMA
↓
CONFIGURACIÓN
↓
FINALIDAD
↓
DATOS
↓
USUARIOS
↓
DECISIONES / ACCIONES
Este mapa es especialmente importante para:
- agentes;
- RAG;
- chatbots;
- automatizaciones;
- aplicaciones empresariales.
46. RAG no elimina las obligaciones del modelo
RAG —Retrieval-Augmented Generation— permite conectar un modelo a:
- documentos internos;
- bases de conocimiento;
- archivos.
Por ejemplo:
GPAI
base documental de empresa
=
asistente interno.
La empresa no deja de depender del GPAI por añadir su propia información.
Además aparecen nuevos riesgos:
- protección de datos;
- permisos;
- confidencialidad;
- información incorrecta;
- prompt injection.
47. Fine-tuning tampoco convierte automáticamente el modelo en “tuyo”
Ajustar un modelo:
no significa automáticamente asumir todas las obligaciones de su proveedor original.
Hay que analizar el grado de modificación.
La Comisión ha desarrollado precisamente criterios para distinguir modificaciones menores de aquellas suficientemente significativas como para cambiar la posición regulatoria del modificador.
48. ¿Qué debería hacer una startup que desarrolla su propio modelo?
El primer análisis sería:
1. ¿Es un modelo GPAI?
Generalidad, tareas y criterios de las Directrices.
2. ¿Somos proveedor?
¿Lo ponemos en el mercado bajo nuestra marca?
3. ¿Cuándo lo ponemos en mercado?
Esto determina calendario.
4. ¿Es open source?
Y, si lo es, ¿cumple realmente las condiciones de la excepción?
5. ¿Existe riesgo sistémico?
Capacidades + compute + criterios del Anexo XIII.
6. ¿Qué obligaciones del artículo 53 aplican?
Documentación, downstream, copyright, training summary.
7. ¿Artículo 55?
Si existe riesgo sistémico.
8. ¿Representante europeo?
Si la empresa está fuera de la UE.
9. ¿Código de Buenas Prácticas?
Decidir adhesión o medios alternativos.
49. ¿Qué debería hacer una empresa que solamente utiliza GPAI?
El análisis es diferente.
No necesita implementar todo el artículo 53.
Debería centrarse en:
inventariar el uso;
conocer al proveedor;
identificar modelo y sistema;
documentar finalidad;
evaluar riesgos;
revisar datos personales;
revisar condiciones contractuales;
determinar si el sistema final entra en alto riesgo;
controlar cambios de versión;
formar a usuarios;
establecer supervisión.
No confundas:
obligaciones del fabricante del modelo
con:
obligaciones de la empresa que lo utiliza.
50. El proveedor GPAI no asume la responsabilidad de tu uso
Esto quizá sea lo más importante para las pymes.
Imaginemos:
Microsoft / OpenAI / Google proporciona un modelo completamente conforme con sus obligaciones GPAI.
Después tu empresa lo utiliza para:
inferir emociones de trabajadores.
El hecho de que el modelo upstream cumpla:
no hace legal tu sistema downstream.
De la misma forma:
comprar un coche homologado no autoriza a conducirlo de cualquier manera.
51. Checklist para integrar un modelo GPAI en una empresa
Antes de incorporar un modelo de propósito general, conviene poder responder:
- ¿Qué modelo utilizamos?
- ¿Quién lo proporciona?
- ¿Qué versión?
- ¿Mediante API, SaaS o local?
- ¿Qué datos enviamos?
- ¿Dónde se procesan?
- ¿Se utilizan para entrenamiento?
- ¿Qué documentación del proveedor tenemos?
- ¿Qué limitaciones declara?
- ¿Qué finalidad tiene nuestro sistema?
- ¿Interviene en decisiones sobre personas?
- ¿Puede ser alto riesgo?
- ¿Interactúa con usuarios?
- ¿Genera contenido?
- ¿Necesita transparencia del artículo 50?
- ¿Qué supervisión humana existe?
- ¿Qué ocurre si el modelo cambia?
- ¿Qué alternativa tenemos si el proveedor deja de estar disponible?
52. Un riesgo poco comentado: el cambio silencioso de modelo
En software tradicional:
versión 3.1
puede mantenerse durante años.
En IA cloud, un proveedor puede introducir:
- nuevo modelo;
- nuevos filtros;
- nuevas capacidades;
- cambios en respuestas.
Esto puede alterar:
- comportamiento;
- riesgos;
- rendimiento;
- controles.
Por eso una empresa no debería documentar simplemente:
“Usamos IA de OpenAI.”
Sería mejor registrar:
proveedor + modelo + versión/familia + finalidad + fecha de revisión.
53. Otro riesgo: dependencia del proveedor
Un sistema empresarial construido sobre un GPAI externo depende de:
- disponibilidad de API;
- precios;
- límites;
- comportamiento;
- condiciones;
- jurisdicción;
- documentación.
En funciones críticas conviene plantear:
¿qué pasa si mañana ese modelo deja de estar disponible?
El AI Act no convierte esto automáticamente en obligación para todas las empresas.
Pero sí es una cuestión de buena gobernanza.
54. GPAI y protección de datos son capas distintas
Que un proveedor cumpla el artículo 53 del AI Act no significa automáticamente:
“cumple RGPD para cualquier tratamiento que hagamos.”
Cuando una empresa envía:
- datos de clientes;
- expedientes;
- emails;
- fotografías;
- conversaciones;
también debe analizar:
- responsable;
- encargado;
- base jurídica;
- transferencias;
- minimización;
- seguridad.
AI Act y RGPD pueden aplicarse simultáneamente.
55. GPAI y artículo 50 también son diferentes
El artículo 53 regula principalmente:
al proveedor del modelo GPAI.
El artículo 50 regula determinados:
sistemas y contenidos de IA frente a personas.
Por ejemplo:
modelo GPAI conforme al artículo 53
↓
empresa crea chatbot
↓
el chatbot puede tener que informar al usuario conforme al artículo 50.
Consulta:
/articulo-50-ai-act/
56. GPAI y copyright tampoco termina en el entrenamiento
El artículo 53 presta especial atención al contenido utilizado para entrenar el modelo.
Pero una empresa downstream también debe pensar en:
outputs.
Por ejemplo:
- textos;
- imágenes;
- código;
- música.
El hecho de utilizar un proveedor GPAI regulado no garantiza que cualquier salida pueda utilizarse libremente en cualquier contexto.
57. ¿Qué está regulando realmente Europa con GPAI?
No intenta regular simplemente:
“ChatGPT porque es popular.”
El objetivo es regular un fenómeno estructural.
Un pequeño número de modelos puede convertirse en infraestructura para:
miles de sistemas posteriores.
Si esos proveedores no proporcionan:
- información;
- transparencia;
- gestión de riesgos;
toda la cadena downstream tendría enormes dificultades para cumplir.
Por eso el Capítulo V del AI Act coloca obligaciones específicas en la raíz de la cadena.
Preguntas frecuentes sobre GPAI
¿Qué significa GPAI?
General-Purpose Artificial Intelligence, traducido normalmente como inteligencia artificial de propósito general o uso general.
¿Qué es un modelo GPAI?
Un modelo con generalidad significativa capaz de realizar de manera competente una amplia variedad de tareas y de integrarse en múltiples sistemas o aplicaciones.
¿ChatGPT es GPAI?
Jurídicamente conviene diferenciar.
ChatGPT es un sistema o servicio que utiliza modelos de IA que pueden pertenecer a la categoría GPAI.
¿GPT es GPAI?
Las familias de modelos de propósito amplio desarrolladas por grandes proveedores constituyen los ejemplos típicos que motivaron este régimen, aunque la clasificación debe realizarse sobre el modelo concreto y conforme a la definición legal y las Directrices.
¿Claude, Gemini o Mistral son GPAI?
Los grandes modelos generalistas de estas familias presentan las características típicas de los modelos de propósito general. La clasificación jurídica corresponde siempre al modelo concreto.
¿Toda IA generativa es GPAI?
No.
Una IA generativa especializada puede no tener suficiente generalidad.
¿Todo GPAI es alto riesgo?
No.
GPAI y alto riesgo son clasificaciones distintas.
¿Todo GPAI es riesgo sistémico?
No.
Solo una categoría reducida de modelos con capacidades de alto impacto o equivalentes entra en ese nivel.
¿Cuál es el umbral de riesgo sistémico?
Existe una presunción cuando el entrenamiento supera 10²⁵ FLOP, aunque la clasificación también puede producirse por otros criterios.
¿Qué significa 10²³ FLOP?
Las Directrices de la Comisión lo utilizan como criterio indicativo para ayudar a identificar modelos GPAI cuando además tienen determinadas capacidades generativas. No es una frontera legal absoluta.
¿Cuándo empezaron las obligaciones GPAI?
El 2 de agosto de 2025 para los modelos sujetos al nuevo régimen a partir de esa fecha.
¿Cuándo empiezan las multas?
Los poderes de enforcement de la Comisión se aplican desde el 2 de agosto de 2026.
¿Y modelos anteriores?
Los proveedores de modelos puestos en el mercado antes del 2 de agosto de 2025 tienen hasta el 2 de agosto de 2027 para adaptarse.
¿El AI Omnibus retrasó GPAI hasta 2027?
No.
El aplazamiento principal afectó al régimen de sistemas de alto riesgo.
El calendario GPAI siguió su curso propio.
¿Quién vigila los GPAI?
Principalmente la AI Office / Comisión Europea.
¿AESIA supervisa GPT o Gemini?
No es la forma correcta de plantearlo.
Las obligaciones del proveedor del modelo GPAI corresponden principalmente a la AI Office.
AESIA puede intervenir en determinados sistemas o usos desplegados bajo el marco español.
¿Qué debe publicar el proveedor sobre el entrenamiento?
Un resumen suficientemente detallado del contenido utilizado, utilizando el marco y plantilla desarrollados por la Comisión.
No significa publicar íntegramente el dataset.
¿Tiene que respetar copyright?
Sí.
El artículo 53 exige una política destinada a cumplir el Derecho europeo de propiedad intelectual, incluyendo las reservas de derechos relevantes para text and data mining.
¿Open source está exento?
Solo parcialmente y bajo determinadas condiciones.
Además, los modelos de riesgo sistémico siguen teniendo obligaciones reforzadas aunque sean abiertos.
¿Tengo obligaciones GPAI si simplemente uso ChatGPT?
Normalmente no como proveedor del modelo.
Sí puedes tener otras obligaciones como empresa usuaria o proveedor del sistema final.
¿Si uso una API soy proveedor GPAI?
No automáticamente.
Puedes ser proveedor del sistema construido sobre esa API sin ser proveedor del modelo base.
¿Si hago fine-tuning soy proveedor GPAI?
No necesariamente.
Depende de la importancia de la modificación; las Directrices distinguen modificaciones menores y significativas.
¿El Código GPAI es obligatorio?
No.
Es voluntario.
Los proveedores pueden utilizar otros medios adecuados para demostrar cumplimiento.
¿Qué empresas lo han firmado?
La lista oficial incluye actualmente, entre otras, OpenAI, Anthropic, Google, Microsoft, Mistral AI, Amazon e IBM.
¿Firmar significa que la Comisión certifica que cumplen?
No.
Es una vía reconocida para demostrar cumplimiento, no una inmunidad regulatoria.
¿Qué multa puede recibir un proveedor GPAI?
Hasta 15 millones de euros o el 3 % de su volumen de negocio mundial anual, tomando el importe superior, bajo las condiciones del artículo 101.
Si solo recuerdas diez ideas
1. GPAI es una categoría jurídica del AI Act.
2. Modelo GPAI y sistema de IA no son lo mismo.
3. ChatGPT es una aplicación/sistema; debemos distinguirlo de los modelos que utiliza.
4. La Comisión utiliza 10²³ FLOP como criterio indicativo para ayudar a identificar GPAI, pero no es una frontera absoluta.
5. 10²⁵ FLOP crea una presunción legal de capacidades de alto impacto y posible riesgo sistémico.
6. Todo proveedor GPAI tiene obligaciones de documentación, información downstream, copyright y transparencia sobre entrenamiento.
7. Los GPAI con riesgo sistémico tienen además evaluación, red teaming, gestión de riesgos, incidentes y ciberseguridad.
8. Open source no significa estar fuera del AI Act.
9. Una empresa que integra ChatGPT o Gemini normalmente no se convierte por ello en proveedor del modelo GPAI.
10. El régimen GPAI ya es exigible y el enforcement de la Comisión está activo desde el 2 de agosto de 2026.
Conclusión: el GPAI es la infraestructura sobre la que se construye buena parte de la nueva IA
Para comprender la regulación europea de inteligencia artificial hay que abandonar una idea demasiado simple:
una empresa desarrolla una IA y esa IA llega directamente al usuario.
En gran parte de la economía actual el esquema es más parecido a:
PROVEEDOR GPAI
↓
MODELO DE PROPÓSITO GENERAL
↓
PROVEEDOR DOWNSTREAM
↓
SISTEMA ESPECIALIZADO
↓
EMPRESA
↓
USUARIO
Un único modelo puede terminar detrás de:
- aplicaciones;
- chatbots;
- herramientas empresariales;
- sistemas educativos;
- Recursos Humanos;
- agentes autónomos.
Eso explica por qué el AI Act ha colocado obligaciones directamente sobre el proveedor del modelo.
Sin documentación suficiente sobre:
- capacidades;
- limitaciones;
- entrenamiento;
sería extremadamente difícil que quienes construyen sistemas encima pudieran cumplir correctamente sus propias obligaciones.
Por eso el artículo 53 obliga a los proveedores GPAI a crear transparencia hacia arriba, hacia abajo y hacia el público.
Y cuando el modelo alcanza un nivel de capacidad capaz de producir riesgos sistémicos, el artículo 55 añade otra capa:
evaluaciones
red teaming
gestión de riesgos
incidentes
ciberseguridad.
La regulación tampoco depende únicamente del tamaño.
El umbral de 10²⁵ FLOP sirve como presunción, pero la Comisión puede designar otros modelos cuando sus capacidades o impactos lo justifiquen.
Y para las empresas usuarias, quizá la conclusión más importante sea otra:
que tu proveedor cumpla las obligaciones GPAI no significa que tu uso cumpla automáticamente el AI Act.
Puedes utilizar un modelo perfectamente conforme y construir sobre él:
un sistema prohibido;
un sistema de alto riesgo;
un chatbot sin transparencia;
una herramienta que trate datos ilegalmente.
El modelo es una capa.
Tu sistema es otra.
Y precisamente por eso el AI Act regula toda la cadena de valor de la inteligencia artificial.
A fecha de agosto de 2026, este régimen ya no es una preparación para el futuro.
Las obligaciones GPAI se aplican desde agosto de 2025 y la Comisión tiene ya desde el 2 de agosto de 2026 sus poderes de enforcement activos, incluidas multas.
El GPAI ha pasado de ser:
“la nueva tecnología que Europa quiere regular”
a:
una categoría regulatoria plenamente operativa.