Propiedad intelectual en proyectos de outsourcing TI: quién es dueño del código y por qué importa
- Por Amparo Silva | Amsoft
Introducción
Existe un error frecuente y costoso en los proyectos de desarrollo de software por encargo: asumir que quien paga por el desarrollo automáticamente se convierte en propietario del código. En Chile, y en la mayoría de los marcos legales de América Latina, esa suposición no tiene respaldo jurídico si no está establecida de manera explícita en el contrato.
Cuando una empresa contrata a un proveedor externo ya sea una agencia, un equipo de desarrollo en régimen de outsourcing o un desarrollador independiente, para construir una plataforma, un sistema interno o una aplicación, está invirtiendo en lo que puede convertirse en uno de sus activos más valiosos. Sin embargo, si el contrato no establece con claridad quién es el titular del código, de la documentación y de los componentes desarrollados, ese activo puede no pertenecerle legalmente.
El problema no es hipotético. Proveedores que retienen el código fuente como mecanismo de fidelización, empresas que descubren al querer cambiar de proveedor que no tienen acceso al repositorio, o proyectos que no pueden ser mantenidos por terceros porque la documentación técnica nunca fue entregada: estos son escenarios reales que ocurren cuando la propiedad intelectual no se gestiona adecuadamente desde el inicio de la relación contractual.
Este artículo explora el marco legal que regula la propiedad intelectual del software en Chile, cuáles son los elementos que deben estar definidos en un contrato de outsourcing TI, qué señales de alerta indican que una propuesta no protege adecuadamente al cliente, y cómo estructurar una relación de desarrollo externo que garantice que el activo tecnológico construido pertenece efectivamente a quien lo financia.
1. El marco legal: qué dice la Ley N° 17.336 sobre la titularidad del software
1.1 La protección nace desde la creación, no desde el pago
En Chile, el software está protegido como obra intelectual por la Ley N° 17.336 sobre Propiedad Intelectual, clasificado de manera análoga a las obras literarias. Esto significa que el código fuente, el código objeto y la documentación asociada están amparados por derechos de autor desde el momento de su creación, sin necesidad de registro previo.
La ley reconoce dos tipos de derechos sobre una obra. Los derechos morales son irrenunciables e inalienables: reconocen la autoría de quien creó el código y no pueden transferirse. Los derechos patrimoniales, en cambio, son los que permiten explotar económicamente el software (venderlo, licenciarlo, reproducirlo o modificarlo) y estos sí pueden transferirse mediante contratos.
La regla general para el caso de un prestador de servicios independiente sin relación laboral con la empresa contratante es clara: el autor del código es el propio desarrollador o proveedor, salvo que exista un contrato que establezca expresamente la cesión de derechos patrimoniales. Esto significa que si una empresa contrata una agencia de desarrollo y el contrato no incluye una cláusula de cesión, técnicamente el proveedor conserva la titularidad sobre el código.
1.2 La excepción del trabajador dependiente y su aplicación al outsourcing
La ley sí establece una excepción para los trabajadores en relación laboral: cuando un empleado dependiente crea software en el desempeño de sus funciones laborales, la titularidad corresponde a la empresa empleadora, salvo estipulación escrita en contrario. Sin embargo, esta excepción no aplica a los proveedores externos en régimen de outsourcing, que no tienen vínculo laboral con el cliente.
Esta distinción es crítica para entender por qué el contrato es el instrumento central en cualquier proyecto de desarrollo externo. El registro ante el Departamento de Derechos Intelectuales (DDI) del Ministerio de las Culturas no crea la protección, esta nace automáticamente, pero sí otorga una fecha cierta y un respaldo probatorio en caso de disputas, y puede ser requerido por inversionistas o en procesos de adquisición como parte del due diligence de propiedad intelectual.
2. Los elementos que deben estar definidos en el contrato
2.1 Cesión de derechos patrimoniales
La cláusula más importante en un contrato de desarrollo de software por encargo es la cesión de derechos patrimoniales. Esta cláusula debe establecer explícitamente que, una vez completado el trabajo y pagados los honorarios, todos los derechos de propiedad intelectual sobre el software desarrollado se transfieren al cliente.
Una cesión bien redactada debe cubrir no solo el código fuente sino también el código objeto, la documentación técnica, las interfaces de usuario, los esquemas de base de datos, las especificaciones funcionales y cualquier otro componente desarrollado específicamente para el proyecto. La ambigüedad en el alcance de la cesión es una fuente frecuente de conflictos posteriores.
2.2 Entrega del código fuente y acceso al repositorio
La cesión de derechos patrimoniales sin entrega efectiva del código fuente es una cesión incompleta. Un contrato de outsourcing TI debe establecer con claridad que el proveedor entregará el código fuente completo, no solo los binarios o ejecutables al cliente, en un formato legible y acompañado de la documentación necesaria para que pueda ser mantenido o evolucionado por terceros.
Esto incluye el acceso al repositorio de control de versiones con el historial completo de cambios, no solo una instantánea del estado final. Un desarrollador o equipo que recibe un proyecto sin historial de versiones tiene una visión parcial del sistema: no puede entender por qué se tomaron ciertas decisiones de diseño ni cómo evolucionó el código en el tiempo.
2.3 Identificación y gestión de componentes de terceros
Un aspecto frecuentemente omitido en los contratos de desarrollo es la identificación de los componentes de código abierto o licenciados que el proveedor incorpora en el desarrollo. Este punto tiene implicaciones legales significativas: una librería bajo licencia GPL, por ejemplo, puede obligar a publicar todo el código fuente que la incorpora si no se gestiona correctamente.
El contrato debe exigir al proveedor que identifique explícitamente todos los componentes de terceros utilizados, que garantice que sus licencias son compatibles con el uso comercial previsto por el cliente y que el cliente tenga derecho a acceder y usar esos componentes de manera independiente. La ausencia de esta cláusula puede crear dependencias técnicas y legales que el cliente desconoce.
2.4 Confidencialidad y no divulgación
El desarrollo de software implica que el proveedor accede a información estratégica del cliente: modelos de negocio, procesos internos, datos de clientes, arquitecturas de sistemas. El contrato debe incluir obligaciones de confidencialidad que cubran tanto la duración del proyecto como un período razonable posterior a su conclusión, y que establezcan consecuencias claras en caso de incumplimiento.
3. La dependencia del proveedor: el riesgo que los contratos deben prevenir
3.1 Qué es el vendor lock-in en el desarrollo de software
La dependencia del proveedor conocida en el ámbito tecnológico como vendor lock-in, ocurre cuando una empresa queda atrapada en una relación con un proveedor porque el costo técnico, económico u operativo de cambiar es demasiado alto. En el contexto del desarrollo de software por encargo, este fenómeno puede manifestarse de maneras que no siempre son evidentes al momento de firmar el contrato.
Las señales más comunes de un contrato que genera dependencia no deseada incluyen: código entregado sin documentación técnica que permita su comprensión por terceros, ausencia de cláusula de entrega del código fuente, componentes críticos del sistema que solo pueden ser mantenidos por el proveedor original, o arquitecturas diseñadas de manera que la migración a otro equipo sea técnicamente compleja sin motivo funcional justificado.
3.2 Consecuencias concretas de una mala gestión de la propiedad intelectual
Las consecuencias de no haber gestionado adecuadamente la propiedad intelectual en un contrato de outsourcing suelen aparecer en momentos críticos: cuando la empresa decide cambiar de proveedor, cuando necesita escalar el desarrollo con un equipo adicional, cuando un inversionista realiza due diligence antes de una ronda de capital, o cuando el proveedor original enfrenta problemas (financieros, operativos o legales) que afectan la continuidad del servicio.
Un checklist de due diligence de propiedad intelectual en proyectos tecnológicos revisa invariablemente la cadena de cesiones de todos los desarrolladores que contribuyeron código, el registro del software ante el DDI, los contratos de desarrollo y mantenimiento vigentes, y el inventario de componentes de código abierto con sus licencias. Si esa documentación no existe o está incompleta, el proceso de due diligence puede ralentizarse o comprometerse.
4. Señales de alerta en una propuesta de outsourcing
4.1 Lo que debe preocupar antes de firmar
No todas las propuestas de outsourcing de desarrollo explicitan cómo gestionan la propiedad intelectual. Antes de firmar, hay preguntas cuyas respuestas son determinantes. ¿El contrato incluye una cláusula de cesión de derechos patrimoniales? ¿Se entregará el código fuente completo o solo los binarios? ¿Quién tendrá acceso al repositorio durante el proyecto y al concluirlo? ¿Cómo se identifican y documentan los componentes de terceros utilizados?
Las señales de alerta más frecuentes incluyen: contratos que no mencionan el código fuente ni su entrega, propuestas que no identifican los componentes de terceros utilizados, proveedores que no garantizan la originalidad del software desarrollado, ausencia de procedimiento de aceptación con criterios objetivos de entrega, y ausencia de cláusula de confidencialidad o con alcance insuficiente.
Las señales de alerta más frecuentes incluyen: contratos que no mencionan el código fuente ni su entrega, propuestas que no identifican los componentes de terceros utilizados, proveedores que no garantizan la originalidad del software desarrollado, ausencia de procedimiento de aceptación con criterios objetivos de entrega, y ausencia de cláusula de confidencialidad o con alcance insuficiente.
4.2 La distinción entre frameworks metodológicos y propiedad del cliente
Un punto de equilibrio importante en los contratos de desarrollo es la distinción entre los frameworks metodológicos o herramientas internas del proveedor, que este puede razonablemente retener como activo propio, y los desarrollos específicos creados para el cliente, que deben pertenecer íntegramente a este último.
Un proveedor puede usar metodologías, plantillas, arquitecturas de referencia o librerías internas en el desarrollo del proyecto. Esos componentes pre-existentes son herramientas de trabajo, no productos del encargo. Lo que debe pertenecer al cliente es el software desarrollado específicamente para su caso de uso, la documentación generada en el proyecto y todos los entregables acordados. Esta distinción debe estar reflejada con claridad en el contrato.
5. Cómo estructurar un contrato que proteja el activo tecnológico del cliente
5.1 Los elementos mínimos de un contrato bien estructurado
Un contrato de desarrollo de software por encargo que protege adecuadamente al cliente debe incluir, como mínimo: cláusula de cesión de derechos patrimoniales sobre todo lo desarrollado específicamente para el proyecto; obligación de entrega del código fuente completo con documentación técnica suficiente para su mantenimiento por terceros; identificación de componentes de terceros y garantía de compatibilidad de licencias; cláusula de confidencialidad con alcance y duración definidos; procedimiento de aceptación con criterios objetivos; y definición de qué ocurre con el código en caso de terminación anticipada del contrato.
La prevención mediante contratos adecuados es siempre más económica que el litigio posterior. Los conflictos de propiedad intelectual en el ámbito del software pueden resultar en la pérdida del activo más valioso de una empresa tecnológica: su código. Abordar estos puntos antes de iniciar el proyecto tiene un costo marginal; resolverlos después de que el conflicto se ha materializado puede ser extraordinariamente costoso.
5.2 La transferencia total como estándar de confianza
Más allá de los aspectos legales, la forma en que un proveedor gestiona la propiedad intelectual es un indicador de la calidad de la relación que propone. Un proveedor que transfiere al cliente la titularidad completa del código incluyendo documentación, repositorio con historial y componentes identificados, no crea dependencia artificial. Propone una relación donde el cliente puede crecer, cambiar o escalar sin restricciones.
Esta transparencia no es solo un valor ético. Es una señal de que el proveedor confía en la calidad de su trabajo y no necesita retener el código como mecanismo de fidelización. Para el cliente, es la garantía de que la inversión realizada en desarrollo es efectivamente suya.
Conclusión
La propiedad intelectual del software desarrollado en proyectos de outsourcing TI no es un tecnicismo legal secundario. Es la diferencia entre ser propietario de un activo estratégico y haber financiado el activo de otra empresa.
En Chile, la Ley N° 17.336 protege el software como obra intelectual desde su creación, pero la titularidad en proyectos con proveedores externos depende de lo que establezca el contrato. Sin cláusula de cesión, sin entrega del código fuente, sin identificación de componentes de terceros y sin documentación técnica adecuada, la empresa que pagó por el desarrollo puede no tener el control real sobre lo que construyó.
Gestionar bien estos aspectos desde el inicio del proyecto no es burocracia. Es la decisión que determina si el software desarrollado se convierte en un activo que la empresa puede mantener, escalar, auditar y transferir libremente, o en una dependencia de la que es difícil salir.
¿Cómo puede Amsoft ayudarte en este camino?
En Amsoft trabajamos con un modelo de propiedad intelectual donde el cliente es titular de todo lo desarrollado específicamente para su proyecto. Esto incluye el código fuente completo, la documentación técnica, los esquemas de arquitectura y todos los entregables acordados. Amsoft retiene únicamente sus frameworks metodológicos internos, que son herramientas de trabajo y no forman parte de la propiedad del cliente.
Al cierre de cada proyecto, el cliente recibe acceso completo al repositorio con historial de versiones, documentación suficiente para que cualquier equipo técnico pueda continuar el desarrollo, e identificación de todos los componentes de terceros utilizados con sus respectivas licencias.
Contáctanos para conversar sobre tu próximo proyecto de desarrollo y conocer en detalle cómo estructuramos los acuerdos de propiedad intelectual.
Este artículo fue elaborado por Amparo Silva, miembro del equipo de Amsoft, comprometida con la innovación y la excelencia en el ámbito tecnológico.
Referencias
- Von Marttens. (2026, Marzo). ¿Quién es el dueño de un software en Chile? Titularidad y propiedad intelectual. https://vonmarttens.cl/dueno-de-un-software-titularidad-propiedad-intelectual-chile/
- Von Marttens. (2026, Mayo). Checklist legal de propiedad intelectual para startups tech en Chile. https://vonmarttens.cl/checklist-legal-propiedad-intelectual-software-chile/
- Von Marttens. (2026, Marzo). Contrato de desarrollo de software y propiedad intelectual. https://vonmarttens.cl/contrato-de-desarrollo-de-software/
- AIJ Abogados. (2026, Enero). Cómo registrar software y apps en Chile: una guía completa. https://www.aijabogados.cl/como-registrar-software-y-apps-en-chile
- Departamento de Derechos Intelectuales (DDI). ¿Cómo se inscribe un programa de computación/software? https://www.propiedadintelectual.gob.cl/node/1234
- Biblioteca del Congreso Nacional de Chile. Ley N° 17.336 sobre Propiedad Intelectual. https://www.bcn.cl/leychile/navegar?idNorma=28933
- Deyel. (2026, Febrero). Soberanía Tecnológica: Cómo evitar el Vendor Lock-in. https://www.deyel.com/blog/soberania-tecnologica-vendor-lock-in-apps-criticas/
- IT Masters Mag. (2026, Febrero). Más allá del contrato: Estrategias de soberanía digital frente al Vendor Lock-in. https://www.itmastersmag.com/cloud/mas-alla-del-contrato-estrategias-de-soberania-digital-frente-al-vendor-lock-in/
- Consultoría Informática. (2026, Marzo). ¿Qué es el bloqueo de proveedor vendor lock-in? Cómo detectarlo y salir a tiempo. https://consultoriainformatica.net/que-es-el-bloqueo-de-proveedor-vendor-lock-in-como-detectarlo-y-salir-a-tiempo/