Contrato de desarrollo de software: obra, cesión de derechos y modelo para España y México

Un proyecto de software rara vez se tuerce por el código. Se tuerce porque nadie escribió qué significa «terminado» ni de quién será el resultado. El cliente cree que compró un programa, el desarrollador cree que vendió horas de trabajo, y la factura final cae justo en medio de los dos malentendidos.

Un contrato de desarrollo de software fija esos puntos antes de que exista el primer commit: qué se construye, cómo se comprueba que está hecho, cuánto cuesta y a quién corresponden los derechos. En España y en México encaja en el contrato de obra. En España es el arrendamiento de obra del artículo 1544 del Código Civil: una parte se obliga a ejecutar una obra por precio cierto. En México es el contrato de obra a precio alzado, que el Código Civil Federal (CCF) regula desde el artículo 2616. Para que exista no hace falta forma escrita, pero dos cosas sí piden papel: poder probar lo prometido y ceder los derechos de autor, que las leyes de propiedad intelectual de ambos países exigen por escrito (artículo 45 del texto refundido de la Ley de Propiedad Intelectual, TRLPI, en España; artículo 30 de la Ley Federal del Derecho de Autor, LFDA, en México).

Esta guía se detiene en las dos trampas que casi siempre fallan los modelos traducidos del inglés: la cesión de derechos, que en ambos países tiene reglas de forma, y la aceptación del trabajo, de la que la ley dice poco. También repasa los tipos de contrato, ocho cláusulas que no conviene dejar en blanco, un modelo, cómo rellenarlo y cómo firmarlo online. Para la diferencia entre contrato y acuerdo, mira nuestro artículo sobre contrato y acuerdo; para el método general, cómo hacer un contrato.

Un contrato de desarrollo de software es el acuerdo entre un cliente y un desarrollador (autónomo, agencia o consultora) para construir un programa: una aplicación web o móvil, una integración, una herramienta interna. También se le llama contrato de desarrollo de aplicaciones o, en sentido amplio, contrato de servicios informáticos: el fondo es el mismo. Fija el alcance, los entregables, el precio, el calendario, los derechos sobre el código, la confidencialidad y la forma de salir del acuerdo.

No es un presupuesto, ni una especificación, ni un hilo de WhatsApp que confirma el encargo. Un presupuesto aceptado puede bastar para que exista contrato, pero rara vez dice quién es el titular del código, cómo se comprueba la entrega o qué pasa si el proyecto se detiene a mitad de camino. Ese silencio es lo que el contrato llena. Si hay un conflicto, es el documento que leerá el juez.

Qué cubre el contrato

Un contrato serio trata, como mínimo:

• Alcance y entregables: qué se construye, con detalle suficiente para que un tercero pueda decir si se entregó
• Precio e hitos: precio total, calendario de pagos y qué dispara cada pago
• Cesión de derechos: de quién es el código una vez escrito, y sobre qué exactamente
• La confidencialidad, es decir, lo que cada parte debe mantener reservado
• Aceptación: cómo comprueba el cliente que el software cumple lo pedido
• La garantía: qué corrige el desarrollador y durante cuánto tiempo
• Terminación y responsabilidad: cómo se sale, qué se paga por lo ya hecho y hasta dónde responde cada parte

Muchos confunden este contrato con la especificación funcional. Se solapan, pero no son lo mismo: la especificación describe el producto, el contrato describe la relación y remite a ella como anexo.

Siempre que alguien te pague por construir software, o que tú pagues a alguien por hacerlo. Da igual que sea un autónomo para dos semanas o una consultora para doce meses de producto: cambia la escala, no la necesidad de dejarlo por escrito.

Hace falta contrato cuando:

