Checklist para revisar un contrato de software o SaaS antes de firmar

1. ¿Es licencia de uso, suscripción SaaS o desarrollo a la medida?

El primer punto define casi todo lo que viene después. Los tres modelos son legales, pero se rigen por reglas distintas y tienen impacto tributario y contractual muy distinto.

• Licencia de uso: el proveedor te autoriza a instalar y usar un software que ya existe. Es propiedad del proveedor y tú pagas por el derecho de uso. Suele venir en formato instalado en tus servidores (on-premise) o híbrido.
• Suscripción SaaS: no descargas nada. Accedes al servicio a través de internet mientras esté vigente la suscripción. Cuando dejas de pagar, pierdes el acceso. Es la modalidad más común hoy.
• Desarrollo a la medida: el proveedor construye para ti un software desde cero o adapta uno existente a tu operación. La propiedad intelectual del desarrollo debería quedar en cabeza de quien pagó por él, pero eso depende de lo que diga el contrato.

Antes de revisar cualquier otra cláusula, define en qué modalidad está el contrato. El resto de este checklist se lee distinto según el caso.

2. ¿Quién es dueño de la propiedad intelectual?

Aquí se separan tres capas y el contrato debe ser claro con cada una:

• Software base: casi siempre queda en cabeza del proveedor, incluso en desarrollos a la medida. Si te lo entregan como obra por encargo y tú eres dueño del código, revísalo bien porque no es lo típico.
• Desarrollo a la medida: las funcionalidades específicas que se construyen para ti deberían quedar en cabeza tuya si tú pagaste por ellas. Ojo con cláusulas que dicen que el proveedor podrá reutilizar el desarrollo para otros clientes. Eso convierte tu inversión en un producto del proveedor.
• Datos generados por el uso: los datos que tú cargas, procesas o generas dentro del SaaS son tuyos. Debe quedar expresamente escrito. Ojo con cláusulas que le dan al proveedor el derecho a usar tus datos de forma agregada y anonimizada para mejorar sus modelos o entrenar IA.

Si el contrato no distingue estas tres capas, exige que se distingan antes de firmar. La confusión hoy es un pleito futuro.

3. ¿Qué SLA compromete el proveedor y qué pasa si incumple?

El SLA (Service Level Agreement) es el nivel de servicio prometido. Para un SaaS empresarial revisa:

• Tiempo activo (uptime): 99% es bajo. 99.5% es el mínimo aceptable para operaciones críticas. 99.9% es lo típico en proveedores serios. 99.99% es nivel operador de telecomunicaciones y suele costar más.
• Exclusiones: la mayoría de los SLA excluyen mantenimientos programados, incidentes de terceros, fuerza mayor y actos del propio cliente. Revisa que las exclusiones sean razonables y no vacíen el compromiso.
• Penalidades: típicamente el proveedor devuelve un porcentaje del canon mensual proporcional al incumplimiento. Es un remedio limitado. Si el software es crítico para tu operación, negocia una penalidad mayor o el derecho a terminar el contrato tras N incidentes graves seguidos.
• Ventana de medición: un uptime del 99% anual permite hasta 3.6 días de caída sin sanción. Mensual permite unas 7 horas. La ventana importa.
• Cómo se reclama: algunos SLA exigen que el cliente presente el reclamo formal en un plazo corto. Si no lo haces, pierdes la compensación.

4. ¿Cómo se tratan los datos personales?

Cuando el SaaS procesa datos de tus clientes, empleados o proveedores, aplica la Ley 1581 de 2012 (Régimen General de Protección de Datos Personales). Tú, como el que decide qué se hace con esos datos, eres el responsable del tratamiento. El proveedor, que solo procesa los datos siguiendo tus instrucciones, es el encargado del tratamiento. El contrato debe reflejar esto expresamente. Revisa:

• Que se identifique con claridad quién es responsable y quién es encargado.
• Finalidad del tratamiento, alcance, duración y tipo de datos procesados.
• Medidas técnicas y organizativas de seguridad exigidas al encargado.
• Obligación de notificar incidentes de seguridad (data breach) en un plazo definido. 72 horas es el estándar de referencia.
• Prohibición de que el encargado use los datos para finalidades distintas a las contratadas.
• Derecho de auditoría del responsable sobre las medidas de seguridad.
• Devolución o eliminación de los datos al terminar la relación.
• Régimen de subcontratación: si el proveedor va a compartir los datos con subcontratistas (por ejemplo un proveedor de almacenamiento), debe declararlos.

Si el SaaS procesa datos financieros (calificación crediticia, comportamiento de pago) también aplica la Ley 1266 de 2008 (habeas data financiero), con reglas más estrictas.

5. ¿Hay transferencia internacional de datos?

