La respuesta corta

El escrow de código fuente es un depósito en manos de un tercero: si tu proveedor desaparece, quiebra o incumple, un agente independiente te entrega el código.

Suena a red de seguridad. En desarrollo a medida, casi siempre es la red equivocada — y la buena es más barata: que el repositorio sea tuyo desde el primer commit.

Donde el escrow sí tiene sentido es en otro escenario: cuando licencias un producto de terceros que no puedes tener, y el fabricante no te va a dar su código pase lo que pase.

(Esto es criterio técnico y contractual desde el lado del comprador de software, no asesoramiento legal. La redacción final la valida un abogado.)

El problema del escrow: un depósito sin verificar no vale nada

El fallo clásico no es que el proveedor incumpla. Es que el depósito no sirve cuando se abre.

Un escrow que solo guarda un ZIP del código es un objeto decorativo. En el momento en que se activa, tu equipo se encuentra con:

  • Código que no compila porque faltan dependencias privadas.
  • Sin las variables de entorno ni la configuración necesarias.
  • Sin el proceso de firma ni las llaves — que casi nunca están en el depósito, y con razón.
  • Una versión desfasada, porque el depósito se actualizó una vez y nadie volvió a mirarlo.

Por eso la única forma útil de escrow es la verificada: el agente no solo custodia, sino que comprueba periódicamente que lo depositado compila y produce el artefacto esperado. Si el contrato no dice eso, lo que tienes es un archivo comprimido con valor emocional.

Qué debe contener el depósito

Si vas a hacerlo, que sirva:

  • Código fuente con histórico, no una foto fija.
  • Dependencias privadas o instrucciones reproducibles para obtenerlas.
  • Documentación de compilación validada por alguien que no la escribió.
  • Infraestructura como código y configuración de despliegue.
  • Esquema de base de datos y migraciones.
  • Inventario de servicios de terceros y qué cuentas hacen falta.
  • Nunca secretos en claro. Los secretos se rotan y se custodian en un gestor de secretos, no en un depósito notarial.

Y una cadencia de actualización escrita: por versión publicada, o mensual. Un depósito anual en un proyecto que publica cada dos semanas está desactualizado el 96 % del tiempo.

Los disparadores: la parte que se negocia de verdad

El contrato tiene que decir exactamente qué activa la entrega. Los habituales:

  • Concurso de acreedores o disolución del proveedor.
  • Cese del mantenimiento pactado durante un plazo determinado.
  • Incumplimiento grave no subsanado tras requerimiento.
  • Cambio de control del proveedor, si te preocupa que lo compre un competidor.

Y hay que fijar el procedimiento: quién notifica, qué plazo de subsanación hay, quién arbitra si las partes discrepan y en cuánto tiempo entrega el agente. Un disparador sin procedimiento es una cláusula que se resuelve en un juzgado, que es justo lo que querías evitar.

La alternativa que casi siempre es mejor

En un desarrollo a medida, el escrow resuelve un problema que no deberías tener. La alternativa:

  • El repositorio está en la organización del cliente desde el primer commit. El proveedor trabaja dentro, no fuera.
  • Las cuentas de desarrollador son del cliente, con el proveedor invitado. El porqué, con el detalle de lo que se rompe si no es así, está en quién debe custodiar los certificados de firma.
  • Los secretos viven en el gestor de secretos del cliente.
  • La compilación reproducible es un entregable, verificada al menos una vez por alguien ajeno al proyecto.

Con eso tienes, cada día, lo que el escrow te prometía para el día malo. Y cuesta cero, porque es cómo debería estar montado igualmente.

Dicho de otra forma: si necesitas un escrow para dormir tranquilo en un proyecto a medida, el problema no es la falta de escrow. Es que el proyecto está montado con las llaves en la casa de otro. Eso se arregla con el checklist de traspaso, no con un depósito.

Cuándo el escrow sí es la herramienta correcta

  • Licencias de software de terceros que no vas a poder tener de otra forma: un motor, un SDK propietario, una plataforma sobre la que construyes.
  • Componentes críticos con un único proveedor en el mundo, donde no hay alternativa si desaparece.
  • Requisito regulatorio o de cliente final que exige demostrar continuidad, típico en sector público y en grandes corporaciones.

En esos tres casos el proveedor no te va a dar el código, y con razón: es su producto. El escrow es el equilibrio entre su propiedad intelectual y tu continuidad.

Qué pedir en el contrato

Cuatro puntos, y ninguno es agresivo:

  1. Depósito verificado, con comprobación de compilación por el agente y periodicidad escrita.
  2. Alcance del depósito enumerado: código, histórico, dependencias, documentación, infraestructura. Sin secretos.
  3. Disparadores y procedimiento con plazos y árbitro.
  4. Derecho de uso posterior: qué puedes hacer con el código cuando te lo entreguen. Un depósito que entregas y que no puedes modificar ni desplegar legalmente no sirve de nada.

Ese cuarto punto es el que más se olvida y el que decide si la cláusula vale o no vale.

Lo que hacemos nosotros

Trabajamos con el repositorio y las cuentas del cliente desde el primer día, y el traspaso a otro equipo forma parte del alcance del proyecto, no es un extra que se negocia al final. Es la razón por la que la conversación de escrow rara vez llega a hacer falta.

Si lo que tienes delante es un pliego o un contrato ajeno y quieres saber si esas cláusulas te protegen de verdad, es parte de lo que revisamos como CTO as a Service.