Provider o deployer del AI Act: cómo saber qué eres y qué obligaciones tienes

Antes de leer una sola obligación del AI Act tienes que responder una pregunta: ¿eres provider o deployer? De esa respuesta depende todo lo demás. Una PYME que confunde su rol puede acabar cumpliendo obligaciones que no le tocan o, peor, saltándose las que sí.

El Reglamento (UE) 2024/1689 construye sus obligaciones en torno a esa distinción. Provider y deployer son los dos roles principales en la cadena de valor de la IA, y cada uno tiene un capítulo entero del Reglamento dedicado a sus deberes. Cambian las obligaciones, los plazos, la documentación que tienes que tener y, sobre todo, la multa máxima si las incumples.

Esta guía explica qué es cada uno, cómo saber con certeza cuál eres tú, los casos grises del Artículo 25 que pueden convertir a un deployer en provider sin querer, y la tabla con todas las obligaciones operativas comparadas.

Por qué esta distinción es la base de todo

El primer error de muchas PYMEs es pensar que el AI Act solo afecta a las empresas que desarrollan IA. La realidad es la opuesta: el Reglamento se centra mucho más en quien la usa, porque es ahí donde se materializa el daño potencial a personas concretas.

El AI Act define cuatro figuras en la cadena de valor —provider, deployer, importer, distributor— pero para una PYME española la inmensa mayoría del peso recae en dos: provider y deployer. Importador y distribuidor son relevantes para quien revende sistemas de IA de fuera de la UE; el resto de empresas pueden olvidarse de esos dos roles.

Saber cuál eres responde, directamente:

• Qué obligaciones operativas te aplican (Cap. III, Sec. 2 si eres provider de alto riesgo; Art. 26 si eres deployer de alto riesgo).
• Qué documentación tienes que tener.
• A qué multa te expones (la del provider llega más alto que la del deployer en algunos supuestos).
• Qué pides a tus proveedores y qué te pueden pedir tus clientes.
• Si tienes que registrar el sistema en la base de datos UE o no.

Por eso es la primera pregunta que cualquier empresa debe contestar antes de hacer absolutamente nada más sobre cumplimiento.

Qué es un provider según el AI Act

El Artículo 3.3 del Reglamento define al provider como toda persona física o jurídica, autoridad pública, agencia u otro organismo que:

"desarrolle un sistema de IA o un modelo de IA de uso general o que tenga un sistema de IA o un modelo de IA de uso general desarrollado y los introduzca en el mercado o ponga en servicio el sistema de IA con su propio nombre o marca registrada, ya sea a título oneroso o gratuito."

Traducido: eres provider si desarrollas un sistema de IA, o si lo comercializas bajo tu nombre o marca, independientemente de quién lo haya construido técnicamente. El cobro es irrelevante: regalar un sistema te convierte en provider igual que venderlo.

Ejemplos típicos de provider en el ecosistema español:

• OpenAI, Anthropic, Google, Mistral son providers de modelos de IA de uso general (GPAI).
• Factorial es provider cuando comercializa su módulo de selección de personal con IA bajo su marca.
• Veridas, FacePhi, Mobbeel son providers de sistemas biométricos.
• Una empresa española de software médico que entrena un modelo propio para análisis de imágenes diagnósticas y lo vende a clínicas es provider de un sistema de IA de alto riesgo.
• Un equipo interno de IT de una gran empresa que construye un modelo de scoring crediticio propio para uso interno es provider de ese sistema, aunque no lo venda fuera.

Lo que define al provider no es el tamaño ni el sector: es el acto de poner el sistema en el mercado o ponerlo en servicio bajo tu nombre.

Las obligaciones del provider en una línea

Si tu sistema es de alto riesgo (entra en el Anexo III) y eres provider, te aplica el bloque más exigente del Reglamento:

• Sistema de gestión de la calidad (Art. 17).
• Documentación técnica completa (Art. 11 y Anexo IV).
• Evaluación de conformidad antes de comercializar (Art. 43).
• Marcado CE y declaración UE de conformidad (Art. 47-48).
• Registro del sistema en la base de datos UE (Art. 49).
• Monitorización post-comercialización (Art. 72).
• Notificación de incidentes graves a las autoridades (Art. 73).
• Cooperación con las autoridades (Art. 21).

