Cómo estructurar contratos y SLAs con proveedores de IA (sin firmar a ciegas)

El contrato que firmas no es el de siempre

La mayoría de empresas que contrata un proveedor de IA (agencia, consultor freelance o plataforma SaaS) firma el mismo contrato que usaría para instalar un software cualquiera: alcance, precio, plazo, garantía de treinta días. Ese contrato no dice nada sobre lo que de verdad importa en un sistema de IA.

Un software tradicional lo instalas y, si el proveedor desaparece mañana, el programa sigue corriendo en tu servidor. Un sistema de IA no funciona así: vive de los datos de tu empresa, de flujos configurados a la medida, de credenciales que muchas veces solo conoce el proveedor. Si el contrato no cubre eso, el negocio depende de la buena voluntad de alguien externo, no de un documento firmado.

Esto se hace mal casi siempre por la misma razón: quien firma no sabe qué preguntar, y el proveedor (sobre todo si es una agencia chica o un consultor independiente) casi nunca llega con un contrato robusto por su cuenta. Nadie pregunta lo incómodo antes de firmar. Lo pregunta después, cuando ya hay un problema.

Qué significa estructurar bien este contrato

Estructurar bien este tipo de contrato no es redactar cláusulas exóticas. Es cubrir, por escrito, cinco preguntas que un contrato de software normal no responde: quién es dueño de los datos, quién es dueño de lo que se construyó, qué nivel de servicio es exigible, qué tan fácil es salir de la relación, y quién responde si el sistema se equivoca.

Nada de esto reemplaza a un abogado. Esta guía no es asesoría legal formal: es el criterio de negocio para saber qué exigir antes de que el contrato pase por el área legal, y para no depender de que el proveedor lo redacte pensando únicamente en proteger su propio riesgo.

Propiedad de los datos y del trabajo construido

Qué pasa con tus datos si el contrato termina

El primer punto ciego es asumir que los datos que el sistema procesó siguen siendo tuyos porque son tus datos de origen. No siempre es así. Si el proveedor los usó para entrenar un modelo, para construir su propio producto, o los alojó sin especificar qué pasa al terminar el contrato, puedes terminar peleando por información que generaste tú.

• Propiedad explícita. El contrato debe decir, sin ambigüedad, que los datos de entrada, los generados durante la operación y cualquier derivado (embeddings, bases vectoriales, historiales) son propiedad de tu empresa, no del proveedor.
• Prohibición de reutilización. Que el proveedor no pueda usar tus datos para entrenar modelos de otros clientes ni para mejorar su producto general sin tu autorización explícita por escrito.
• Devolución y borrado al terminar. Un plazo concreto (no “razonable”, un número de días) para que el proveedor entregue una copia completa y utilizable de tus datos, y confirme el borrado de su lado.
• Formato de entrega. Que la devolución sea en un formato que puedas usar sin depender de la herramienta del proveedor, no un archivo propietario que solo su plataforma puede leer.

Quién es dueño del código, los flujos y las automatizaciones

La segunda pregunta que casi nadie hace: si el consultor o la agencia que construyó tus automatizaciones se va mañana, tu empresa se queda con un sistema que funciona o depende de esa persona para siempre. La respuesta depende de una cláusula que muchas veces no existe.

• Propiedad intelectual del trabajo hecho a medida. Los flujos, prompts, integraciones y configuraciones construidos para tu empresa deben quedar en propiedad de tu empresa al pagar, no en licencia de uso del proveedor.
• Documentación como entregable, no como favor. La documentación técnica (cómo está armado cada flujo, qué credenciales usa, dónde vive cada pieza) debe ser parte del contrato, con fecha de entrega.
• Acceso administrador propio. Tu empresa debe tener sus propias credenciales de administrador en cada plataforma usada, no depender de la cuenta personal del consultor para entrar a ver o modificar algo.
• Cláusula de transferencia al terminar. Qué pasa el día que el contrato termina: quién mueve qué, en cuánto tiempo, y quién paga si hay que migrar algo a infraestructura propia.

El SLA: disponibilidad y tiempo de respuesta ante fallas

Un SLA (acuerdo de nivel de servicio) para un sistema de IA no es un lujo de empresa grande. Es la diferencia entre tener un sistema que sostiene una operación real y tener un experimento que un día deja de responder y nadie sabe a quién llamar.

Pide que el contrato fije números concretos, no adjetivos como “alta disponibilidad” o “soporte rápido”. Un adjetivo no se puede exigir en una disputa; un número sí.

• Disponibilidad mínima del sistema, en porcentaje mensual, con qué se considera caído (no responde, responde con error, responde mal) y qué compensación existe si no se cumple.
• Tiempo de respuesta ante una falla reportada, separado por severidad: un sistema caído en producción no puede tener el mismo tiempo de respuesta que una duda de configuración menor.
• Tiempo de resolución, no solo de respuesta: que te contesten en una hora no sirve si el problema tarda una semana y nadie avisa del avance.
• Canal y horario de soporte reales, con nombre de la persona o del equipo responsable, no solo un correo genérico que nadie revisa el fin de semana.
• Penalidad por incumplimiento. Un SLA sin consecuencia (descuento, crédito de servicio, derecho a salir del contrato) es una intención, no una garantía.

Para un consultor freelance chico, un SLA exigente puede sonar desproporcionado. Es razonable ajustarlo al tamaño del proveedor, pero no eliminarlo: si tu operación depende del sistema todos los días, necesitas saber qué pasa el día que falla.

