Qué es un SLA de IA y qué debe incluir

El dolor: un contrato que se cumple y una empresa que igual queda expuesta

Una empresa mediana de servicios financieros en Colombia contrató a un proveedor para automatizar la evaluación inicial de solicitudes de crédito con un modelo de IA. El contrato que firmaron era el mismo formato que usaban con sus proveedores de software de facturación: porcentaje de disponibilidad del servicio, tiempo de respuesta ante una caída, mesa de ayuda con horario extendido. Nadie en el equipo legal ni en el de tecnología se preguntó qué pasaba si el sistema seguía funcionando, seguía arriba, pero empezaba a evaluar mal las solicitudes.

Eso fue justo lo que pasó. A los cuatro meses, un analista detectó que el modelo estaba rechazando solicitudes de un segmento de clientes con un patrón que no tenía ninguna justificación de riesgo real. El proveedor respondió que el servicio nunca se había caído, que el SLA se había cumplido al cien por ciento. Tenía razón en los términos que habían firmado. El problema es que ese SLA medía lo que mide cualquier software: que la luz esté prendida. No medía lo único que de verdad importaba en un sistema de IA que decide sobre el dinero de una persona: si sus respuestas eran correctas.

Esto se repite en empresas de tamaños y sectores distintos: retail, salud, manufactura. El proveedor de IA no actuó de mala fe, cumplió exactamente lo que firmó. El error fue anterior, ocurrió en la mesa de negociación, cuando el equipo comprador copió un contrato pensado para software determinístico y lo aplicó a un sistema cuya salida cambia de una ejecución a otra. Nadie tradujo el riesgo real del negocio a una cláusula del contrato.

Qué es un SLA de IA, en criterio de negocio

Un SLA (acuerdo de nivel de servicio) existe para una sola cosa: convertir una promesa comercial en un número que se puede exigir. Sin ese número, decir que se va a dar buen servicio es una frase de venta, no un compromiso. Con IA, el error más común es firmar el SLA de siempre y asumir que ya cubre el riesgo nuevo. No lo cubre, porque el riesgo nuevo no es que el sistema se caiga: es que el sistema esté prendido y responda mal.

En la práctica de negocio, el SLA de IA es el documento que el equipo de operaciones va a sacar cada mes cuando algo salga mal: cuando el agente de atención invente una política, cuando el modelo de scoring rechace de forma injustificada, cuando el sistema de clasificación de documentos falle en un porcentaje de casos que nadie definió como aceptable. Si esas situaciones no están descritas en el SLA con un umbral concreto y una consecuencia concreta, el proveedor no tiene ninguna obligación real más allá de mantener el servicio prendido. La guía de cómo estructurar contratos y SLAs con proveedores de IA explica el procedimiento completo para armar ese documento cláusula por cláusula. Acá el foco es entender qué hace distinto a un SLA de IA antes de sentarte a redactarlo.

Por qué la salida probabilística cambia el contrato

Un software tradicional es determinístico: mismo input, mismo código, mismo output, siempre. Si falla, el error es reproducible, un ingeniero lo puede aislar y corregir de una vez, y ahí tiene sentido medir la disponibilidad del servicio como métrica central del SLA. Un sistema de IA generativa no funciona así. La misma pregunta, hecha dos veces, puede producir dos respuestas distintas, y eso no es necesariamente un defecto: es cómo opera el modelo. Copiar el SLA de software y solo cambiar el nombre del proveedor deja fuera exactamente el riesgo que hace distinto a este contrato.

• El mismo prompt puede darte una respuesta distinta según el momento, el contexto de la conversación o una actualización silenciosa del modelo.
• Un error no es un defecto reproducible que el proveedor arregla de una vez: es una probabilidad que hay que bajar y monitorear todo el tiempo.
• La disponibilidad del servicio, que el sistema responda, no dice nada sobre si esa respuesta es correcta.
• Un sistema puede estar arriba el cien por ciento del tiempo y fallar en una parte importante de los casos que de verdad le importan al negocio.
• El costo de un error de IA no siempre aparece de inmediato: puede tardar semanas en convertirse en un reclamo, una devolución o una denuncia.

Ninguno de estos puntos es un tecnicismo de ingeniería. Son la razón por la que un SLA copiado de un proveedor de software corporativo, por más detallado que sea en tiempos de respuesta de soporte, no dice nada sobre lo único que en la práctica define si el sistema sirve: si sus respuestas son correctas con la frecuencia que el negocio necesita.

Qué calidad mínima pactar, y sobre qué conjunto de casos

Si la disponibilidad no es la métrica que protege al negocio, la pregunta correcta es qué sí hay que pactar. La respuesta es calidad mínima medible sobre un conjunto de casos acordado entre las dos partes, no una promesa genérica de alta precisión. Ese conjunto de casos tiene que salir de la operación real de la empresa, no del material de venta del proveedor. Si el proveedor elige los ejemplos con los que se mide a sí mismo, el número que resulte no protege a nadie.

• Casos reales de la operación, anonimizados si hace falta, no ejemplos de demo elegidos por el proveedor.
• Casos límite: la pregunta ambigua, el cliente molesto, la solicitud que se sale del guion esperado.
• Casos donde la respuesta correcta es admitir que no se sabe o escalar a una persona, no inventar una salida.
• Una cadencia de revisión fija, semanal o mensual, con muestreo real, no una auditoría única al momento de firmar.
• Un criterio explícito de quién evalúa cada caso (el proveedor, la empresa o un tercero) y qué pasa si no coinciden en el resultado.