Es exigente y por eso la mayoría de PYMEs que no desarrollan IA prefieren asegurarse de no caer aquí por error.

Qué es un deployer según el AI Act

El Artículo 3.4 define al deployer como toda persona física o jurídica, autoridad pública, agencia u otro organismo que:

"utilice un sistema de IA bajo su propia autoridad, salvo cuando su uso se enmarque en una actividad personal de carácter no profesional."

Traducido: eres deployer si usas un sistema de IA en tu actividad profesional, decidiendo cómo, cuándo y para qué se usa. Si una empresa contrata un software con IA y lo aplica en su día a día, es deployer de ese sistema. Si un autónomo usa ChatGPT para preparar informes a sus clientes, es deployer.

El uso doméstico personal queda fuera. Todo lo demás entra.

Ejemplos típicos de deployer en una PYME española:

• Una gestoría que usa un software con IA para clasificar facturas automáticamente.
• Una empresa de e-commerce que activa el módulo de recomendaciones de su plataforma.
• Un departamento de RRHH que utiliza un ATS con scoring de candidatos.
• Una clínica que usa un software de IA para apoyar diagnósticos por imagen.
• Una asesoría que usa ChatGPT Enterprise para redactar borradores.
• Un banco regional que utiliza un sistema de IA del proveedor X para detectar fraude.

La inmensa mayoría de PYMEs españolas son solo deployers. No desarrollan IA: la consumen.

Las obligaciones del deployer en una línea

Si usas un sistema de alto riesgo, el Artículo 26 te impone nueve obligaciones operativas, ya detalladas en la guía práctica de obligaciones para PYMEs:

1. Usar el sistema según las instrucciones del provider.
2. Asignar supervisión humana competente.
3. Garantizar datos de entrada pertinentes.
4. Monitorizar el funcionamiento.
5. Conservar los logs durante al menos seis meses.
6. Informar a los trabajadores y a sus representantes.
7. Realizar la evaluación de impacto en derechos fundamentales (FRIA) si aplica.
8. Informar a las personas afectadas.
9. Cooperar con las autoridades.

Si tus sistemas no son de alto riesgo, las obligaciones se reducen a transparencia (Art. 50) y alfabetización del personal (Art. 4).

Tabla comparativa: obligaciones de provider vs deployer

Esta es la diferencia operativa entre ambos roles cuando se trata de un sistema de alto riesgo. Sirve como referencia rápida para entender de un vistazo qué le toca a cada uno.

| Obligación | Provider | Deployer | |---|---|---| | Sistema de gestión de la calidad (Art. 17) | Sí | No | | Documentación técnica completa (Art. 11 + Anexo IV) | Sí | No | | Datos de entrenamiento, validación y prueba (Art. 10) | Sí | No | | Evaluación de conformidad antes de comercializar (Art. 43) | Sí | No | | Marcado CE y declaración UE de conformidad (Art. 47-48) | Sí | No | | Registro en la base de datos UE (Art. 49) | Sí | Solo si es organismo público | | Monitorización post-comercialización (Art. 72) | Sí | No | | Instrucciones de uso al deployer (Art. 13) | Sí | No | | Supervisión humana del sistema (Art. 14) | Sí (diseño) | Sí (operación) | | Notificación de incidentes graves (Art. 73) | Sí | Sí (15 días) | | Datos de entrada pertinentes | No | Sí | | Monitorización operativa diaria | No | Sí | | Conservación de logs ≥ 6 meses | No | Sí | | Informar a trabajadores y representantes | No | Sí | | Evaluación de impacto en derechos fundamentales (Art. 27) | No | Sí (si aplica) | | Informar a personas afectadas | No | Sí | | Cooperación con autoridades | Sí | Sí | | Multa máxima por incumplir obligaciones específicas | Hasta 15M€ o 3% facturación | Hasta 15M€ o 3% facturación |

