¿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 sigue siendo un simple usuario de 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? El uso puramente interno, sin comercialización, suele mantener a la empresa como deployer.
4. ¿Has realizado una modificación sustancial del sistema original? Si la respuesta es sí, el Art. 25 activa obligaciones de 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.

Este artículo es exactamente el que activa la mayoría de los casos de integración de API: al envolver un modelo de terceros en un producto con finalidad propia y marca propia, la empresa integradora asume las obligaciones plenas de proveedor respecto al sistema resultante, incluidas evaluació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 el etiquetado legible por máquina del Art. 50.2 exigible desde el 2 de diciembre de 2026.

¿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 Desplegador: 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.