Infraestructura y técnica

SLA de un servicio de IA

Un SLA (Service Level Agreement) de un servicio de IA es el compromiso contractual del proveedor sobre niveles de servicio: disponibilidad, latencia, soporte y, cuando aplica, estabilidad del modelo. En IA tiene una particularidad crítica que casi nadie negocia: qué pasa cuando el proveedor cambia o retira el modelo del que depende tu proceso.

Por Ana María González Actualizado: 16 de mayo de 2026

Definición rápida

Respuesta directa

Explicación ampliada

Los SLA son habituales en servicios tecnológicos: garantizan un porcentaje de disponibilidad, tiempos de respuesta, ventanas de soporte, compensaciones si se incumplen. En un servicio de IA aplican todos esos elementos clásicos, pero hay tres dimensiones específicas que una empresa debe mirar y que rara vez vienen bien cubiertas. Primera: la estabilidad y el ciclo de vida del modelo. A diferencia de una API estable, un proveedor de IA actualiza, versiona y deprecia modelos; un proceso crítico afinado a un modelo concreto puede romperse cuando ese modelo cambia o se retira. ¿El SLA garantiza preaviso de deprecación? ¿Acceso a la versión anterior durante un periodo de transición? Segunda: la latencia, especialmente relevante en usos interactivos (un agente de voz, un asistente en tiempo real) y muy variable en modelos de razonamiento. Tercera: el soporte real y los límites de uso (cuotas, throttling) que pueden afectar a operaciones en picos. Negociar o al menos exigir y leer estas cláusulas es parte de la evaluación de proveedores: muchas empresas firman el SLA estándar mirando solo la disponibilidad y descubren tarde que no tienen ninguna garantía sobre lo que de verdad les puede romper el proceso, que es el cambio de modelo. El SLA es, junto con la evaluación de transferencias de datos y el riesgo de lock-in, uno de los tres pilares de una contratación de IA hecha con criterio.

Por qué importa para tu empresa

Aplicación práctica

Para una empresa con procesos críticos sobre IA externa, firmar el SLA estándar sin mirar la estabilidad del modelo deja desprotegido justo el riesgo más probable: que el proveedor cambie o retire el modelo. La regla práctica: al evaluar un servicio de IA, exigir y leer cláusulas sobre preaviso de deprecación, acceso a versión anterior en transición, latencia comprometida (si el uso es interactivo) y límites de uso reales; no solo el porcentaje de disponibilidad. La pregunta de control: "¿qué garantiza el contrato el día que cambien el modelo?".

Ejemplo concreto

Caso real

Una empresa tenía un proceso crítico construido sobre un modelo concreto de un proveedor, con el SLA estándar firmado sin negociar. El proveedor anunció la deprecación del modelo con poco margen; el SLA no garantizaba ni preaviso amplio ni acceso de transición a la versión previa. La empresa tuvo que readaptar el proceso a contrarreloj. Para la siguiente contratación incluyeron en la evaluación de proveedores cláusulas explícitas de ciclo de vida del modelo (preaviso mínimo, periodo de transición) como requisito, al mismo nivel que la disponibilidad.