¿Está contratando software a medida o SaaS?

Marco de decisión: ¿compra un resultado o un servicio?

La primera pregunta no es jurídica, sino operativa. El software a medida significa que paga por la creación de algo que aún no existía y que quiere conservar. El SaaS significa que alquila el acceso a una solución ya hecha, que el proveedor opera y desarrolla para todos sus clientes.

La diferencia tiene tres consecuencias prácticas. En el desarrollo a medida, lo que está en juego son los derechos sobre el código y la documentación; en el SaaS, la disponibilidad, los datos y las condiciones de salida. En el desarrollo, usted es vulnerable en el momento de la entrega; en el SaaS, durante todo el periodo de funcionamiento. Y en el desarrollo el mayor riesgo es recibir algo que nadie más sepa asumir, mientras que en el SaaS es que el proveedor le cambie las condiciones unilateralmente.

La mayoría de los proyectos reales son híbridos: una plataforma ya hecha más adaptaciones a medida, y es precisamente en esas adaptaciones donde luego se descubre que el contrato solo regula una de las dos partes. La solución práctica es describir ambas capas por separado e indicar, para cada una, quién tiene los derechos, quién responde por la funcionalidad y qué ocurre tras la finalización del contrato. La capa operativa del SaaS la tratamos en detalle en el artículo Garantía contractual de la disponibilidad y la calidad de los servicios en la nube (SLA).

Existe una cuarta variante, con la que las empresas se topan más tarde: el desarrollo mediante herramientas de inteligencia artificial generativa. En ese caso es fundamental saber con qué herramientas el proveedor generó el código, porque de ello depende lo que realmente le puede entregar. Analizamos esta cuestión en el artículo Desarrollo de software mediante inteligencia artificial: a quién pertenece el código.

Procedimiento paso a paso

El orden de los pasos reproduce las fases de la negociación. Quien se los salte lo acaba pagando durante el funcionamiento del sistema.

El primer paso es describir el resultado de forma medible. La especificación debe incluir las funciones, los parámetros de rendimiento y los escenarios sobre los que se hará la prueba. Una formulación del tipo «el sistema será fácil de usar» no se sostiene en un acta de aceptación; una formulación como «tiempo de respuesta inferior a dos segundos con cincuenta usuarios simultáneos» sí.

El segundo paso es resolver los derechos sobre el código, por escrito y antes de firmar el contrato principal. Decida si necesita ejercer los derechos patrimoniales de autor sobre el código o si le basta con una licencia suficientemente amplia y, en ese caso, con qué alcance: para cuántos usuarios, para cuántas instalaciones, con derecho a ceder el código a un tercero que desarrolle el sistema en lugar del proveedor.

El tercer paso es la aceptación. El contrato debe indicar quién realiza la prueba, cuánto dura, qué ocurre en caso de fallo parcial y cuándo se considera aceptada la obra aunque no se firme el acta. Sin ello surge la disputa sobre si la obra se completó y se entregó, y sobre si la parte correspondiente del precio es exigible. La ley no exige la firma del acta como condición de pago, pero el contrato sí puede vincular ambas cosas.

El cuarto paso es el funcionamiento: disponibilidad, tiempos de reacción, ventanas de mantenimiento y sanciones por su incumplimiento. Aquí conviene configurar las sanciones como créditos automáticos, no como indemnización por daños que el cliente tendría que demostrar.

El quinto paso es la garantía para el caso de que el proveedor desaparezca. La herramienta clásica es el depósito del código fuente en manos de un tercero, con condiciones de entrega definidas. Un depósito sin documentación actualizada no sirve de nada, por lo que el contrato debe obligar también a depositar la documentación y la versión (build) actual.

El sexto paso es la salida. El contrato debe fijar el formato en que recibirá los datos, el plazo para su entrega, el periodo de colaboración tras la finalización y el precio de la asistencia en la migración. En el desarrollo a medida, la salida depende exclusivamente del contrato, y sin un precio pactado se convierte en una negociación bajo presión.

Sin embargo, en los servicios en la nube y SaaS, la salida ya no depende solo del contrato. Desde el 12 de septiembre de 2025 se aplica el capítulo VI del Reglamento de Datos de la UE, que obliga a los proveedores de servicios de tratamiento de datos a eliminar los obstáculos al cambio a otro proveedor y a permitir la exportación de los datos. Las tarifas de cambio están limitadas transitoriamente a los costes directamente vinculados a él y, a partir del 12 de enero de 2027, deben suprimirse por completo. Al negociar conviene, por tanto, comprobar si el borrador del contrato respeta estas normas o si las contradice.

El séptimo paso es el proceso de cambios. Sin un procedimiento descrito para las solicitudes de cambio, los cambios se resuelven por correo electrónico y la disputa sobre qué estaba incluido en el precio está garantizada. Por ello, el contrato debe indicar quién aprueba el cambio, en qué plazo entrega el proveedor la estimación de esfuerzo y qué ocurre con el plazo si el cliente no aprueba esa estimación.

Qué es estándar en el mercado y qué es una señal de alarma

En los proyectos sólidos es habitual que el precio del desarrollo se divida en fases vinculadas a aceptaciones parciales, y que la última parte se pague solo tras la puesta en funcionamiento. También es habitual que el proveedor responda por defectos durante el periodo de garantía y, en paralelo, ofrezca soporte de pago, que son dos cosas distintas y no deben mezclarse en una sola.

En el SaaS es habitual que la disponibilidad se describa con una única cifra mensual, que se defina el mantenimiento planificado que no cuenta para esa disponibilidad, y que existan créditos por incumplimiento. También es habitual que el proveedor pueda modificar las funciones, pero no reducir el nivel de servicio pactado, y que informe del cambio con antelación.

