Control de versiones en un data room: reemplazar archivos sin perder el rastro

Un martes de junio, en Bogotá, una asistente legal de Cordillera Asesores subió un nuevo contrato marco de cliente al data room de Frigoríficos del Valle.

El cambio parecía menor. El contrato renegociado bajaba el tope de responsabilidad frente a su mayor cliente, una cadena de supermercados, y eso era una buena noticia para cualquier comprador. Arrastró el archivo a la carpeta, la sala le preguntó si era un documento nuevo o una nueva versión de uno existente, y ella eligió lo segundo.

Tres semanas después, ese clic pesó más que cualquier otra cosa que hizo en la operación.

Fondo Andes Sur, un fondo de Santiago y uno de los cuatro postores, presentó una oferta revisada con un descuento. Su modelo, dijeron, partía del tope anterior, más alto, porque ese era el contrato que estaba en la sala. Cordillera no estaba de acuerdo. Alguien tenía razón, y la respuesta estaba en el historial de versiones.

Volveremos a Frigoríficos del Valle a lo largo de la guía, porque el caso muestra casi todas las piezas del control de versiones: el reemplazo, el registro que deja, el aviso que debería acompañarlo y la exportación que zanja la discusión.

Qué es el control de versiones en un data room

El control de versiones es la función que sigue cada iteración de un documento bajo una identidad estable, de modo que un borrador nuevo reemplaza la copia vigente mientras los anteriores quedan guardados, atribuidos y auditables.

Tiene tres piezas. Una identidad estable: el documento conserva su número de índice, su lugar en el árbol de carpetas y sus permisos cuando llega una versión nueva. Un historial guardado: las versiones previas no se sobrescriben ni se pierden. Y atribución: cada versión dice quién la subió, cuándo y, idealmente, por qué.

La entrada del glosario sobre versionado de documentos explica el término en abstracto. En la práctica, lo que separa a una sala seria de una carpeta compartida no es que guarde copias viejas; muchas nubes lo hacen. Es que vincule cada versión al registro de auditoría, para que la pregunta “quién vio qué” se convierta en “quién vio qué versión de qué”.

Esa diferencia es toda la disputa de Frigoríficos del Valle en una frase.

Las piezas de un documento versionado

Si desarmas un documento dentro de la sala, aparece más estructura de la que sugiere su nombre.

Arriba está la identidad: un número de índice como 4.2.7, una posición fija en las carpetas y un enlace al que apuntan los revisores y los hilos de preguntas. Esta parte nunca debe cambiar cuando llega un borrador nuevo, porque todo lo demás cuelga de ella.

Debajo está la versión vigente, la que un revisor abre por defecto. Detrás, la pila de versiones anteriores, cada una tal como estaba el día en que fue reemplazada.

Cada versión lleva sus propios metadatos: nombre de quien la subió, hora en UTC, una nota de cambio si alguien se tomó el trabajo de escribirla, y un registro de vistas propio que anota quién abrió ese borrador concreto.

Junto a eso hay dos piezas más. Los permisos se heredan del documento, así que un reemplazo no puede ampliar el acceso por la puerta de atrás. Y un registro de avisos muestra a qué grupos se les informó de la nueva versión.

La pieza que más a menudo queda vacía es la nota de cambio. Con prisa, nadie la escribe, y meses después es imposible distinguir una corrección de una errata de un precio renegociado sin abrir los dos archivos lado a lado.

Reemplazar, borrar o duplicar: qué deja cada acción

Hay tres maneras de meter un borrador nuevo en la sala, y cada una deja un rastro muy distinto. La mayoría de las disputas sobre versiones nacen de elegir la equivocada con el reloj en contra.