• externalizas el desarrollo, sobre todo a un equipo remoto o de otro país, donde la ley aplicable deja de ser obvia
• el software es a medida: cuanto más específico, más pesa la pregunta «¿de quién es?»
• el proyecto avanza por fases y cada pago depende de una aceptación por escrito
• por el proyecto pasan datos personales, lo que exige un contrato de encargo de tratamiento (artículo 28 del RGPD en España; en México, lo que prevea la ley de protección de datos personales en posesión de los particulares)
• el desarrollador reutiliza código que ya tenía o librerías de código abierto
• el desarrollador es autónomo: la cesión de derechos debe constar por escrito (artículo 45 del TRLPI en España; artículo 30 de la LFDA en México, que declara nulos los actos que no cumplan esa forma)

¿Se puede prescindir del contrato? Casi nunca. Incluso una tarea de tres días merece una página que diga qué, cuánto, cuándo y de quién es el resultado. Cuesta una hora. Un malentendido en un proyecto «sencillo» cuesta mucho más.

No hay un contrato único para todos los proyectos, y quien dice lo contrario te está vendiendo algo. La estructura debe seguir la forma en que se cotiza y se acota el proyecto; si no, crea incentivos que juegan en contra de un buen resultado.

Precio cerrado

El precio cerrado, también llamado «llave en mano», es la forma habitual del contrato de desarrollo de software a medida. En un contrato llave en mano de software, el desarrollador se compromete a un alcance y a un precio total, y tú sabes cuánto pagarás. Todo depende de lo bien descrito que esté el alcance: si es vago, cada parte descubre por el camino que no entendía lo mismo. Las dos leyes tratan el precio cerrado con una regla parecida. El contratista no puede pedir más aunque suban los costes, salvo que el cliente autorice el cambio: en España, el artículo 1593 del Código Civil, pensado para la construcción pero útil como guía; en México, los artículos 2626 y 2627 del CCF, que exigen autorización por escrito y precio expreso para el cambio. Y el cliente puede desistir cuando quiera si indemniza los gastos, el trabajo y la utilidad (artículo 1594 del Código Civil; artículo 2635 del CCF). Conviene cifrar esa salida en el contrato en vez de dejarla al juez.

Por horas

Pagas el tiempo trabajado a una tarifa pactada. Es la opción lógica cuando el producto se descubre sobre la marcha. El reverso es que no hay techo natural: un presupuesto máximo y una revisión mensual reducen el riesgo.

Equipo dedicado

Para un producto que vive años, un equipo dedicado fija las reglas de una relación continua en lugar de una entrega única. Los contratos de las empresas de TI suelen pasar por este modelo con sus socios de externalización. Ojo: un autónomo integrado en tu equipo, con tu horario y bajo tus órdenes, puede acabar considerado trabajador, como explica nuestro artículo sobre autónomos y empleados.

Proyectos ágiles

El desarrollo ágil encaja mal con un precio cerrado sobre un alcance que cambia cada sprint. Se resuelve con un precio por sprint o por lote, con por horas con tope, o con un alcance variable y salida posible al final de cada sprint. La aceptación pasa entonces a cada incremento, y el contrato debe decirlo.

Contrato marco y SOW

Para una relación larga se separa el contrato marco (derechos, confidencialidad, responsabilidad, ley aplicable) de los SOW u órdenes de trabajo, que fijan los entregables, los plazos y el precio de cada proyecto.

No todas las cláusulas pesan igual. Estas son las ocho en las que un contrato se gana o se pierde, porque una redacción vaga produce conflictos reales.

1. Alcance y entregables

Describe lo que se construye con detalle suficiente para que alguien ajeno al proyecto pueda decir si se entregó: funciones, restricciones técnicas, servicios de terceros, niveles de rendimiento. Nombra también lo que queda fuera. «Hacer una web» no es un alcance. «Una aplicación Next.js adaptable con las funciones del Anexo A y una puntuación Lighthouse móvil de al menos 90» sí lo es. La vaguedad es la primera fuente de conflictos de software: cada parte está convencida de haber sido clara.

2. Precio, hitos y plazos de pago