Si el proveedor almacena los datos fuera de Colombia (Estados Unidos, Europa, Brasil), hay transferencia internacional y aplican reglas específicas. La Circular Externa 002 de 2023 de la Superintendencia de Industria y Comercio consolidó el régimen:

• Colombia mantiene un listado de países con nivel adecuado de protección. La transferencia a esos países no requiere autorización adicional del titular.
• A países que no están en el listado, la transferencia se puede hacer con cláusulas contractuales tipo aprobadas por la SIC, con reglas corporativas vinculantes o con autorización expresa e informada del titular.
• Estados Unidos no está declarado como país con nivel adecuado, así que un SaaS con servidores en AWS US East o Google Cloud us-central requiere una de las tres vías anteriores.
• El contrato debe declarar dónde se almacenan los datos y qué mecanismo se usa para legitimar la transferencia.

Revisa en el DPA la sección de ubicación de procesamiento o subprocesadores y confirma que existan las cláusulas contractuales tipo. Si el contrato guarda silencio, el riesgo es tuyo, no del proveedor.

6. ¿Hay portabilidad al terminar el contrato?

Un SaaS bien contratado permite salir con los datos en un formato usable. Sin portabilidad, dejar al proveedor implica perder años de información operativa. Revisa:

• Formato de exportación: JSON, CSV, XML u otro estándar. Nada de que el proveedor podrá entregar los datos en el formato que técnicamente pueda.
• Ventana de descarga: cuánto tiempo tienes después de terminar el contrato para bajar los datos. Lo razonable son 30 a 60 días. Menos de 30 días es una señal de alarma.
• Costo de la exportación: algunos proveedores cobran por el volcado final. Revisa si es gratis o hay un rubro específico.
• Borrado seguro tras exit: después de la ventana de descarga, el proveedor debe borrar los datos y certificarlo por escrito. Esto conecta con la obligación de la Ley 1581.
• Ayuda a la migración: algunos proveedores incluyen horas de soporte a la migración a otro sistema. Es negociable.

7. ¿El proveedor se reserva el derecho a modificar los términos?

Muchos contratos de SaaS tienen una cláusula del estilo el proveedor podrá modificar estos términos con aviso de 30 días. Es una carta blanca que rara vez se lee. Revisa:

• Si la cláusula existe, negocia excepciones: precio, propiedad intelectual, tratamiento de datos y jurisdicción no deberían modificarse unilateralmente. Solo lo operativo debería quedar bajo esa vía.
• Si no puedes eliminarla, pacta un derecho de terminación sin penalidad ante una modificación que te afecte. Así el aviso de 30 días se equilibra: el proveedor cambia si quiere, pero tú puedes salir si no aceptas.
• Ojo con las modificaciones efectivas de inmediato por razones legales o de seguridad. Suelen ser razonables, pero no deberían servir de comodín para cambiar precios.

Un contrato con modificaciones unilaterales sin límite es en la práctica un contrato de adhesión. En Colombia eso no lo invalida, pero sí abre defensa por abuso del derecho si el proveedor lo usa mal.

8. ¿Cómo se calcula el precio y cuándo se ajusta?

El precio en un SaaS suele estructurarse por licencias activas, por consumo (llamadas a API, almacenamiento, transacciones) o por un tarifario mixto. Revisa:

• Base de facturación: por usuario nombrado, usuario concurrente o uso real. La diferencia puede duplicar la factura mensual.
• Ajuste anual: IPC colombiano, IPC del país sede del proveedor, porcentaje fijo o fórmula que decida el proveedor. Un ajuste a discreción del proveedor es una bomba de tiempo.
• Verdaderos true up: algunos contratos permiten al proveedor revisar el uso real vs. el uso contratado y facturar la diferencia. Es legítimo, pero debe tener reglas claras (frecuencia, notificación previa, derecho a discutir la medición).
• Moneda: dólares vs. pesos colombianos. Un contrato en dólares transfiere el riesgo cambiario al cliente. Si es un compromiso a 12 meses o más, el impacto es real.
• Descuentos por volumen: casi todos los proveedores tienen descuentos escalonados que no ofrecen si no los pides.

9. ¿Cómo se termina el contrato por tu parte?

La salida es donde muchos contratos se vuelven ásperos. Revisa:

• Terminación por conveniencia: si el cliente puede terminar sin causa dando aviso, con qué antelación y con qué penalidad.
• Compromiso mínimo: contratos anuales o multianuales suelen tener penalidad por salida anticipada equivalente al canon restante. Es discutible.
• Terminación por justa causa: debe listar los eventos que la activan sin cargo (incumplimiento del SLA por varios períodos, incidente grave de datos, incumplimiento del régimen de datos personales, cambio unilateral no aceptado).
• Preaviso al proveedor: revisa que el aviso sea posible por correo electrónico, no solo por correo certificado internacional. A veces se exige eso para complicar la salida.
• Auto-renovación: las renovaciones automáticas son válidas pero riesgosas. Debe haber una ventana clara para no renovar (por ejemplo 30 días antes del vencimiento) y esa ventana debe cumplirse. Pon un recordatorio en calendario.