Acción	Identidad y enlace	Versión anterior	Historial de auditoría	Permisos	Aviso a revisores
Reemplazar como nueva versión	Se conservan	Guardada en el historial	Continuo, un registro por versión	Heredados sin cambios	Se puede enviar a los grupos afectados
Borrar y subir de nuevo	Se pierden: índice y enlace nuevos	Eliminada o en la papelera	Partido en dos documentos sin relación	Hay que configurarlos otra vez	El revisor ve un archivo “nuevo”, no un cambio
Subir al lado como segundo archivo	Dos documentos con nombres parecidos	Sigue visible y vigente	Dos historiales paralelos	Se definen por separado	Confuso: ambos parecen actuales

La primera fila es la que quieres casi siempre. La segunda es el error más común y el que más duele en una disputa, porque el vínculo entre el borrador viejo y el nuevo queda solo en la memoria de alguien.

Por qué el reemplazo silencioso es el verdadero riesgo

Un archivo que cambia sin que nadie lo note es peor que uno que nunca cambia.

Imagina la otra versión de la historia. La asistente borra el contrato anterior y sube el nuevo con el mismo nombre. Para un revisor, nada parece distinto. El analista de Andes Sur, que descargó una copia con marca de agua de la versión uno en la segunda semana, no tiene motivo para volver a mirar.

Cuando llega el descuento, Cordillera puede mostrar que el contrato nuevo estaba en la sala. Lo que no puede mostrar con facilidad es cuándo reemplazó al viejo, si se avisó a Andes Sur o si alguien del fondo lo abrió. La discusión se convierte en una negociación sobre recuerdos.

Por eso a los abogados de M&A les importan las versiones. En una disputa casi nunca se pregunta si el documento fue revelado, sino qué versión, a quién y cuándo. Nuestra guía sobre lo que registra la auditoría de un data room explica por qué un log que no responde a esa segunda pregunta vale mucho menos.

Hay un costo más silencioso. Cuando los revisores sienten que los archivos cambian sin aviso, empiezan a descargarlo todo para guardar sus propias copias. Eso anula el sentido del acceso de solo lectura y multiplica las copias sin control.

Cómo manejan las versiones los distintos proveedores

“Control de versiones” suena a casilla marcada. No lo es. La profundidad varía mucho, y a menudo varía por plan además de por proveedor.

Algunos datos concretos de nuestras reseñas. CapLinked incluye versionado junto a permisos por grupo y por carpeta, marcas de agua dinámicas y acceso con fecha de vencimiento; lo verás en la reseña de CapLinked. DocSend permite actualizar un documento ya enviado sin romper el enlace original, útil para un pitch deck que cambia en plena ronda, aunque no está pensado para una due diligence estructurada; la reseña de DocSend marca ese límite.

Las salas modernas y completas, como Ellty junto a iDeals y Datasite, combinan auditoría completa con permisos granulares, marca de agua y preguntas y respuestas. Sea cual sea el producto, las preguntas son las mismas: cuánto tiempo se guardan las versiones, si el registro es por versión y si el historial llega al archivo final. Si estás armando una lista corta, compara proveedores lado a lado en esos puntos y no en la palabra “versionado”.

Cómo reemplazar un archivo sin perder el rastro

Esta es la rutina que siguió Cordillera con el contrato de Frigoríficos del Valle. Lleva unos diez minutos por documento relevante, casi todos dedicados a la nota y al aviso.

Cómo reemplazar un documento en un data room sin romper su historial

Una rutina repetible para subir un borrador nuevo sobre un documento vigente durante la due diligence.

Estimated time: 15min

1. 1

   Ubica el documento, no solo la carpeta

   Abre el documento vigente por su número de índice y usa la acción de reemplazar o subir nueva versión sobre ese documento. Soltar el archivo en la carpeta suele crear un documento aparte.

2. 2

   Revisa el archivo antes de publicarlo

   Confirma que es el borrador final, que las tachaduras están aplicadas y que el nombre sigue tu convención de índice. El reemplazo es visible en cuanto llega.

3. 3

   Escribe una nota de cambio de una línea

   Di qué cambió en palabras simples, por ejemplo tope de responsabilidad reducido según adenda del 2 de junio. Esa línea la leerás tú en el futuro, y quizá el abogado de la otra parte.

