El escrow de software como salvavidas en la contratación pública en Colombia
La modernización tecnológica del Estado y de las empresas de servicios públicos en Colombia suele venderse bajo la promesa de la eficiencia: medidores inteligentes, plataformas de recaudo en la nube, sistemas SCADA automatizados para el control de fluidos. Sin embargo, detrás de la interfaz de usuario y las métricas de rendimiento, se esconde un riesgo silencioso que solo se vuelve evidente cuando la relación con el proveedor se rompe: la pérdida del control operativo.
El reciente debate en torno a EMCALI y su sistema de control de acueducto es el ejemplo perfecto de este dilema. Cuando la operación de una infraestructura crítica, como el suministro de agua potable de una ciudad, pasa a depender de un software propietario cerrado, la entidad contratante se enfrenta a una vulnerabilidad estratégica: si el proveedor quiebra, desaparece o decide unilateralmente suspender el soporte por una disputa comercial, la entidad queda con una "caja negra" que no puede mantener, auditar ni reparar. El agua deja de ser un problema de ingeniería hidráulica para convertirse en un problema de ingeniería de software y, fundamentalmente, de ingeniería contractual.
En este escenario, el escrow de código fuente (depósito en garantía de software) deja de ser una cláusula exótica de abogados anglosajones para convertirse en un mecanismo esencial para la continuidad del negocio y la soberanía tecnológica. En Colombia, no obstante, su implementación suele ser deficiente, confundiéndose con el registro de derechos de autor o limitándose a cláusulas muertas que, en el momento de la crisis, resultan inejecutables.
Este artículo desglosa la naturaleza operativa y jurídica del escrow de software en el ordenamiento colombiano, proponiendo una ruta para pasar de la teoría a la protección real de la infraestructura crítica.
1.- La ilusión del control: Qué es (y qué no es) un escrow
Para entender la necesidad del escrow, debemos superar la confusión habitual entre "comprar software" y "licenciar uso". En la gran mayoría de los contratos de modernización tecnológica estatal o corporativa, la entidad no compra la propiedad intelectual del software lo cual sería costosísimo e innecesario, sino que adquiere una licencia de uso.
Esto implica que el código fuente, las instrucciones legibles por humanos que permiten entender y modificar el programa, permanece bajo el control exclusivo del proveedor. Aquí nace el riesgo de Vendor Lock-in: la entidad depende totalmente del proveedor original para cualquier corrección, actualización o parche de seguridad. Si ese proveedor falla, el sistema muere.
El software escrow es el mecanismo para mitigar este riesgo. Según definiciones internacionales aceptadas, como las analizadas por la OCDE en el ámbito de la seguridad digital, es un acuerdo tripartito entre: (i) el licenciante (proveedor), dueño del software; (ii) el licenciatario (cliente/entidad), usuario del sistema; y (iii) el agente de escrow (tercero de confianza), custodio neutral.
El proveedor deposita el código fuente y la documentación técnica crítica en manos del agente de escrow. Este agente se obliga a custodiarlo y a no entregarlo al cliente a menos que ocurra una "condición de liberación" (release event) pactada previamente (ej., quiebra del proveedor).
Lo que NO es un Escrow
.- No es una cesión de derechos patrimoniales: el cliente no se convierte en dueño del código al firmar el contrato. Solo accede a él si ocurre el desastre y, usualmente, con una licencia restringida exclusivamente para el mantenimiento ("licencia de supervivencia").
.- No es el registro ante la DNDA: En Colombia, muchos abogados confunden el escrow con el Registro de Software ante la Dirección Nacional de Derecho de Autor. El registro ante la DNDA tiene fines probatorios de titularidad y de publicidad; no es un mecanismo operativo para entregar el código al cliente en caso de falla. La DNDA no actúa como un agente contractual de liberación rápida.
.- No es un backup: No se trata de guardar una copia del ejecutable (.exe), sino de los planos de construcción (código fuente, scripts de compilación, librerías, documentación, etc.).
2.- Depósito, fiducia y propiedad intelectual
Colombia no tiene una "Ley de escrow de software". Por tanto, la figura debe construirse a partir de las herramientas del derecho privado y del derecho administrativo existentes. La solidez del mecanismo depende de la figura jurídica que se elija para estructurarlo.
A. El contrato de depósito (Código Civil)
La base más elemental es el contrato de depósito regulado en el Código Civil (Art. 2236 y ss.). El proveedor (depositante) confía una cosa corporal o incorporal (el soporte magnético o las llaves de acceso al repositorio) a un tercero (depositario) para que la guarde y la restituya en especie a voluntad del depositante o cuando se cumplan las condiciones del contrato.
- Limitación: El depósito civil es precario para activos digitales complejos y no ofrece las garantías de un patrimonio autónomo en caso de que el agente de escrow mismo entre en problemas.
B. La fiducia mercantil y el encargo fiduciario
Esta es la estructura más robusta y realista en el ordenamiento jurídico colombiano. Bajo el Código de Comercio (Art. 1226) y la doctrina de la Superfinanciera, se puede constituir un patrimonio autónomo o un encargo fiduciario en el que el bien fideicomitido es el soporte del código fuente (o de las credenciales de acceso).
Ventaja: La fiduciaria actúa como un agente profesional, imparcial y regulado. Las instrucciones irrevocables garantizan que, si se demuestra el incumplimiento técnico o la insolvencia del proveedor, la fiduciaria otorgará a la entidad contratante el acceso al código sin que el proveedor pueda bloquearlo arbitrariamente.
Uso práctico: En fusiones y adquisiciones (M&A) en Colombia, el escrow es estándar para retener una parte del precio; la misma lógica aplica para retener el "know-how" crítico del software.
C. El escrow en la contratación estatal
La guía de adquisición de software de Colombia Compra Eficiente reconoce la tensión entre adquirir licencias (en las que no se entrega el código) y el desarrollo a la medida (en el que el Estado suele pedir la cesión de derechos).
El escrow se presenta como la vía media ideal para sistemas híbridos o modernizaciones. Un precedente técnico relevante se encuentra en los procesos de la DIAN, donde, en etapas de indagación de mercado (RFI), se ha contemplado explícitamente el "acuerdo de escrow" o "depósito en garantía" del código fuente como alternativa para mitigar riesgos en soluciones que involucran propiedad intelectual preexistente del proveedor.
Esto respeta la Decisión Andina 351 sobre derecho de autor: el proveedor mantiene su propiedad patrimonial (y puede seguir vendiendo su software a otros), pero la entidad pública asegura que, si el proveedor desaparece, el servicio público no se detendrá, ya que tendrá el derecho contractual de acceder al código para mantenerlo operativo.
3.- El checklist para un acuerdo funcional
Una cláusula que simplemente diga "el proveedor depositará el código" es letra muerta. El software moderno es casi un organismo vivo, complejo y dependiente de múltiples factores. Un acuerdo de escrow mal diseñado puede hacer que, al momento de la crisis, la entidad reciba un código obsoleto, encriptado o imposible de compilar.
Para que el escrow funcione, debe incluir estas condiciones técnicas y legales:
A. Alcance del depósito (El "Qué")
No basta con el código. El depósito debe incluir:
Código fuente completo (versión exacta en producción).
Scripts de compilación (Build scripts) y de despliegue.
Documentación técnica y manuales de arquitectura.
Lista de librerías de terceros y dependencias (Bill of materials).
Si se trata de infraestructura en la nube: los scripts de Infrastructure as Code (Terraform, Ansible, CloudFormation).
Advertencia: Nunca se deben depositar credenciales vivas (passwords) sin una política de rotación, ya que supone un riesgo de seguridad.
B. Verificación técnica (El "Test de Vida")
Este es el punto en el que falla el 90% de los escrows. Depositar un USB o un archivo ZIP cerrado no sirve.
Verificación de nivel 1: El agente verifica que los archivos no estén corruptos y sean legibles.
Verificación de nivel 2 (Compilación): Un tercero técnico toma el material depositado e intenta compilarlo y ejecutarlo en un ambiente limpio. Si el software no "corre" con lo depositado, el proveedor incumple. Esto debe hacerse anualmente o con cada actualización mayor (Release).
C. Los triggers de liberación (El "Cuándo")
Las condiciones deben ser objetivas y verificables para evitar litigios que paralicen la entrega:
Disolución, liquidación o admisión a procesos de insolvencia del proveedor.
Cesación de operaciones o abandono del soporte técnico durante más de “X días”.
Incumplimiento grave de Acuerdos de Nivel de Servicio (SLA) críticos no subsanados.
Fusión o adquisición del proveedor en la que el nuevo dueño descontinúa el producto.
D. Procedimiento de liberación (El "Cómo")
Notificación del beneficiario al agente de escrow.
Periodo de objeción corto para el proveedor (p. ej., 10 días) para demostrar que no ha ocurrido el incumplimiento.
Mecanismo de resolución expedita (p. ej., dictamen de perito técnico) ante una disputa, para no esperar años a un fallo en la jurisdicción ordinaria.
E. Licencia posliberación (El "Para Qué")
El contrato debe establecer que, al producirse la liberación, se otorga automáticamente a la entidad una licencia de uso y modificación del código fuente.
Alcance: estrictamente para fines de mantenimiento, corrección de errores y continuidad del negocio propio.
Restricción: Prohibición expresa de comercializar, vender o distribuir ese código a terceros (protegiendo el patrimonio del proveedor).
4.- Conclusión
El caso de las alertas en EMCALI sobre el control del software de acueducto es un aviso temprano de la nueva realidad de la gestión pública y corporativa. A medida que la infraestructura física (tubos, cables, edificios) depende de la infraestructura lógica (código, algoritmos, nubes), la propiedad de la máquina es irrelevante si no se tiene control sobre el "cerebro" que lo opera.
Implementar esquemas de escrow en Colombia no es un acto de desconfianza hacia el proveedor tecnológico, sino un estándar de madurez en la gestión de riesgos. Es el equivalente digital de tener un seguro de lucro cesante. Para las entidades públicas y las empresas de servicios esenciales, exigir estas cláusulas y, sobre todo, auditar su cumplimiento técnico es la única forma de garantizar que la modernización no se convierta en una trampa de dependencia. El software puede fallar, las empresas pueden quebrarse, pero el agua, la energía y la salud no pueden dejar de fluir. Ese riesgo se gobierna, antes que con código, con contratos inteligentes y previsivos.