SOW y MSA: qué contrato protege tu proyecto SaaS

MSA y SOW son dos mitades del mismo contrato de software. El acuerdo marco de servicios (MSA, master service agreement) fija los términos legales que rigen toda la relación: quién es dueño del código, quién responde cuando algo se rompe, cómo se trata la información confidencial, cómo termina el acuerdo. El enunciado de trabajo (SOW, statement of work) define un proyecto concreto dentro de esos términos: los entregables, los plazos, el precio, los criterios de aceptación. Firmas un MSA por proveedor, y luego adjuntas un SOW nuevo por cada proyecto que sigue.

Si eres fundador o CTO y estás por contratar un estudio, una agencia o un freelance para construir un SaaS, la estructura que firmas no es papeleo. Decide quién es dueño de lo que pagaste, y quién paga cuando un proyecto se alarga. Esta es una guía sobre cómo los dos documentos se reparten el trabajo, y qué debe revisar un comprador en cada uno antes de firmar. No es asesoría legal: para un contrato que mueve dinero real o propiedad intelectual real, que lo revise un abogado.

SOW y MSA: la versión de 30 segundos

Firma un MSA cuando esperas más de un proyecto con el mismo proveedor, o un proyecto que crees que vas a extender. Negocia los términos legales difíciles una sola vez, para no reabrirlos en cada proyecto. Firma un SOW por cada pieza de trabajo: es corto, específico, y el único documento que debe cambiar cuando cambia el alcance. El MSA es el marco. El SOW es el cuadro. Quien se salta el MSA y firma un único contrato todo en uno descubre el hueco la primera vez que añade un segundo proyecto, o la primera vez que algo sale mal.

Qué rige de verdad el MSA

En el MSA viven los términos que sobreviven al proyecto. Cinco cláusulas reciben en la práctica el escrutinio más duro: propiedad intelectual, limitación de responsabilidad, indemnización, terminación y seguridad de datos. Son las que conviene leer con atención antes de firmar (SMVRT Legal).

Propiedad intelectual. El MSA debe decir que el trabajo hecho para ti se te cede a ti, y debe decir cuándo surte efecto esa cesión. La propiedad puede consolidarse en la creación, en la entrega y aceptación, o en el pago (Icertis). Consolidarse en el pago es común y razonable, pero léelo: si disputas una factura, puede que no seas dueño del código hasta que se salde. El MSA también debe separar tu PI de la PI preexistente del proveedor y de cualquier componente de terceros o de código abierto, con una licencia de uso para todo lo que el proveedor reutiliza entre clientes.

Limitación de responsabilidad. Casi todos los MSA limitan la responsabilidad total de cada parte a los importes pagados en los doce meses anteriores (Icertis). Tres cosas deciden si ese tope te protege: el importe, la ventana a la que se refiere, y qué queda fuera. Las infracciones de PI, las de confidencialidad y la culpa grave suelen quedar excluidas del tope, así que la responsabilidad por ellas se queda sin límite. Un tope de un mes de honorarios en un proyecto de un año no es una protección real.

Indemnización. La indemnización decide quién paga cuando demanda un tercero. Las palabras pesan más que el título: una cláusula que te hace responsable de reclamaciones "relacionadas con" un trabajo es mucho más amplia que una limitada a reclamaciones "derivadas de" tus propios actos (SMVRT Legal). La indemnización mutua, donde el proveedor cubre las reclamaciones de terceros que nacen de su propia infracción de PI, es la base justa.

Qué define de verdad el SOW

El SOW es el documento en el que viven tus equipos de producto e ingeniería. Nombra los entregables, los divide en hitos, fija los plazos, fija el precio o la tarifa, y define la aceptación: cómo decides que el trabajo está terminado. Un SOW vago es donde mueren los presupuestos. Los contratos que no trazan una línea clara entre el alcance inicial y las añadiduras posteriores invitan a discutir si una función siempre estuvo prevista o es trabajo nuevo (Genie AI).

La cláusula que mantiene honesto a un SOW es el proceso de orden de cambio. El alcance se moverá. La única pregunta es si moverlo es una decisión por escrito o una disputa seis semanas después. Las encuestas del sector sitúan las pérdidas por scope creep entre el 15 y el 27 por ciento del presupuesto del proyecto (Digital Applied). Una cláusula de orden de cambio que funciona dice quién puede aprobar una modificación, exige una estimación escrita del impacto en coste y plazo antes de empezar, y establece que la fecha no se mueve salvo que lo diga la propia orden de cambio.

La cláusula que decide los conflictos: el orden de prelación

Como los dos documentos pueden contradecirse, cada par MSA más SOW necesita una cláusula de orden de prelación. Dice qué documento gana cuando los términos chocan. Hay dos enfoques comunes, y apuntan en direcciones opuestas.

Lo habitual en casi todos los MSA es que el MSA prevalece, salvo que un SOW concreto lo derogue de forma expresa y por escrito (Aaron Hall). Así los términos legales negociados no se reescriben en silencio dentro de un alcance de proyecto. La alternativa, común donde los SOW están muy personalizados, es que el SOW prevalezca solo para ese proyecto, con la lógica de que el documento más específico debe ganar (American Bar Association). Ambas se sostienen. Lo que no se sostiene es el silencio: sin una cláusula de prelación, un conflicto se vuelve una discusión entre abogados, y descubres quién tenía razón en una disputa en lugar de en el contrato.

Qué revisar antes de firmar

1. ¿Hay un MSA? Un único contrato combinado sirve para un trabajo pequeño. Más allá, pide la estructura de dos documentos para que los términos legales dejen de renegociarse en cada proyecto.
2. ¿La PI se consolida limpia, y cuándo? Confirma que el código y el diseño se te ceden, que los componentes preexistentes y de código abierto quedan separados, y que conoces el momento exacto en que nace la propiedad.
3. ¿Cuál es el tope de responsabilidad, y qué queda fuera? Lee el importe, la ventana temporal y las exclusiones. Un tope muy por debajo del valor del contrato es una alarma, no una formalidad.
4. ¿El proceso de orden de cambio está por escrito? Si los cambios de alcance se gestionan por email y buena voluntad, se gestionarán por disputa después. Es una de las señales de alerta que conviene revisar antes de firmar.
5. ¿Hay una cláusula de orden de prelación? Si falta, añádela. Decide ahora qué documento gana, no durante un conflicto.
6. ¿Cómo funciona la terminación, y qué te quedas? Una salida limpia entrega todo lo construido hasta la fecha. Confirma que la entrega es un derecho, no un favor.

Definir bien el alcance antes de todo esto es un trabajo aparte. Una fase de discovery corta y pagada produce la lista de entregables que un SOW de verdad necesita, y por eso tratamos el precio de la discovery y el brief al proveedor como trabajo que ocurre antes de escribir el SOW, no después.

Qué usamos nosotros y por qué

Firmamos un MSA por cliente, y luego un SOW corto por proyecto. El MSA lleva los términos que nunca queremos reabrir: PI cedida al cliente en el pago, un tope de responsabilidad mutuo, confidencialidad, y una salida limpia que entrega todo lo que construimos. El SOW se mantiene corto a propósito, para leerlo rápido y modificarlo rápido, con una cláusula de orden de cambio que convierte una petición de alcance en una decisión de dos líneas en vez de un pulso. Cuando un proyecto es un único trabajo pequeño sin expectativa de un segundo, un contrato combinado es más simple y lo decimos. Más allá, separar el marco legal del alcance del proyecto es lo que permite que una relación sume proyectos sin renegociar la ley cada vez.