4. 4

   Decide quién ve las versiones previas

   Elige si los revisores pueden abrir borradores anteriores o solo el vigente. El historial completo debe quedar visible para los administradores en cualquier caso.

5. 5

   Avisa a los grupos afectados

   Envía un aviso neutral a cada grupo con acceso al documento. Si el cambio es relevante, añade una entrada equivalente en el módulo de preguntas o en el registro de revelaciones.

6. 6

   Verifica el registro

   Abre el historial y confirma que la nueva versión muestra tu nombre, la hora UTC y la nota, y que los permisos no cambiaron.

El quinto paso es el que los equipos se saltan. Y fue el que decidió el caso.

Cuando la asistente subió el contrato nuevo, la sala envió un aviso a los cuatro grupos de postores: “Contrato marco 4.2.7 actualizado; ver nota de versión”. El analista principal de Andes Sur abrió la versión dos a la mañana siguiente, a las 08:14 UTC, y pasó varios minutos en el anexo de responsabilidad. El registro lo mostraba.

¿Deberían los postores ver las versiones anteriores?

Es una decisión de criterio, y asesores sensatos no siempre coinciden.

Una vía intermedia es habitual: los administradores siempre ven todo el historial, los revisores ven la versión vigente por defecto, y las versiones previas se liberan solo donde el cambio en sí importa, con una nota breve que explique la diferencia.

El tema de los datos personales merece atención especial. Si una versión posterior tacha datos de empleados o clientes y la anterior sigue abierta, la tachadura no sirve de nada. En Colombia, la Ley 1581 de 2012 exige proteger los datos personales que tratas; en Brasil rige la LGPD; en España, el RGPD. En cualquiera de esos marcos, dejar abierta una versión sin tachar no es un detalle técnico. Nuestra guía sobre RGPD y data rooms virtuales amplía las obligaciones.

Versiones, preguntas y respuestas y el registro de revelaciones

El control de versiones no vive aislado. En una operación activa toca al menos otras dos partes de la sala.

La primera es el módulo de preguntas. Cuando un comprador pregunta por una cláusula y el vendedor responde subiendo un documento corregido, la respuesta debe citar la versión. “Ver 4.2.7, versión 2, cargada el 9 de junio” sobrevive a una disputa; “ver contrato actualizado” no. Nuestra guía para gestionar las preguntas y respuestas de un data room muestra cómo enlazar respuestas y documentos.

La segunda es la carta de revelaciones. En muchos contratos de compraventa, el contenido de la sala se incorpora por referencia, a menudo adjuntando un índice o una copia de la sala a una fecha de corte. Si las versiones cambian al final, el índice tiene que decir cuál cuenta. Acuérdalo pronto con los abogados: ¿lo revelado es la sala a una fecha de corte o todas las versiones que alguna vez se subieron?

Esa pregunta parece técnica. En realidad decide quién asume el riesgo cuando un documento cambia en la última semana.

Qué probar durante una prueba gratuita

Las páginas comerciales dirán “control de versiones”. Una prueba breve con un documento ficticio te dice qué significa en ese producto concreto.

• Reemplaza desde el documento y luego desde la carpeta. ¿Soltar un archivo con el mismo nombre crea una versión o un duplicado?
• Busca el campo de nota de cambio. ¿Existe, lo ven los revisores, aparece en las exportaciones?
• Abre ambas versiones como revisor de prueba. Luego revisa la auditoría: ¿registra qué versión se abrió o solo el documento?
• Activa y desactiva la visibilidad de versiones previas. ¿Se configura por documento o solo para toda la sala?
• Dispara un aviso. ¿Puedes elegir los grupos y editar el texto?
• Exporta el archivo de cierre. ¿Incluye las versiones previas y sus registros, o solo los archivos vigentes?
• Pregunta por el almacenamiento. ¿Las versiones previas cuentan contra el límite de páginas o de espacio? Lo tratamos en la guía sobre los costos ocultos de un data room y en la de límites de almacenamiento.