10. ¿Cuál es el límite de responsabilidad?

Casi todos los contratos de SaaS limitan la responsabilidad del proveedor a un múltiplo del canon anual (típicamente 12 meses de servicio) y excluyen daños indirectos, lucro cesante y pérdida de datos. Revisa:

• Monto del cap: 12 meses de servicio es lo estándar. Para software crítico intenta subir a 24 o 36 meses. Es negociable en cuentas grandes.
• Exclusiones al cap: el cap no debería aplicar a incumplimientos por incidentes de datos personales, violaciones de propiedad intelectual del proveedor, incumplimiento del deber de confidencialidad o dolo y culpa grave. Estas exclusiones al cap son el punto que más se negocia.
• Daños indirectos y lucro cesante: la exclusión es estándar, pero si tu negocio depende del sistema para operar puede tener sentido negociar excepciones específicas.
• Cross-indemnity: el proveedor típicamente indemniza al cliente por reclamos de propiedad intelectual de terceros contra el software. Revisa que exista y con qué alcance.

11. ¿Hay derecho de auditoría y cláusula de true-up?

En software con modelo por usuario o por instalación, el proveedor suele reservarse el derecho de auditar tu uso real. Revisa:

• Frecuencia: una vez al año es razonable. Más frecuente es agresivo.
• Notificación previa: 15 a 30 días antes de la auditoría es lo razonable.
• Costo: si el resultado revela uso dentro de lo contratado, la auditoría la asume el proveedor. Si revela exceso, tú asumes el costo más el ajuste.
• True-up discutible: algunos contratos te obligan a firmar un ajuste al alza sin discusión. Discute que se pueda revisar la medición antes de aceptar el ajuste.
• Confidencialidad de los datos revisados: la auditoría implica acceso del proveedor a tu operación. Debe quedar bajo régimen de confidencialidad estricta.

12. ¿Qué pasa con el código fuente y la confidencialidad?

Dos capas de confidencialidad conviven en estos contratos:

• Código fuente del proveedor: debe quedar sujeto a confidencialidad estricta si tú lo conoces (por ejemplo en un desarrollo a la medida con acceso al repositorio). En SaaS puro esto no aplica.
• Tus datos operativos y comerciales: el proveedor tiene acceso a lo que corre por el sistema. Datos de clientes, precios, márgenes, contratos. Todo debe quedar bajo confidencialidad con vigencia post-terminación (mínimo cinco años).
• Escrow de código: en contratos de software crítico y de larga duración, se puede pactar que el proveedor deposite el código fuente en un tercero (escrow) que lo entrega al cliente si el proveedor quiebra o cierra la operación.

13. ¿Cuál es la ley aplicable y la jurisdicción?

Los proveedores globales suelen imponer Delaware, Irlanda o California como jurisdicción y ley aplicable. Para un cliente colombiano eso implica que un pleito potencial se litiga afuera, en otro idioma y con otros costos. Discute:

• Ley aplicable: ley colombiana es lo natural para un contrato con impacto operativo en Colombia. En proveedores grandes es negociable, sobre todo si el ticket lo justifica.
• Jurisdicción: juez colombiano o arbitraje en Bogotá. El arbitraje es más rápido pero implica costos altos, así que solo tiene sentido en contratos de valor significativo.
• Aplicación de la Ley 1581: aunque la ley aplicable del contrato sea otra, el tratamiento de datos personales de titulares en Colombia sigue rigiéndose por la ley colombiana. Eso no se puede pactar en contrario.
• Notificaciones: revisa por dónde se notifican los eventos contractuales. Debe ser un canal razonablemente accesible.

Cuándo firmar y cuándo renegociar

Un contrato de software o SaaS con estos 13 puntos claros suele ser un contrato razonable. Uno con cuatro o más puntos abiertos o desbalanceados es un contrato que conviene renegociar antes de firmar. Las señales de alarma más frecuentes son el DPA estándar que no distingue responsable de encargado, la ausencia de cláusulas contractuales tipo para transferencia internacional, la modificación unilateral sin excepciones y el cap de responsabilidad que incluye los incidentes de datos.

Klos analiza contratos de software y SaaS aplicando este checklist con criterio jurídico colombiano y cuantificación económica en pesos de cada hallazgo. Si quieres entender el detalle de cómo funciona el pipeline y qué revisa exactamente, tenemos una página dedicada al análisis de contratos con IA en Klos. Para casos específicos o pilotos empresariales, escríbenos a contacto@klosai.com.