Enumera cada pago: importe, hecho que lo dispara y medio de pago. Liga los hitos a entregables aceptados, no a fechas del calendario. En España, el plazo de pago entre empresas es de 30 días por defecto y no puede pasar de 60 (Ley 3/2004), y los costes de cobro se indemnizan con 40 euros; el detalle está en nuestro artículo sobre plazos de pago. En México, la regla supletoria del CCF es otra: el precio de la obra se paga al entregarla, salvo convenio en contrario (artículo 2625), así que los pagos por hitos deben pactarse de forma expresa.

3. Cesión de derechos de propiedad intelectual

Es la cláusula que casi todos leen por encima y donde las leyes de ambos países exigen más forma. ¿De quién es el código a medida? ¿Y las piezas que el desarrollador ya tenía? ¿Y el código abierto? La cesión debe indicar los derechos cedidos, las modalidades de explotación, el plazo y el ámbito territorial (artículo 43 del TRLPI; artículos 30 a 33 de la LFDA). La sección de propiedad intelectual, más abajo, detalla la redacción.

4. Confidencialidad

Pacta una confidencialidad recíproca: el desarrollador no revela tus datos ni tu lógica de negocio, y tú no revelas sus herramientas y métodos. Fija cuánto dura la obligación tras el fin del contrato. Para un acuerdo independiente, lee la guía de NDA para empresas de software y cómo crear un NDA sólido.

5. Aceptación

Define cómo verifica el cliente cada entregable: plazo de revisión (cinco a diez días hábiles es habitual), formato de los comentarios, criterios de éxito y qué pasa si el cliente no responde. La ley dice poco: el Código Civil español presume aprobada y recibida la parte pagada de la obra por piezas o medida (artículo 1592), y el CCF dice lo mismo (artículo 2631). Todo lo demás depende de lo que escribas.

6. Garantía

El desarrollador garantiza que el software funciona según el Anexo A, que el código es original (o está debidamente licenciado) y que su entrega no infringe derechos de terceros. Un periodo de corrección de errores tras la aceptación (de treinta a noventa días, en la práctica) protege frente a defectos que aparecen en producción. Aclara que la garantía no cubre lo que el cliente haya modificado por su cuenta. En México, el artículo 2634 del CCF ya hace responsable al contratista de los defectos que aparezcan después de recibida la obra por vicios de su ejecución.

7. Terminación

Cualquiera de las partes debe poder salir con preaviso (treinta días es lo habitual). Define qué pasa con el trabajo en curso y cómo se calcula el saldo. Separa la resolución por incumplimiento (artículo 1124 del Código Civil español; artículo 1949 del CCF), con requerimiento previo, del desistimiento por conveniencia, que se paga.

8. Ley aplicable y jurisdicción

Nombra la ley que rige el contrato y los tribunales competentes. Entre un cliente en España y un desarrollador en otro país, esta cláusula decide qué juez resolverá el conflicto. No la dejes en blanco porque suene «formal»: es de las más útiles en cuanto una de las partes está fuera de tu país. En la Unión Europea, el Reglamento Roma I deja que las partes elijan la ley aplicable.

Usa este modelo como base. Sustituye todos los campos entre corchetes por tus condiciones. Está escrito para que sirva en España y en México: donde la ley de cada país exige algo distinto, el texto lo indica entre corchetes. La cláusula de cesión (la tercera) es, junto con la garantía y la limitación de responsabilidad, la parte que debe revisar un abogado especializado en tecnología. Un modelo es un punto de partida, no un asesoramiento jurídico.

CONTRATO DE DESARROLLO DE SOFTWARE

Fecha del contrato: [fecha]

El Cliente: [denominación social, NIF o RFC, domicilio]
representado por [nombre, cargo] («el Cliente»)

El Desarrollador: [denominación social o nombre del autónomo, NIF o RFC, domicilio]
representado por [nombre, cargo] («el Desarrollador»)

CLÁUSULA PRIMERA. OBJETO Y ALCANCE