Si las respuestas son vagas, esa es la respuesta.

Lo que el historial de versiones no puede hacer

El versionado es una prueba sólida sobre lo que pasó dentro de la sala. Dice mucho menos sobre lo que pasa fuera.

No actualiza las copias que ya salieron. El archivo que el analista de Andes Sur descargó en la segunda semana quedó congelado en su portátil. La sala registra la descarga y la marca de agua, pero no puede cambiar ese archivo por el nuevo.

No explica el cambio por sí solo. Sin nota ni vista comparativa, “v2 cargada” obliga a buscar la diferencia en cuarenta páginas.

No prueba que alguien entendió. Un registro que muestra seis minutos sobre la versión dos es prueba de acceso, no de comprensión. Por eso el texto del aviso y la entrada en preguntas y respuestas importan tanto como el reemplazo.

Y depende de que la gente lo use. Un asociado que suelta un archivo en una carpeta a medianoche crea un duplicado aunque la sala tenga el mejor motor de versiones del mercado. Una capacitación corta al inicio y un responsable nombrado para los reemplazos evitan la mayoría de esos tropiezos. Si migras de sala a mitad del proceso, exporta el historial completo antes de cerrar la vieja; la guía sobre cómo migrar a un nuevo data room detalla el orden, y la de buenas prácticas de índice explica por qué conviene no poner “v3 FINAL” en el nombre del archivo.

Cómo terminó la disputa de Frigoríficos del Valle

Volvamos al descuento de Andes Sur.

Cordillera exportó el historial del documento 4.2.7. Mostraba la versión uno cargada el 19 de mayo y la versión dos el 9 de junio a las 16:05 UTC, con la nota “tope de responsabilidad reducido según adenda del 2 de junio”. Mostraba el aviso enviado esa tarde a los cuatro grupos. Y mostraba al analista principal del fondo abriendo la versión dos a las 08:14 UTC del día siguiente.

La exportación llegó a los abogados del fondo con una nota breve.

El descuento por el tope de responsabilidad se retiró en una semana. La operación se firmó en plazo, con otros puntos aún por negociar, como en toda operación.

Lo decisivo no fue solo el software. Fue un clic correcto al subir, una línea de nota y un aviso a los grupos adecuados. El control de versiones es una función; usarlo con constancia es un proceso. Necesitas las dos cosas.

Preguntas frecuentes

¿Qué es el control de versiones en un data room virtual?

Es la función que mantiene cada iteración de un documento bajo una identidad estable. Al subir un borrador nuevo, la sala lo convierte en la versión vigente, guarda las anteriores y registra quién subió cada una y cuándo. En las salas pensadas para operaciones, la auditoría también anota qué versión abrió cada revisor.

¿Puedo borrar un archivo y subir uno nuevo en su lugar?

Técnicamente sí, pero durante una due diligence es mala práctica. Borrar y volver a subir crea un documento con otro enlace y otro historial, y se pierde la conexión entre el borrador viejo y el nuevo. Usa la acción de reemplazar o nueva versión sobre el documento existente.

¿Se avisa a los postores cuando se reemplaza un documento?

Solo si la sala está configurada para hacerlo, y las salas capaces te dejan elegir qué grupos reciben el aviso y con qué texto. Para cambios relevantes, acompaña el aviso con una entrada en preguntas y respuestas para que quede un segundo registro.

¿Los revisores pueden ver versiones anteriores?

Depende del proveedor y de tu configuración. Muchas salas permiten que el administrador decida si los revisores abren versiones previas, para toda la sala o por documento. Lo habitual es mostrar solo la versión vigente y liberar el historial donde el cambio importa.

¿Las versiones viejas cuentan para el límite de almacenamiento?

A menudo sí, porque son archivos guardados. En planes por página o con tope de espacio, reemplazar varias veces documentos grandes puede subir el consumo. Pregunta cómo se cuenta el historial y confirma los límites en USD antes de firmar.