Hay un patrón claro: el provider se ocupa del diseño, conformidad técnica y comercialización; el deployer se ocupa del uso responsable, supervisión humana operativa y trazabilidad del sistema cuando ya está funcionando.

Para obligaciones de transparencia (Art. 50) y alfabetización (Art. 4), ambos están sujetos.

El caso peligroso: cuándo un deployer se convierte en provider (Art. 25)

Esta es la sección que más empresas se saltan y la que más cara puede salir. El Artículo 25 del Reglamento establece tres situaciones en las que un deployer (o un distribuidor, o un importador) se convierte automáticamente en provider del sistema, heredando todas las obligaciones del provider original.

Situación 1 — Poner tu marca a un sistema existente

Si compras un sistema de IA de alto riesgo a un tercero y lo comercializas bajo tu nombre o marca, eres provider de ese sistema. Esto es lo que en otros sectores se conoce como "white label" o "OEM". Da igual que técnicamente no hayas tocado una línea de código: si lo vendes con tu marca, eres provider.

Ejemplo: una consultora española compra un motor de IA de scoring crediticio a una empresa francesa, le pone su propio branding y lo vende a bancos regionales como "BankScore Pro". La consultora es provider de "BankScore Pro" a todos los efectos del AI Act.

Situación 2 — Modificación sustancial de un sistema de alto riesgo

Si modificas un sistema de alto riesgo de manera que afecta a su conformidad con los requisitos del Reglamento, te conviertes en provider. La clave está en el adjetivo sustancial: no toda modificación cuenta.

Lo que no es modificación sustancial:

• Configurar parámetros expuestos por el provider (umbrales, idiomas, plantillas).
• Cambiar prompts en un sistema generativo.
• Integrar el sistema con otros sin alterar su finalidad.
• Actualizar a una nueva versión del provider.

Lo que sí es modificación sustancial:

• Hacer fine-tuning del modelo con tus propios datos.
• Reentrenar el sistema con un nuevo dataset.
• Modificar el código del sistema más allá de la configuración expuesta.
• Alterar la finalidad declarada del sistema.

Ejemplo: una empresa de RRHH compra un ATS con módulo de IA que ordena candidatos por probabilidad de éxito. La empresa hace fine-tuning del modelo con datos históricos de su propia plantilla para "afinarlo a su cultura". En el momento del fine-tuning, esa empresa se convierte en provider del nuevo sistema modificado y hereda todas las obligaciones del provider de alto riesgo: documentación técnica completa, evaluación de conformidad, marcado CE, etc.

Situación 3 — Cambiar la finalidad de un sistema GPAI a alto riesgo

Si tomas un sistema de IA de uso general (GPAI: GPT, Claude, Gemini, Mistral, etc.) y lo integras en un producto o flujo cuya finalidad es un uso de alto riesgo del Anexo III, te conviertes en provider del sistema de alto riesgo resultante.

Ejemplo: una asesoría española conecta la API de GPT-4 a un sistema interno que automáticamente puntúa a candidatos en procesos de selección para sus clientes. Aunque GPT-4 sea un sistema GPAI desarrollado por OpenAI, el uso final (selección de personal) entra en el Anexo III dominio 4 (empleo) y la asesoría se convierte en provider de un sistema de alto riesgo. OpenAI no asume esas obligaciones; las hereda quien construye el caso de uso final.

Este es el caso más insidioso, porque muchas PYMEs creen que estar "usando ChatGPT" siempre les hace deployer. No es así. Si lo integras en un producto cuya finalidad es alto riesgo, eres provider de ese producto.

Test rápido: ¿qué eres en cada uno de tus sistemas?

Para cada sistema de IA que use tu empresa, responde estas seis preguntas en orden. La primera que respondas con "sí" determina tu rol.