1.1 El Desarrollador diseña, desarrolla y entrega al Cliente el software
descrito en la especificación del Anexo A («el Software»), conforme a los
requisitos, restricciones y criterios de aceptación que allí figuran.

1.2 Todo trabajo no descrito en el Anexo A queda fuera del alcance y solo
puede ejecutarse tras firmar una orden de cambio (cláusula décima).

1.3 El Software se entrega por hitos, según el calendario del Anexo B.

CLÁUSULA SEGUNDA. PRECIO Y PAGO

2.1 El precio es de [importe] [euros / pesos mexicanos] más impuestos («el
Precio»), pagadero por hitos según el Anexo B. [Precio cerrado, o por horas
con tope de [importe]]

2.2 Las facturas se pagan a los [30] días de su fecha de emisión [España:
60 días como máximo, Ley 3/2004].

2.3 El retraso devenga intereses de demora al [tipo] % anual [España: y la
indemnización de 40 euros por costes de cobro].

2.4 El Desarrollador puede suspender los trabajos si una factura sigue
impagada [30] días después de su vencimiento y tras requerimiento por escrito.

CLÁUSULA TERCERA. PROPIEDAD INTELECTUAL

3.1 Cesión. Una vez pagado íntegramente el Precio, el Desarrollador cede al
Cliente, en exclusiva, los derechos de explotación (en México, derechos
patrimoniales) sobre los desarrollos específicos creados para él («los
Desarrollos»), con código fuente, código objeto y documentación, en estas
modalidades:
a) reproducción, total o parcial, permanente o transitoria, por cualquier
   medio y forma;
b) transformación: traducción, adaptación, arreglo o cualquier otra
   modificación, y reproducción del resultado;
c) distribución, incluido el alquiler, y comunicación pública, incluida la
   puesta a disposición como servicio en línea.
Ámbito territorial: todo el mundo. Plazo: toda la duración legal de los
derechos de propiedad intelectual. Finalidad: cualquier uso del Cliente,
incluida la explotación comercial frente a terceros [o: solo las necesidades
internas del Cliente].

3.2 Remuneración. La cesión se hace a cambio del Precio, que retribuye de
forma fija y determinada los derechos cedidos.

3.3 Versiones y derivados. El Desarrollador no se opone a que el Cliente
realice o autorice versiones sucesivas y programas derivados del Software.

3.4 Elementos preexistentes. El Desarrollador conserva la titularidad de las
herramientas y componentes anteriores al proyecto o independientes de él,
enumerados en el Anexo A («los Elementos Preexistentes»), y concede al
Cliente una licencia no exclusiva, mundial, perpetua y gratuita para usarlos
tal como están integrados en el Software.

3.5 Código abierto. Los componentes de código abierto del Software figuran en
el Anexo A con sus licencias. El Desarrollador garantiza que su uso es
compatible con la explotación prevista en el apartado 3.1.

3.6 Cadena de titularidad. El Desarrollador garantiza ser titular de los
derechos necesarios, incluidos los de sus empleados y los de sus
subcontratistas, que se los han cedido por escrito, y que los Desarrollos no
infringen derechos de terceros.

3.7 Registro. Las partes podrán inscribir la cesión en el Registro de la
Propiedad Intelectual [España] o en el Registro Público del Derecho de
Autor [México].

CLÁUSULA CUARTA. CONFIDENCIALIDAD

4.1 Cada parte mantiene en reserva la información no pública que la otra le
comunique con motivo del contrato, durante [2/3/5] años tras su fin.

4.2 Quedan excluidas la información pública sin culpa de quien la recibe, la
ya conocida por este y la que deba revelarse por ley o por orden judicial.

CLÁUSULA QUINTA. DATOS PERSONALES

Si el Desarrollador trata datos personales por cuenta del Cliente, las partes
firman antes de cualquier tratamiento el contrato de encargo del Anexo C
[España: artículo 28 del RGPD].

