¿Qué es un contrato de desarrollo de software?
Un contrato de desarrollo de software es el acuerdo vinculante entre un cliente y un desarrollador que define qué se construye, quién es el titular del código, cómo funciona el pago y quién asume cada riesgo. Sus cláusulas esenciales son el alcance, la titularidad de la propiedad intelectual, los criterios de aceptación, los pagos por hitos, el control de cambios, la confidencialidad, las garantías, la responsabilidad y la rescisión. Si acierta con la titularidad de la propiedad intelectual y con la aceptación, la mayoría de las disputas desaparecen.
Un contrato de desarrollo de software es el acuerdo jurídicamente vinculante que convierte una propuesta en obligaciones exigibles: establece qué se construirá, quién es titular del software resultante, cómo y cuándo se paga y quién responde cuando algo sale mal. También se denomina acuerdo de desarrollo de software o acuerdo de servicios de desarrollo de software, y existe para sustituir los supuestos por condiciones escritas, porque casi todas las disputas graves en un desarrollo se remontan a una pregunta que el contrato nunca respondió.
Lo que está en juego es concreto. Un acuerdo débil puede dejarle pagando seis cifras por un código que legalmente no es suyo, o con la obligación de asumir un alcance que se duplicó en silencio. Tanto si contrata a un autónomo como a una empresa de desarrollo de software a medida, la misma lista corta de cláusulas decide si la relación está protegida o expuesta, y conviene leerlas antes de que empiece el trabajo, no después.
La probabilidad de problemas es lo bastante alta como para que esto no sea una hipótesis: el CHAOS Report del Standish Group ha constatado en repetidas ocasiones que solo alrededor de un tercio de los proyectos de software tienen éxito sin reservas, aproximadamente la mitad están «con dificultades» (superan el presupuesto, se retrasan o reducen su alcance) y el resto fracasa por completo. Un contrato no aclarará por sí solo los requisitos, pero un alcance limpio, una aceptación basada en hitos y un proceso definido de control de cambios son exactamente los mecanismos que llevan un proyecto de «con dificultades» hacia «con éxito».
Esta guía recorre cada cláusula que debería contener un contrato en 2026, explica las dos que más importan (la titularidad de la propiedad intelectual y la aceptación) y termina con una lista de verificación. Es una orientación general y no asesoramiento jurídico: para las condiciones de propiedad intelectual, responsabilidad y jurisdicción, haga que su propio asesor jurídico revise el borrador final.
¿Qué tipo de contrato de desarrollo de software conviene usar?
Elija el tipo de contrato según lo bien definido que esté el alcance: precio cerrado para trabajo estable y totalmente especificado, tiempo y materiales para trabajo que evoluciona y un modelo híbrido para la mayoría de los proyectos reales. El modelo de precios no es un detalle de facturación: determina quién asume el riesgo de que las cosas tarden más de lo previsto y condiciona todas las cláusulas de pago y de control de cambios que siguen.
Los tres modelos estándar y qué compensa cada uno:
- Precio cerrado. Un precio acordado para un alcance muy especificado. Obtiene certeza presupuestaria y el desarrollador asume el riesgo de sobrecostes, pero cualquier cambio exige una modificación formal, de modo que penaliza la incertidumbre y premia una especificación previa exhaustiva.
- Tiempo y materiales (T&M). Se pagan las horas reales a las tarifas acordadas. Encaja con el trabajo que evolucionará y mantiene el proyecto flexible, a costa de renunciar a un total fijo; por eso necesita un tope de gasto, informes periódicos y tarifas por perfil claras para seguir siendo controlable.
- Equipo dedicado / iguala. Una cuota mensual fija por un equipo asignado que usted dirige. Es lo mejor para productos de larga duración: cambia el precio por funcionalidad por continuidad y velocidad.
La opción habitual en 2026 para la mayoría de los desarrollos a medida de menos de unos $300,000 es un modelo híbrido: contratar a precio cerrado la construcción inicial o el MVP y pasar la iteración y el mantenimiento a una iguala de tiempo y materiales cuando el alcance deja de poder conocerse por completo. Para una comparación más a fondo del aspecto económico, consulte nuestra guía de tiempo y materiales frente a precio cerrado frente a equipo dedicado.
Las cláusulas que todo contrato de desarrollo de software necesita
Todo contrato de desarrollo de software sólido se construye con la misma docena de cláusulas, cada una de las cuales responde a una pregunta: qué, cuándo, quién es titular, quién responde y cómo termina. Es en la falta de cualquiera de ellas donde entra el riesgo, así que tome la lista siguiente como el mínimo que debe cubrir un acuerdo serio.
| Cláusula | Qué decide |
|---|---|
| Alcance del trabajo (SOW) | Las funcionalidades, entregables y requisitos técnicos exactos que se van a construir |
| Criterios de aceptación | La prueba objetiva que da un entregable por «terminado» y activa el pago |
| Precios e hitos | El modelo, el calendario de pagos y a qué se vincula cada pago |
| Control de cambios | Cómo se ajustan el alcance, el plazo y el coste sin disputas |
| Propiedad intelectual y licencias | Quién es titular del código y las condiciones de licencia de la propiedad intelectual de terceros o preexistente |
| Confidencialidad y protección de datos | Cómo se tratan sus datos y secretos comerciales (y las obligaciones del RGPD y del DPA) |
| Garantías y soporte | El periodo de corrección de defectos (garantía) tras la entrega y las condiciones de soporte |
| Indemnización | Quién protege a quién frente a reclamaciones de terceros, en especial por infracción de la propiedad intelectual |
| Limitación de responsabilidad | El tope de la exposición financiera de cada parte si algo sale mal |
| Rescisión y salida | Cómo puede cada parte poner fin al contrato y la entrega del código fuente y de los activos |
Las secciones siguientes abordan las cuatro cláusulas que más problemas causan en la práctica (propiedad intelectual, alcance, aceptación y control de cambios) y muestran cómo es una buena redacción de cada una. La confidencialidad, las garantías, la indemnización y la responsabilidad también importan, pero rara vez sorprenden a nadie como lo hacen estas cuatro.
¿Quién es el titular del código? La propiedad intelectual en un contrato de desarrollo de software
Si el contrato no se lo cede de forma expresa, el desarrollador puede ser el titular del código por el que usted pagó. Según la ley de derechos de autor de EE. UU., la obra creada por un contratista independiente pertenece por defecto al contratista: contratar y pagar a alguien para que construya software no transfiere, por sí solo, la titularidad. Es la condición más malentendida y de mayores consecuencias de todo el acuerdo.
Dos mecanismos transfieren la titularidad, y un buen contrato los usa conjuntamente:
- Cláusula de cesión (IP assignment). El desarrollador cede de forma irrevocable al cliente todos los derechos, títulos e intereses sobre los entregables, normalmente al completarse el pago. Es la vía fiable, porque funciona incluso donde no se aplica la figura de «obra por encargo» (work made for hire).
- Obra por encargo (work made for hire). Una disposición que establece que la obra se crea como obra por encargo, de modo que pertenece al cliente desde el principio. Es útil, pero más limitada de lo que se suele suponer en la legislación de EE. UU., y por eso mismo debe respaldarse con una cesión explícita.
Otros dos puntos deciden si su titularidad es real. Primero, vincule la transferencia al pago: los derechos deben pasar a usted cuando haya pagado, lo que protege a ambas partes. Segundo, trate la propiedad intelectual preexistente y de terceros: las bibliotecas reutilizables propias del desarrollador y cualquier componente de código abierto deben identificarse y concederse a usted bajo una licencia clara y perpetua, para que más adelante no se le impida usar ni revender su propio producto. Combine la cesión con una cláusula de indemnización que cubra las reclamaciones de terceros por infracción de la propiedad intelectual, para que usted no responda por un componente elegido por el desarrollador.
Los componentes de código abierto requieren un nivel más de cuidado: en la práctica, su base de código es en su mayor parte código de otras personas, y la licencia de cada dependencia es una decisión comercial, no un tecnicismo. Las licencias permisivas (MIT, Apache, BSD) no crean un riesgo real. Las licencias copyleft (GPL, AGPL) pueden obligarle a publicar su propio código fuente si distribuye, o, en el caso de AGPL, incluso si aloja la obra combinada, algo grave para un producto propietario. Pida al desarrollador una lista de materiales de los paquetes de terceros y de código abierto utilizados, y haga que el contrato exija mantener esa lista actualizada hasta la entrega.
La misma lógica de titularidad se aplica al código generado por IA: trátelo como un entregable más, cubierto por la misma cláusula de cesión, y no como una categoría especial al margen del contrato. Las cuestiones abiertas en 2026 son si el resultado asistido por IA goza siquiera de protección de derechos de autor en su jurisdicción y si las condiciones del proveedor del asistente de programación imponen restricciones propias sobre el resultado. Un contrato actual debería exigir al desarrollador que declare el uso sustancial de herramientas de generación de código con IA y que confirme que el resultado está libre de reclamaciones de terceros sobre datos de entrenamiento o licencias, igual que haría con cualquier otro componente reutilizado.
Alcance del trabajo y entregables
El alcance del trabajo es la cláusula que define el «qué», y su calidad determina si todas las demás condiciones pueden hacerse cumplir. Un buen SOW enumera entregables concretos con requisitos medibles (funcionalidades con nombre, especificaciones técnicas, plataformas, integraciones y exclusiones fuera de alcance) en lugar de una descripción vaga de un resultado. Si un entregable no se puede señalar y verificar, no puede aceptarse, pagarse ni discutirse con limpieza.
El fallo más común es un alcance redactado para sonar tranquilizador y no para ser verificable. «Un panel moderno y fácil de usar» no es un entregable; «un panel que muestre las cinco métricas enumeradas en el anexo A, filtrable por rango de fechas, y que cargue en menos de dos segundos con el conjunto de datos de referencia» sí lo es. La precisión aquí no es burocracia: es lo que permite que la aceptación, el pago y el control de cambios funcionen. Una estimación disciplinada es la materia prima de un buen SOW; nuestra guía de estimación de proyectos de software explica cómo desglosar el trabajo hasta ese nivel antes de incluirlo en el contrato.
Criterios de aceptación, hitos y pago
El pago debe seguir al trabajo aceptado, y la aceptación debe ser una prueba objetiva, no una opinión. Los criterios de aceptación son las comprobaciones que determinan si un entregable está «terminado», y vincular el pago a ellos es lo que protege a ambas partes: el desarrollador obtiene un flujo de caja previsible y usted solo paga el trabajo que supera la prueba. Este único vínculo entre aceptación y pago evita más disputas que cualquier otra condición.
En la práctica, estructúrelo así:
- Divida el desarrollo en hitos. La mayoría de los proyectos bien gestionados usan hitos separados por unas cuatro a ocho semanas, cada uno con entregables definidos y una demostración.
- Asocie pruebas de aceptación a cada hito. Criterios objetivos y por escrito (funcionalidades presentes, pruebas superadas, umbrales de rendimiento cumplidos) para que «terminado» sea verificable y no una cuestión de gusto.
- Vincule un pago a cada hito aceptado. El pago se libera cuando el hito supera la aceptación, con una ventana de revisión definida y un proceso para tratar los defectos razonables antes de dar la conformidad.
Evite dos extremos: grandes pagos iniciales sin ningún control de aceptación (usted asume todo el riesgo) y pago solo al final (lo asume todo el desarrollador, y presupuesta en consecuencia). El pago por hitos condicionado a la aceptación reparte el riesgo de forma justa y mantiene a ambas partes honestas sobre el avance.
Un ejemplo sencillo de calendario para el desarrollo de un MVP a precio cerrado muestra cómo encajan las piezas:
| Hito | Entregable | Prueba de aceptación | Pago |
|---|---|---|---|
| Arranque | SOW firmado, acceso a los entornos, plan del proyecto | Plan revisado y aprobado | 15% |
| Hito 1 (~sem. 4–6) | Backend principal + autenticación | Funcionalidades presentes, pruebas superadas en staging | 25% |
| Hito 2 (~sem. 8–10) | Conjunto completo de funcionalidades, integraciones | Demostración frente a la lista de verificación de aceptación | 30% |
| Entrega final | Build validada por QA, código fuente, documentación | Conformidad de UAT, defectos clasificados | 20% |
| Liberación de la garantía | Fin del periodo de corrección de defectos | Sin defectos críticos/altos abiertos | 10% |
El reparto exacto es negociable, pero el patrón importa más que las cifras: un pago de arranque modesto financia la movilización, la mayor parte de los honorarios se libera contra hitos funcionales y probados, y una retención final se mantiene hasta que concluye el periodo de garantía.
Control de cambios y desviación del alcance (scope creep)
Una cláusula de control de cambios es lo que permite que el alcance evolucione sin caos ni conflicto. Define un proceso escrito para ajustar el alcance, el plazo o el coste, de modo que una nueva petición se convierte en una decisión visible, con un precio y un efecto en el calendario, en lugar de una adición silenciosa que hace estallar el presupuesto sin que nadie lo note. La desviación del alcance (scope creep) es la forma más común en que un proyecto bien dotado de personal y bienintencionado acaba fracasando, y el control de cambios es su antídoto.
Un proceso viable es sencillo: cualquier cambio se plantea como una solicitud de cambio por escrito, se estima su impacto en coste y plazo, y solo avanza cuando ambas partes lo aprueban. Así se mantiene intacta la estructura original de precio cerrado o de hitos, y a la vez se dispone de una vía legítima para decir que sí a requisitos realmente nuevos. Sin él, ocurre una de dos cosas malas: o los cambios se absorben de manera informal hasta que se erosionan la calidad y los márgenes, o cada petición se convierte en una discusión. Decidir el mecanismo antes de necesitarlo es lo que mantiene colaborativo un desarrollo largo.
Depósito del código fuente en garantía (escrow): ¿lo necesita?
La cesión de la propiedad intelectual establece que el código es suyo; el depósito del código fuente en garantía (escrow) protege su capacidad de seguir usándolo si el desarrollador desaparece. Es un acuerdo independiente con un tercero: un agente de depósito independiente custodia una copia actualizada del código fuente, los scripts de compilación, la configuración de entornos y la documentación, y se la entrega a usted únicamente si se produce un evento desencadenante definido: la insolvencia del proveedor, el abandono del soporte o un incumplimiento grave del contrato.
El escrow importa más cuando no dispone de un equipo interno capaz de retomar una base de código desconocida, y menos cuando ya tiene acceso continuo al repositorio y podría asumir usted mismo la entrega. Si lo utiliza, la cláusula necesita tres precisiones para que merezca la pena la tarifa: qué se deposita exactamente (no solo la build final, sino el código fuente compilable), con qué frecuencia se actualiza y qué verificación realiza el agente de depósito antes de la liberación; un depósito sin probar que resulta estar incompleto cuando por fin se necesita es peor que no tener escrow.
Cómo negociar las condiciones del contrato antes de firmar
La mayoría de los primeros borradores llegan redactados para proteger al desarrollador, lo cual es un punto de partida normal y no una señal de alerta en sí mismo: su tarea es reajustarlo hacia el equilibrio, no tratar como irrazonable cada cláusula que le favorezca. Unos cuantos hábitos prácticos hacen que esa negociación sea más rápida y dé mejores resultados:
- Revise primero las cuatro cláusulas más importantes: cesión de la propiedad intelectual, criterios de aceptación, estructura de pagos y límites de responsabilidad, y considere secundario todo lo demás hasta que estén resueltas.
- Pregunte «por qué» antes de pedir un cambio. Un límite de responsabilidad o una cláusula amplia de retención de la propiedad intelectual a veces existe por una razón defendible (límites de seguro, frameworks reutilizables); entenderla suele producir un compromiso más rápido y limpio que una reescritura general.
- Rechace el silencio, no solo la mala redacción. Un contrato que no dice nada sobre la entrega del código fuente o el control de cambios es un riesgo mayor que otro con una cláusula agresiva pero negociable, porque el silencio juega en su contra por defecto.
- Ponga cifras a todo lo vago. «Soporte razonable» pasa a ser un tiempo de respuesta definido; «colaboración continua», una cadencia de hitos. La ambigüedad que suena amable en una llamada comercial sale cara en una disputa.
- Haga que un asesor jurídico revise las cláusulas de propiedad intelectual, responsabilidad y jurisdicción incluso cuando el resto del acuerdo sea estándar: estas tres cláusulas concentran la mayor parte del riesgo financiero de todo el contrato.
Señales de alerta que conviene vigilar antes de firmar
Si un contrato presenta alguna de las señales siguientes, considérelo un motivo para renegociar antes de firmar: cada una puede dejarle pagando por un software que no es suyo o que no puede mantener. Estas son las señales de alerta recurrentes que vemos en los acuerdos de desarrollo de software débiles:
- Sin cesión explícita de la propiedad intelectual. El silencio sobre la titularidad favorece por defecto al desarrollador según la ley de EE. UU.: corregirlo no es negociable.
- Alcance vago y sin criterios de aceptación. Si «terminado» no está definido, no puede verificar ni pagar nada con seguridad.
- Pago no vinculado a entregables aceptados. Los pagos grandes por adelantado o basados en fechas, desligados del software funcionando, trasladan el riesgo a usted.
- Sin proceso de control de cambios. Garantiza o bien desviaciones del alcance (scope creep) o bien fricción constante.
- Condiciones de responsabilidad ausentes o ilimitadas. Ambos extremos son peligrosos; lo que conviene es un tope claro y recíproco.
- Sin entrega del código fuente a la salida. Sin ella, la rescisión puede dejarle con un producto que no puede ejecutar ni mantener.
- Sin cláusula de confidencialidad ni de protección de datos. Especialmente crítica si el desarrollador va a tratar datos personales o regulados.
La presencia de estas cláusulas es también una señal sobre el proveedor: un socio que plantea abiertamente la propiedad intelectual, la aceptación y la responsabilidad antes que las funcionalidades le está diciendo cómo se comportará bajo presión. Nuestra guía sobre cómo elegir una empresa de desarrollo de software explica en qué más fijarse además del papeleo.
Modelo de contrato de desarrollo de software: qué incluir
Un modelo de contrato de desarrollo de software es una útil lista de verificación inicial, pero nunca debe firmarse sin cambios: la estructura de cláusulas es reutilizable, los detalles son siempre propios de cada proyecto. Use un modelo para garantizar que no falte ninguna cláusula esencial; después adapte cada una y haga que un asesor jurídico revise las condiciones de propiedad intelectual, responsabilidad y cumplimiento. Un modelo completo debe contener, por orden:
- Partes y definiciones: quién contrata y los términos clave definidos una sola vez.
- Alcance del trabajo y entregables: con un SOW detallado, normalmente como anexo.
- Modelo de precios y calendario de hitos: precio cerrado, T&M o híbrido, con un plan de pagos.
- Criterios de aceptación y proceso de revisión: pruebas objetivas y una ventana de conformidad definida.
- Procedimiento de control de cambios: cómo se plantean, valoran y aprueban las solicitudes.
- Titularidad de la propiedad intelectual, cesión y licencias: además del tratamiento de la propiedad intelectual preexistente y de código abierto.
- Confidencialidad y protección de datos: condiciones del NDA y cualquier obligación del RGPD y del DPA.
- Garantías, soporte e indemnización: periodo de corrección de defectos y protección frente a reclamaciones de terceros.
- Limitación de responsabilidad: un tope recíproco y claramente expresado.
- Rescisión, salida y traspaso: incluida la transferencia del código fuente y de los activos.
- Ley aplicable y resolución de disputas: jurisdicción y cómo se resuelven las disputas.
Las plantillas denominadas «muestra», «ejemplo» o «formato» comparten todas este esqueleto; el valor que usted aporta está en los anexos: los entregables exactos, las pruebas de aceptación y las condiciones de protección de datos que hacen que el acuerdo se ajuste a su proyecto y no a uno genérico.
Preguntas frecuentes
¿Qué es un contrato de desarrollo de software?
Un contrato de desarrollo de software es el acuerdo jurídicamente vinculante entre un cliente y un desarrollador o agencia que define qué se construirá, quién es titular del código resultante, cómo y cuándo se paga y quién asume cada riesgo. También llamado acuerdo de desarrollo de software, convierte una propuesta en obligaciones exigibles al fijar el alcance, los entregables, los criterios de aceptación, la titularidad de la propiedad intelectual, la confidencialidad, las garantías, la responsabilidad y las condiciones de salida. Su función central es eliminar la ambigüedad antes de que se convierta en una disputa.
¿Quién es el titular del código en un contrato de desarrollo de software?
Por defecto, el desarrollador. Según la ley de derechos de autor de EE. UU., el código escrito por un contratista independiente pertenece al contratista salvo que el contrato lo ceda expresamente al cliente. Para ser titular de lo que paga, el acuerdo necesita una cesión escrita de la propiedad intelectual o una disposición de obra por encargo (work made for hire) que transfiera todos los derechos con el pago. Sin esa cláusula, el desarrollador puede conservar la titularidad o la cotitularidad de un software que usted financió, de modo que la titularidad de la propiedad intelectual es la condición más importante que hay que acertar.
¿Qué debe incluir un contrato de desarrollo de software?
Un contrato de desarrollo de software completo incluye un alcance del trabajo y entregables; criterios de aceptación vinculados al pago; un modelo de precios y un calendario de hitos; un proceso de control de cambios; la titularidad de la propiedad intelectual y las condiciones de licencia; confidencialidad y protección de datos; garantías y soporte; indemnización; una limitación de responsabilidad; y condiciones de rescisión y salida con entrega del código fuente. Cada cláusula responde a una pregunta (qué, cuándo, quién es titular, quién responde y cómo termina), de modo que nada importante queda al supuesto.
¿Es mejor un contrato de precio cerrado o de tiempo y materiales para desarrollar software?
Ninguno es mejor en todos los casos; depende de lo bien definido que esté el alcance. El precio cerrado encaja con un alcance muy especificado y estable y traslada el riesgo de sobrecostes al desarrollador, pero se resiste al cambio. El tiempo y materiales encaja con el trabajo que evoluciona y paga el esfuerzo real, con flexibilidad a costa de certeza presupuestaria. La mejor práctica de 2026 para la mayoría de los proyectos a medida de menos de unos $300,000 es un modelo híbrido: construcción inicial o MVP a precio cerrado y, después, una iguala de tiempo y materiales para la iteración y el mantenimiento.
¿Cuáles son las mayores señales de alerta en un contrato de desarrollo de software?
Las mayores señales de alerta son: la ausencia de una cesión explícita de la propiedad intelectual (puede que el código no sea suyo); un alcance vago sin criterios de aceptación medibles; un pago no vinculado a entregables aceptados; la falta de un proceso de control de cambios; unas condiciones de responsabilidad ilimitadas o ausentes; la falta de entrega del código fuente en caso de rescisión; y la falta de una cláusula de confidencialidad o de protección de datos. Cualquiera de ellas puede dejarle pagando por un software que no es suyo o que no puede mantener, así que considere su ausencia un motivo para renegociar antes de firmar.
¿Necesito un modelo de contrato de desarrollo de software o un acuerdo a medida?
Un modelo de contrato de desarrollo de software es una útil lista de verificación inicial, pero nunca debe firmarse sin cambios. Los modelos ofrecen la estructura estándar de cláusulas (alcance, propiedad intelectual, aceptación, pago, responsabilidad), pero los detalles que más importan (entregables exactos, pruebas de aceptación, alcance de la propiedad intelectual, obligaciones de protección de datos y jurisdicción) son propios de cada proyecto y a menudo requieren la revisión de un abogado. Use un modelo para asegurarse de que no falte ninguna cláusula esencial; después adapte cada una y haga que un asesor jurídico revise las condiciones de propiedad intelectual, responsabilidad y cumplimiento.
¿Qué es el depósito del código fuente en garantía (escrow) y lo necesito?
El depósito del código fuente en garantía (source-code escrow) es un acuerdo con un tercero por el que el desarrollador entrega el código fuente actual, los scripts de compilación y la documentación a un agente de depósito independiente, que solo los libera al cliente si se producen eventos desencadenantes definidos, como que el proveedor cese su actividad, abandone el soporte o incumpla el contrato. Importa sobre todo cuando depende del proveedor para el mantenimiento continuo y no tiene un equipo interno que pueda retomar la base de código. No sustituye a una cláusula de cesión de la propiedad intelectual: el escrow protege la continuidad de una base de código funcional que ya es suya, mientras que la cesión establece la titularidad en primer lugar.
¿Quién es el titular del código generado por IA en un contrato de desarrollo de software?
Trate el resultado asistido por IA igual que cualquier otro entregable: la titularidad se rige por la cláusula de cesión, no por la herramienta que lo produjo. La cuestión abierta es si los fragmentos generados por IA gozan de protección de derechos de autor en una jurisdicción determinada y si las condiciones de servicio del proveedor de IA imponen restricciones o derechos retenidos propios sobre el resultado. Un contrato preparado para 2026 debería exigir al desarrollador que declare el uso sustancial de herramientas de generación de código con IA y que confirme que todo resultado asistido por IA queda cubierto por la misma cesión de propiedad intelectual y está libre de reclamaciones de terceros sobre datos de entrenamiento o licencias, igual que el código escrito a mano.
Publicado el 21 de julio de 2026; última actualización: 25 de septiembre de 2026, con el depósito del código fuente en garantía (escrow), la titularidad del código generado por IA y un calendario de ejemplo de pagos por hitos. Esta guía es información general sobre los contratos de desarrollo de software, no asesoramiento jurídico; las condiciones de propiedad intelectual, responsabilidad, protección de datos y jurisdicción varían según el país y el proyecto. Los puntos sobre derechos de autor en EE. UU., aceptación y precios híbridos reflejan la práctica habitual del sector y jurídica en 2026: haga que un asesor jurídico cualificado revise su acuerdo concreto antes de firmar.
