Integramos IA de terceros: cuándo podemos dejar de ser solo responsables del despliegue

Una empresa compra acceso a un modelo o a una plataforma de inteligencia artificial. Al principio la lectura parece sencilla: el proveedor desarrolla o comercializa el sistema y la empresa lo utiliza. Pero esa fotografía puede dejar de ser válida si la organización empieza a cambiar la finalidad, modifica el sistema, lo integra en un producto propio o lo coloca bajo su nombre.

La pregunta útil no es «¿hemos desarrollado nosotros el modelo?». Es otra: ¿qué función estamos desempeñando realmente dentro de la cadena que convierte ese sistema en un producto, un servicio o una capacidad operativa?

La posición jurídica no se decide por la etiqueta comercial

El Reglamento (UE) 2024/1689 distingue varias posiciones en la cadena de los sistemas de IA. Entre ellas están el proveedor y el responsable del despliegue. La regulación también contempla supuestos en los que un operador distinto del proveedor inicial puede pasar a asumir obligaciones de proveedor.

Esto importa porque muchas implantaciones empresariales no consisten en «usar una aplicación» de forma estática. La empresa puede combinar un modelo de tercero con datos propios, memoria, herramientas, reglas, interfaces, flujos de decisión y un propósito concreto. Esa configuración puede cambiar con el tiempo.

Por eso hay que separar tres preguntas:

1. quién desarrolló o comercializó inicialmente el sistema;
2. quién determina cómo se configura y utiliza en la práctica;
3. qué cambios introduce después cada operador y con qué efecto.

La respuesta a la primera no cierra necesariamente las otras dos.

Tres señales que obligan a reabrir el análisis

1. El sistema empieza a presentarse bajo nuestra marca o nombre

La forma de presentación puede ser jurídicamente relevante. Si una organización deja de limitarse a desplegar una solución ajena y pasa a colocar el sistema en el mercado o ponerlo en servicio bajo su propio nombre o marca, la arquitectura de posiciones debe revisarse.

No significa que cualquier personalización de interfaz transforme automáticamente a la empresa en proveedor. Significa que la cuestión ya no puede resolverse diciendo únicamente «el modelo es de un tercero».

2. Cambia la finalidad prevista

El mismo componente técnico puede formar parte de configuraciones jurídicamente distintas. Un sistema utilizado para apoyo general interno no plantea necesariamente la misma clasificación que ese mismo sistema integrado después en selección de personal, evaluación, acceso a un servicio o una decisión que afecta a terceros.

Cuando cambia la finalidad material, hay que preguntar de nuevo qué sistema existe y qué posición ocupa cada parte. El objeto regulado no es el nombre comercial del modelo, sino la configuración y el uso sometidos al régimen aplicable.

3. Se introduce una modificación sustancial

Una actualización, integración o modificación puede ser jurídicamente neutra o puede alterar el funcionamiento de manera relevante. No es posible decidirlo solo por el número de líneas de código cambiadas o por si la modificación la realizó un equipo interno.

Hay que reconstruir qué cambió: finalidad, comportamiento, datos, controles, capacidad de actuación, afectados, riesgo o condiciones de uso. Si el cambio es material para la posición o el régimen, el expediente jurídico debe reflejarlo.

El error habitual: dibujar la cadena una sola vez

En muchas implantaciones se identifica al proveedor durante la compra y esa asignación queda congelada. Después cambian el modelo, la integración, los datos, el uso o el nombre del producto, pero el mapa jurídico no se vuelve a abrir.

Ese enfoque confunde una fotografía contractual con una función mantenida en el tiempo.

Un sistema de IA empresarial necesita una memoria de posiciones: quién ocupa cada función, en virtud de qué hechos y qué cambios obligarían a revisarla. La posición no debe tratarse como una etiqueta administrativa, sino como una hipótesis jurídicamente mantenida.

Qué conviene documentar

Antes de asignar obligaciones, el expediente debería poder responder al menos a estas cuestiones:

• cuál es la finalidad prevista y cuál es el uso real;
• qué entidad suministra modelo o sistema;
• qué componentes añade la organización;
• bajo qué nombre se presenta el sistema frente a usuarios o terceros;
• quién decide cambios de modelo, versión y configuración;
• quién controla datos, memoria, herramientas y permisos;
• si existen modificaciones capaces de alterar finalidad, funcionamiento o riesgo;
• quién puede suspender el sistema o revertir un cambio.

El Mapa de posiciones jurídicas del sistema de IA está diseñado precisamente para fijar esa estructura antes de aplicar obligaciones.

Criterio H&C

No es correcto partir de que toda empresa que compra IA es simplemente «cliente» o «usuario» a efectos regulatorios durante toda la vida del sistema. Tampoco lo es presumir que cualquier integración convierte a la organización en proveedor.

La posición debe reconstruirse desde la función real y mantenerse frente a cambios de nombre, finalidad, configuración y control material.

La secuencia adecuada es:

sistema real → operadores → funciones → cambios → posición jurídica → obligaciones.

Cuando la organización no puede explicar esa secuencia, todavía no sabe con suficiente precisión qué está regulando.

Qué hacer cuando aparece la duda

Primero se fija el sistema: finalidad, componentes, datos, integraciones y efectos. Después se dibuja la cadena de operadores. Solo entonces se analiza si la organización continúa como responsable del despliegue o si algún hecho obliga a revisar la posición.

La pregunta no es terminológica. Tiene consecuencias en documentación, gobernanza, contratación, evaluación de conformidad cuando proceda, información, supervisión y responsabilidad.

Por eso esta cuestión pertenece al mapa de AI Act y regulación, pero no termina allí: si la posición cambia, también deben cambiar el expediente, los contratos y los instrumentos con los que se gobierna el sistema.