El proveedor de IA cambia de modelo: qué debe poder decidir la organización antes de aceptar el cambio

Una organización contrata un servicio de inteligencia artificial después de revisar seguridad, privacidad, funcionalidad y condiciones económicas. Meses después el proveedor anuncia una nueva versión del modelo. Puede parecer mantenimiento ordinario, pero la pregunta jurídica correcta es otra: ¿sigue siendo materialmente el mismo sistema que la organización evaluó y decidió utilizar?

El problema no está en que los sistemas cambien. Está en aceptar que cambien sin un mecanismo equivalente de gobierno.

Un cambio técnico puede producir una diferencia jurídica

El AI Act trata de forma específica modificaciones, posiciones y obligaciones dentro de la cadena de valor. El RGPD sigue gobernando los tratamientos de datos personales cuando resulten aplicables.

Pero incluso antes de determinar si un cambio produce una consecuencia regulatoria concreta, la organización necesita saber qué se ha modificado materialmente.

Una nueva versión puede alterar:

• comportamiento y precisión;
• límites conocidos o patrones de error;
• contexto máximo, memoria o herramientas disponibles;
• tratamiento, retención o localización de datos;
• subproveedores;
• capacidad de ejecutar acciones;
• documentación o logs disponibles;
• condiciones de propiedad o reutilización;
• compatibilidad con pruebas previamente superadas;
• costes y condiciones de salida.

Por eso «nueva versión» no es una categoría jurídica suficiente.

El contrato necesita una función de cambio

Muchos contratos describen bien el servicio inicial y mal su evolución. Reconocen al proveedor facultad para actualizar la plataforma, pero no distinguen entre mantenimiento ordinario y una modificación capaz de cambiar la posición de riesgo de la organización.

Una arquitectura contractual más robusta debería responder al menos a cinco preguntas.

1. ¿Qué cambios deben notificarse?

No todo ajuste merece el mismo tratamiento. El contrato puede definir categorías materiales: cambio de modelo principal, subproveedor, región de tratamiento, política de reutilización, herramientas disponibles, arquitectura de seguridad, documentación o funcionalidad que afecte al uso aprobado.

2. ¿Con cuánta antelación?

Si la organización solo conoce el cambio después del despliegue, puede carecer de una opción real de evaluación. El plazo debe guardar relación con el impacto y con la capacidad de migrar, probar o limitar.

3. ¿Qué información debe acompañar al aviso?

Saber que «hay una nueva versión» no basta. Puede ser necesario conocer qué cambió, documentación relevante, compatibilidad, efectos sobre datos, riesgos conocidos, cambios de subprocesamiento y posibilidad de mantener temporalmente una versión anterior.

4. ¿Qué debe volver a probarse?

Las pruebas deberían repetirse cuando el cambio pueda afectar a los criterios que justificaron la aceptación. No siempre será necesario rehacer toda la evaluación. Sí debe existir una decisión sobre qué pruebas siguen siendo válidas y cuáles han perdido valor.

5. ¿Qué puede decidir el cliente?

La organización debería conocer de antemano sus opciones: aceptar, posponer, limitar, exigir aclaraciones, migrar, suspender una funcionalidad o activar salida cuando el cambio sea incompatible con el uso aprobado o con obligaciones aplicables.

El problema del cambio unilateral invisible

El riesgo aumenta cuando el sistema está profundamente integrado. Una empresa puede tener procesos, prompts, memoria, conectores y personas organizados alrededor de una versión determinada. Si el proveedor cambia silenciosamente el comportamiento, el efecto no termina en el software: puede alterar decisiones, cargas de revisión, resultados, incidencias o evidencias.

Por eso el cambio debe conectarse con el expediente de gobernanza. El contrato informa; el expediente decide y conserva memoria.

La secuencia debería ser:

aviso → comparación → análisis de materialidad → pruebas → decisión → actualización de expediente y contrato cuando proceda.

El Protocolo de cambio de modelo o proveedor está construido sobre esa secuencia.

Una cláusula no basta si no existe capacidad material

También puede ocurrir lo contrario: el contrato reconoce derecho a rechazar cambios, pero técnicamente el proveedor no permite mantener la versión anterior y la organización no dispone de alternativa.

Entonces existe un derecho formal con poca capacidad práctica.

Por eso la due diligence debe preguntar no solo «qué dice el contrato», sino:

• si existe versionado real;
• si se puede probar antes de producción;
• si hay rollback;
• si la API o producto permite fijar versión;
• qué ocurre con memoria y configuraciones al migrar;
• cuánto tarda una salida;
• qué activos pueden exportarse.

La Checklist jurídica de proveedor conecta esos elementos contractuales y técnicos.

Criterio H&C

La contratación de IA no queda cerrada cuando se firma. El objeto contratado puede cambiar durante la relación y, con él, el sistema jurídico que la organización debe gobernar.

No toda actualización obliga a renegociar ni toda modificación es sustancial. La regla es más precisa: todo cambio capaz de alterar obligación, posición, riesgo, datos, autoridad, evidencia o continuidad debe entrar en un mecanismo de evaluación y decisión.

El contrato debe hacer posible ese mecanismo. El expediente debe conservar la decisión. Y la arquitectura técnica debe permitir ejecutar lo pactado.

Qué debe poder demostrar la organización

Después de una actualización material debería poder responder:

• qué cambió;
• cuándo se conoció;
• qué información facilitó el proveedor;
• qué impacto se evaluó;
• qué pruebas se repitieron;
• quién aceptó el cambio;
• qué controles se modificaron;
• qué habría ocurrido si el cambio se rechazaba.

Si esa memoria no existe, la organización puede terminar utilizando una versión distinta sin poder explicar por qué sigue siendo aceptable.

Ese es el punto en el que una cláusula de actualización deja de ser una cuestión de procurement y se convierte en una función de gobernanza jurídica.