Salida limpia y quién responde si la IA se equivoca

Cláusula de salida y portabilidad

La pregunta que decide si una relación con un proveedor de IA es sana o es una trampa: qué tan fácil es irse si la relación no funciona. Si la respuesta es “muy difícil”, ya estás atado antes de firmar.

• Plazo de salida definido. Cuánto tiempo hay que dar de aviso, y cuánto tiempo tiene el proveedor para entregar todo lo pactado en la cláusula de propiedad.
• Sin candados tecnológicos encubiertos. Que el sistema no dependa de una función exclusiva del proveedor que nadie más pueda replicar, salvo que sea una decisión consciente y documentada.
• Costo de migración acotado. Si migrar exige trabajo adicional, que el contrato defina de antemano cómo se cobra ese trabajo, no que quede a discreción del proveedor que se está yendo.
• Transición asistida, no abandono. Un período de dos a cuatro semanas donde el proveedor saliente ayuda a que el entrante entienda el sistema, en vez de desconectarse el mismo día que termina el contrato.

Responsabilidad cuando el sistema toma una mala decisión

Esta es la cláusula que casi nadie negocia y la que más le importa a un cliente afectado. Si el sistema de IA da mal una cotización, aprueba algo que no debía, o perjudica a un cliente tuyo, ¿quién responde: tu empresa, el proveedor, o los dos?

• Límites de decisión autónoma por escrito. El contrato (y el diseño del sistema) debe dejar claro qué puede decidir el sistema solo y qué siempre pasa por revisión humana antes de afectar a un cliente o un contrato de dinero.
• Responsabilidad compartida, no transferida por completo. Un proveedor rara vez acepta responsabilidad ilimitada por decisiones del modelo; tu empresa tampoco debería cargar con el cien por ciento del riesgo si el error viene de una falla del proveedor.
• Seguro o cobertura del proveedor, cuando el volumen o el riesgo lo justifica: pregunta si tiene alguna cobertura frente a errores que generen pérdidas económicas al cliente final.
• Registro de auditoría como cláusula, no como favor. Sin un registro de qué decidió el sistema y por qué, no hay forma de determinar responsabilidad cuando algo sale mal.

Los errores que veo al firmar estos contratos

Se repiten con variaciones menores, sin importar el tamaño de la empresa ni del proveedor.

• Copiar el contrato de un software de licencia y solo cambiar el nombre del producto, sin agregar una sola cláusula sobre datos, código o responsabilidad.
• Confiar en la buena relación personal con el consultor en vez de dejarlo por escrito. La relación es buena hasta que deja de serlo, y ahí es cuando el contrato importa.
• No pedir documentación técnica como entregable, y descubrir meses después que nadie en la empresa entiende cómo está armado el sistema del que depende un tercero.
• Firmar sin definir el SLA porque “es una empresa chica y confiamos”. El tamaño del proveedor no cambia el impacto de un sistema caído en tu operación.
• No revisar quién tiene las credenciales de administrador, y enterarse el día que se necesita entrar a modificar algo que solo el proveedor puede acceder.

Cómo se ve esto en la práctica

Una empresa de logística mediana contrató a un consultor freelance para automatizar el seguimiento de pedidos con un agente conectado a su sistema de despacho. El contrato fue un correo con el precio y el plazo de entrega. Nada de propiedad de datos, nada de SLA, nada de qué pasaba si el consultor no podía seguir.

El sistema funcionó bien seis meses. Después el consultor tomó otro proyecto grande y dejó de responder rápido. Una falla en la integración empezó a marcar pedidos como entregados sin estarlo, y nadie en la empresa tenía acceso administrador ni documentación para entender por qué pasaba. La empresa terminó pagando a otro proveedor para reconstruir desde cero algo que ya existía, porque nunca fue dueña de lo que había pagado.

Lo que hubiera cambiado el resultado no era un consultor mejor. Era un contrato de dos páginas con cuatro cláusulas: propiedad del flujo, acceso administrador propio, tiempo de respuesta definido ante fallas, y documentación como entregable. Nada de eso cuesta más caro al firmar. Cuesta carísimo no haberlo pedido.

Mi criterio

Cómo saber si el contrato está bien estructurado

No lo sabes por cómo se ve el documento ni por cuántas páginas tiene. Lo sabes por si puedes responder, sin llamar al proveedor, estas preguntas:

• ¿Puedo nombrar hoy mismo, sin preguntarle al proveedor, quién es dueño legal de los datos que procesa el sistema?
• ¿Tengo acceso administrador propio a cada plataforma involucrada, o dependo de la cuenta de otra persona?
• ¿Existe un número, no un adjetivo, de disponibilidad y de tiempo de respuesta ante fallas, con una consecuencia si no se cumple?
• ¿Sé, en días concretos, cuánto tardaría en tener todo mi sistema funcionando con otro proveedor si esta relación terminara mañana?
• ¿El contrato dice qué pasa si el sistema toma una decisión que afecta a un cliente mío, o ese riesgo quedó sin nombre?

Si alguna de esas cinco preguntas no tiene respuesta clara hoy, el contrato no está mal escrito: está incompleto. Y un contrato incompleto en IA no se nota en la firma. Se nota el día que algo falla y nadie sabe a quién le toca resolverlo.