| # | Pregunta | Si "sí" → eres | |---|---|---| | 1 | ¿Has desarrollado tú el sistema desde cero (modelo entrenado por ti o tu equipo)? | Provider | | 2 | ¿Comercializas un sistema desarrollado por un tercero bajo tu nombre o marca? | Provider (Art. 25.1.a) | | 3 | ¿Has hecho una modificación sustancial al sistema (fine-tuning, reentrenamiento, alteración del código)? | Provider (Art. 25.1.b) | | 4 | ¿Integras un sistema GPAI (ChatGPT, Claude, Gemini…) en un producto o flujo cuya finalidad es un uso del Anexo III? | Provider (Art. 25.1.c) | | 5 | ¿Usas un sistema de IA en tu actividad profesional bajo tu responsabilidad, sin haber hecho nada de lo anterior? | Deployer | | 6 | ¿Solo distribuyes o revendes el sistema sin alterarlo ni rebrandearlo? | Distribuidor (otro régimen) |

Nota importante: un sistema puede no caer en ninguna categoría comercial relevante si lo usas en un contexto personal no profesional. Pero en cuanto entras en el ámbito empresarial, alguno de los seis roles te aplica.

Y un mismo sistema, en función del uso, puede asignarte roles distintos en empresas diferentes. La clave es analizar cada sistema y cada uso por separado.

Casos prácticos por sector

Gestoría que usa ChatGPT Enterprise

La gestoría es deployer de ChatGPT. OpenAI es el provider. Mientras la gestoría use el sistema para tareas que no entran en el Anexo III (redactar borradores, resumir documentos internos, traducir contenidos), sus obligaciones son las del deployer general: transparencia (Art. 50) si el contenido se publica como generado por IA, alfabetización del personal (Art. 4) y RGPD si trata datos personales. No tiene obligaciones del Art. 26 porque no usa un sistema de alto riesgo.

E-commerce con módulo de recomendaciones de su plataforma

El e-commerce es deployer del módulo de recomendaciones. Shopify, PrestaShop o la plataforma propia del SaaS es el provider. Los recomendadores comerciales estándar no son de alto riesgo según el Anexo III. Obligaciones: transparencia si afecta a decisiones automatizadas del cliente, Art. 4 y RGPD.

Empresa de RRHH que compra un ATS con módulo de IA

La empresa es deployer del ATS. El proveedor del software (Factorial, Workday, Bizneo, etc.) es el provider. El módulo de IA para selección de personal es de alto riesgo (Anexo III dominio 4). Obligaciones plenas del Art. 26 + información a empleados y a sus representantes. Tratado en detalle en la guía sobre AI Act en RRHH.

Misma empresa de RRHH que hace fine-tuning del modelo con sus datos

En el momento en que la empresa entrena el modelo con su propia base de datos para "ajustarlo a su cultura", deja de ser solo deployer y se convierte también en provider del nuevo modelo (Art. 25.1.b). Hereda: documentación técnica completa, evaluación de conformidad, marcado CE, registro en la base de datos UE. Las multas máximas se acumulan.

Asesoría que conecta la API de GPT-4 a un sistema propio de scoring de clientes para banca

La asesoría es provider del sistema de scoring (Art. 25.1.c). OpenAI es provider de GPT-4 como GPAI, pero la finalidad de alto riesgo (scoring crediticio, Anexo III dominio 5) es responsabilidad del integrador. La asesoría tiene que cumplir todo el bloque de provider de alto riesgo.

Empresa española de software médico que entrena un modelo propio para análisis de imagen diagnóstica

La empresa es provider del sistema (Art. 3.3). Si las clínicas españolas lo compran y lo usan, ellas son deployer. Para la empresa: bloque completo de provider de alto riesgo + posible solapamiento con el Reglamento de Productos Sanitarios (MDR/IVDR), que añade exigencias paralelas.

Errores frecuentes que confunden el rol

"Como compramos el software, somos deployer y ya está." Solo cierto si no haces nada del Art. 25. Si rebrandeas, modificas sustancialmente o integras un GPAI en un caso de uso de alto riesgo, te conviertes en provider. La compra inicial no te exime.

"Hacer fine-tuning es solo configuración." Falso. El fine-tuning altera los pesos del modelo, y eso es modificación sustancial por definición. La diferencia con "configurar parámetros" está en si tocas el modelo (provider) o solo su interfaz de uso (deployer).

