Qué es un SLA y qué debes exigir a tu proveedor de software
Un SLA (acuerdo de nivel de servicio, del inglés service level agreement) es la parte del contrato en la que tu proveedor de software se compromete por escrito a unos mínimos medibles: cuánto tiempo estará disponible el servicio, en cuánto tiempo atenderá y resolverá cada tipo de incidencia y qué te compensa si no cumple. Sin SLA, «te damos soporte» puede significar cualquier cosa; con un SLA bien redactado sabes qué esperar y qué reclamar. En esta guía repasamos, cláusula a cláusula, qué pedir cuando contratas un SaaS, un mantenimiento o una aplicación a medida.
Qué es un SLA y en qué se diferencia del contrato de servicio
El contrato define qué te presta el proveedor: el software, el alojamiento, el soporte, las actualizaciones. El SLA define cómo de bien tiene que prestarlo, con indicadores que se pueden medir y comprobar. Suele ir como anexo y se negocia aparte, porque es donde se juega la calidad del servicio.
Un ejemplo sencillo: tu tienda online depende de un programa de gestión de pedidos en la nube. El contrato dice que el proveedor te da acceso al programa y soporte técnico. El SLA dice qué porcentaje del mes estará disponible, en cuánto tiempo te contestan si deja de funcionar, a qué horas, y qué parte de la cuota te descuentan si fallan.
Conviene no mezclar tres ideas:
- SLA: el compromiso con el cliente, con consecuencias si se incumple.
- Objetivo interno (a veces llamado SLO): la meta que el proveedor se pone a sí mismo, normalmente más exigente que el SLA para tener margen.
- Indicador: lo que se mide de verdad, por ejemplo, el porcentaje de comprobaciones en las que la aplicación respondió correctamente.
No hay una ley que regule los SLA como tal: son un pacto entre las partes. Por eso lo que no está escrito no existe, y lo que está escrito de forma vaga tampoco te protege.
Disponibilidad: qué significa el porcentaje y cómo se mide
La cláusula estrella es la disponibilidad, expresada como el porcentaje del tiempo en que el servicio funciona. Lo importante no es solo el número, sino lo que lo rodea. Haz la cuenta antes de firmar: si el contrato promete un 99,9 % mensual, el margen de caída es el 0,1 % del mes, que en un mes de 30 días (720 horas) son algo más de 43 minutos. Con un 99 %, el margen sube a más de siete horas. Dos cifras que parecen casi iguales esconden una diferencia enorme para tu negocio.
Además del porcentaje, pregunta:
- Sobre qué periodo se calcula. No es lo mismo al mes que al año: un porcentaje anual permite concentrar muchas horas de caída en un mal día sin incumplir.
- Qué cuenta como caída. ¿Solo si no carga nada, o también si va tan lento que no se puede trabajar o si falla una función clave, como el cobro?
- Qué se excluye. Las paradas programadas, los fallos de terceros o la «fuerza mayor» suelen quedar fuera. Una lista de exclusiones demasiado amplia vacía el compromiso.
- Quién lo mide. Pide una página de estado o un informe mensual, y valora tener tu propia monitorización externa para contrastarlo.
Tiempos de respuesta y de resolución según la gravedad
El segundo bloque son los tiempos de atención, y aquí hay una trampa clásica. El tiempo de respuesta es lo que tardan en contestarte y ponerse con el problema; el tiempo de resolución es lo que tardan en que todo vuelva a funcionar, aunque sea con una solución provisional. Un SLA que solo garantiza respuesta te asegura un acuse de recibo, no una solución.
Lo razonable es clasificar las incidencias por gravedad y fijar tiempos distintos para cada nivel. No hay cifras universales: dependen de cuánto te cuesta cada hora de parada. Esta tabla te sirve de punto de partida para negociar:
| Gravedad | Qué significa | Ejemplo | Qué pedir |
|---|---|---|---|
| Crítica | El servicio no funciona o los datos están en riesgo | La tienda no permite comprar | Atención también fuera de horario si vendes fuera de horario, y el plazo de resolución más corto del contrato |
| Alta | Falla una función importante y no hay alternativa | No se generan las facturas | Respuesta el mismo día laborable y una solución provisional rápida |
| Media | Algo falla, pero se puede seguir trabajando | Un informe sale incompleto | Corrección planificada en un plazo cerrado |
| Baja | Dudas, detalles estéticos o mejoras | Un texto mal alineado | Atención en horario laboral e inclusión en la siguiente versión |
Pide también que el contrato diga quién decide la gravedad (mejor una definición objetiva que el criterio del proveedor), por qué canales puedes avisar, en qué horario corre el reloj y cómo se escala una incidencia que no avanza.
Penalizaciones: qué pasa si el proveedor no cumple
Un SLA sin consecuencias es una declaración de intenciones. Lo habitual es que el incumplimiento genere créditos de servicio: un descuento en la cuota del periodo afectado que crece cuanto mayor es el incumplimiento. Revisa con lupa estos detalles:
- Si el crédito es automático o hay que reclamarlo, y en qué plazo. Muchos contratos exigen pedirlo por escrito en pocos días; si se te pasa, lo pierdes.
- El tope. Casi siempre hay un máximo de descuento por periodo. Comprueba que no sea simbólico frente a lo que te cuesta una parada.
- Si es la única compensación. Algunas cláusulas dicen que el crédito es el «único recurso» del cliente. Negócialo o, al menos, sé consciente de que renuncias a reclamar daños mayores.
- El derecho a salir. Pide poder resolver el contrato sin penalización si el proveedor incumple de forma repetida, por ejemplo, varios meses dentro de un mismo año.
Mantenimiento, copias de seguridad y avisos de seguridad
El tercer bloque protege tus datos y tu operación diaria. Pide que queden por escrito:
- Las ventanas de mantenimiento: cuándo se hacen las paradas programadas (idealmente en horas de poca actividad para ti), con cuánta antelación te avisan y cuántas puede haber al mes.
- Las copias de seguridad: cada cuánto se hacen, cuánto tiempo se guardan, dónde (mejor en una ubicación distinta del servidor principal) y, sobre todo, cada cuánto se comprueba que se pueden restaurar. Una copia que nunca se ha restaurado es una suposición.
- Cuántos datos puedes llegar a perder y en cuánto tiempo vuelves a funcionar si ocurre un desastre. Son dos compromisos distintos y conviene fijar ambos; lo explicamos en esta guía sobre recuperación ante desastres y alta disponibilidad.
- El aviso de incidentes de seguridad. Si el proveedor trata datos personales por tu cuenta, el Reglamento General de Protección de Datos le obliga a avisarte sin dilación indebida de cualquier brecha (artículo 33.2), y a ti te obliga a notificarla a la autoridad de control sin dilación indebida y, si es posible, en un máximo de 72 horas desde que tengas constancia, salvo que sea improbable que suponga un riesgo (artículo 33.1). Si el proveedor tarda, el problema es tuyo: fija en el contrato un plazo concreto de aviso y qué información mínima debe darte.
La salida: cómo recuperar tus datos si cambias de proveedor
Es la cláusula que nadie lee hasta que la necesita. Todo contrato de software debería responder a una pregunta: si mañana lo dejamos, ¿qué me llevo, en qué formato y en cuánto tiempo? Dos normas te respaldan:
- Si el proveedor trata datos personales por tu cuenta, el RGPD exige que el contrato recoja que, al terminar el servicio y a tu elección, los suprimirá o te los devolverá, y borrará las copias salvo que una ley obligue a conservarlas (artículo 28.3.g).
- Si contratas un servicio en la nube o un SaaS de catálogo, el Reglamento de Datos de la UE, aplicable desde el 12 de septiembre de 2025, exige que el contrato recoja por escrito cómo se cambia de proveedor: un preaviso máximo de dos meses para iniciar el cambio, un periodo transitorio de hasta treinta días naturales con asistencia del proveedor, al menos treinta días más para extraer los datos y el borrado posterior (artículo 25).
Más allá de la norma, concreta en el contrato el formato de exportación (estándar y legible por otras herramientas, no un volcado que solo entiende el proveedor), qué asistencia te presta durante la migración y si tiene coste. Si el software es a medida, deja claro quién es el dueño del código y cómo se entrega: repositorio, documentación y credenciales. Lo contamos en cómo no quedar atrapado con tu proveedor web.
Resumen: lo que debes revisar antes de firmar
Un buen SLA no es el que promete las cifras más altas, sino el que deja claro qué se mide, cómo se mide y qué pasa si falla. Antes de firmar, repasa esta lista:
- Disponibilidad con periodo de cálculo, definición de caída y exclusiones acotadas.
- Niveles de gravedad objetivos, con tiempos de respuesta y de resolución para cada uno.
- Créditos de servicio fáciles de cobrar y derecho a salir si el incumplimiento se repite.
- Mantenimientos avisados con antelación y en horas que no te perjudiquen.
- Copias de seguridad con pruebas de restauración periódicas.
- Un plazo concreto para avisarte de cualquier incidente de seguridad.
- Un plan de salida: formato de exportación, plazos y propiedad del código.
Si vas a contratar un SaaS, renovar un mantenimiento o encargar una aplicación a medida y quieres revisar el SLA con alguien que conoce los dos lados de la mesa, cuéntanos tu caso y te ayudamos a convertir la letra pequeña en compromisos que se puedan medir.