Gobierno de Proveedores de Software: SLA, Propiedad Intelectual y Salida
El riesgo más caro de un proyecto de software no suele ser que el proveedor lo haga mal: es que la empresa descubra, dos años después, que no es dueña del código, que no tiene acceso a la infraestructura donde corre su operación y que nadie definió qué pasa si la relación se termina. Y eso no se arregla con una buena ejecución técnica; se arregla —o no— en el contrato.
Elegir bien al proveedor es la primera mitad del problema y la cubrimos en cómo elegir una agencia de desarrollo de software. Esta guía es la segunda: qué debe quedar por escrito para que la empresa conserve el control de un activo que va a operar durante años.
1. Propiedad intelectual: quién es dueño de qué
Es la cláusula que más empresas firman sin leer y la que más caro se paga. En un desarrollo a la medida, la regla que protege al cliente es la cesión total de derechos patrimoniales sobre el código desarrollado específicamente para el proyecto, efectiva al pago, y por escrito.
Hay tres capas que conviene distinguir, porque no todas se ceden ni tienen por qué hacerlo:
| Capa | Qué es | Quién debería ser dueño |
|---|---|---|
| Código del proyecto | Lo escrito para tu negocio | El cliente, cesión total |
| Componentes propios del proveedor | Librerías internas reutilizables | El proveedor, con licencia perpetua e irrevocable para el cliente |
| Software de terceros | Librerías de código abierto, servicios | Sus respectivos titulares, bajo su licencia |
Dos señales de alarma concretas: un contrato que solo concede una licencia de uso sobre el código del proyecto en vez de cederlo, y uno que guarda silencio sobre los componentes propios del proveedor. En el primer caso no puedes contratar a otro para que lo modifique; en el segundo, el día que cambies de proveedor descubres que una pieza central del sistema no viene contigo.
Pide también la lista de dependencias de terceros con su licencia. Una librería con licencia copyleft fuerte incrustada en el núcleo de un producto que planeas comercializar es un problema que se detecta barato antes de firmar y caro después.
2. Acceso a la infraestructura y a los repositorios
La propiedad del código no sirve de nada si no tienes dónde tomarlo. La regla práctica es simple: las cuentas raíz de todo lo que sostiene tu operación deben estar a nombre de tu empresa, con el proveedor invitado como colaborador y no al revés.
Esto aplica al proveedor de nube, al registrador del dominio, al repositorio de código, a las cuentas de las tiendas de aplicaciones, a la pasarela de pagos y a los servicios de correo y mensajería. Es la diferencia entre cambiar de proveedor en una semana y quedar bloqueado durante meses.
Pide además que el repositorio reciba el código de forma continua desde el primer día, no en una entrega final. Un repositorio al que tu empresa tiene acceso durante todo el proyecto es también la mejor verificación de que el trabajo avanza.
3. Niveles de servicio que se puedan medir
Un SLA sirve cuando define eventos observables y consecuencias. Los cuatro parámetros que no deberían faltar:
- Disponibilidad mensual comprometida. El 99.9% permite unos 43 minutos de caída al mes; el 99.5%, unas 3.6 horas. La diferencia de costo entre ambos niveles es real, así que conviene elegir el que corresponde a la criticidad del sistema y no el más alto por reflejo.
- Tiempo de respuesta y de resolución por severidad. Separados: responder no es resolver. Y con la severidad definida por impacto en el negocio, no por criterio técnico del proveedor.
- Ventanas de mantenimiento. Cuándo puede haber indisponibilidad planeada y con cuánta anticipación se avisa.
- Consecuencia del incumplimiento. Normalmente un crédito sobre la mensualidad. Un SLA sin consecuencia es una declaración de intenciones.
Los rangos de inversión asociados al soporte continuo están en cuánto cuesta mantener un software al año: entre el 10% y el 35% de la inversión inicial según la criticidad del sistema.
4. Datos personales: el proveedor es encargado del tratamiento
Si el sistema procesa datos de personas —clientes, empleados, usuarios—, tu empresa es responsable del tratamiento y el proveedor es encargado. Esa relación exige un acuerdo escrito, y la responsabilidad ante el titular y ante la autoridad no se delega: sigue siendo tuya aunque el incidente ocurra del lado del proveedor.
El acuerdo debe cubrir al menos las finalidades autorizadas, la prohibición de usar los datos para fines propios, las medidas de seguridad, el régimen de subcontratación, la obligación de notificar incidentes en un plazo definido y la devolución o supresión certificada al terminar. En Colombia el marco aplicable está en la Ley 1581 de 2012 y sus decretos reglamentarios, desarrollado en qué debe cumplir tu sitio o app frente a la Ley 1581.
Un punto que se pasa por alto con frecuencia: los datos de producción usados en ambientes de prueba. Si el proveedor trabaja con copias reales de tu base de datos, eso es tratamiento de datos personales y necesita quedar regulado —o, mejor, sustituido por datos anonimizados.
5. El plan de salida se escribe al principio
Ninguna relación con un proveedor dura para siempre, y el momento de definir la salida es cuando ambas partes tienen incentivos para ser razonables: antes de firmar. Un plan de salida útil especifica:
- Qué se entrega: código fuente completo con su historial, documentación de arquitectura, credenciales, scripts de despliegue y datos en formato estándar y documentado.
- En cuánto tiempo: un plazo concreto desde la notificación, no "en un tiempo razonable".
- Con qué acompañamiento: un periodo de transición pagado con disponibilidad definida para resolver dudas del equipo entrante.
- Y en qué estado: que el sistema quede desplegable por un tercero competente a partir de lo entregado. Es la cláusula que evita la entrega formalmente completa pero prácticamente inservible.
Conviene también un depósito de garantía de código fuente (escrow) cuando el sistema es crítico y el proveedor es pequeño: un tercero custodia una copia que se libera si el proveedor desaparece o incumple.
Preguntas frecuentes
¿Quién es el dueño del código en un desarrollo a la medida? Depende de lo que diga el contrato, no de quién pagó. Por defecto, los derechos patrimoniales nacen en cabeza de quien desarrolla, así que la cesión al cliente debe estar escrita de forma expresa. Si el contrato solo concede una licencia de uso, la empresa no puede contratar a un tercero para modificar el sistema.
¿Qué nivel de disponibilidad debo exigir en un SLA? El que corresponda al impacto real de una caída. Para sistemas internos de oficina, 99.5% suele ser suficiente; para plataformas transaccionales de cara al cliente, 99.9%. Exigir 99.99% en un sistema que no lo necesita encarece la arquitectura sin beneficio.
¿Puedo cambiar de proveedor sin rehacer el sistema? Sí, si desde el inicio tienes cesión de derechos, acceso al repositorio con el historial completo, cuentas raíz de infraestructura a tu nombre y documentación de despliegue. Sin esos cuatro elementos, un cambio de proveedor se parece bastante a un proyecto nuevo.
¿El proveedor puede reutilizar en otros clientes lo que hizo para mí? Debe quedar explícito. Lo razonable es que pueda reutilizar sus componentes genéricos y conocimiento general, pero no la lógica de negocio específica ni nada que revele información confidencial de tu operación.
¿Qué pasa con la responsabilidad si hay una fuga de datos del lado del proveedor? Frente al titular del dato y frente a la autoridad, la responsabilidad principal sigue siendo de tu empresa como responsable del tratamiento. El contrato regula cómo se reparte internamente entre las partes, pero no traslada la obligación legal hacia afuera. Por eso el acuerdo de encargo y las medidas de seguridad verificables importan tanto.
Un contrato claro protege a las dos partes
Nada de esto es una defensa contra un mal proveedor: es la estructura que permite que una buena relación dure años sin convertir a la empresa en rehén de su propio sistema. Un proveedor serio no pone reparos a ninguno de estos cinco puntos, porque también lo protegen a él.
En BigBoc trabajamos con empresas de Colombia y Latinoamérica en React, Next.js, Node.js e inteligencia artificial, con cesión de derechos sobre el código del proyecto, infraestructura a nombre del cliente y documentación de despliegue desde el primer día.
¿Vas a firmar con un proveedor y quieres revisar estos puntos antes? Solicita tu cotización gratuita en bigboc.com/cotizacion y recibe una propuesta con alcance, tiempos y costos en menos de 24 horas. ¿Prefieres consultarnos tu caso primero? Escríbenos por el formulario de contacto.