Qué tiene que decir una cláusula de IA con un proveedor
En los contratos con IA por medio se repite siempre lo mismo, y no es lo que uno esperaría. Las cláusulas de responsabilidad suelen estar bien. Las de protección de datos, también. Lo que falta está en otro sitio, y son seis puntos.
Dos de ellos no suelen aparecer escritos en ninguna parte, y son los que más me interesan.
1 · La definición no la escribes tú
La tentación es definir sistema de inteligencia artificial dentro del contrato, con precisión, adaptado al servicio. Es un error de mantenimiento: esa definición envejece con la primera actualización normativa y obliga a renegociar para algo que ya está resuelto fuera.
Lo que funciona es anclar la definición al artículo 3.1 del AI Act y, esto es lo que casi siempre falta, incorporar también la exclusión del considerando 12, que deja fuera los sistemas de software tradicionales más simples.
Sin esa segunda mitad, la cláusula acaba abarcando cualquier cosa que ordene una lista o aplique una regla. Y una cláusula que abarca todo no se aplica a nada: la primera vez que alguien intente ejecutarla sobre un gestor de reglas de toda la vida, el marco entero pierde credibilidad.
2 · La IA embebida necesita su propio régimen
La mayoría de los casos reales no son sistemas de IA contratados como tales. Son funcionalidades que llegan dentro de software empresarial que ya usabas, y que el fabricante activa por su cuenta en una actualización.
Aplicar a eso el examen completo (cualificación, documentación, evaluación por caso de uso) no es exigente, es inviable. Y lo que es inviable en volumen no se hace: se salta, se documenta como excepción o simplemente se ignora, y el marco entero se erosiona.
Régimen simplificado para ese supuesto, con obligaciones de información y notificación de cambios materiales. El examen completo se reserva para los sistemas cuyo objeto contratado es la propia IA, y para cualquier servicio que toque a tus clientes con independencia de cómo llegue la tecnología.
Esto no es relajar el criterio. Es ponerlo donde puede ejecutarse.
3 · La garantía sustitutiva
Este es el primero de los dos que no había visto escritos.
Cuando contratas un servicio que incorpora un sistema de alto riesgo de un tercero, necesitas saber quién lo desarrolló. No por curiosidad: buena parte de tus obligaciones como responsable del despliegue dependen de información que solo el desarrollador tiene, y el reglamento presupone que esa información circula por la cadena.
A veces el proveedor no la da. El escalón que funciona tiene tres peldaños, y se suben en orden:
- Pedirlo. Sorprende cuántas veces la información existe y nadie la había pedido, porque nadie sabía que la necesitaba.
- Ofrecer confidencialidad. Si el proveedor alega que su cadena de suministro es información comercialmente sensible, y es una alegación legítima, se le ofrece un régimen que permita conocerla sin difundirla.
- Garantía sustitutiva. Si aun así se niega, el proveedor responde frente a ti como si fuera él el desarrollador del sistema.
El tercer peldaño no es una cláusula agresiva ni una posición de negociación. Es la consecuencia lógica de que hayas asumido una obligación sobre algo que él no te deja verificar. Dicho así, en esos términos, se acepta más veces de las que uno esperaría, porque el argumento es difícil de rebatir sin dar la información.
4 · La prohibición de entrenamiento va en todos los casos
La prohibición de usar tus datos para entrenar modelos suele estar escrita. Suele estar escrita solo donde se pensó primero, que es el servicio donde se procesa documentación.
Y el riesgo es mayor, no menor, en los servicios donde se procesan conversaciones con tus clientes. Ahí no hay documentos, hay personas hablando, y el material es incomparablemente más rico para quien quiera mejorar un modelo.
La prohibición cubre todos los supuestos del contrato, sin excepción por tipo de servicio, y viene acompañada de la obligación de acreditar el cumplimiento. Sin esa segunda parte es una afirmación que nadie puede comprobar. Y si el proveedor la incumple, deja de ser encargado en ese tratamiento y pasa a ser responsable por finalidad propia, con las consecuencias que ya conté.
5 · La capa de IA del plan de salida
El plan de salida está en casi todos los contratos importantes. La capa de IA no está en casi ninguno, porque no viene exigida por ninguna norma: para modelos, pesos afinados, librerías de prompts y marcos de evaluación no hay derecho de portabilidad por defecto.
Tres líneas, y hay que escribirlas: exportación de logs e histórico en formato portable, preaviso de cambios materiales de modelo, y prohibición de retención tras la terminación con evidencia de borrado.
6 · Si sustituye personas por agentes, el precio deja de medir lo que medía
El segundo que no había visto escrito, y el que más me gusta porque no va de riesgo, va de dinero.
Muchos servicios se tarifan por jornada o por perfil. Esa tarifa es un proxy del coste de las personas asignadas: se acordó sabiendo cuántas eran y de qué nivel.
Si el proveedor sustituye parte de esas personas por agentes y mantiene la tarifa, el margen se desplaza sin que cambie ninguna cláusula. Nadie ha incumplido nada. Simplemente el precio ha dejado de medir lo que las partes acordaron que medía.
No se trata de impedirlo. Que un proveedor automatice suele ser bueno para el servicio y para ti. Se trata de escribir que ese cambio se notifica y abre revisión de precio, igual que se notifica cualquier cambio material en la prestación.
Es una cláusula que más suele discutirse, y la única de las seis que no tiene nada que ver con el AI Act.
Lo que estas seis cosas tienen en común
Ninguna de las seis se resuelve con una plantilla. Todas salen de haber tenido delante el servicio concreto y haberse preguntado qué pasa cuando esto cambie, que es una pregunta que un modelo de contrato no puede hacerse por ti.
Y todas comparten el mismo supuesto de fondo: el contrato crea derechos, no gobierno. Un derecho a exigir información que nadie ejerce, una notificación que llega a un buzón que nadie lee y una revisión de precio que nadie dispara valen exactamente lo mismo que no haberlos escrito. La cláusula es la mitad; la otra mitad es que alguien tenga encomendado usarla. Y lo que se pueda recuperar del proveedor después de indemnizar a alguien también se decide aquí, al firmar: quién paga cuando un sistema de IA causa un daño.