La compra de IA en empresa sigue un guion conocido: alguien enseña una demo, el sistema responde bien tres veces seguidas, la sala asiente y se firma. Nadie abre la pestaña del acuerdo de nivel de servicio. Seis meses después, un martes por la mañana, el agente que responde a clientes deja de responder —y ahí empieza la conversación que debería haberse tenido antes de firmar: ¿quién arregla esto, en cuánto tiempo, y qué pasa si no lo arregla?
La tesis en una frase: eliges proveedor por la demo y convives con él por el soporte. Y el SLA que crees que has comprado suele fallar en tres puntos a la vez: no cubre el plan que estás usando, mide disponibilidad en vez de que el sistema haga bien su trabajo, y no dice absolutamente nada de cuánto va a existir el modelo del que depende tu operación.
El soporte y el SLA de tu proveedor de IA no cubren lo que crees
Empecemos por lo básico y menos comprobado: casi ningún plan de entrada lleva SLA. El compromiso de disponibilidad vive en el contrato enterprise, y el resto de clientes opera con el mejor esfuerzo del proveedor y un foro. No es una sospecha: está escrito en sus propias páginas.
En OpenAI, el 99,9% de disponibilidad y los compromisos de latencia van atados al Scale Tier, y su propia página lo dice sin rodeos: es una oferta disponible para clientes Enterprise, a la que se accede hablando con ventas. El pago por uso corriente no lleva ese compromiso. Además, el vehículo cambia con la generación de modelo: el Scale Tier aplica a modelos anteriores a GPT-5.6, y de ahí en adelante la conversación se traslada al Reserved Tier. Si tu contrato de nivel de servicio está atado a un producto que se jubila con el modelo, tu cobertura tiene fecha de caducidad aunque el papel no la lleve escrita.
El caso de n8n es todavía más nítido, porque pone precio a la frontera. Su plan Business cuesta 667 € al mes con facturación anual, y en su propia página de precios se lee que el Business es una opción de autoservicio y que el soporte dedicado solo está en Enterprise. Es decir: puedes estar pagando casi ochocientos euros al mes y tu canal de soporte oficial sigue siendo el foro de la comunidad. No es un abuso —está publicado y es coherente con su modelo—, pero es exactamente el tipo de detalle que nadie mira en la reunión de compra y que aparece el día que el flujo crítico se cae.
Un SLA mide que esté encendido, no que acierte
Aquí está el punto que más caro sale, porque es conceptual y no se arregla pagando más. Un acuerdo de nivel de servicio de IA mide disponibilidad y, con suerte, latencia. La página de Scale Tier de OpenAI, por ejemplo, publica compromisos de velocidad del tipo «99% por encima de 50 a 100 tokens por segundo», medidos sobre la latencia mediana en ventanas de cinco minutos. Es un compromiso serio y verificable. Y no dice nada sobre si la respuesta era correcta.
Llévalo al extremo para verlo claro: un modelo que responde disparates a toda velocidad y sin caerse cumple el 99,9% con matrícula de honor. El SLA está satisfecho; tu operación, rota. La calidad —que el agente clasifique bien, que no invente, que no responda una barbaridad a un cliente— no está en ningún contrato de infraestructura, porque no es un problema de infraestructura. Es tuyo. Y por eso el trabajo de fijar el umbral aceptable y medirlo con casos reales no se delega en el proveedor.
| Lo que crees que cubre el SLA | Lo que cubre de verdad | Quién responde |
|---|---|---|
| Que el sistema funcione | Que el servicio esté disponible | El proveedor, con créditos |
| Que responda rápido | A veces, y solo en planes altos | El proveedor, si lo firmaste |
| Que responda bien | Nada. La calidad no está en el SLA | Tú |
| Que siga existiendo el modelo | Nada. Eso va por la política de retirada | Tú, migrando |
| Que tu integración no se rompa | Nada. Los parámetros también se deprecan | Tú |
Las dos últimas filas son las que sorprenden, y merecen sección aparte.
El reloj que nadie mira: cuánto vive el modelo del que dependes
Tu sistema no depende de «la IA»: depende de un modelo concreto, con nombre y versión, que un día se retira. Anthropic lo documenta con una claridad que se agradece y que conviene leer como lo que es —un compromiso mínimo, no una promesa de permanencia—: avisa con al menos 60 días antes de retirar un modelo publicado a los clientes con despliegues activos.
Sesenta días suena a mucho hasta que lo miras en el calendario real. Su propio historial de retiradas lo enseña: Claude Opus 4.1 se marcó como obsoleto el 5 de junio de 2026 y se retiró el 5 de agosto de 2026. Claude Sonnet 4 y Opus 4 se anunciaron el 14 de abril de 2026 y se retiraron el 15 de junio. Dos meses, del aviso al apagado. En ese plazo tienes que enterarte, probar el sustituto contra tus casos reales, ver qué se degrada, ajustar los prompts que dependían del comportamiento del modelo viejo y desplegar. Si tu operación descubre el correo del aviso a los cuarenta días, no tienes dos meses: tienes tres semanas.
Y hay un matiz que rompe planificaciones enteras: la fecha depende de dónde compres. La documentación de Anthropic señala que las plataformas operadas por partners —Amazon Bedrock y Google Cloud— fijan sus propios calendarios de retirada, así que el mismo modelo puede tener estados y fechas distintos según por dónde lo consumas. Si tu contrato de nube y tu contrato de modelo son distintos, tienes dos relojes y ninguno te avisa del otro.
La versión fina del problema no es siquiera el modelo: son los parámetros. Anthropic documenta que «temperature», «top_p» y «top_k» están obsoletos a partir de Claude Opus 4.7 y devuelven un error 400 si los pones a un valor distinto del predeterminado. Traducido: una línea de código que llevaba dos años funcionando pasa a romper la llamada. Eso no es una caída del servicio —el SLA sigue impoluto— pero tu agente ha dejado de trabajar igual.
Las cinco preguntas que sí hay que hacer antes de firmar
No hace falta un departamento legal para blindarse. Hacen falta cinco preguntas, por escrito, y guardar las respuestas:
- ¿El SLA aplica a mi plan? Y si no, cuánto cuesta el plan que sí lo lleva. Muchas veces la respuesta convierte una compra barata en una decisión distinta.
- ¿Qué mide exactamente y cómo se reclama? Disponibilidad mensual, latencia, ambas. Y sobre todo: ¿los créditos son automáticos o tengo que reclamarlos yo con evidencia y dentro de una ventana? Si es lo segundo —y suele serlo—, alguien de tu equipo tiene que estar monitorizando para poder reclamar.
- ¿Cuál es el canal de soporte real y su tiempo de respuesta? Foro, correo o persona con nombre. Un tiempo de respuesta comprometido por escrito vale más que un logo de «soporte 24/7» en la web.
- ¿Cuál es la política de retirada de modelos y cuánto aviso dan? Y con la respuesta en la mano: ¿mi equipo tiene capacidad de migrar y revalidar en ese plazo, con mis casos reales?
- ¿Qué pasa con mis datos si me voy? Formato de salida, plazo de borrado y si el proveedor entrena con lo que le mandas. Es la pregunta que más incomoda y la que más rápido revela con quién estás tratando.
Lo que ningún SLA te va a dar: el turno de guardia
Aunque firmes el mejor contrato del mercado, queda un hueco que ningún proveedor cubre y que es el que de verdad duele. Cuando tu agente deja de funcionar, lo normal no es que el proveedor se haya caído: es que una API de al lado ha cambiado un campo, que el volumen se ha triplicado, que alguien tocó un prompt o que el caso raro por fin apareció. Ahí no hay a quién llamar. La respuesta es tuya.
Eso significa cuatro cosas nada glamurosas, que son exactamente el trabajo de operar IA: alguien que vigile y se entere antes que el cliente, alguien de guardia con permiso para parar el sistema, un procedimiento escrito de qué se hace cuando falla —el mantenimiento de las automatizaciones no es opcional, es la mitad del proyecto— y un marco de control que decida quién puede desactivar qué, que es de lo que va la gobernanza y el control de la automatización. Si esas cuatro piezas no tienen dueño, tu SLA es un papel bonito.
Nuestra posición es sencilla y poco comercial: el SLA del proveedor cubre su parte, y su parte es la más pequeña. La grande —que el sistema haga bien el trabajo, que alguien se entere cuando deja de hacerlo y que el negocio no se pare mientras se arregla— es una función operativa continua que hay que montar. Es justo lo que hacemos con la gestión de incidencias de agentes de IA: turno, procedimiento, contención y postmortem, para que la caída sea un incidente gestionado y no una mañana perdida.
La conclusión, sin adorno
Un SLA es una transferencia de riesgo muy parcial y muy bien delimitada: el proveedor te devuelve unos créditos si su servicio no estuvo disponible. No te devuelve el cliente que se fue, ni el cierre que se retrasó, ni las tres semanas que te comió migrar de modelo con prisas. Léelo entendiendo eso y firmarás mejor. Léelo esperando que te proteja de todo y te llevarás la sorpresa un martes por la mañana.
Los demás eligen proveedor por la demo y descubren el soporte cuando ya no hay marcha atrás. Tú puedes hacer cinco preguntas antes de firmar y montar el turno de guardia que ningún contrato incluye. No es glamuroso. Es lo que hace que el sistema siga funcionando el martes.