Propiedad de Código y Datos en Software Empresarial

En la negociación de un proyecto de software empresarial a medida, las cláusulas de propiedad del código y los datos suelen tratarse como tecnicismo legal. Casi siempre es error. Esas cláusulas determinan si la empresa cliente tiene un activo o un alquiler con apariencia de activo.

Este artículo desglosa qué significa propiedad real, qué patrones contractuales son trampa habitual y por qué la decisión importa más de lo que parece en el momento de firmar.

Qué significa propiedad real del código

Propiedad real implica tres cosas concretas.

Acceso al repositorio Git completo. No solo a las versiones desplegadas. Al historial completo de commits, ramas, documentación interna. Desde el primer día del proyecto, no al final.

Derecho de modificación y reuso sin permiso del proveedor. Si la empresa quiere modificar el código mañana, contratando a otro proveedor o equipo interno, no necesita pedir autorización ni pagar licencia.

Sin cláusulas de cesión inversa o license-back. El proveedor no se queda con derechos paralelos sobre el código construido para reutilizarlo con otros clientes salvo que se acuerde explícitamente.

Si falta cualquiera de las tres, la propiedad es nominal pero no operativa.

Qué significa propiedad real de los datos

Para datos, propiedad real implica:

Hosting en infraestructura cloud propiedad del cliente. Cuenta AWS, GCP, Azure o Vercel a nombre del cliente. No subcuentas o tenants del proveedor.

Acceso completo a la base de datos. Credenciales root, capacidad de hacer backups, exportar, migrar. Sin intermediación del proveedor.

Sin almacenamiento paralelo en sistemas del proveedor. Ningún dato del cliente vive en sistemas del proveedor más allá del tiempo estrictamente necesario para mantener el código (logs limitados, etc.).

Los patrones contractuales que comprometen la propiedad

Cuatro trampas habituales que aparecen en contratos de software a medida.

Trampa 1 — Licencia exclusiva en lugar de cesión de derechos

El contrato dice «el cliente recibe licencia exclusiva e ilimitada de uso del software». Suena fuerte. No lo es. El proveedor sigue siendo titular. Puede revocar la licencia bajo determinadas condiciones (impagos, terminación de la relación). El cliente nunca posee de verdad.

Cláusula correcta: «el cliente adquiere la titularidad plena y los derechos de explotación del código desarrollado».

Trampa 2 — Código en repositorios del proveedor con acceso limitado

Repositorio Git en cuenta GitHub o GitLab del proveedor, con cuenta del cliente añadida como colaborador. Al terminar la relación, el proveedor revoca el acceso. El cliente se queda con el código fuente comprimido entregado en el último hito pero pierde el histórico, las ramas, la documentación interna del repositorio.

Cláusula correcta: «el repositorio Git principal vive en cuenta del cliente desde el primer commit. El proveedor accede como colaborador con permisos definidos».

Trampa 3 — Hosting cloud bajo cuenta del proveedor

Infraestructura desplegada en AWS bajo cuenta del proveedor con el argumento «para facilitar gestión». Al terminar la relación, migrar la infraestructura a cuenta del cliente cuesta semanas y a menudo se cobra como proyecto aparte.

Cláusula correcta: «infraestructura cloud desplegada en cuenta del cliente desde el inicio. El proveedor accede como administrador con permisos auditables».

Trampa 4 — Cláusulas de no competencia camufladas

Aparece como «el cliente se compromete a no usar el código para servicios competidores del proveedor». Suena razonable. En la práctica limita la capacidad del cliente para evolucionar su propio negocio.

Cláusula correcta: ninguna restricción de uso una vez cedida la propiedad.

Por qué los proveedores incluyen estas cláusulas

No siempre por mala fe. Hay tres motivos legítimos que muchos proveedores tienen.

Primero, reutilización de patrones técnicos. El proveedor quiere poder reutilizar arquitectura genérica en otros clientes (lo que es legítimo si no es código específico del cliente).

Segundo, dependencia comercial. Quieren asegurar mantenimiento recurrente. Sin acceso, el cliente no puede irse fácilmente.

Tercero, miedo a perder control en la gestión de incidentes (si el cliente toca código sin avisar, las cosas se rompen).

Estos motivos se pueden resolver con cláusulas justas en lugar de cláusulas que comprometen la propiedad.

Cómo se negocia propiedad real sin perjudicar al proveedor

Cuatro acuerdos que protegen a ambas partes.

Acuerdo 1 — Repositorio en cuenta del cliente con SLA de mantenimiento. El proveedor accede para mantener. Si el cliente modifica fuera del proceso acordado, las garantías de mantenimiento se ajustan. Pero la propiedad es del cliente.

Acuerdo 2 — Documentación de arquitectura como parte del entregable. El cliente recibe documentación completa que permite que cualquier tercero competente continúe el mantenimiento. Esto reduce el coste de salida en ambas direcciones.

Acuerdo 3 — Período de transición definido. Si el cliente decide terminar la relación, hay 1-3 meses de transición pagados con tarifas claras donde el proveedor entrega el traspaso completo. Justo para ambos.

Acuerdo 4 — Reutilización de componentes genéricos delimitada. Si el proveedor reutiliza patrones técnicos no específicos del negocio del cliente, se especifica qué sí y qué no.

El argumento del «código en escrow»

Algunas empresas grandes piden cláusulas de escrow: el código vive en un tercero neutral y se libera al cliente si el proveedor desaparece. Es un patrón válido para proyectos críticos con proveedores pequeños.

Pero el escrow no sustituye a la propiedad. Es seguro adicional. El cliente sigue dependiendo del proveedor mientras este existe, y solo recupera el control si pasa algo grave.

Propiedad real desde el día uno es más sólido que escrow nominal.

Por qué importa para la empresa B2B mid-market

Hay tres razones estratégicas más allá del coste.

Razón 1 — Valoración patrimonial. Software a medida con propiedad real se contabiliza como activo. Sin propiedad real, no es activo: es un gasto recurrente disfrazado.

Razón 2 — Riesgo de continuidad. Si el proveedor cierra, es adquirido, o cambia su modelo de negocio, el cliente con propiedad real sigue operando. El cliente con licencia depende de decisiones externas.

Razón 3 — Capacidad de negociación. Un cliente con propiedad real puede pedir presupuesto a otro proveedor por el mantenimiento. Esa alternativa real disciplina al proveedor actual. Sin propiedad, no hay alternativa y el cliente paga lo que diga el proveedor.

Cómo trabajamos en Nexus

Nuestro modelo es propiedad real desde el día uno. Repositorio Git en cuenta del cliente. Hosting cloud en cuenta del cliente. Documentación entregada como parte de cada fase. Sin cláusulas de license-back, sin cláusulas de no competencia.

Si el cliente decide terminar la relación, se queda con todo: código, infraestructura, accesos, documentación. La transición está definida contractualmente y se ejecuta sin fricción.

Esto no es generosidad. Es lo que separa una boutique seria de un proveedor que intenta retener clientes por dependencia técnica.

Propiedad del Código y Datos en Software Empresarial a Medida: Por Qué Importa Más de lo que Parece