CLÁUSULA SEXTA. ACEPTACIÓN

6.1 En cada entrega de un hito, el Cliente dispone de [10] días hábiles para
verificar el entregable conforme a los criterios del Anexo A y aceptarlo o
notificar por escrito los errores.

6.2 El Desarrollador corrige los errores bloqueantes en [10] días hábiles sin
coste; los errores menores se anotan como reservas y no impiden la aceptación.

6.3 Si el Cliente no responde en el plazo, el Desarrollador se lo recuerda por
escrito. Si sigue sin responder en [5] días hábiles, el hito se da por aceptado.

6.4 La aceptación se rige por los criterios objetivos del Anexo A, no por la
satisfacción personal del Cliente. Cada hito se cierra con un acta firmada.

CLÁUSULA SÉPTIMA. GARANTÍA

Durante [90] días desde la aceptación final, el Desarrollador corrige sin
coste los errores de conformidad con el Anexo A, salvo que procedan de una
modificación del Software o de su entorno hecha por el Cliente o un tercero.

CLÁUSULA OCTAVA. RESPONSABILIDAD

8.1 La responsabilidad de cada parte se limita al Precio pagado en los [12]
meses anteriores al hecho, sin indemnización de daños indirectos.

8.2 Estos límites no se aplican al dolo.

CLÁUSULA NOVENA. DURACIÓN Y TERMINACIÓN

9.1 El contrato dura hasta la aceptación final y el pago del saldo.

9.2 Incumplimiento: tras un requerimiento sin efecto durante [15] días, la
parte perjudicada puede resolver el contrato.

9.3 Desistimiento: el Cliente puede desistir con [30] días de preaviso,
pagando los hitos aceptados, el trabajo en curso y [importe o porcentaje] por
la utilidad dejada de obtener.

9.4 Al terminar, el Desarrollador entrega el código, la documentación y los
accesos necesarios.

CLÁUSULA DÉCIMA. ÓRDENES DE CAMBIO

Todo cambio de alcance consta en una orden de cambio firmada por ambas partes
antes de ejecutarse. La orden indica la adición, su efecto en el calendario y
el precio expreso. Solo [cargos autorizados] pueden firmarla.

CLÁUSULA UNDÉCIMA. LEY APLICABLE Y JURISDICCIÓN

[España: El contrato se rige por la ley española y las partes se someten a los
juzgados y tribunales de [ciudad].]
[México: El contrato se rige por las leyes federales aplicables y las partes
se someten a los tribunales de [ciudad].]

CLÁUSULA DUODÉCIMA. TOTALIDAD

El contrato, sus anexos y sus órdenes de cambio constituyen el acuerdo
completo de las partes.

FIRMAS

Hecho en [ciudad], a [fecha], mediante firma electrónica.

El Cliente: [nombre, cargo, firma]
El Desarrollador: [nombre, cargo, firma]

---
ANEXO A. ESPECIFICACIÓN
[Funciones, restricciones técnicas, criterios de aceptación de cada entregable,
elementos preexistentes, componentes de código abierto y licencias]

ANEXO B. HITOS Y PAGOS

| Hito | Entregable | Fecha | Pago |
|------|------------|-------|------|
| H1: inicio | [descripción] | [fecha] | [importe] |
| H2: [fase] | [descripción] | [fecha] | [importe] |
| H3: entrega final | [descripción] | [fecha] | [importe] |

ANEXO C. CONTRATO DE ENCARGO DE TRATAMIENTO DE DATOS (si procede)

Si gestionas los contratos de varios proveedores de TI, guardar todos los ejemplares firmados en un mismo sitio, con el historial de versiones, te ahorra los intercambios de archivos Word renombrados «final_v3_DEFINITIVO».

La mayoría de los modelos cubren lo básico. Estas son las cláusulas que desaparecen de los contratos hechos deprisa y las que más importan el día que algo sale mal.

Criterios de aceptación medibles