Ese conjunto de casos, junto con el umbral de calidad aceptable, debería quedar documentado como parte de lo que el proveedor tiene que entregar en los primeros treinta días de la relación, no negociarse recién después de la primera crisis.

Las cláusulas que faltan casi siempre

Hay cinco cláusulas que en la mayoría de contratos de IA que se firman hoy simplemente no existen, porque el equipo legal partió de una plantilla de software y nadie se detuvo a pensar qué es distinto en este caso.

• Cambio de modelo: qué pasa cuando el proveedor cambia de modelo o de versión sin avisar. El comportamiento del sistema puede cambiar de un día para otro, y el contrato debe obligar a notificación previa y a un periodo de prueba antes de que ese cambio llegue a producción.
• Responsabilidad por una alucinación que causó daño: quién responde cuando el sistema inventa una información que termina costándole dinero, salud o reputación a alguien. La mayoría de contratos no menciona ese escenario ni asigna responsabilidad.
• Plazo de corrección: un plazo concreto para corregir un error de calidad detectado, no solo para restaurar el servicio cuando se cae.
• Propiedad de los datos y de los prompts: quién es dueño de la información usada para ajustar el sistema y de las instrucciones que la empresa construyó a fuerza de prueba y error. Sin esta cláusula, ese conocimiento se queda con el proveedor cuando la relación termina.
• Salida ordenada: cómo se sale de la relación sin perder la operación, con exportación de datos, historial de conversaciones, configuración y prompts, en un formato utilizable y dentro de un plazo definido.

La cláusula de salida ordenada está directamente conectada con el riesgo de vendor lock-in en IA: si el proveedor no tiene la obligación contractual de entregar los datos y los prompts propios de la empresa en un formato usable, la dependencia deja de ser una elección y se convierte en una trampa.

Cómo se verifica en la operación, no solo en el papel

Firmar el SLA correcto es la mitad del trabajo. La otra mitad es verificarlo con la misma disciplina con la que se audita cualquier proveedor crítico del negocio. Eso implica pedir, antes de firmar, los documentos que sustentan las promesas del proveedor (la guía de qué documentos exigirle a un proveedor de IA detalla cuáles) y, después de firmar, revisar el desempeño real del equipo del proveedor con una cadencia definida durante los primeros meses de la relación, siguiendo el mismo criterio que se usa para medir el desempeño de un equipo proveedor de IA en los primeros noventa días, en lugar de esperar a la fecha de renovación del contrato para hacerlo.

Una señal de alerta clara: si el proveedor se resiste a definir un umbral de calidad medible y prefiere quedarse en frases como alta precisión o resultados de clase mundial, es porque no quiere comprometerse con un número que después le puedan reclamar. Un proveedor serio no le teme a un conjunto de casos de prueba acordado. Lo pide él mismo, porque le sirve para demostrar que su sistema funciona.

Mi criterio

Cuándo urge renegociar y cuándo el contrato ya está bien armado

No todo negocio necesita renegociar su contrato de IA la próxima semana. El riesgo real depende de qué tan expuesta queda la operación cuando el sistema falla y de qué tan crítica es la decisión que la IA está tomando. Estas señales ayudan a distinguir un caso urgente de uno que puede esperar.

Señales de que tu SLA de IA no te protege

• El contrato menciona disponibilidad del servicio pero no dice nada sobre la calidad de las respuestas.
• El sistema toma decisiones que afectan dinero, salud o datos sensibles de clientes y no hay ningún umbral de error aceptable pactado.
• Nadie dentro de la empresa sabe qué pasa contractualmente si el proveedor cambia de modelo.
• Ya hubo al menos un incidente de respuesta incorrecta y el proveedor respondió que el servicio nunca se había caído.
• No existe ningún documento que defina cómo se sale de la relación con los datos y los prompts de la empresa.

Señales de que tu contrato con el proveedor de IA ya está bien armado

• Existe un conjunto de casos de prueba acordado entre las dos partes y se revisa con una cadencia fija.
• El contrato define qué pasa ante un cambio de modelo, incluyendo aviso previo y periodo de prueba.
• Hay una cláusula explícita de responsabilidad ante un error del sistema que cause daño, no solo ante una caída del servicio.
• La empresa puede exportar sus datos, su historial y sus prompts en cualquier momento, en un formato utilizable.
• El proveedor participa activamente en definir el umbral de calidad, en lugar de evitarlo.

El orden correcto: dolor, proceso, dato, herramienta

El error de fondo detrás de un mal SLA de IA casi nunca es legal: es de secuencia. La empresa que termina con un contrato que no la protege es, casi siempre, la que empezó por la herramienta: eligió el proveedor, negoció el precio, y dejó el contrato para el final, como un trámite. El orden que funciona es al revés. Primero el dolor real: qué decisión se está automatizando y qué pasa si esa decisión sale mal. Después el proceso: quién revisa, con qué frecuencia, con qué casos de prueba. Después el dato: qué umbral de error es tolerable para ese proceso específico, no un número genérico tomado de otra industria. Recién ahí la herramienta, y el contrato que la acompaña, incluido el SLA.

Un SLA de IA bien escrito no elimina el riesgo de que el sistema se equivoque, porque ese riesgo es parte de la naturaleza del sistema. Lo que hace es asegurar que, cuando se equivoque, alguien responda por eso con un número y un plazo, no con la frase de que el servicio nunca se cayó. Esa es la diferencia entre haber comprado disponibilidad y haber comprado un resultado.