Hay tres señales de alarma que se detectan nada más leer el borrador del contrato. La primera es un contrato que no dice una palabra sobre el código fuente ni sobre la documentación, porque eso significa que otro proveedor no podrá asumir técnicamente el sistema. La segunda es una responsabilidad del proveedor limitada al importe del pago mensual, lo que en un contrato de un año significa que, en la práctica, apenas responde por los daños causados.

La tercera señal de alarma es vincular los datos a un formato que no se puede leer en ningún otro sitio. La cláusula «los datos se entregarán en el formato utilizado por el proveedor» significa, en la práctica, una exportación cuyo tratamiento pagará dos veces. Con la misma lógica hay que leer también las disposiciones sobre el tratamiento de datos personales; las analizamos en el artículo Plataforma SaaS en la UE.

Dónde está el límite legal

La regulación legal es, en el caso del software, más estricta de lo que las empresas esperan, y en un punto, en cambio, más favorable.

Según el artículo 58, apartado 7, de la Ley de Derechos de Autor checa, los programas informáticos y las bases de datos se consideran obras creadas por encargo laboral incluso cuando el autor las haya creado por encargo, y en ese caso el cliente se considera el empleador. Esto significa que, en el caso de un programador autónomo que haya escrito el código por encargo suyo, es usted quien ejerce los derechos patrimoniales, salvo que se haya pactado otra cosa.

La situación cambia, sin embargo, cuando el proveedor es una empresa de software. Si el código lo escriben sus empleados, es ella quien ejerce los derechos patrimoniales conforme a la misma disposición, en calidad de empleadora, y esos derechos llegarán a usted solo en la medida en que lo establezca el contrato.

En la práctica, además, el proveedor suele combinar el trabajo de empleados, colaboradores externos, subcontratistas, bibliotecas de código abierto y componentes de terceros, por lo que es necesario comprobar toda la cadena de derechos, no solo la declaración del proveedor. Por eso, incluso en el caso de un programador autónomo, el contrato debe incluir la entrega del código fuente, la documentación, la autorización para realizar modificaciones y la lista de los componentes de terceros utilizados.

Para las obras a las que no se aplica esta regla, el artículo 61 de la Ley de Derechos de Autor establece que el autor solo concede la licencia para la finalidad que se derive del contrato. Cualquier uso que exceda ese marco requiere un contrato de licencia. En el caso de los gráficos, los textos o los diseños de interfaz entregados junto con el software, este suele ser un detalle que se pasa por alto.

El propio contrato de licencia tiene un mínimo legal. Según el artículo 2358, el licenciante concede la licencia en el alcance limitado o ilimitado pactado, y el licenciatario se compromete a pagar una remuneración, salvo que se acuerde otra cosa; la ley exige la forma escrita en el caso de la licencia exclusiva. Por tanto, es necesario describir el alcance, porque de lo contrario será objeto de disputa.

La salida también se ve afectada por la norma sobre la cesión de la licencia. Según el artículo 2364 del Código Civil checo (Ley n.º 89/2012 Sb., en adelante «OZ»), el licenciatario solo puede ceder la licencia a un tercero con el consentimiento del licenciante, que debe constar por escrito. En caso de transmisión de la empresa o de una parte independiente de esta, el artículo 2365 exige el consentimiento solo si así se ha pactado expresamente. Quien planee vender la empresa o segregar una división debe resolver este punto ya en el momento de firmar el contrato de TI.

En la aceptación se aplican las normas sobre el contrato de obra. Según el artículo 2610 del OZ, el derecho al pago del precio de la obra nace con su ejecución y, si la obra se recibe por partes, el derecho al pago de cada parte nace con su ejecución. Según el artículo 2605, la obra se considera terminada cuando se ha demostrado su aptitud para servir a su finalidad, y si el cliente recibe la obra sin reservas, el tribunal no le reconocerá el derecho derivado de un vicio manifiesto si el proveedor alega que se invocó fuera de plazo. La firma del acta de aceptación no es, por tanto, un requisito legal para que nazca el derecho al precio, pero el contrato sí puede vincular a ella la exigibilidad del pago, y por eso se negocia su contenido.

El último límite lo constituye la limitación de responsabilidad. Según el artículo 2898 del OZ, no se tiene en cuenta el pacto que excluya o limite de antemano la obligación de indemnizar el daño causado a una persona en sus derechos naturales, o causado dolosamente o por negligencia grave. El límite de responsabilidad pactado no se aplica, por tanto, a estos casos, sea cual sea la forma en que las partes lo hayan configurado.

Resumen final

El contrato de TI debe redactarse empezando por el final. Responda primero a qué necesita tener en sus manos el día en que ponga fin a la relación con el proveedor: el código fuente, la documentación, los datos en un formato utilizable y a alguien que pueda asumir el sistema. Solo después ocúpese del precio y de los plazos. Redacte los criterios de aceptación de forma medible, describa la salida incluyendo el precio de la asistencia, e implante el proceso de cambios desde el principio.

El límite legal es, en este sentido, más favorable de lo que las empresas suponen en un punto, y más estricto en otro. En el caso de un programador contratado por encargo, es usted quien ejerce los derechos patrimoniales; en el caso de una empresa de software, solo los tiene en la medida que establezca el contrato. El bufete ARROWS cuenta con un seguro de responsabilidad civil profesional con un límite de 350 000 000 CZK (aprox. 14,4 millones EUR) y negocia contratos de TI en el marco del servicio Derecho informático y del software, ciberseguridad. Escriba a consultas@arws.cz.