¿Proveedor o deployer al integrar una API de IA?

Cuando una empresa integra una API de IA generativa o de terceros (como un modelo de lenguaje) en su propio producto, no siempre se limita a utilizar esa tecnología a efectos del Reglamento (UE) 2024/1689. En muchos casos, esa empresa se convierte en proveedor de un nuevo sistema de IA, con obligaciones muy superiores a las de un mero responsable del despliegue (deployer). Distinguir correctamente el rol no es un detalle técnico: determina qué artículos del EU AI Act aplican y qué documentación debe preparar la organización.

¿Qué diferencia a un proveedor de un responsable del despliegue?

El Art. 3(3) del EU AI Act define al proveedor como la persona física o jurídica que desarrolla un sistema de IA (o un modelo de IA de uso general) y lo introduce en el mercado o lo pone en servicio bajo su propio nombre o marca, ya sea a título oneroso o gratuito.

El Art. 3(4) define al deployer (responsable del despliegue) como quien utiliza un sistema de IA bajo su propia autoridad, salvo que sea para una actividad personal no profesional.

La clave no es quién entrenó el modelo, sino quién lo pone en el mercado bajo su marca y define su finalidad concreta. Como ya explicamos en Deployer vs Provider en el EU AI Act: diferencias clave, esta distinción condiciona directamente el volumen de obligaciones que asume cada actor.

¿Qué ocurre cuando integras una API de IA en tu propio producto?

Aquí es donde muchas empresas se confunden. Si una startup consume una API de un modelo de lenguaje de terceros y construye encima una funcionalidad concreta —por ejemplo, un asistente de selección de personal, un motor de scoring crediticio o un chatbot de atención médica— y la comercializa bajo su propia marca, esa startup pasa a ser proveedora del sistema de IA resultante, aunque no haya entrenado ni ajustado el modelo subyacente.

El proveedor de la API (el desarrollador del modelo de IA de uso general) mantiene sus propias obligaciones como proveedor de modelo GPAI bajo el Art. 53. Pero la empresa que integra esa API en un producto con una finalidad específica y la ofrece a terceros bajo su nombre asume, respecto a ese sistema final, el papel de proveedor conforme al Art. 3(3).

El test práctico: cuatro preguntas para identificar tu rol

Para determinar el rol real, conviene responder a estas preguntas:

1. ¿El sistema se comercializa bajo tu marca o nombre? Si sí, hay un fuerte indicio de que eres proveedor.
2. ¿Has definido tú la finalidad prevista del sistema? Definir un caso de uso concreto (RRHH, crédito, salud) sobre una API genérica te convierte en proveedor de ese sistema específico.
3. ¿El sistema se usa solo internamente o se ofrece a clientes/terceros? Usar internamente un sistema de un tercero, sin cambiar su marca ni su finalidad, te mantiene como responsable del despliegue (deployer); pero si el sistema lo desarrollas tú (o se desarrolla para ti) y lo pones en servicio para uso propio, también eres proveedor (Art. 3.3 y 3.11).
4. ¿Has realizado una modificación sustancial del sistema original? Si el sistema es de alto riesgo y lo sigue siendo tras la modificación, el Art. 25.1.b) te convierte en proveedor.

¿Cuándo te conviertes en proveedor aunque no hayas entrenado el modelo? (Art. 25)

El Art. 25 del EU AI Act establece que un distribuidor, importador, deployer u otro tercero se considerará proveedor de un sistema de IA de alto riesgo cuando: (a) pone su nombre o marca en un sistema ya introducido en el mercado; (b) realiza una modificación sustancial de un sistema de IA de alto riesgo ya en el mercado; o (c) modifica la finalidad prevista de un sistema que no era de alto riesgo, de forma que pasa a serlo.

Ojo: el Art. 25 sólo opera sobre sistemas de alto riesgo. En la mayoría de integraciones de API, la empresa que envuelve un modelo de terceros en un producto con finalidad y marca propias ya es proveedora del sistema resultante por la definición del Art. 3.3; y si ese sistema es de alto riesgo, asume además las obligaciones del proveedor de alto riesgo: gestión de riesgos, documentación técnica y, si corresponde, registro en la base de datos de la UE.

¿Qué pasa si el sistema resultante es de alto riesgo?

Si la finalidad definida por la empresa integradora encaja en algún supuesto del Anexo III (por ejemplo, selección de personal, evaluación crediticia o triaje sanitario), el sistema deberá cumplir las obligaciones de alto riesgo del Art. 9 y siguientes. Es importante recordar que, tras el Reglamento (UE) 2026/1744, las obligaciones de alto riesgo del Anexo III se aplican desde el 2 de diciembre de 2027, mientras que las del Anexo I se postergaron al 2 de agosto de 2028. Las obligaciones de transparencia del Art. 50 sí aplican ya desde el 2 de agosto de 2026, con un plazo hasta el 2 de diciembre de 2026 para que los sistemas introducidos en el mercado antes del 2 de agosto de 2026 incorporen el marcado legible por máquina del Art. 50.2 (Art. 111.4).

¿Cómo documentar correctamente tu rol?

Este análisis de rol —proveedor, deployer, o ambos simultáneamente, como ocurre en muchas pymes tecnológicas— debe quedar documentado desde el inicio del proyecto. Como se detalla en Proveedor y responsable del despliegue: cómo gestionar múltiples roles en la IA, una misma empresa puede ser deployer de unas herramientas de IA y proveedor de otras construidas sobre APIs de terceros.

La metodología de autoevaluación de AICONTEXT incluye precisamente un bloque dedicado a la identificación del rol dentro de sus 13 secciones, ayudando a las organizaciones a mapear cada sistema de IA que usan o integran y a determinar, sistema por sistema, si actúan como proveedor, deployer o ambos. Puedes iniciar ese análisis a través del brief de autoevaluación.

Conclusión

Integrar una API de IA no es una decisión neutra desde el punto de vista regulatorio. La empresa que construye un producto sobre un modelo de terceros, lo bautiza con su marca y define una finalidad concreta deja de ser un simple usuario tecnológico para convertirse en proveedor de un nuevo sistema de IA, con toda la carga documental que ello implica. Identificar este cambio de rol a tiempo —antes de lanzar el producto al mercado— es la diferencia entre una preparación ordenada y una exposición innecesaria ante el Reglamento (UE) 2024/1689.