Necesitas preparar el cumplimiento normativo para un proceso de due diligence tecnológica

¿Tienes razón?

No se trata de tener la respuesta legal perfecta, sino de controlar tres grandes vectores que los compradores inspeccionan: la gestión de datos personales, los derechos sobre el software y las dependencias externas, y la postura de seguridad operativa. Si puedes demostrar que los datos se recogen con base legal legítima, que los desarrollos están correctamente licenciados o transferibles, y que hay controles razonables de seguridad —y que todo eso está documentado— tu posición ante la due diligence es favorable. Si falta cualquiera de estas piezas, el comprador reduce precio o exige remediaciones. La calidad de tus evidencias suele importar más que la perfección técnica: exportar registros y contratos claros resuelve muchas dudas.

Cómo se soluciona

1. Mapear activos y responsabilidades.

• Haz un inventario de sistemas, repositorios de código, bases de datos y proveedores en la nube. Para cada activo identifica al responsable y copia la documentación técnica básica (diagramas, credenciales de acceso con control, políticas internas).

1. Reunir la documentación contractual.

• Localiza contratos con clientes, desarrolladores externos, proveedores de hosting, plataformas y contratos de licencia de terceros. Exporta versiones firmadas y los anexos donde se regulan la propiedad intelectual y la confidencialidad.

1. Protocolizar el tratamiento de datos.

• Enumera categorías de datos personales que almacenas, finalidades y transferencias. Prepara evidencias de consentimiento o de bases legales aplicadas, y las políticas y avisos que publicas. Exporta registros de acceso y de entregas solicitadas por titulares.

1. Evaluar la seguridad y sus evidencias.

• Reúne informes de pruebas de penetración, auditorías, registros de incidentes y las medidas tomadas. Si no tienes auditorías, prepara evidencias de configuración segura y de parcheo.

1. Preparar paquetes exportables.

• Crea un dossier con índices, resúmenes ejecutivos y archivos que se puedan compartir bajo NDA: listados, contratos, capturas de registros, informes técnicos, y un documento que explique la arquitectura y los riesgos conocidos.

1. Redactar un memorandum de remediaciones.

• Señala las carencias y las acciones en curso. Los compradores admiten plan de trabajo si es claro, con responsables y coste estimado.

Qué puedes hacer hoy sin abogado: compilar el inventario, exportar contratos y registros, y generar la descripción técnica. Cuándo llamar a un licenciado: cuando haya incertidumbre sobre la titularidad del código, transferencia de licencias, o exposición de datos sensibles, o cuando el comprador proponga cláusulas contractuales complejas.

Qué puede pasar

1. Se arregla con una carta o aclaración documental.

• Si las dudas son menores (falta de un contrato menor, una cláusula de licencia), un paquete organizado y una carta explicativa suelen bastar. El comprador ajusta condiciones y sigue con la operación.

1. Acuerdo o cláusulas de cierre negociadas.

• Es común que el comprador pida indemnizaciones limitadas, escrows de código, o fondos en garantía hasta que se subsanen hallazgos. Un acuerdo así supone menos coste que una renegociación total y evita litigio.

1. Renegociación o salida del trato y posible procedimiento.

• Si hay riesgos graves (uso indebido de datos, software con licencias que impiden transferencia), el comprador puede retirar su oferta o exigir soluciones costosas. Si se llega a disputa, la resolución puede exigir arbitraje o juicio; y si se obtiene una resolución favorable, cobrar depende de la solvencia de la contraparte y de las garantías pactadas.

Una pregunta habitual: «y si gano, ¿cobro?» Una sentencia a tu favor o una cláusula de indemnización no garantiza el cobro si la contraparte es insolvente; por eso los escrows y garantías son herramientas comunes en las operaciones.

Errores que arruinan el caso

• Entregar documentación incompleta o contradictoria: versiones de contrato distintas sin control de cambios generan desconfianza.
• No exportar registros técnicos: dejar que la única evidencia quede en manos de un empleado incrementa riesgo si ese empleado sale.
• Ignorar licencias de terceros: dependencias con licencias restrictivas pueden bloquear la operación.
• Ocultar incidentes de seguridad: un incidente conocido y no documentado suele terminar en ruptura del trato.
• No usar acuerdos de confidencialidad antes de compartir paquetes: perder control sobre la información sensible complica remedios.