La cláusula sexta del modelo dice cuándo y cómo revisa el cliente. Lo que muchos contratos omiten son los criterios en sí. Sin umbrales medibles, la aceptación se convierte en una negociación: el cliente siempre puede juzgar que el software «no está lo bastante bien». Escribe criterios objetivos en el Anexo A antes de empezar a desarrollar.

Depósito del código fuente y reversibilidad

Si tu negocio depende de un software a medida y el desarrollador desaparece, necesitas el código. Un depósito (escrow) entrega el código a un tercero, que lo libera al cliente si el desarrollador cesa su actividad o incumple gravemente. Como mínimo, incluye una cláusula de reversibilidad: entrega del código, la documentación y los accesos al terminar el contrato, sin costes ocultos. Poca gente lo pide hasta que lo necesita, y la mayoría de los desarrolladores lo aceptan si se pide pronto.

Responsabilidad tras la entrega

La cláusula octava limita la responsabilidad, pero muchos modelos callan sobre su duración. ¿Hasta cuándo responde el desarrollador? Si un fallo hace perder datos dieciocho meses después, ¿quién paga? Fija el periodo de garantía y la responsabilidad posterior. Y no cuentes con que el límite lo cubra todo: en ambos países la responsabilidad por dolo es exigible y es nula la renuncia a exigirla (artículo 1102 del Código Civil español; artículo 2106 del CCF).

Órdenes de cambio

La cláusula décima exige una orden firmada para cualquier cambio de alcance. Lo que muchos omiten es quién tiene poder para firmarla. Si un jefe de proyecto del cliente pide una función por mensaje y el desarrollador la construye, ¿se debe? Solo si se siguió el procedimiento. Nombra cargos, no personas, con autoridad para autorizar cambios. En México, el CCF lo refuerza: ningún aumento de precio sin autorización escrita del dueño y con el precio expreso (artículo 2627).

Código abierto y datos personales

Una librería con licencia GPL, por ejemplo, puede obligar a publicar el código de tu producto que la integre. Exige la lista de componentes de código abierto y sus licencias, y que se confirme su compatibilidad con el uso previsto. Lo mismo con los datos: si el desarrollador trata datos personales, el artículo 28 del RGPD exige un contrato de encargo de tratamiento, y conviene firmarlo antes del primer acceso a una base real.

La propiedad intelectual es la cláusula que el cliente hojea y donde los errores salen más caros. En España y en México tiene reglas de forma que los modelos traducidos del inglés suelen ignorar, y las dos leyes no coinciden en todo.

La cesión que no vale

En la cesión de derechos de software, los modelos en inglés casi siempre dicen lo mismo: el desarrollador cede «todos los derechos, títulos e intereses, incluidos todos los derechos de autor». Eso no basta. En España, la cesión se limita al derecho cedido, a las modalidades de explotación expresamente previstas y al tiempo y ámbito territorial que se determinen; si falta el tiempo, queda en cinco años, si falta el territorio, en el país donde se hace la cesión, y si no se concretan las modalidades, solo cubre lo que se deduzca necesariamente del contrato (artículo 43 del TRLPI). La cesión global de obras futuras es nula (artículo 43.3). En México, la transmisión de derechos patrimoniales debe constar por escrito o será nula de pleno derecho, es onerosa y temporal, y a falta de estipulación dura cinco años (artículos 30 y 33 de la LFDA). Un contrato que solo copia la fórmula estadounidense deja al cliente con una cesión frágil.

Qué dice la ley, país por país

Los cuatro modelos de propiedad

Elementos preexistentes y cadena de titularidad

Casi todos los desarrolladores aportan herramientas y librerías escritas antes de tu proyecto. El contrato debe identificarlas y concederte una licencia de uso, sin transferir la propiedad de esas piezas. Pide también la cadena de titularidad: en España, los derechos sobre el programa creado por un asalariado corresponden al empresario (artículo 97.4), pero no los de un autónomo subcontratado. El desarrollador solo puede cederte lo que tiene.

