1) Alcance del servicio y modelo de entrega

Empieza por la definición del “qué” y el “cómo”. En SaaS, el alcance suele desbordar el simple acceso al sistema e incluir soporte, funcionalidades opcionales, integraciones, ventanas de mantenimiento y límites operativos. Recomienda describir:

  • Funcionalidades incluidas y criterio para “disponibilidad” de features.
  • Niveles de servicio (p. ej., disponibilidad mensual) con umbrales medibles.
  • Gestión de incidencias: tiempos de respuesta, categorización y escalados.
  • Dependencias del cliente (conectores, requisitos de infraestructura, datos de entrada).

2) SLA, mantenimiento y ventanas de cambio

Una cláusula de SLA correcta no es la que “promete”, sino la que mide. Revisa si el contrato distingue entre:

  • Disponibilidad y su método de cálculo.
  • Exclusiones (fuerza mayor, fallos por terceros, incumplimiento del cliente).
  • Descuentos o créditos cuando no se cumple el SLA, y su tope.
  • Mantenimiento: programado vs. no programado, preaviso y duración máxima.

En cambios de producto, evita la ambigüedad. Si el proveedor puede modificar funcionalidades, pide un esquema de notificación, transición y impacto sobre integraciones y flujos del cliente.

3) Datos del cliente: tratamiento, devolución y retención

La cláusula de datos suele combinar tres ejes: titularidad, licencias y tratamiento. En SaaS empresarial, el foco está en:

  • Titularidad de los datos: el cliente mantiene la propiedad.
  • Finalidad: el proveedor trata los datos para prestar el servicio.
  • Retención y tiempos de borrado al finalizar el contrato.
  • Portabilidad: formato de exportación, granularidad y condiciones para recuperación.

Si el contrato remite a anexos (DPA, políticas de seguridad, anexos técnicos), asegúrate de que sean vinculantes o, como mínimo, incorporados con claridad. En caso contrario, el alcance del compromiso se diluye.

4) Propiedad intelectual y licencias de uso

Una buena redacción evita confundir la licencia de uso con la cesión. Analiza si el contrato otorga:

  • Una licencia limitada para usar el software durante la vigencia.
  • Derechos sobre mejoras o “works” del cliente (si aplica).
  • Acceso y uso de materiales de terceros (open source, librerías, APIs).

Para el proveedor, la clave es proteger su plataforma. Para el usuario, la clave es que el uso sea estable, con reglas claras frente a restricciones de acceso y reventa interna.

5) Garantías, soporte y “funciona o se corrige”

Las garantías deben aterrizarse en expectativas operativas. Revisa:

  • Garantía de conformidad: descripciones, rendimiento esperado y límites.
  • Soporte: canales, horarios, tiempos de solución por severidad.
  • Procedimientos de aceptación si hay entregables configurables (p. ej., plantillas, flujos, migraciones).

Evita cláusulas que convierten la garantía en una promesa genérica sin mecanismo correctivo. El remedio debe estar definido: workaround, corrección, actualización o crédito aplicable.

6) Responsabilidad: limitaciones, indemnidades y daños

En disputa, la parte que define qué daños se pagan y cuáles no suele marcar el desenlace. Busca un equilibrio entre:

  • Tope de responsabilidad (múltiplos de cuotas pagadas, exclusiones y límites por categoría).
  • Daños excluidos (lucro cesante, pérdida de datos, daños indirectos) y si existe restauración razonable.
  • Indemnidades por reclamaciones de terceros (PI, infracciones, incumplimiento de normativas específicas si se asume por el proveedor).
  • Obligación de mitigación y cooperación en la defensa.

Un enfoque práctico: revisa el “mapa de riesgos” desde el tipo de fallo. Un incidente de seguridad no suele tratarse igual que un fallo de integración o una indisponibilidad por mantenimiento.

7) Terminación, transición y salida ordenada

La mejor negociación termina cuando el usuario puede salir sin quedar atrapado. Asegura:

  • Terminación por incumplimiento con plazos de subsanación.
  • Terminación por razones de cumplimiento (p. ej., cambios regulatorios que vuelven inviable el servicio en condiciones).
  • Asistencia de transición y acceso a datos durante un periodo razonable.
  • Condiciones de continuidad para evitar interrupciones bruscas.

Checklist final antes de firmar

Si estás negociando un contrato SaaS, confirma que el documento y sus anexos responden de forma concreta a:

  1. Qué funcionalidades están incluidas y cómo se mide la disponibilidad.
  2. Cómo se calculan SLA, cómo se gestionan cambios y mantenimiento.
  3. Qué pasa con los datos del cliente al finalizar, con formatos y plazos.
  4. Qué se garantiza, qué no, y cuál es el remedio ante el incumplimiento.
  5. Cómo se limita la responsabilidad y qué indemnidades aplican.
  6. Cómo es la salida: transición, exportación y tiempos de borrado.

Una mirada equilibrada proveedor vs. usuario

Para el proveedor, el contrato debe limitar riesgos de forma razonable, proteger su plataforma y evitar compromisos imposibles. Para el usuario, el contrato debe traducir el servicio en obligaciones verificables, especialmente alrededor de disponibilidad, datos y cambios.

El resultado “bueno” rara vez es idéntico para ambas partes. Lo decisivo es que la redacción sea operativa. Si una cláusula no se puede medir, rara vez se puede exigir.