SLA en contratos SaaS: disponibilidad, tiempo de respuesta, RTO, RPO y créditos de servicio

Por Mallbutiken · Información verificada el 30 de septiembre de 2026 · Aproximadamente 8 minutos de lectura

Un SLA hace que el nivel de servicio del proveedor SaaS sea medible. Debe definir qué significa la disponibilidad, cómo se calcula, cómo se priorizan los incidentes, qué tiempos de respuesta se aplican, qué objetivos de recuperación son relevantes y qué recibe el cliente si no se alcanza el nivel de servicio.

Respuesta corta: Evite formulaciones como "alta disponibilidad" o "soporte rápido". En su lugar, escriba niveles medibles, excepciones claras, fuentes de datos para la medición, clases de incidentes, escalado y consecuencias en caso de desviación.

¿Qué es un SLA en un contrato SaaS?

SLA significa Service Level Agreement (Acuerdo de Nivel de Servicio) y suele ser un anexo al contrato principal. El contrato principal describe la relación comercial, mientras que el SLA precisa los niveles de calidad medibles del servicio continuo.

Un buen SLA debe poder utilizarse tanto durante el funcionamiento normal como cuando algo sale mal. Si las partes solo comienzan a discutir qué significa "interrupción crítica" o "99,9 por ciento de disponibilidad" durante un incidente, el contrato es demasiado vago.

Consulte también la guía principal sobre lo que debe contener un contrato SaaS.

Disponibilidad: el porcentaje es solo el principio

Un nivel de disponibilidad, por ejemplo 99,9 por ciento, dice poco sin reglas de medición. Por lo tanto, especifique:

  • qué servicio o componentes están cubiertos,
  • periodo de medición, por ejemplo, mes natural,
  • qué fuente de datos se utiliza,
  • cuándo comienza y termina el tiempo de inactividad,
  • si se excluye el mantenimiento programado,
  • cómo se tratan los errores causados por el cliente o la fuerza mayor,
  • si la degradación del rendimiento puede considerarse falta de disponibilidad.

La diferencia entre 99,9 y 99,99 por ciento puede ser comercialmente significativa. El requisito debe basarse, por tanto, en la importancia crítica del servicio para la empresa y en lo que la arquitectura técnica del proveedor puede ofrecer realmente.

Punto de medición Pregunta a responder
Disponibilidad ¿Qué nivel porcentual, periodo y componente se aplican?
P1/P2/P3 ¿Cómo se definen los incidentes críticos, altos y normales?
Tiempo de respuesta ¿Cuándo debe haber iniciado el proveedor una gestión cualificada?
Recuperación ¿Existen objetivos para la recuperación del servicio y los datos?
Comunicación ¿Con qué frecuencia debe recibir el cliente actualizaciones de estado?
Penalización ¿Cuándo se aplican créditos de servicio u otros derechos?

Clases de incidentes y tiempo de respuesta

La clasificación de incidentes debe basarse en el impacto, no solo en el tipo de error técnico. Un error puede ser técnicamente limitado pero crítico para el negocio si, por ejemplo, bloquea pagos o el acceso a un proceso central.

Para cada nivel de prioridad, el SLA puede especificar el tiempo de respuesta inicial, el tiempo objetivo para una solución alternativa o recuperación, la frecuencia de actualización y el nivel de escalado. Tenga cuidado con la diferencia entre tiempo de respuesta y tiempo de resolución. Una respuesta en 30 minutos no significa automáticamente que el error deba resolverse en 30 minutos.

Las ventanas de soporte deben coincidir con la operación

Un tiempo de respuesta P1 de 30 minutos es inútil para una empresa que opera las 24 horas si el soporte del proveedor solo está abierto los días laborables de 09:00 a 17:00. Especifique qué niveles se aplican fuera del horario de soporte habitual y cómo se reportan los incidentes críticos.

RTO y RPO: dos objetivos de recuperación diferentes