El «work made for hire» no existe tal cual

El derecho estadounidense tiene el work made for hire: el código escrito por un empleado es del empleador. En España, el TRLPI prevé algo parecido solo para el trabajador asalariado; para el autónomo y la agencia hace falta una cesión escrita. En México, la regla es distinta: el comitente de una obra por encargo es titular de los derechos patrimoniales salvo pacto en contrario, pero la ley lo condiciona a que los términos del contrato sean claros y precisos, y las dudas se resuelven a favor del autor. Para los modelos de contrato de desarrollo web, la biblioteca de plantillas de Chaindoc ofrece una base editable; la redacción de la cesión la debes adaptar a tu caso.

Estos documentos se confunden constantemente. En resumen: un contrato de desarrollo para un proyecto aislado, y un contrato marco más un SOW para una relación que dura. Cada uno cumple una función, y mezclarlos crea huecos de responsabilidad.

Para un proyecto aislado basta un contrato único, como el de esta guía. Para un socio de desarrollo con el que llevas varios proyectos, el conjunto contrato marco y SOW es más eficiente: negocias la base jurídica una vez y cada proyecto añade un SOW.

Conseguir firmado un contrato de desarrollo de software significaba imprimir, escanear, enviar y esperar que las dos versiones coincidieran. Ya no hay motivo para hacerlo así.

Qué hace válida una firma electrónica

Para un contrato mercantil, una firma electrónica sirve cuando cumple estas condiciones:

• identifica a su autor y manifiesta su consentimiento
• está vinculada al documento firmado
• permite detectar cualquier cambio posterior
• el registro se conserva en una forma que permite consultarlo más tarde

En España, el Reglamento eIDAS (artículo 25) impide negar efectos jurídicos a una firma electrónica por el solo hecho de serlo, y la Ley 6/2020 regula determinados aspectos de los servicios electrónicos de confianza. En México, el Código de Comercio tiene por cumplida la forma escrita con un mensaje de datos íntegro y accesible (artículo 93) y admite la firma electrónica apropiada para los fines del mensaje (artículo 97). Las firmas criptográficas van más lejos: cada una queda ligada matemáticamente al hash del documento, y cambiar un solo carácter después modifica la huella. Ninguna parte puede alegar luego que se alteró el documento sin que se note.

Cómo es el proceso de firma

Un contrato de TI rara vez va solo: contrato marco, SOW, NDA y adendas circulan a la vez. Un circuito de firma propio evita el desorden de versiones intercambiadas por correo:

• sube el contrato definitivo, con los anexos, en un único archivo
• añade el correo de cada firmante; todos reciben la invitación a la vez, y un orden fijo se logra con los circuitos de aprobación del plan Business
• cada firmante firma desde su dispositivo
• el servicio emite un certificado de firma, con los sellos de tiempo y la huella del documento
• cada parte conserva el documento firmado, y la prueba puede verificarse después con el servicio de verificación de Chaindoc

Hitos y facturación

Lo más útil de una herramienta de contratos no es la firma, sino lo que viene después. El acta de aceptación de un hito es un documento que se firma igual que el contrato, y es el que justifica la factura. Para equipos que llevan pagos y contratos, firmar el acta de aceptación en el mismo sitio que el contrato mantiene alineados aceptación y cobro. Los planes se detallan en la página de precios, y el servicio de firma, en la página de firma electrónica.

Textos de referencia

• Texto refundido de la Ley de Propiedad Intelectual (TRLPI), artículos 43 a 47 y 95 a 101
• Código Civil español, artículos 1544 y 1588 a 1594
• Ley 3/2004 contra la morosidad en las operaciones comerciales
• Ley Federal del Derecho de Autor, artículos 30 a 33, 83 y 103
• Código Civil Federal, artículos 2616 a 2643
• Reglamento (UE) n.º 910/2014 (eIDAS)

Encontrarás más guías prácticas en el blog de Chaindoc.