Cuatro cláusulas que deciden quién manda en tu proyecto de tecnología
Un proyecto de tecnología se gana o se pierde en el contrato, mucho antes de la primera línea de código. El alcance, el cronograma y el precio ocupan las primeras páginas y reciben toda la atención. Las cuatro cláusulas que definen quién conserva el control cuando el proyecto crece, cambia o termina viven más abajo, en el texto que casi nadie discute.
Este artículo recorre esas cuatro cláusulas con una pregunta para cada una, qué respuesta buscar y qué dejar escrito. Al final encuentras una lista para llevar a tu próxima reunión de contratación.
1. Propiedad: ¿de quién es el código al terminar?
El software que un proveedor construye para ti tiene un autor, y la ley asigna por defecto los derechos al autor. Si el contrato guarda silencio, el código que pagaste puede seguir siendo del proveedor y tú recibes, en el mejor caso, una licencia de uso.
Lo que conviene pedir:
- Cesión de los derechos patrimoniales sobre todo lo desarrollado específicamente para tu empresa, o una licencia perpetua, irrevocable y transferible.
- Una lista clara de los componentes previos del proveedor y de terceros (librerías, frameworks, módulos propios) que se incorporan al proyecto, con el tipo de licencia de cada uno.
- Entrega del código fuente completo y de la documentación técnica en un repositorio al que tengas acceso desde el primer sprint.
La propiedad decide quién puede mantener, modificar y extender el sistema. Con el código a tu nombre, cada evolución futura se puede hacer con el equipo que elijas.
2. Datos: ¿puedes llevártelos, y en cuántos días?
Los datos de clientes, operación y precios son el activo que más rinde con los años. Cuando viven dentro del diseño de otro, su disponibilidad depende de la hoja de ruta y del humor comercial de ese tercero.
Lo que conviene pedir:
- Exportación completa en formato abierto y documentado (CSV, JSON, SQL estándar), bajo demanda y sin costo adicional.
- Un plazo máximo escrito para entregar la exportación, medido en días hábiles.
- Una cláusula de confidencialidad y tratamiento de datos personales alineada con la Ley 1581 de 2012, con indicación de dónde se alojan los datos y quién tiene acceso.
- Borrado verificable de tus datos en los sistemas del proveedor al terminar la relación.
Una prueba sencilla: pide que el proveedor haga una exportación de muestra durante el proyecto. Si funciona en la semana cuatro, funcionará el día que la necesites de verdad.
3. Cambios: ¿cómo se cobra y se aprueba un cambio de alcance?
Todo proyecto de software cambia. El negocio aprende mientras se construye, y ese aprendizaje genera solicitudes nuevas. Ahí suelen nacer los sobrecostos de un proyecto de software: el cambio ocurre en una conversación, se ejecuta sin papel y se cobra al final.
Lo que conviene pedir:
- Un procedimiento de control de cambios con formato fijo: descripción, impacto en tiempo, impacto en costo y aprobación.
- Una tarifa o unidad de cobro acordada de antemano para los cambios, de modo que cada solicitud se valore con la misma regla.
- Un aprobador nombrado de tu lado y uno del lado del proveedor, con autoridad real para decidir.
- Una regla de prioridad: qué entra, qué sale y qué se mueve cuando un cambio ocupa espacio en el cronograma.
Un cambio bien gestionado queda registrado, valorado y aprobado antes de que alguien escriba código. Esa disciplina protege a las dos partes.
4. Salida: ¿qué pasa el día que termina el contrato?
Todos los contratos terminan: por cumplimiento, por cambio de estrategia o por desacuerdo. La salida ordenada se negocia el día de la firma, cuando la relación es buena y las dos partes comparten el mismo interés.
Lo que conviene pedir:
- Un plazo de transición después de la terminación, con soporte para que otro equipo asuma el sistema.
- Entrega de documentación actualizada: arquitectura, accesos, procesos de despliegue, dependencias y credenciales administrativas.
- Acceso a repositorios, entornos y cuentas de infraestructura a nombre de tu empresa.
- Una sesión de traspaso de conocimiento con el equipo que lo reemplaza.
Mide el costo de salida antes de firmar. Si cambiar de proveedor exige más de un año o obliga a reescribir tu proceso, el control ya pasó a manos del proveedor, aunque el contrato diga lo contrario.
Una lista para tu próxima reunión de contratación
| Cláusula | Pregunta | Respuesta que buscas |
|---|---|---|
| Propiedad | ¿De quién es el código al terminar? | Cesión de derechos o licencia perpetua, con inventario de componentes de terceros |
| Datos | ¿Puedo llevármelos y en cuántos días? | Exportación completa en formato abierto, con plazo escrito |
| Cambios | ¿Cómo se cobra y se aprueba un cambio? | Procedimiento con formato fijo, tarifa acordada y aprobadores nombrados |
| Salida | ¿Qué pasa el día que termina el contrato? | Transición, documentación y accesos a tu nombre |
Cuatro preguntas caben en una reunión de media hora. Un proveedor sólido las responde sin incomodidad y las convierte en cláusulas. Una respuesta evasiva en cualquiera de ellas es información valiosa sobre cómo será la relación durante el proyecto.
Cómo lo hacemos en STG
En Simphony Technologies Group construimos software y sistemas con IA para empresas ambiciosas de Latinoamérica. Estas cuatro cláusulas forman parte de cómo contratamos: el código es de nuestros clientes, sus datos salen cuando lo piden, los cambios pasan por un procedimiento claro y la salida queda pactada desde el primer día.
Si estás por firmar un proyecto de tecnología y quieres una segunda lectura del contrato, escríbenos en simphony.com.co.
Este artículo ofrece orientación general para ejecutivos y no reemplaza la asesoría de un abogado sobre tu contrato específico.