El RTO se utiliza como objetivo de la rapidez con la que un servicio o proceso debe poder restaurarse tras una interrupción. El RPO se utiliza como objetivo de la pérdida de datos hacia atrás en el tiempo que puede tolerarse en una situación de recuperación.

No deben elegirse de forma aislada en el contrato de TI. Un BIA (Análisis de impacto empresarial) puede mostrar cuánto tiempo puede soportar realmente la empresa una interrupción y qué pérdida de datos es aceptable. Lea la guía sobre el Business Impact Analysis y el ejemplo práctico de BIA.

Compruebe también qué entiende el proveedor por sus valores. ¿Es el RTO un objetivo, una garantía o solo un principio de diseño interno? ¿Se aplica el RPO a todos los tipos de datos? ¿Con qué frecuencia se prueba la recuperación?

Créditos de servicio: ¿compensación o única penalización?

Los créditos de servicio pueden crear un incentivo económico automático cuando no se alcanza el nivel de servicio. Una escala progresiva puede, por ejemplo, otorgar más crédito cuanto más tiempo se sitúe el servicio por debajo del nivel objetivo.

Sin embargo, compruebe si el contrato establece que el crédito de servicio es la única penalización del cliente. En casos de deficiencias graves o recurrentes, el cliente puede necesitar otros derechos, como el derecho a un plan de acción, un escalado especial o la rescisión. Coordinar el SLA con las limitaciones de responsabilidad y las normas de rescisión del contrato principal.

Mantenimiento programado y otras excepciones

Normalmente, el proveedor necesita poder realizar el mantenimiento del servicio, pero una excepción demasiado amplia puede hacer que el objetivo de disponibilidad sea engañoso. Regule con cuánta antelación se debe notificar el mantenimiento, qué ventanas de tiempo se pueden utilizar y si el mantenimiento de seguridad urgente se gestiona de forma diferente.

Tenga cuidado también con las excepciones para servicios de terceros. Si el propio proveedor ha elegido un proveedor de nube o infraestructura crítico, el contrato debe aclarar cómo afecta esa dependencia al SLA y a la responsabilidad.

Lista de verificación para un SLA útil

  • ¿Está claramente definido el servicio medido?
  • ¿Existe una fórmula inequívoca para la disponibilidad?
  • ¿Está delimitado el mantenimiento programado?
  • ¿Están los niveles de incidente vinculados al impacto en el negocio?
  • ¿Distingue el contrato entre respuesta, solución alternativa y resolución?
  • ¿Funciona el soporte durante sus horas críticas de operación?
  • ¿Están el RTO y el RPO vinculados a las necesidades reales de continuidad?
  • ¿Existe el requisito de actualizar el estado durante incidentes P1?
  • ¿Son claros los créditos de servicio y otras penalizaciones?
  • ¿Existe derecho a actuar en caso de incumplimientos repetidos del SLA?
Contrato SaaS con SLA GDPR seguridad y salida

¿Necesitan contrato principal y SLA en la misma estructura?

El contrato SaaS de Mallbutiken contiene un contrato principal y seis anexos sobre, entre otros temas, especificación de servicios, SLA, APD/GDPR, seguridad, salida y precio. Word y PDF. Precio en tienda: 149 SEK.

Ver el contrato SaaS

Preguntas frecuentes

¿Es el 99,9 por ciento siempre un buen SLA?

No. El nivel adecuado depende de la criticidad del servicio, el método de medición, las excepciones y el coste de una mayor redundancia. El porcentaje debe contextualizarse.

¿Es el RTO lo mismo que la disponibilidad SLA?

No. La disponibilidad mide normalmente la operación durante un periodo. El RTO trata sobre el objetivo de recuperación tras una interrupción.

¿Debería ser el crédito de servicio la única penalización?

Es una cuestión contractual, pero el cliente debe evaluar conscientemente si solo el crédito es suficiente ante deficiencias graves o repetidas.

Regresar al blog