"Como usamos ChatGPT, no podemos ser provider de nada." Falso. Si construyes un producto sobre la API de ChatGPT cuya finalidad es alto riesgo, eres provider de ese producto.

"Si lo desarrollamos in-house pero no lo vendemos fuera, no somos provider." Falso. La definición del Art. 3.3 incluye también "ponerlo en servicio" con tu nombre, no solo comercializarlo a terceros. Un sistema interno desarrollado por la empresa para su propio uso convierte a esa empresa en provider y deployer simultáneamente.

"Como nuestro proveedor cumple, nosotros estamos cubiertos." Falso. Las obligaciones del provider y del deployer son acumulativas, no excluyentes. El provider tiene las suyas, el deployer las suyas, y nadie las cumple por el otro. Pedir al provider que te entregue su documentación es una obligación tuya como deployer (Art. 26.1).

"Como el sistema no es de alto riesgo, da igual si soy provider o deployer." No es así, pero el peso operativo es menor: ambos roles tienen obligaciones de transparencia (Art. 50) y alfabetización (Art. 4), pero el provider además tiene que cumplir códigos de conducta voluntarios (Art. 95) y, si su sistema es un GPAI con riesgo sistémico, las obligaciones del Art. 55.

Por qué este análisis se hace por sistema, no por empresa

Una conclusión central: no eres "provider" o "deployer" como empresa. Lo eres respecto a cada sistema que usas o construyes. Una PYME estándar puede ser:

• Deployer de ChatGPT.
• Deployer del ATS de Factorial.
• Provider de su chatbot interno construido sobre la API de Mistral.
• Provider de un sistema de scoring de leads desarrollado por su equipo de datos.

Por eso el primer paso operativo del cumplimiento es siempre el inventario por sistema, no por empresa: una fila por cada herramienta de IA y, para cada una, su rol (provider/deployer), su nivel de riesgo, y sus obligaciones específicas. Las multas se aplican por sistema y por infracción.

Cómo identificar tu rol exacto en cada sistema sin equivocarte

La clasificación correcta de cada sistema es lo que diferencia "cumplimiento real" de "cumplimiento aparente". Una empresa que cree ser deployer cuando en realidad es provider está incumpliendo el bloque más serio del Reglamento, expuesta a las multas más altas y sin marcado CE en un sistema que técnicamente debería tenerlo.

CumpleConIA tiene un test gratuito de 2 minutos que analiza, para cada herramienta de IA que use tu empresa, cuál es exactamente tu rol según los Artículos 3 y 25 del Reglamento, qué obligaciones aplican y qué documentación tienes que generar.

→ Comprobar mi rol en cada sistema de IA

Sin registro ni tarjeta. 10 preguntas, una clasificación por sistema y un plan de acción priorizado por riesgo.

Lo importante

El AI Act no es un Reglamento que se aplique "a la empresa". Se aplica a cada sistema que la empresa desarrolla o usa, y la primera pregunta para cada sistema es la misma: ¿soy provider o deployer? La respuesta condiciona absolutamente todo lo demás —obligaciones, documentación, plazos, multas, marcado CE, registro en la base de datos UE—.

Para la mayoría de PYMEs españolas, la respuesta es "deployer en todos mis sistemas" y el bloque de obligaciones es el del Art. 26 más transparencia y alfabetización. Pero basta un fine-tuning, un rebrand o un caso de uso de alto riesgo construido sobre GPT para que un sistema concreto cambie de categoría y la empresa pase a tener obligaciones de provider sin haberlo planificado.

Repasa cada sistema. Documenta el rol por escrito. Si dudas, pide a tu provider que te confirme su rol y revisa si tu uso encaja en alguno de los tres supuestos del Art. 25. Entrar en agosto de 2026 con el rol mal clasificado es el error más caro que puede cometer una PYME en este Reglamento.

---

Esta información es orientativa y no constituye asesoramiento jurídico. Consulte con un profesional cualificado para una evaluación vinculante de su situación concreta.